Windows PC, mint generátor az arp árvíz
Windows PC mint ARP flud generátor +13
- 06.07.16 11:15 •
- Yoda33 •
- # 304868 •
- Habrahabr •
- 46 •
- 15800
- ugyanaz, mint Forbes, csak jobb.
Jó nap,% username%!
Szeretnék elmondani egy olyan tanulságos történetet, ami ma munkahelyemen történt. Egy nagyon híres vállalatnál dolgozom, amely többek között hozzáférést biztosít a világhálóhoz. És a munkám lényege az adathálózat normál működésének fenntartása. Ez a hálózat a Core, Aggregation, Access klasszikus struktúrájának megfelelően épül fel. A hozzáférési kapcsolók megközelítőleg a D-Link termelésének fele, a második (nagy) rész a Huawei-től származik. A hálózatba épített vas kezelése különálló vilánként történik, amelyen keresztül figyelemmel kísérik.
A hálózatfigyelő szolgáltatás hívása nem adott örömet - a ház csomópontjai ősszel történt incidensét okozták. Ugyanakkor az ügyfelek részéről nem érkezett tömeges panasz a szolgáltatás megszerzésének korlátairól. Még lehetséges volt megtalálni az ügyfelet a probléma szegmensben, amely 0,8 milliszekundumra bátorította az ICMP-t. Kísérletek, hogy jelentkezzen be bármilyen telnet kapcsolótábla hasonlították kínzás: Csatlakoztassa leesik vagy időt, vagy meg kellett várni a reakciót pillanatok adja meg a felhasználónév / jelszó és csapat. Kétségbeesett, hogy a napló „félholt” Switch, hogy törölje a lelkiismeretem, szenvednek rosszul, újraindul azt. 10 másodperc után a start kapcsoló még életben volt, vidáman válaszol ICMP kérések, de majd a „ping” előtt kezdett meglehetősen illetlen értékeket a 800-1000 ms, majd teljesen eltűnt.
Itt kezdett hajnalozni, hogy a processzorok, messze a nagy teljesítményű kapcsolókban, nyilvánvalóan tele vannak valamivel, és nyilvánvalóan 100% -kal. A tcpdump futtatása a felügyeleti szerver vlan felületén, a kapcsolók nagy CPU-terhelésének oka volt. Az ARP forgalom abnormálisan nagy mennyisége a vezetés vilan másodpercenként több ezer csomagból áll. Az ok megtalálható, de itt találni a forrást? Úgy döntöttek, hogy lezárják a kontroll vilont az összes aggregációs porton, majd feloldják, amíg probléma szegmenst nem találnak.
Ezt a műveletet csak két aggregátum csomópontján sikerült elvégeznem, amikor hirtelen az egész fistula leállt. De nagyon gyanakvónak tűnt, hogy egy perccel korábban a kollégám, aki egy közeli asztalnál ült, kivette a hálózati csatlakozózsinórt a kapcsoló kikötőjéből, amely hozzáférést biztosított a berendezéshez és a beállításokhoz. Megkérdeztem a kollégámtól, hogy csatlakoztassa újra a laptopomat a hálózathoz - 10 másodperc múlva a kapcsolókon "ping" újra ugrott a csúnya értékekre. Megtalálták a forrást, de ezt a laptopot egy hónapon keresztül használják a szoftver frissítéséhez és a hálózati eszközök konfigurálásához, mi történhetett vele?
Először is, úgy döntöttünk, bár volt telepített vírusirtó, a rosszindulatú programokat az orvos és a laboratórium közreműködésével ellenőrizni. Semmi jelentőset nem találtunk. Megpróbáltunk Linuxba indítani - a hálózat csendes volt, nincs árvíz. Vissza a betöltött Windows - a tartós hatás, azonnal a vilánt feltöltötték az ARP árvízzel. De csak tegnap a laptopnál rendben volt! Aztán valahogy bekerültem a hálózati kártya konfigurációjába ... A kollégám gyakran nem foglalkozik hardver beállításával és a szoftver frissítésével, ezért nem emlékezett az ellenőrző hálózat maszkjára és átjáró értékeire. És szerencsétlen hibát követett el a hálózati kártya konfigurációjában - a 255.255.224.0 helyett az alhálózati maszk helyett 255.255.254.0-et adott meg!
De mi még ennél is meglepett az a tény, hogy annak ellenére, hogy nyilvánvalóan téves konfiguráció (gateway volt a hálózaton kívüli szegmens miatt hibásan megadott maszk), operációs rendszer szelíden lenyelni ezt a hülyeséget! A laptop cseréje ARP forgalmi generátorként. Itt található az ipv4 protokoll beállításai:
Hálás lennék, ha valaki megpróbálná megmagyarázni az ARP árvíz mechanizmusát ebben a helyzetben, önmagamban szeretnék minden szakértőnek újratervezni a figyelmet és a figyelmet. Amint azt mondják - hétszer mérjük meg, vágjuk egyszer.
RFC 1620 - Internetes architektúra bővítmények megosztott médiához például. A lényeg az, hogy manapság teljes forgatókönyvek léteznek, amikor 2 gazda van ugyanabban az L2 szegmensben (SameSM), de különböző IP alhálózatokban (LIS). Ebben az esetben az egyik gazda átjáró lehet a másiknak. Annak érdekében, hogy ez működjön, csak azt kell közölnie a fogadóval, hogy az átjáró ugyanabban a megosztott médiában van, vagyis manuálisan regisztrálja az útvonalat a felületre, vagy elküldi a DHCP 121. opcióján keresztül