DHCP - Domain Hijack and Control Protocol

A DHCP a Dynamic Host Configuration Protocol rövidítése, azonban olyannyira nem biztonságtudatos módon történt a megalkotása, hogy a címbeli feloldás is tökéletesen helytálló. A DHCP-vel a legtöbb felhasználó akkor találkozik, amikor a Windows systrayen figyeli a hálózat állapotát jelző kis piktogramot, és várja, hogy a gép ikon alatt kis vajszínű pöttyöt mozgató három fázisú animáció eredményeképp végre forgalmazhasson a hálózaton, azaz legyen végre internet.

A DHCP klasszikus rétegelési értelemben UDP-s, azaz a TCP/IP negyedik rétege, azonban a támadhatóságát kihasználó módszerek tulajdonságai és eredménye miatt szokták a második rétegbeli protokollokkal együtt tárgyalni a szakirodalomban. A megalkotását az az igény szülte, hogy az egyre nagyobbá váló hálózatok beállításakor a hálózatüzemeltetőknek kézzel kellett nyilvántartaniuk a kiosztott IP-címeket, DNS-beállításokat, emiatt egy mérethatár elérése után kiszaladt a kezükből a hálózat. A DHCP automatizálja a technikust, aki oda-vissza szalad a hálózati eszközök és a csatlakoztatott hosztok között.

Működését tekintve roppant egyszerű protokollról van szó: a hálózathoz csatlakoztatott kliens broadcast kérést küld, a DHCP szerver pedig unicast üzenetben válaszol a kliensnek, amelyben megmondja, hogy mik a hálózat beállításai. Alapkiépítésben az alábbiakat mondta meg a válaszban:

• a kliens IP-je
• netmask
• DNS szerverek címe
• a default gw címe
• időtartam, ami lejártakor el kell felejtenie a beállításokat a kliensnek és új IP-t kérnie

Ehhez újabban hozzájött windowsos hálózatokban néhány újabb mező is:

• a DC neve és IP-címe
• a CIFS master browser neve és IP-címe

A kliens részéről megadható preferált cím (például akkor, amikor ismételten ugyanahhoz a hálózathoz csatlakozunk), ezt a szerver vagy elfogadja, vagy nem. A DHCP protokoll lehetővé teszi, hogy több szerver is legyen ugyanazon hálózatban, ekkor a kliens a legelső választ tekinti irányadónak.

Támadások?

• Man-in-the-middle. Egyrészt azért, mert a DHCP kérés broadcast, arra bárki válaszolhat: ha például a támadó annyit csinál, hogy elindít egy DHCP szervert a gépén és figyeli a kéréséket, válaszolhat rájuk, amin saját magát adja meg default gw-nek, a buta kliensek (figyelem! Nem olvastunk a fenti leírásban sem hitelesítésről, sem azonosításról!) szó nélkül érvényesítik a küldött beállítást. Mivel felhetetőleg azért az igazi DHCP szerver is válaszol némi késéssel, a kliens megkapja az igazi választ is, de a protokoll kialakítása miatt nem foglalkozik vele, a támadón keresztül forgalmaz csak. Fokozható a hatás azzal, hogy a támadó előzékenyen saját magát adja meg master browsernek, és ekkor a kliens mindenképpen rajta keresztül fog authentikálni a hálózati SMB-szerverekhez.
  
• DoS - IP pool exhaustion. A másik triviális támadási mód a szerverek ellen irányul: egész egyszerűen több száz (ezer) DHCP-kérést injektál bele a támadó a hálózatba, ezzel nagy valószínűséggel elég hamar elfogyasztja a rendelkezésre álló tartományt (scope-ot). A gobbler nevű eszköz dokumentációja szerint negyven másodperc alatt le lehet halasztani egy /24-es szkópot: aki ez után szeretne csatlakozni, az nem fog tudni.
  
• DoS - Die, baby, die! Nagyméretű hálózatokban sem lehetnek meg DHCP nélkül, viszont ez azt jelenti, hogy nem lehet minden switch mögé DHCP szervert telepíteni, keresztül kell vinni a switcheken a DHCP forgalmat. A Cisco switchek a DHCP feldolgozást erőből (CPU-ból) végzik, viszont ebből meglehetősen kevés áll rendelkezésükre relatíve, emiatt viszont nagy valószínűséggel működésképtelennél válnak, ha rengeteg DHCP-kérés/válasz megy egyszer csak keresztül rajtuk.

Ami az eszközöket illeti, a fiatal, lelkes, ám nem kikezdhetetlen tudású IT-biztonsági szakemberek távoltartása érdekében csak pár szót mondunk: yersinia és gobbler, valamint ettercap.

Védekezés.
Nyilván rengeteg lehetőség van a védekezésre, lássunk ezek közül néhány fontosat - és hogy miért lövik lábon magukat az üzemeltetők, ha aktiválják.

• Nem használunk DHCP-t. Ekkor lehet kézzel beállítgatni mindent. Nem reális két hosztnál többet tartalmazó hálózatokban.
  
• Port security. Szokták mondani, hogy ez a megoldás a L2-beli támadások nagy részére, de sajnos ez ellen nem véd. Például szépen be lehet állítani, hogy a 23-as fizikai porton csak a DEADBEEFCAFE MAC-cím fogalmazhat, de ez sajnos nem véd a pool exhaustion ellen, ugyanis a proxyzások miatt belekerült egy szolgáltatás a protokollba, amely lehetővé teszi, hogy egy MAC-címről ne csak saját magunknak kérhessünk címet, hanem a valaki másnak is - a MAC címek ugyanazok lesznek mind az ezer kérésben, ennek ellenére szépen elérhetetlenné tesszük egy napra az IP-poolt ezzel az opcióval.
• ICMP/ARP ping a DHCP poolban. Sok DHCP szerver ICMP-n/ARP-n megpingeli a kiosztott címeket rendszeres időközönként - elsősorban nem biztonsági okokból, ugyanis sok kliens egész egyszerűen nem engedi el a szervernél kikapcsoláskor a használt IP-címet. A gobbler például azt is tudja, hogy válaszol az ilyen pingekre.
  
• Rate limiting per port. Lehet persze azzal is próbálkozni, hogy nem engedünk, csak n kérést bejönni a porton percenként - ezzel annyi a gond, hogy a DHCP lease rendszerint több órára szól, viszont ha ezt a rate-et szeretnénk átengedni mindenfajta forgalomból, az meglehetősen lerontja a felhasználói élményt.
  
• DHCP snooping. Ez a legkevésbé rossz megoldás, a Cisco switchek saját védelmi mechanizmusa, cserébe meglehetősen sok CPU-időt foglal: a switch figyeli a kiosztott IP-címeket, megjegyzi, melyik portján lakik az érintett IP/MAC cím, valamint hogy hol lakik a DHCP-szerver és nem enged másféle forgalmat. A hátránya annyi, hogy rengeteg hibát tud okozni: ha a switchnek valahogy egy, a hálózat távoli pontján végzett átpatchelés miatt bekövetkezett feszítőfa-változás következtében másik lábára került a DHCP-szerver (jó, igaz: rendesen menedzselt hálózatoknál ilyen nyilván nem fordulhat elő, de maradjunk meg az esőben váratlanul szakadozó hálózatok való világában), akkor az üzemeltetők napokig nyomozhatnak az összes swichen, hogy miért is nem működik a DHCP abban a szegmensben...