Rogue DHCP found...

#1 Hallo allerseits...

ich habe hier in diesem Forum leider keinen Treffer in der Suche landen können.

ich hätte gerne mal gewusst welche techniken oder wie es in der praxis von "euch" gehandhabt wird, wenn sich in einem Netzwerk mit einem "regulärem DHCP" ein sogenannter "Rogue DHCP" Server befindet.

z.B. Überwachung via Nagios ? ...wenn man den übeltäter dann hat (MAC und IP) was dann? Wo steht der Übeltäter? Wer ist der Übeltäter?
gibt es sinnvolle einstellungen/konfigurationsmöglichkeiten in einem heterogenem netzwerk um dem entgegenzuwirken?

mfg

#2 Frage:
gibt es sinnvolle einstellungen/konfigurationsmöglichkeiten in einem heterogenem netzwerk um dem entgegenzuwirken?
Antwort:
Falls DHCP Client IP-Adresse vorgibt, funktioniert Angriff nicht.

pff.. das ist aber auch schon alles. Wenn DHCP zwingend an ist, machts richtig Arbeit.
Wusste bis eben nicht mal das es sowas gibt.

TS

#3

Zitat

Falls DHCP Client IP-Adresse vorgibt, funktioniert Angriff nicht.

hmmmm... in diesem sinne gibt ja jeder DHCP Server den clients aus seinem Adress-Range eine Adresse vor.

IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from <MAC>

das problem das sich wie folgt darstellt ist, das der DHCP Client sich die IP von dem "zuerst antwortenden" DHCP Server holt.
Ich denke du hast immer schlechte Karten (in einem heterogenem netzwerk), da du darauf keinen einfluss nehmen kannst.
oder hab ich dich falsch verstanden?

ein Angriff "im übertragenen sinne" ...denn angriff hört sich immer nach "mit absicht an" ...muss es aber nicht, ein falsch konfigurierter und gestarteter dienst reicht i.d.R.
2 DHCP server die in einem physischen Netzwerk Adressen aus 2 unterschiedlichen subnetzen verteilen, ...ist schon eine sehr bösartige sache.

Zitat

Wenn DHCP zwingend an ist,...

naja, in grösseren netzwerken, iist diese art des adressmanagements eigentlich schon fast zwingend notwendig... meine meinung.

#4 Also das Stichwort war Client und nicht Server!
Wenn man im Netzwerk die IP selber vergibt ist ein DHCP-Server ergo witzlos. Egal ob Rogue oder legal.
Und ich weiss nicht wie es in grösseren Netzwerken so läuft.

Hier bei mir machen wir alles selbst und händisch (<50 clients), so hat man über jede interne IP die Kontrolle, da hängt tatsächlich noch ein Zettel an der Wand, wo jede IP bekannt ist... (macht vieles einfacher bezgl. Firewalleinstellungen)
Ein Rogue müsste hier also ..
erstens mal installiert sein.. und
zweitens nen Client finden, der versucht DHCP zu händeln...

Beides zum Glück hier unwahrscheinlich.
Trotzdem ist diese mögliche "man-in-the-middle" Geschichte nicht zu vernachlässigen...
Da sollte jeder gute Admin sowas wie "intrusion-detection" am Laufen haben denke ich...

TS

#5 naja, ...rumstreiten wollt ich mich mit dir nicht.

Zitat

Falls DHCP Client IP-Adresse vorgibt, funktioniert Angriff nicht

fällt mir immer noch schwer, das richtig zu interpretieren, interpunktion hilft ergo...
"Stichwort Client" spielt also keine Rolle, solange der Sinn dieser Aussage für mich im verborgenen bleibt.

Philosophieren, ab wann DHCP Sinn macht oder nicht, wollt ich hier eigentlich auch nicht...
ergo eine IP Konfiguration der Clients im einzelnen vorzunehmen = Turnschuh-Administration (meine Meinung)
Wenn du in grösseren Netzwerken die Netzwerkgrössen ändern musst (subnetting) ...dann mach ich das an einer Stelle, am DHCP.
ich muss eben nicht jeden einzelnen Rechner anfassen, um ihn an "das neue Netz" anzupassen.
was ist mit Mitarbeitern, die keinen fest integrierten PC im Firmennetzwerk haben und ihren Laptop mit nach hause nehmen... und und und...

Zitat

...macht vieles einfacher bezgl. Firewalleinstellungen

versteh ich nicht? ...was gibt es einfacheres, als die gesamte IP Konfiguration an nur einer Stelle vorzunehmen? ...egal was sich im netzwerk ändert? ..ob du mal einen DNS umswitched oder ein zweiter hinzukommt?
du hingegen musst dann deine (<50 clients) einzeln anfassen.
(die frage ob und ab wann etwas sinn macht oder nicht, steht hier garnicht)
mit der firewall versteh ich auch nicht?
in abhängigkeit der MAC Adresse meiner clients vergebe ich "dynamisch feste IP Adressen" und dieses Spiel kannst du soweit treiben, das du "unbekannten clients" via DHCP nichtenmal eine IP gibst o.O ...
aber mit "DHCP" konfigurierst du eben immer nur an dieser einen stelle... und musst nicht alle clients abklappern...

Zitat

Da sollte jeder gute Admin sowas wie "intrusion-detection" am Laufen haben denke ich...

...und eigentlich nur hierum ging es mir ---> "intrusion-detection"
siehe 1. posting:
...Überwachung via Nagios ? ...wenn man den übeltäter dann hat (MAC und IP) was dann? Wo steht der Übeltäter? Wer ist der Übeltäter?
gibt es sinnvolle einstellungen/konfigurationsmöglichkeiten in einem heterogenem netzwerk um dem entgegenzuwirken?

mfg

#6

Zitat

lucy postete
...und eigentlich nur hierum ging es mir ---> "intrusion-detection"
siehe 1. posting:
...Überwachung via Nagios ? ...wenn man den übeltäter dann hat (MAC und IP) was dann? Wo steht der Übeltäter? Wer ist der Übeltäter?
gibt es sinnvolle einstellungen/konfigurationsmöglichkeiten in einem heterogenem netzwerk um dem entgegenzuwirken?

mfg

pff... ganz ehrlich, ich habe keine Ahnung.
Was nützt mir ne IP und MAC in nem mehrstöckigen Gebäude mit "hunderten" von Räumen? Nix.
Wenn die MAC dann auch noch nen Fake ist, hab ich eh schlechte Karten, ansonsten könnte man ja wenigsten annährungsweise das Modell/den Rechner rausbekommen anhand der MAC.
Was macht man in so nem Falle? Die Turnschuhe rausholen und schnüren?
Was anderes wird wohl nicht übrigbleiben oder?
Evtl. noch an den Schrank gehen und einzelne Etagen/Gebäuteteile mal vom Netz nehmen um den Täter einzukreisen?

TS

#7

Zitat

Was macht man in so nem Falle? Die Turnschuhe rausholen und schnüren?

...jo eben, das ist wirklich mist (hab ich also schon hinter mir)

Zitat

Evtl. noch an den Schrank gehen und einzelne Etagen/Gebäuteteile mal vom Netz nehmen um den Täter einzukreisen?

...auch das ist erstmal richtig und man muss nicht in "jedes Zimmer"

wie schaut es aus mit der anschaffung von managebaren switchen? ...die vielleicht auch SNMP tauglich sind ? ...dann muss man vielleicht doch nich die turnschuhe schnüren.

die können dann doch eventuell jeder MAC adresse (egal ob fake oder nicht) einen Switch HWPort zuordnen ...und das müsste man via SNMP abfrage doch abrufen können...
ist das denkbar?
dann muesste man eigentlich nur noch ein gespooften PING mit der absender adresse des "Bösen DHCP" an die Brodcast schicken und der SWITCH registriert dann die Antwort in seinem ARP Cache...

so jedenfalls die Theorie... ob das funktioniert? ... ich mag nämlich keine Turnschuhe...

mfg

#8 ja, ein leidiges Thema. Bei mir allerdings auch noch nicht durchgesetzt, kommt aber demnächst. Daher erstmal nur Theorie, kA ob das richtig ist, was ich da schreibe
Ergoogled habe ich folgendes:
http://support.microsoft.com/kb/303317/en-us

Zitat

Windows 2000 can block rogue DHCP servers. Each DHCP server that is part of the domain must be authorized. If a DHCP server that is part of the domain is not authorized, it will not distribute IP addresses. For additional information, click the following article number to view the article in the Microsoft Knowledge Base:
300429 How to install and configure a DHCP server in an Active Directory domain in Windows 2000

(die deutsche Übersetzung war grausig )

Wenn man einen rogue DHCP aufspüren möchte kann man ansich passiv darauf reagieren => Man installiert mehrere IDS in den Netzwerksegmenten.
Dann sollte man Regeln definieren, die jegliche DHCP- Broadcasts die nicht vom eigenen DHCP Server beantwortet werden protokolliert. Merken sollte man das auch, indem Clients, die sich an dem rogue DHCP angemeldet haben Netzwerkprobleme bekommen müßten (da falsche Netzwerksettings?). Über SNMP sollte man erkennen können, an welcher Unterverteilung der rougue DHCP angeschlossen ist.

Aktiv müßte man es verhindern können, indem man im Netz einen IPS installiert, der unbekannte DHCP- Broadcasts einfach verwirft.
__________
Woher soll ich wissen was ich denke, bevor ich höre was ich sage??
Sag NEIN zu HD+/CI+ - boykottiert die Etablierung von HD+/CI+!

#9 lucy fragte:

Zitat

wie schaut es aus mit der anschaffung von managebaren switchen?

Schaut gut aus. Auf Layer 3 sollte sich das imho handlen lassen. In der Theorie zumindest.

Hevtig tippte:
[Zitat aus http://support.microsoft.com/kb/303317/en-us]
Hm...der Aussage von MS will ich nicht so recht Glauben schenken. AD und Authorisierung hin oder her.
Ich kann mir nicht vorstellen, dass die Clients einen 'DHCP Offer' von einem Fake-DHCP abweisen werden.

Zitat

Wenn man einen rogue DHCP aufspüren möchte kann man ansich passiv darauf reagieren[..]

Für die OS aus Redmont:
"dhcploc.exe" aus dem Resource Kit spürt jegliche DHCP-Server, welche sich im selben Subnetz befinden, auf.
Besser als nichts, allerdings sollte der Befehl nicht auf dem DHCP-Server ausgeführt werden, sondern auf einem
Client.

Obwohl ich praktisch (und glücklicherweise) noch keine Erfahrungen mit Rogue DHCP Servern hatte, teile ich eure
Meinungen bezüglich der Alternativen zur Entdeckung selbiger: SNMP und/oder geeignete Sniffer.

Gruß,

Sepia

#10 also ersteinmal vielen dank für die Antworten und hätte als erstes auch gleich eine frage:

Zitat

Aktiv müßte man es verhindern können, indem man im Netz einen IPS installiert, der unbekannte DHCP- Broadcasts einfach verwirft.

wohaaa , wie soll das funktionieren? gibt es ein IPS das sowas kann?
meine theorie ist, wenn einer etwas von der broadcast nehmen kann, dann doch nur ein switch... ein paket was auf dem obersten ether (der broadcast liegt) ...wie will man das von netz ziehn? ...firewalling kann man denk ich auch vergessen... oder verstehe ich da etwas falsch oder garnicht ?

in jedem fall denke ich, ist dies ein wirklich interessantes thema und es hat mich die letzten 2 oder 3 tage ordentlich viel nerven gekostet.
wer sich diesbezueglich mal "durch das internet recherchiert" hat, der weiss aufgrund des mangels an "wirklich" hilfreichem material, jede hilfe zu schätzen.

an dieser stelle sei auch gesagt das ich nun ein ganzes stück weiter bin und zumindest für mich ersteinmal eine lösung gefunden habe, also etwas theorie in die praxis umsetzen konnte.

der auslöser für die ganze sache waren folgende, zwei komponenten:
1) ein MS Serversystem eines unserer Kunden mit gestartetem DHCP Dienst der IP Adressen aus einem Class C netzwerk verteilte
2) ein mitarbeiter, der diesen Rechner ohne erkennbaren grund in seine Netzwerkdose steckte, die in ein völlig anderes Netz, mit meinem DHCP (Linux) gepatched war.

im entsprechenden VLAN Switch segment agierten nun ab dem einschaltpunkt des servers nun zwei DHCP server, was zur folge hatte, das eine ganze abteilung auf grund falscher IP-Konfigurations informationen arbeitsunfähig wurde.
ich musste mir also meine turnschuh anziehen und quasi etage für etage abklemmen um den rogue ausfindig zu machen, üble geschichte.
danach fing meine eigentliche arbeit an, das recherchieren.
eine reaktionszeit bis hin zur lokalisierung und behebung des problems von 2 stunden ist unzumutbar aus meiner sicht und man beschäftigt u.U. 2 techniker in abhängigkeit der örtlichen gegebenheit. (mir viel nichts besseres ein ...einer "ping't" ...der andere zieht die stecker aus dem patchfeld... systematisch versteht sich

jedenfalls war dies kein "böswilliger" angriff, mehr ein "naja, was halt alles so passieren kann", ...
dennoch und zu jeder zeit ein denkbar möglicher "man-in-the-middle" Angriff auf ein netzwerk wie jedem ganz schnell klar werden muesste (lägen die verteilten Adressen auch noch im gleichem Subnetz, GUTEN TAG Herr Prall.

gegenmassnahmen injedemfall ein muss > detection und prevention < das ist mir nun klar geworden.

Zitat

Windows 2000 can block rogue DHCP servers...

dem kann ich ehrlich gesagt nur schlecht folgen und es ist in der praxis, nicht gänzlich jedoch im grossen und ganzen unbrauchbar.
es setzt denke ich mal ein homogenes MS netzwerk vorraus und entsprechende Clients muessen bereits mitglied der domain sein, da ja über die domainrichtlinien nur IP's von authorizierten DHCP servern vergeben werden (so meine theorie).
frage: was ist mit IP netzwerkdruckern? anderen OS clients? MS clients im arbeitsgruppen modell? ...und und und, die ja auch ihre IP beziehn (wollen).

da ich für meine administrativen tätigkeiten das Linux OS bevorzuge, stiess ich auf den dhcpdetector, ich denke funktoniert ähnlich wie MS dhcploc.exe.
http://www.mirrorservice.org/sites/download.sourceforge.net/pub/sourceforge/d/dh/dhcpdetector/

nachdem ich gestern auch feststellte, das man snmp nur aktivieren muss auf unseren switchen, war ich mehr als nur hochaufbegeistert.
ich hab mich dann nur noch fix mit den SNMP OID's und MIB's beschäftig und das wars.
defakto lässt sich nun über ein paar kurze und gezielte snmpwalk's der schädling HWSwitch port genau lokalisieren, insofern seine MAC sich im ARP cache befinden.
und sie befinden sich definitiv (zumindest bei mir) im cache... musste also nichts spoofen, denn scheinbar werden die MAC's aller nicht "unicast" pakete gecached... dazu gehören wohl auch DHCP pakete.
die internen switch (MAC)routingtabellen sind jedenfalls nicht via SNMP abrufbar.
bei der gelegenheit stellte ich zu meiner freude auch fest, das man auch jeden CLient am switch port ausfindig machen kann, dazu muss man ein broadcast paket (so war ja meine theorie ) mit der zu identifizierenden IP spoofen und schon befindet sich die MAC des clients im ARP cache des switch und kann via snmp dem entsprechenden Port zugewiesen werden.
dies ist in der tat ganz praktisch, denn jeder admin kennt ja den kabelsalat in seinem patch schrank, quasi "wo geht welches kabel hin".
das interssiert mich nun auch nicht mehr... denn das bekomm ich ja nun sehr schnell raus.

das ende vom lied ist also, mit einem "kleinem shellscript" ...einem "dhcpdetect cronjob" kann ich nun mein netzwerk auf unreglmässigkeiten diesbezueglich überwachen...
natuerlich ist ein zeitgesteuerter job nicht so gut wie ein aktives IDS, das sofort mitbekommt wann ein rogue auftaucht...

das würde mich noch interessieren, gibt es hier nette tools die das tun? ...auf den ersten blick fällt mir da ntop ein, ...aber hola... das ist auch so ein brocken und muss mich noch mit befassen... gibts auch weniger komplexe anwendungen?

JJAAA und heute... werde ich mit "snmpset" beschäftigen, ein script schreiben, das den identifizierten schädling und seinem switchport sofort sperrt...
schon erstaunlich was so alles geht, wenn man es nur weiss^^

das nenne ich doch mal prevention was... jedenfalls bin ich so habby und hoffe das mir dies nichtnochmal passiert...


danke an alle, love u ... und sorry für die lange geschichte
P:S euphorie ist schuld ^^

LG

Zitat