Puncte:0

Rezolvarea DNS și filtrarea portului de solicitare

drapel gd

În timpul atacurilor de amplificare DNS pe un server DNS, am observat că unele solicitări DNS au pentru cuplu IP/port ceva de genul 104.49.96.196:80. Înțeleg că acest IP este falsificat, dar este bine să luați în considerare filtrarea portului solicitării DNS? Cred că nu ar trebui să ne așteptăm la un port > 1023. Este o presupunere sigură? În acest caz, cred că este o victorie ușor de identificat și nu răspunde la atacul de amplificare DNS (dacă pachetul ajunge la serverul DNS și nu este aruncat de WAF).

Puncte:1
drapel in

Clienții DNS ar trebui să aibă portul sursă > 1023.

Dacă este < 1024, ar trebui să fie doar portul sursă 53 dacă vine de la alt server DNS - dar este puțin probabil.

Verificați cu portul tcpdump 53

Privind la RFC6056 și simplificare cu unele mostre am putea merge mai departe și am spune că orice stivă IP care se comportă bine nu ar trebui să aibă (a avut) un port sursă mai mic decât 49152 (primul port efemer). Cu toate acestea, secțiunea 3.2 contrazice acest lucru, la fel și eșantioanele.

Dar până când cineva poate oferi referință la RFC care redefinește RFC6056, este sigur să spunem că sportul <= 1023 nu este valid.

Dacă dintr-un anumit motiv există o solicitare care eșuează, clientul ar trebui să încerce din nou și, sperăm, să obțină o solicitare reușită. (Chiar dacă acest lucru ar eșua, aș ignora acele implementări)

vinz avatar
drapel gd
Sunt total de acord cu tine. Preocupările mele au fost mai mult despre implementarea acelui filtru pe port? poate avea un dezavantaj care mi-e dor? Există vreun solutor DNS bine cunoscut (nu am găsit nicio informație despre asta) care implementează această filtrare?
drapel in
De regulă, nimic nu ar trebui să aibă un port sursă
Patrick Mevzek avatar
drapel cn
„De regulă, nimic nu ar trebui să aibă un port sursă
drapel in
S-a adăugat referință la RFC.
Puncte:1
drapel cn

Nu, nu este o presupunere sigură.Nu încercați să filtrați pe porturi, acest lucru nu va produce consecințe utile. Modul în care un client își gestionează porturile locale este propria sa afacere și, prin urmare, ca server, vă puteți aștepta să obțineți trafic din toate porturile. Despărțirea Unix la 1024 este o moștenire arhaică a trecutului care nu mai înseamnă nimic în prezent.

Dacă doriți să combateți amplificarea DNS, pe lângă măsurile „standard” (cum ar fi să vă asigurați că într-adevăr trebuie să gestionați tot traficul pe care îl primiți, adică nu sunteți larg deschis), una dintre modalitățile cele mai des folosite în zilele noastre este RRL sau practic limitare de rata.

Uita-te la https://www.infoblox.com/dns-security-resource-center/dns-security-solutions/dns-security-solutions-response-rate-limiting-rrl/ pentru o introducere pe subiect și la https://www.isc.org/docs/DNS-RRL-LISA14.pdf pentru o prezentare mai tehnică.

drapel in
Aveți referire la vreun RFC care face declarația din RFC6056 „o moștenire arhaică a trecutului care nu mai înseamnă nimic, practic, astăzi”?
Michael Hampton avatar
drapel cz
Acea „moștenire arhaică a trecutului” este bine codificată în RFC 6335, de exemplu.
Patrick Mevzek avatar
drapel cn
@NiKiZe Nu există nimic în RFC care să impună ceva. Propoziția este „Cu toate acestea, algoritmii de selecție a portului efemere ar trebui să folosească întregul interval 1024-65535." Rețineți că este „trebuie” și nu „TREBUIE” (sau chiar „TREBUIE”) ceea ce face o diferență MARE în lumea IETF, consultați RFC2119 pentru explicații despre asta.
Patrick Mevzek avatar
drapel cn
@MichaelHampton Nu este obligatoriu, vezi comentariul de mai sus. Este un caz minor „ar trebui”. Aceasta nu este o specificație IETF care impune nimic, ci doar o bună practică curentă din ceea ce se întâmplă astăzi.
Patrick Mevzek avatar
drapel cn
Iar portul sursă nu mai înseamnă nimic astăzi. În trecut, comenzile „r” (rlogin, rtelnet etc.) își bazau doar autentificarea pe asta, crezând că dacă portul sursă era mai mic decât 1024, atunci era „privilegiat” și, prin urmare, ok. Acest lucru s-a dovedit greșit din punct de vedere al designului, așa că nimeni nu mai face asta astăzi, nimic din punct de vedere al securității nu poate fi derivat doar din portul sursă utilizat.
Michael Hampton avatar
drapel cz
@PatrickMevzek În mod clar, IANA nu vede lucrurile așa.
Patrick Mevzek avatar
drapel cn
@MichaelHampton IANA nu este cea care decide ce porturi **sursă** folosește un sistem de operare. Acest lucru este diferit de porturile de destinație, evident. Atribuirea (cu ce se ocupă IANA) este doar un mecanism de sincronizare pentru ținte. Și acest lucru este arhaic, dacă fiecare aplicație ar folosi înregistrări `SRV`, nici măcar nu ar trebui să înregistrăm numere de port, deoarece oricare dintre ele ar suporta orice protocol.
drapel in
Ai dreptate, nimic nu împiedică
Patrick Mevzek avatar
drapel cn
@NiKiZe „Ai dreptate, nimic nu împiedică
drapel in
Aș spune că este statistic, dar va colecta date, mulțumesc. Până acum, nicio conexiune sau documentație găsită care să fie împotriva ei, va fi bucuros să afle despre orice caz care o face de fapt.
Patrick Mevzek avatar
drapel cn
@NiKiZe (și @MichaelHampton) poate nu este clar, dar teoretic sunt cam de acord cu tine. Ideea mea este că vreau să transmit OP că combaterea problemelor de amplificare DNS/DDOS nu ar trebui să se bazeze pe filtrarea porturilor sursă, deoarece aceasta va fi fragilă și limitată.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.