Windows PC ca generator ARP flud +13
- 06.07.16 11:15 •
- Yoda33 •
- # 304868
- Habrahabr •
- 46 •
- 15800
- la fel ca Forbes, doar mai bine.
Zi bună,% numele utilizatorului%!
Vreau să vă spun o poveste instructivă care sa întâmplat astăzi la locul meu de muncă. Lucrez într-o companie foarte cunoscută care oferă, printre alte servicii, acces la World Wide Web. Iar esența lucrării mele este de a menține funcționarea normală a rețelei de date. Această rețea este construită în funcție de structura clasică a Core, Aggregation, Access. Comutatoarele de acces reprezintă aproximativ jumătate din producția D-Link, cea de-a doua parte (mare) de la Huawei. Gestionarea întregului fier în rețea este făcută într-un vilan separat, prin care este monitorizat.
Apelul de la serviciul de monitorizare a rețelei nu a adus nici o bucurie - au provocat un incident în toamna nodurilor casei. În același timp, nu au existat plângeri în masă din partea clienților cu privire la limitările în obținerea serviciului. Am reușit chiar să găsească un client pentru sectorul tulbure care răspunde la ICMP încuraja 0,8 milisecunde lea. Încercările de a conecta la orice tabloul de distribuție telnet a fost înrudită cu tortura: Conectează-te care se încadrează în afara sau pauză sau a trebuit să aștepte pentru momentele de reacție introducerea numelui de utilizator / parola și pe echipa. Disperat pentru a vedea jurnalul de „jumătate mort“ Schimbă-mi pentru a șterge conștiința mea, suferă grav, ea repornită. 10 secunde după ce comutatorul de pornire era încă în viață, vesel răspuns la solicitările ICMP, dar apoi „ping“ în fața a început să ia valori destul de indecente în 800-1000 ms, și apoi a dispărut complet.
Aici a inceput sa-mi revina ca procesoarele, departe de a fi performante in switch-uri, au fost in mod evident incarcate de ceva si, aparent, cu 100%. Făcând tcpdump pe interfața vlan a serverului de monitorizare, am descoperit cauza unei încărcări mari a procesorului pe switch-uri. O cantitate anormal de mare de trafic ARP în vilanul de management este de câteva mii de pachete pe secundă. Motivul este găsit, dar iată cum să-i găsim sursa? Sa hotărât blocarea vilonului de control pe toate porturile de agregare și apoi, la rândul său, pentru ao debloca până când se găsește un segment de problemă.
Am reușit să fac această operație numai pe două noduri de agregare, când brusc întrerupta întreaga fistula. Dar mi se părea foarte suspect că minute mai devreme colegul meu stând la masa următoare, a scos un patch cord de la portul de comutare de curent alternativ, care permite accesul la echipamentele și configurația acestuia. L-am rugat pe colegul meu să-mi conecteze laptop-ul la rețea - după 10 secunde, "ping-urile" de pe switch-uri au scăzut din nou la valori urâte. S-a găsit sursa, dar acest laptop a fost folosit o lună pentru a actualiza software-ul și pentru a configura echipamentele de rețea, ce s-ar fi putut întâmpla?
Pentru început, am decis, deși a existat un antivirus instalat, pentru a scana malware-ul prin utilități de la medic și laborator. Nimic semnificativ nu a fost găsit. Am încercat să pornim în Linux - rețeaua a fost silențioasă, fără inundații. Înapoi încărcate Windows - un efect persistent, imediat vilan a fost umplut cu ARP inundații. Dar tocmai ieri cu laptop-ul a fost bine! Și apoi am ajuns pentru un motiv oarecare, în configurația de plăci de rețea ... colegul meu nu este adesea implicat în stabilirea de fier și actualizarea software-ului pe ea, astfel încât să memoreze semnificațiile măștii, și poartă pentru el nu a putut gestiona rețeaua. Și a făcut o greșeală nefericită în configurația plăcii de rețea - în loc de 255.255.224.0 255.255.254.0 pentru masca de subrețea a subliniat el!
Dar ceea ce ma surprins chiar mai mult este faptul că, în ciuda configurației evident incorecte (poarta de acces a fost în afara segmentului de rețea din cauza incorect specificat masca), sisteme de operare cu sfială înghițit acest nonsens! Întorcând laptop-ul într-un generator de trafic ARP. Iată ce a fost în setările pentru protocolul ipv4:
Mi-ar fi recunoscător dacă cineva a luat probleme să explice mecanismul de inundații ARP în această situație, pe cont propriu vreau să doresc tuturor experților netizmikam îngrijire și atenție din nou. După cum se spune - măsoară șapte ori, taie o dată.
RFC 1620 - Extensii de arhitectură Internet pentru medii partajate, de exemplu. Linia de jos este că astăzi este plin de scenarii în cazul în care cele două gazde se află în același segment L2 (SameSM), dar într-o subrețea IP diferită (LIS). În acest caz, unul dintre gazde poate fi un gateway pentru altul. Pentru ca acest lucru să funcționeze, trebuie doar să specificați gazdă că gateway-ul este cu el într-un mediu comun, t. E. Pentru a înregistra manual, aceasta ruta „în interfața» (ruta link-ul), sau distribui-l prin opțiunea DHCP 121