DHCP teszt (Megoldva)

Hálózatok egyéb

Sziasztok.

Van egy hálózat monitorozó programom, amiben megcsináltam a Nagios pluginek kezelését (https://github.com/csikfer/lanview2).
Gondoltam én mint egyszerű rendszergazda, hogy beizzítom a kb. 40db DHCP-s subneten a DHCP ellenőrzését egy Nagios plugin-nel. Nem csak annyi a feladat, hogy működik-e a DHCP szerver, azt is észre kéne venni, ha egy önjelölt rendszergazda routert (ami DHCP szerver is) csatlakoztatott, mint az már többször előfordult.

A megfelelő VLAN-okra (Ubuntu 16.04 szerveren) konfiguráltam vlan interfészeket (IP cím nélkül, majd IP címmel), és teszteltem a (hivatalos Nagios plugin) check_dhcp programot. A vlan interfésszel nem működik. A kérést elküldi, de a választ, ami egyébként megjön, azt nem veszi a program. (A kérésben elküldi 0.0.0.0 forrás cím helyett a saját címét, ami ha volt címe a vlan interfésznek, akkor az, ha nem akkor a fizikai interfész címe. Ez a szervert nem igazán zavarja, visszaküldi a választ broadcast-ként, de ezt a program nem veszi)

Találtam egy Perl-ben írt programot: check_dhcp_relayed.pl, ami rendesen teszi a dolgát, könnyebbség, hogy nem kellenek interfészek a subnetekbe, de ettől még a relay szerver lehet rossz, és a kalóz DHCP szervert nem veszi észre.

Talán van aki futtat DHCP ellenőrzést nagyobb számú subnet-re. Hogyan kell ezt csinálni?

  • 7245 megtekintés

( wpeople v | 2016. 10. 04., k – 12:07 )

ugyan nem oldja meg a problémádat, de a fenti kérdés Mikrotik-et használva megoldott.

Ha nincs más, kiindulási alapnak jó lehet, nem kell nulláról megírni az egészet. Nem nevezném egy "kerek" programnak (pl. paramétereket nem kezel), de legalább működik rendesen.
Én abban a tévhitben éltem, hogy erre (meg még sok másra is a tágabban vett témában) van kész megoldás. És nem olyan szerencsétlen, mint a Nagios plugin-je. Kipróbáltam pár check_dhcp változatot, de ez a feature eddig mindben benne van. Mintha senkinek nem lenne 1-2 subnet-nél többje.

raw módban használja a megadott hálókártyát,
random MAC-kel broadcastol egy DHCPDISCOVER-t,
válaszra vár,
ha a megadott időn belül jön válasz és az nem a hivatalos dhcp szervertől jön, vagy nincs a dhcp válasz routers mezőjében a hivatalos dhcp szerver címe, akkor 1-gyel lép ki, egyébként 0-val.

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack

Hát, én is így gondoltam. A paramétereket be kell írni a forrásba, lehet, hogy elszúrtam velemit (nem hinném, de benne van a pakliban), rossz router címet írtam be, és nem ír ki semmit (csak a küldött kéréseket). Kivettem a kommentet egy debug sor elöl, és azt sem írja ki. Mintha a sniff függvény nem fogna el egy csomagot sem. A kilépési kódot nem néztem.
Van benne egy vevő függvény is, amit a kutya nem hív. Talán nem működött, és lett helyette a sniff., és csak ott maradt (otthonrol írok a pontos függvény nevekre nem emlékszem).

rossz router címet írtál, azaz NEM annak a címét ami válaszol. ha így van, akkor jó eséllyel 1-es hibakóddal lép ki a program.

csak a küldött kéréseket írja ki? azaz azt h "DHCP Discover xx:xx:..."?
az tényleg gond, azt jelentené h nem kap választ.
ami mondjuk azért is lehet, mert ugy hamis MAC címmel küldte a kérést és lehet h a te hálózatodban a switchek letiltják az ilyen forgalmat.
ha így lenne, állísd be a $HWaddr -t a megfelelőre.

a fake_listen_socket valóban le lett cserélve a sniff-es módszerre.

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack

Újra letöltöttem, hátha valamit én szúrtam el. Csak a fizikai interfész nevét, és a MAC-et átírva (kikommentezve ott volt a random cím helyett egy fix MAC, nehéz elrontani).
Nem működik. Garantáltan rossz a(z eredeti) router cím, nálam olyan subnet nincs is. Visszaadott érték 0. Kimenet:

Waiting 10 sec
DHCP Discover 00:1c:c0:01:3d:64
DHCP Discover 00:1c:c0:01:3d:64
DHCP Discover 00:1c:c0:01:3d:64
DHCP Discover 00:1c:c0:01:3d:64
DHCP Discover 00:1c:c0:01:3d:64

Ahol a fenti MAC a gép valódi címe. A dhcpdump szerint jön válasz.

Gyanúsan sok DHCP-t monitorozó program működik hibásan.

( ricsip v | 2016. 10. 04., k – 12:48 )

Csak kérdezem: nem egyszerűbb letiltani az összes switch porton a DHCP szerver működését, és csak a te DHCP szervereidnek engedélyezni azokon a switch portokon?
Mivel használsz VLAN-okat, gondolom managelt switch, azok közül ma talán már nincs olyan a piacon amelyik ne tudná a DHCP snooping-ot.

Vagy explicite DHCP monitoringot akarsz, nem pedig jogosulatlan DHCP szerverek megakadályozását?
--
WP8.x kritika: http://goo.gl/udShvC

Igen sok szempontból az a jó megoldás, ha bekapcsolom a snooping-ot, de hogy egyszerűbb lenne azt kétlem. (kb 60 switch, 40 VLAN, 3 DHCP szerver).
És jó lenne detektálni is a kalóz szervert (ami alatt nem azt értem, hogy néha megnézem a log-ot), ez ugyan lehetséges, de (szintén) nincs rá kész megoldás.
Monitorozni akarok, és számomra triviálisnak tűnt, hogy eközben kiderül van-e jogosulatlan szerver. Ha kapok választ a DHCP kérésre akkor OK, ha többet is kapok, az nem annyira OK, a plusz válasz tartalma alapján pedig beazonosítható a kalóz szerver, gondoltam én balga.

Ok, meggyőztél. Le is adom a megrendelést. Ja mégse, majd szolnak (kb. fél év múlva), hogy írjam össze mi kell. Aztán két éven belül pik-pakk itt is van, ha szerencsém van, ha nincs akkor soha. Mert a reformok működnek!
Szóval, félretéve a viccet, ehhez teljesen jó lenne egy szoftveres megoldás, csak meg kell csinálni. Meg is tudom csinálni, de se kedvem, se időm (idő a legkevésbé). Azon húztam fel magam, hogy van egy rahedli elvileg bejáratott letesztelt megoldás, aztán mégsem jó egyik sem.

( csfeco | 2016. 10. 05., sze – 11:18 )

Bár számomra a DHCP monitorozás, és a kalóz DHCP detektálás egy feladatnak tűnt, jobb híján kettő lesz belőle:
A check_dhcp_relayed.pl korrekten teszi dolgát, Nagios plugin.
A relay szerver az a központi router switch, ha azzal baj van, azt garantáltan észreveszem tesztelgetés nélkül is.
A kalóz szerver detektálásra meg találtam egy kész megoldást: dhcp-probe, benne van az Ubuntu repóban, működik rendesen (a vlan-okat nem jól kezeli, de ha van VLAN interfész azzal működik), könnyen illeszthető.
Azért, ha valaki tud egy VLAN interfészeken is működő check_dhcp változatot, az ne titkolja.

( csfeco | 2016. 10. 08., szo – 10:12 )

A megoldás:
Nem a Google-n kell keresni, hanem a github-on. A dhtest lett a (majdnem) befutó. Rendesen működik, és viszonylag egyszerűen átalakítható, hogy olyan (is) legyen, amilyennek szerintem a check_dhcp -nek lennie kéne.
Ellenörzi, hogy van-e DHCP címkiosztás, le tudja ellenörizni opcionálisan a DHCP szerver és a GW címet, és az elsö vett csomag után vár, hogy jön-e több.
Forkoltam, ha valakinek esetleg kell letöltheti : https://github.com/csikfer/dhtest
Nincs agyon tesztelve, de mint Nagios plugin, ahogy nekem kell, úgy okés, de lehetnek nem várt együttállások más kapcsolókkal. A json kimenet nincs megírva, akinek kell majd hozzáírja :).

Na, most már tényleg működik egy rendes DHCP monitorozás, kikapcsolt, és kalóz DHCP szerverre is jelez (csekkolja a DHCP szerver, és a kapott GW címét).
Az egy naposra tervezett project simán meglett alig több mint egy hét alatt.
Azzal persze nem számoltam, hogy a hivatalos letesztelt Nagios plugin enyhén szólva felületes, ill. vlan-okon nem működik, és nekem kell majd keresnem, forkolnom egy majdnem jó plugint.
Ami számomra fura: Ebből a fórum témából nekem az jött le, hogy nem igen használ senki Nagios-t a DHCP monitorozására, vagy használ, de nem HUP olvasó, vagy nekik ez a felületes ellenőrzés is OK. És a nagy Nagios-ra se lehet mindig számítani, vagy én vagyok túl igényes ill. paranoiás.
Ui.: Ehhez már csak egy lehetséges választ kell hozzácsapni: "Nem érdekel, leszarom." és lehetne indítani egy szavazást.

ez az egyik megoldás. a másik, meg hogy még sohasem akartam az intránkat monitorozni, hogy ugyanmár bejön-e egy kolléga egy routerrel és ráköti-e, hogy pár izgalmas percet okozzon számomra :D ez tipikus "kollégiumi" probléma, ha ott lettem volna rendszergazda, no, akkor lehet, hogy szembejött volna velem a nagios vs dhcp monitorozás :)

Tette itt fel tanár is az AP routerét, aztán nem értették mit pattogok. A koliban pedig az igazgató meg is engedte egyszer a routerek csatlakoztatását, csak éppen nekem felejtett el szólni. Szerintem akad egy két egyetem, főiskola az országban, ahol szintén zajlik az élet.
Ok. Nem érdekes a kalóz szerver detektálás, de halkan megjegyzem a hivatalos Nagiso plugin, nem működik VLAN interfészen. Vagy a VLAN interfész is egy olyan huncutság, amit rendes helyen nem használnak?

Két szerverrel csak részben működik, mert csak egy szerver címet lehet megadni, az meg két különböző szerver címmel nem lesz azonos. De nem kötelező megadni, és akkor pedig csak a GW.-t ellenkörzi, ami viszont már eséllyel azonos. Két GW-t ugyanúgy nem kezel, mert csak egy cím adható meg (és ha több van a válasz csomagban, akkor csak az elsőt ellenőrzi).
De ezt beleírni nem olyan nagy kihívás, nekem nem kellett.

Tényleg csak kérdezem, h. az volt-e a feladat h. 1) embereket kell a szőnyeg szélére állítani ha bűnelkövetésen kapod őket, vagy 2) a hálózat kontrollált állapotban maradjon azáltal h. jogosulatlanok nem tudnak DHCP szerverrel IP konfigot osztani?
--
WP8.x kritika: http://goo.gl/udShvC

A kettő nem zárja ki egymást.
Nem vagyok olyan nagy ember, hogy a lecseszéseimet a szőnyeg széléről keljen hallgatni.
Ez nem műszaki egyetem, (elnézést) nagyon hülyék a hálózathoz, viszont bátrak. Rákötik a router-üket/AP-jukat rosszul, majd mérgelődnek, meg panaszkodnak nem nekem, hanem felfelé, hogy szar a hálózat. Így legalább egy kis szelete letudva a problémáknak.
Egy kérdés, mert lehet hogy csak félreértek valamit: A snooping bekapcsolás 60 db switch esetén tényleg minden switch-en be kell állítani (és nem egy paranccsal), vagy elég egyen, mint pl. a relay-t (többin csak engedélyezni). Mert ha mindegyiken, akkor csinálja az akinek 6 anyja van (az anyánként csak 10 switch). A manuálban leírt példa hálózatnál a mienk egy picit bonyolultabb, és nem is teljesen homogén, és pár switch nem is támogatja.

Cisco switcheken a DHCP snooping-ot vlan-onként lehet/kell engedélyezni, és igen sajnos minden switchen be kell kapcsolni ahová enduser potenciálisan dughat dhcp szevert. Ugyanis a switch portokra egyesével Te fogod megmondani, h. elméletileg mehet-e ki róluk dhcp request packet v. sem (a default az h. nem, szóval igazából csak a trusted portokat kell megmondanod, mindenki más untrusted lesz). Ehhez fel kell rajzolnod a hálózati topológiát, és neked kell felismerned az útvonalat, amit egy DHCP request csomag bejár az igénylőtől (dhcp kliens) a kiszolgálóig (dhcp szerver). Több switch esetén értelemszerűen a trönk portokon keresztül, ill. redundáns útvonalakról sem elfelejtkezve! A snooping lényege, h. nem fogja szét broadcast-olni az egyik switchporton bejövő dhcp request-et az összes többi switchportra, hanem csak arra az 1-re (vagy esetleg néhányra) ahol dhcp szerver található. Ergo a kalóz dhcp szervernek esélye se lesz IP konfigot szolgáltatni, ha a request-et eleve meg se kaphatja. Tehát emiatt nincs értelme vadászni az ilyen kalóz dhcp szerverekre, mivel a működésük lehetetlenül el a helyesen belőtt dhcp snooping-gal. Amihez viszont sajnos minden résztvevő switchnek támogatnia kell a snoopingot, és megfelelően be kell konfigurálni a portokat. De ha a hálózat statikus, nem változik hetente, ezt kb 1x kell beállítani jól, utána már nem kér enni, csak teszi a dolgát. Inhomogén hálózat esetén azokon a switcheken amik nem tudják a snoopingot, még működni fog az esetlegesen ott üzemelő kalóz dhcp.
--
WP8.x kritika: http://goo.gl/udShvC

Hat, ha egyedul van egy ekkora halozatra, akkor ez tenyleg az a kategoria, hogy csinalja, akinek feltetlenul szopasra van szuksege. Azon felul, ha az insecure switchek felol johet DHCP response, akkor megette a fene az egeszet.

Arrol nem is beszelve, hogy nem tudunk semmit a halozati topologiarol, az se biztos, hogy Cisco switchek vannak, lehet, hogy valami Dell-HP-istentudja hulladekok.
--
Blog | @hron84
Üzemeltető macik

Köszönöm a választ.
Jól sejtettem, hogy ehhez nekem egyáltalán nincs kedvem. Ráadásul, itt maximálisan rugalmatlan munkarend dívik, és ezt jobb lenne akkor csinálni, amikor mást nem akadályozok a munkában (valószínűtlen, hogy ennyi parancsot, még ha nem nagy kihívás, akkor is hibátlanul kiadjak). Nem cisco switch-ek vannak, hanem HP ProCurve switch-ek (54xx,53xx,29xx,28xx,26xx), 3COM (az most már HP 19xx), és van egy pár HP a 18xx,17xx sorozatból, amin én nem látok snooping lehetőséget.
És még egy apróság: Ha beállítom a snooping-ot, akkor a DHCP ellenőrzésem csak arról fog szólni, hogy működik-e a szerverem onnan nézve, ahonnan csekkolom. Ha valahol el lett baltázva a konfig, vagy egy változás nem lett lekövetve, akkor azt a hibát csak a júzer fogja észrevenni, ami kevésbé elegáns, mintha én veszem észre.
ui.: Lényegében egyedül menedzselem a hálózatot, egy kolléga ismeri a jelszavakat, a többieknek nagy bátorság (vagy inkább botorság) lenne elárulni.

Nyilván jól kell beállítani (amúgy nem több mint 2-3 parancs / switch), utána kényelmesen "just works".
Vaterán vett használt cisco-n csináltam pár éve egy kis irodában. Miután az unmanaged switch-ek miatt a mindenféle rádugdosott gépek össze-vissza dhcp-t osztogattak, és fél nap volt minden alkalommal mire kiderült ki volt aznap a bűnös. Bementem a főnökhöz h. vegyünk legalább 3 db 24 portos cisco 2950 / 2960-at (relatíve bagóért vaterán), és megoldódik a probléma. Azóta semmi esemény nem történt tudtommal.
--
WP8.x kritika: http://goo.gl/udShvC

Ez akkor jo, ha olyan a fonok, en dolgoztam mar olyan helyen, ahol kizarolag az ar volt szempont, es valami nagyon dzsunka L3 switchet akartunk megvenni core routernek, aztan szerencsere halasztodott addig a dolog, hogy ez mar az utanam kovetkezo rendszergazda problemaja legyen.
--
Blog | @hron84
Üzemeltető macik