Proprietatea unui nume de gazdă, fără certificat

Orice produs care lasă un client să tasteze un nume de gazdă și apoi îl verifică în fiecare minut a construit două lucruri. Primul este monitorizarea. Al doilea este un generator distribuit de cereri, îndreptat oriunde îi place clientului, cu numele firmei dumneavoastră în user agent și cu adresa de facturare a clientului dumneavoastră în spate.

Obiecția obișnuită este că ținta are o adresă publică, deci oricine i-ar putea trimite trafic oricum. Este adevărat și nu despre asta e vorba. O adresă publică nu este o permisiune de a măsura pe cineva, iar „oricine ar putea” nu este o apărare care supraviețuiește primei reclamații de abuz, mai ales când traficul este periodic, susținut și provine de la o platformă comercială identificabilă.

Așadar, o țintă de tip nume de gazdă trebuie câștigată. Aceasta este proiectarea pe care am ales-o, inclusiv părțile mai puțin evidente decât par.

Două metode care dovedesc lucruri diferite

Există două feluri practice în care cineva poate demonstra că un nume îi aparține și merită să fie limpede că ele nu sunt echivalente.

O înregistrare TXT în DNS dovedește controlul asupra zonei. Cine poate pune acolo o valoare decide unde indică numele, ceea ce este cea mai tare afirmație despre un nume care există.

Un fișier pe serverul web dovedește controlul asupra mașinii către care se rezolvă numele în acel moment. Aceasta este mai slabă: pe găzduire partajată, mai mulți oameni îl pot produce decât cei care pot edita zona. Este și mult mai la îndemână pentru un client care are un server, dar nu are acces la furnizorul de DNS al angajatorului său.

Aceasta este aceeași pereche de compromisuri pe care o fac autoritățile de certificare cu cele două tipuri obișnuite de challenge, iar concluzia care urmează este aceeași: oferiți-le pe amândouă, consemnați care a fost folosit și nu pretindeți că au greutate egală.

Forma challenge-ului

Înregistrarea TXT stă sub o etichetă proprie, nu pe domeniul însuși. Aceasta nu este chestiune de ordine. O înregistrare pe apexul zonei ajunge lângă înregistrările de politică de mail ale clientului, unde fiecare șir suplimentar împinge răspunsul mai aproape de dimensiunea la care rezolvatoarele încep să aibă o zi proastă și unde curățenia făcută de altcineva la „înregistrările TXT vechi” o înlătură fără nicio rea-voință. Sub o etichetă proprie stă singură.

Fișierul trăiește sub o cale rezervată, cu jetonul drept nume de fișier, iar fișierul conține jetonul și nimic altceva.

Jetonul însuși are treizeci și doi de caractere hexazecimale, adică o sută douăzeci și opt de biți. Nu este un secret și nu este o cheie: urmează să stea în DNS public sau pe un server web public. Ce trebuie el să fie este imposibil de ghicit, pentru că oricine poate prezice un jeton valid poate revendica un nume care nu îi aparține, punându-l mai întâi pe propriul lui server. Hexazecimalul cu litere mici îl păstrează sigur pentru o înregistrare DNS, sigur într-un URL și lipsit de caractere care pot fi citite greșit când un client îl copiază de mână.

O regulă structurală: exact o bucată de cod scrie challenge-ul, iar rezultatul călătorește odată cu cererea către cine face verificarea. Dacă ambele părți ar cunoaște prefixul independent, ar veni în cele din urmă o zi în care panoul afișează o etichetă și verificatorul caută alta, iar mesajul rezultat este „înregistrarea nu este acolo” despre o înregistrare care este acolo. Nimic nu costă mai mult la asistență decât un răspuns corect la o întrebare pe care nu a pus-o nimeni.

De ce agentul face aducerea

Aceasta este decizia de care atârnă restul.

Platforma nu rezolvă numele și nu aduce fișierul. Dacă ar face-o, propria noastră infrastructură ar face conexiuni către un nume tastat de un utilizator, ceea ce este falsificare de cereri de partea serverului, cu un câmp de formular drept suprafață de atac. Rezultatul clasic este o cerere către un endpoint de metadate din cloud, din interiorul propriei noastre rețele, făcută de noi, la cerere.

În schimb, o face agentul propriu al clientului: același agent care va rula verificările ulterior, aflat în rețeaua proprie a clientului și conectându-se numai spre exterior. A minți despre rezultat nu aduce nimic, pentru că răsplata este permisiunea de a măsura ceva la care agentul putea ajunge oricum. Verificarea este făcută de partea care are deja accesul, care este singurul aranjament în care stimulentul de a trișa dispare.

Există o consecință care merită spusă cu voce tare, pentru că arată ca o protecție lipsă. Îndrumările pentru acest fel de funcție spun de obicei să blocați intervalele private, loopback, link-local și adresele de metadate. Acea regulă aparține sondelor găzduite, adică punctelor de măsurare pe care le operăm noi și care stau în rețeaua noastră. Pentru un agent aflat în rețeaua proprie a clientului, adresele private sunt cazul normal: hipervizorul lui, comutatorul lui, stocarea lui. Blocarea lor ar dezactiva singura sursă de măsurare exact pentru situația pe care el există ca să o servească.

Ce împart ambele trasee este o singură funcție care decide ce adrese sunt permise. Dacă verificarea și măsurarea ar avea fiecare propria listă, ar veni o zi în care ele nu ar fi de acord, iar în acea zi una dintre ele este un ocol pe lângă cealaltă.

Eșec închis la răspunsuri amestecate

Un nume se poate rezolva către mai multe adrese, iar ele nu trebuie să fie la fel de acceptabile.

Dacă un nume răspunde și cu adresa publică a clientului, și cu un endpoint de metadate, atunci fiecare execuție este o nouă tragere la sorți. Nouă rulări măsoară adresa publică, iar a zecea vorbește cu altceva cu totul. Așadar, numărul răspunsurilor acceptabile nu poartă absolut nicio informație: o singură adresă interzisă din mulțime face tot numele inutilizabil, iar clientului i se spune care adresă a fost, pentru că un refuz în privința căruia nu poate acționa este doar un mesaj de eroare.

Același lucru este valabil în timpul verificării și în timpul verificărilor obișnuite, ceea ce este din nou motivul pentru care există o singură politică de adrese, nu două.

Detalii pe care le afli numai rulându-l

Trei dintre acestea au ieșit din construirea verificatorului; a patra este o decizie de proiectare care le stă alături.

Comparați cu „conține”, nu cu egalitate. Un furnizor de DNS are voie să prezinte o valoare TXT cu ghilimele în jur, iar unele panouri de control adaugă ghilimele pe care apoi le taie la loc în propria lor afișare. Jetonul este lung și opac: ori este acolo, ori nu, iar cererea unei potriviri exacte îi pedepsește doar pe clienții care au făcut totul corect.

Trimiteți numele în antetul de gazdă și în numele de server TLS. Conexiunea merge către o adresă care a trecut deja de verificarea politicii, dar unui server web cu mai multe site-uri trebuie să i se spună despre care dintre ele se întreabă. Fără amândouă, un client configurat corect pică verificarea, pentru că i s-a servit site-ul implicit al altcuiva.

Permiteți exact o redirecționare. Un server web care împinge totul către HTTPS este normal, iar refuzarea redirecționării ar pica jumătate din internet. Permiterea mai multora ar lăsa dovada să ajungă cu totul în altă parte. Un singur salt, și numai către aceeași gazdă.

Nu cereți HTTPS pentru challenge-ul cu fișier. Dovada este jetonul. Un certificat nu îi adaugă nimic, iar cererea unuia transformă o verificare de proprietate într-o verificare de certificat, care este altă întrebare, cu alte moduri de eșec. Acesta este același raționament care stă în spatele tipului de challenge peste HTTP simplu din emiterea de certificate. Rețineți că această valoare implicită este specifică verificării: când schema este tocmai lucrul măsurat, ghicirea ei ar produce o măsurătoare verde a altceva decât ce a configurat clientul, iar acolo comportamentul corect este refuzul.

Dovada expiră, pentru că domeniile își schimbă stăpânul

Un nume verificat nu trebuie să rămână verificat pentru totdeauna, iar motivul nu este paranoia față de propriile noastre înregistrări.

Domeniile își schimbă proprietarul fără să spună nimănui. Un client lasă o înregistrare să expire, o ia altcineva, iar din acel moment măsurăm în fiecare minut mașina unui străin, cu numele clientului nostru atașat programării. Nimeni din acel lanț nu a făcut ceva greșit, iar rezultatul este tot inacceptabil.

Nouăzeci de zile este valabilitatea pe care am ales-o, care este de același ordin ca un certificat de scurtă durată și din același motiv: destul de scurtă încât un transfer să fie observat repede, destul de lungă încât clienții să nu facă hârtii în fiecare săptămână. Reverificarea începe cu paisprezece zile înainte de expirare, ceea ce este generos în mod deliberat, pentru că o reverificare eșuată înseamnă de obicei că agentul era deconectat sau că un rezolvator a fost lent, nu că s-a schimbat proprietatea.

Încercările sunt limitate la una la fiecare șase ore, nelegate de intervalul de monitorizare. O verificare nu este o măsurătoare: nu spune nimic despre disponibilitate, nu își are locul într-o cifră de uptime, iar întrebarea mai deasă nu generează decât trafic către DNS-ul clientului. Șase ore de-a lungul a paisprezece zile înseamnă mai mult de cincizeci de încercări, ceea ce transformă „expirat” într-un semnal real, în loc de ghinion.

Stările care ies din asta sunt în așteptare, verificat, expiră curând, expirat și revocat, iar una dintre ele nu este o poartă. „Expiră curând” există ca să poată avertiza interfața pe cineva; o dovadă care se stinge peste zece zile este valabilă astăzi, iar verificările continuă să ruleze. Tratarea ei ca stare-poartă separată i-ar lua unui client monitorizarea într-o zi în care nu s-a schimbat nimic.

Baza de date impune perechea, în loc să se încreadă în cod: un rând ori are și un moment de verificare, și un moment de expirare, ori nu are niciunul dintre ele. Un rând verificat fără expirare este o permisiune permanentă pe care nu a ales-o nimeni, adică tocmai lucrul pe care toată această proiectare există ca să îl împiedice.

Ce am scrie

1. 01Hotărâți ce dovedește challenge-ul, controlul zonei sau controlul mașinii, și stocați care dintre ele a fost folosit.
2. 02Puneți challenge-ul sub o etichetă proprie, niciodată pe apex, lângă înregistrările de mail ale cuiva.
3. 03Faceți din verificator partea care are deja accesul. Dacă platforma dumneavoastră aduce un nume furnizat de utilizator, ați construit o funcție de falsificare de cereri.
4. 04O singură politică de adrese pentru verificare și măsurare. Două liste devin două comportamente.
5. 05Eșuați închis la răspunsuri amestecate și numiți în refuz adresa vinovată.
6. 06Dați dovezii o expirare și începeți reînnoirea cu mult înainte de ea, pentru că eșecul de care vă păziți este tăcut prin natura lui.

Ca să fie limpede în privința propriei noastre stări: aceasta este o proiectare care există în cod, cu teste proprii, monitorizarea nu este ceva ce puteți cumpăra astăzi de la noi, iar nimic din cele de mai sus nu trebuie citit ca un anunț de produs. Este forma pe care am construi-o din nou.

Din munca de monitorizare de la Provibr. Întrebarea înrudită despre măsurarea fără atingere și despre câți octeți are voie să trimită o verificare se află în de ce un scaner trebuie să trimită zero octeți; felul în care un agent hotărăște pe care dintre mai multe puncte de măsurare să îl folosească se află în cum alege un agent serverul de margine potrivit.