Cum citiți un schimb IKE_SA_INIT nou într-o captură
O negociere IKEv2 nouă poate fi citită înainte de a exista chei. Înregistrați încercarea, citiți antetul, potriviți răspunsul și deosebiți IKE de ESP pe portul 4500.
Începeți cu o captură care începe înainte de primul pachet al încercării, altfel veți citi mijlocul unei conversații. O negociere deja în curs arată schimburi criptate și reînnoiri de chei, și niciuna nu seamănă cu deschiderea. Deschiderea este partea pe care o puteți decoda fără chei, și de aceea răspunde atât de bine la întrebările despre accesibilitate. Patru verificări în ordine vă duc de la o captură proaspătă la o afirmație defendabilă despre care parte a încetat să vorbească.
Mai întâi, confirmați că captura începe de la început
O captură pornită după ridicarea tunelului va conține fluxul de date încapsulat și keepalive periodice, iar ambele sunt fie criptate, fie aproape goale. Reporniți clientul și înregistrați încercarea în sine, sau provocați deliberat o conexiune nouă în timp ce captura rulează. Dacă nu puteți produce o încercare proaspătă, notați asta, pentru că nicio decodare nu recuperează o deschidere pe care nu ați înregistrat-o niciodată.
Limitați captura la cele două capete și la UDP 500 și 4500, astfel încât fișierul să rămână suficient de mic pentru citire. Pe o gazdă aglomerată, o captură nefiltrată îngroapă negocierea sub trafic fără legătură.
tcpdump -i any -n -s 0 -w fresh-ike.pcap 'udp port 500 or udp port 4500'Păstrați fișierul când încercarea este interesantă, pentru că aceeași captură răspunde la ambele întrebări următoare: care a fost schimbul și dacă s-a întors ceva. Etichetați-l cu ora de început și cu perechea de capete pe care ați filtrat. O captură fără aceste două fapte este inutilă o săptămână mai târziu, când adresele s-au schimbat și nimeni nu își amintește ce încercare a înregistrat.
În al doilea rând, citiți antetul înaintea încărcăturilor
Antetul IKE poartă indicii parametrilor de securitate, tipul schimbului și ID-ul mesajului, iar într-o negociere nouă aceste valori sunt distinctive. Inițiatorul inventează un SPI diferit de zero, cererea inițială poartă un SPI de răspunzător zero pentru că nu s-a văzut încă niciun răspuns, tipul schimbului este IKE_SA_INIT, iar ID-ul mesajului este zero. Orice altceva aparține unei etape ulterioare a aceleiași negocieri sau unei încercări complet diferite.
Încărcăturile de propunere, schimb de chei și nonce din acest prim schimb sunt lizibile în clar. Lizibil nu înseamnă autentificat, iar în acest punct niciuna dintre părți nu și-a dovedit identitatea.
Valoarea privată Diffie-Hellman nu traversează niciodată firul, așa că captura nu vă permite să derivați chei de sesiune. Autentificarea are loc în schimbul următor, protejată de ceea ce a negociat primul. Dacă cineva întreabă dacă o parte este autentică, acest schimb nu poate răspunde la acea întrebare. Poate doar arăta că ambele părți au fost de acord asupra unei propuneri și au produs un secret comun pe care fișierul nu îl conține.
În al treilea rând, potriviți cererea cu răspunsul ei
Potriviți după perechea SPI, tipul schimbului și ID-ul mesajului, apoi verificați indicatorul de răspuns. O retransmisie repetă ID-ul mesajului originalului și nu este o a doua încercare de autentificare. A număra pachete în loc de schimburi este felul în care o negociere sănătoasă devine o buclă fantomă.
Un răspuns poate fi și un refuz: o cerere de cookie, o notificare despre un grup inacceptabil sau o eroare despre o propunere. Acestea sunt răspunsuri legitime și înseamnă că traseul funcționează în timp ce politica nu. Decodați notificarea în loc să tratați fiecare răspuns ca un succes. Când notificarea numește un grup sau o propunere, reparația este de partea configurației și nu la paravanul de protecție.
Și direcția contează. O cerere fără răspuns și un răspuns care nu ajunge niciodată la client sunt defecțiuni diferite, iar doar al doilea arată ca un timeout de partea clientului.
În al patrulea rând, separați IKE de orice altceva pe 4500
Portul 4500 transportă trei lucruri care într-o vedere sumară arată la fel: IKE în spatele unui marcaj non-ESP zero de patru octeți, ESP încapsulat a cărui poziție a marcajului conține un SPI diferit de zero, și keepalive scurte. Acel marcaj este ceea ce separă IKE de ESP încapsulat, așa că citiți acei octeți înainte de a eticheta traficul drept IKE. O etichetă de captură care citește 4500 este un număr de port, nu un protocol.
ESP încapsulat este încărcătură criptată pe care nu o puteți interpreta fără chei, iar prezența lui poate fi semnul unui tunel funcțional și nu al unei defecțiuni.
Urmăriți ambele porturi pentru aceeași încercare, pentru că IKE se poate muta pe 4500 după detectarea NAT, deși s-a deschis pe 500. O urmă filtrată doar pe 500 pare tăcută exact când negocierea a reușit și s-a mutat. Lărgiți filtrul și recitiți aceeași fereastră de timp înainte de a trage vreo concluzie din absență.
Ce înseamnă tăcerea într-un punct de observație
Absența unui răspuns la client dovedește doar ce a observat acel punct. Filtrarea, rutarea, adresa la distanță greșită, un serviciu oprit și o nepotrivire de protocol produc toate aceeași urmă goală.
Un ICMP unreachable relevant adaugă dovezi, dar citiți pachetul citat din interiorul lui și notați adresa dispozitivului care l-a trimis.
Refuzul unui router este un eveniment diferit de o eroare autentificată returnată de partea cealaltă, și doar al doilea dovedește că serviciul este viu. Corelați aceeași încercare cu jurnalele serverului sau cu o observație aprobată pentru a afla dacă cererea a ajuns și dacă un răspuns a plecat. Păstrați capturile limitate și private, pentru că câmpurile lizibile ale strângerii de mână nu fac restul fișierului inofensiv. Rezultatul care merită este o pereche potrivită de cerere și răspuns, sau o lacună documentată cu un punct de observație numit.