Elimineren van rogue DHCP servers

[Verwijderd]

Zoals iedereen weet is een roque DHCP server in je netwerk moordend. Het opsporen hiervan is niet zo moeilijk:

- start een sniffer en sjek voor DHCP traffic
- trace het MAC address op je core switch etc.

Zoals iedereen ook weet gaat een NT4 DHCP server uit als er een Windows 2000 DHCP server in het netwerk aanwezig is.

Maar wat ik nergens kan vinden is een tool ( behalve een moker of hamer ) om een DHCP server uit te schakelen ( op afstand dus ).

Heeft er iemand een id

[Koffie]

net stop \\servername dhcpsrvr

Move PNS > SA

[F_J_K]

offtopic:
Ik maak er even rogue ipv roque van in de titel, zoekt even beter zonDer spelfout

Verder heeft Koffie alles al gezegd geloof ik

[ Voor 3% gewijzigd door F_J_K op 20-02-2003 14:19 . Reden: OMG :X ]

[QBiT]

Als ik het goed begrijp wil je weten hoe je er voor kan zorgen dat niet iedereen een dhcp in je netwerk kan hangen ?? niet hoe je em remote kan beheren ? volgensmij geef je het antwoord zelf al. MEt windows 2000/ADS kan je een Roque dhcp uitschakelen. Wel moeten al je dhcps dan win2k zijn (of heb je ook nt4 dhcps ?) ander oplossing zou ik niet weten. heb ik ook nog nooit wat over gehoord.

[Verwijderd]

De andere computers zitten niet in mijn domain, dit is helaas niet software gerelateerd maar netwerk gerelateerd een MOD heeft m'n topic naar Software Algemeen gesleept. Het gaat er dus om dat Windows DHCP servers elkaar kunnen stoppen. De gene met de nieuwste versie die "wint" en blijft aan. Degene met de oude versie gaat uit.

Wat mijn vraag dus was of iemand een tool heeft geschreven die dit voor jouw kan doen. ( dus de dhcp server uit te schakelen door ze te laten denken dat er een nieuwere versie van een dhcp server in het netwerk aan wezig is )

Verder hebben we al DHCP blocks in de access lists van de core switch dus hierdoor geeft de rogue dhcp server alleen maar ip adressen uit op 24 porten van je netwerk ( in totaal bij ons 1038 clients en een stuk of 40 servers )

Helaas zijn er teveel stand alone clients waar wij dus geen beheer rechten over hebben en dus ook niet met net stop deze services kunnen stoppen. De oplossing boven genoemd is dus absoluut niet relevant in dit verhaal omdat ik het me niet kan veroorloven mezelf beheersrechten te verschaffen op deze client omdat dit in strijd is met de wet.

Ik hoop dat ik mijn probleem zo duidelijker over komt.

[Verwijderd]

F_J_K schreef op 11 February 2003 @ 22:01:

offtopic:
Ik maak er even rogue ipv roque van in de titel, zoekt even beter zoner spelfout

Verder heeft Koffie alles al gezegd geloof ik

ehehe

[Shuriken]

Als je een pure (native) Win 2000 omgeving hebt, dan moet elke DHCP server geauthenticeerd zijn in de Active Directory voordat clients een ip van em mogen ontvangen.

Zodoende kan je voorkomen dat er zich rogue DHCP servers in het netwerk nestelen.

[Verwijderd]

Ik draai geen active directory, en het is ook geen optie om dit wel te gaan doen

tnx anyway

[ Voor 55% gewijzigd door Verwijderd op 20-02-2003 14:23 . Reden: iets aardiger had gekunt :P ]

[MSalters]

Als je weet waar de DHCP server zit kun je dan niet z'n adrespool exhausten? Dus gewoon alle adressen claimen voor gefake'te MACs?

[alt-92]

In de win2k resource kit zit wel Dhcpobjs.exe...

DHCP Objects is an automation object-model library for the Microsoft® DHCP server. It allows administrators and developers to write applications and scripts to administer a DHCP server remotely. It provides enhanced capabilities over Dhcpcmd.exe (a tool included in the Microsoft® Windows® 2000 Support Tools), such as the ability to remove a DHCP lease.

Daarnaast zou je met dhcpcmd dat ding ook van z'n subnet kunnen strippen enzo, alleen vermoed ik dat je dan weer de rechten mist...

Verwijderd schreef op 20 February 2003 @ 13:57:
De andere computers zitten niet in mijn domain,
[.....]
Helaas zijn er teveel stand alone clients waar wij dus geen beheer rechten over hebben
[....]... ik het me niet kan veroorloven mezelf beheersrechten te verschaffen op deze client omdat dit in strijd is met de wet.

Zoveel last van rogue cq andermans DHCP servers in je eigen netwerk?
Ben ik toch heel nieuwsgierig naar de network layout geworden nu

[Aetje]

Meerdere virtuele netwerken over dezelfde fysieke interface... en dan alles op meerdere DHCP's? Geen wonder dat 't fout gaat... Ik zou de clients die je beheert gewoon statisch een ip toewijzen. Eventuele mobiele clients via een klein routertje op een andere IP range gooien (ook veel makkelijker te beveiligen).

[_nethack]

Verwijderd schreef op 20 February 2003 @ 13:57:
Helaas zijn er teveel stand alone clients waar wij dus geen beheer rechten over hebben en dus ook niet met net stop deze services kunnen stoppen. De oplossing boven genoemd is dus absoluut niet relevant in dit verhaal omdat ik het me niet kan veroorloven mezelf beheersrechten te verschaffen op deze client omdat dit in strijd is met de wet.

Als je de betreffende machine hebt gelokaliseerd de eigenaar daarvan inlichten dat ie x tijd heeft om die dhcpserver te killen omdat anders er 'ineens' een poort op de switch shutdown gaat.

Of andersom, de machine van het netwerk afsluiten en pas weer toegang verschaffen op het moment dat de eigenaar jou plechtig heeft belooft dat die dhcp server eraf cq. uitgeschakeld is en dat ook blijft.

[Zwelgje]

met een sniffer achterhalen welke machine de rogue dhcp server is dan deze dan op de switchport disabelen... Exit rogue dhcp servers...

of beter nog (als je een goede switch heb) gewoon even het dhcp poortje blocken... ben je er ook vanaf, kan die machine alles nog doen behalve als dhcp server dienen

[Verwijderd]

Ik vraag me af wat voor netwerk het is. In een niet zo ver verleden had ik te maken met een ISP waarbij nogal wat hobbyisten rondliepen asl KLANT.
Die hadden dan thuis een netwerkje en programma's als sygate draaien om internet toegang te sharen.
Sommigen van die hobyisten prutsten dan maar wat en lieten rustig sygate op hun externe NIC ip adressen uitdelen. Dat soort rogue dhcp servertjes zijn minimaal irritant te noemen. Op zo'n manier lag dan de hele ring eruit. Enige manier om dan weer direct een werkende internetconnectie te krijgen was om ip adres/subnetmask/DNS er hard in de tcp/ip properties te zetten.

[Aetje]

Beetje ISP blokt toch zeker DHCP servers waar er clients horen te zitten???

[raymonvdm]

En hoe wou je dit blokkeren je kan niet de dhcp poort dichtspijkeren (69 dacht ik) want dan krijgen je clients ook niks meer.

Wij hebben het dus pass geleden gehad een persoon die met win2k ging spelen alles in eens een 10.0.0.* adres in plaats van onze standaard reeks.

Toch 4 uur bezig geweest om hem te vinden.

Maar ja wat wil je met een groot gebouw.

[alt-92]

raymonvdm schreef op 21 februari 2003 @ 00:38:
En hoe wou je dit blokkeren je kan niet de dhcp poort dichtspijkeren (69 dacht ik) want dan krijgen je clients ook niks meer.

67/68, 69 is tftp (kijk in %systemroot%\system32\drivers\etc\services )

Als je goeie apparatuur hebt, kun je bijv. per VLAN poort filteren op DHCP.
Dus als je aan 1 poort een /24 hebt hangen kun je de DHCP server daar isoleren, zodat de rest er geen last van heeft.

[Verwijderd]

Hmm je kan het per poort dichtgooien omdat de server de bootps poort gebruikt en de client de bootpc poort. Hierdoor kan je de bootps packets die van de poort waarachter je server farm zit en dus ook je dhcp server toelaten en op de overige poorten packetjes met als source poort bootps ( UDP ) blocken.

Opzich is het niet een super groot probleem dat er ergens een rogue dhcptje komt te staan. Vlanning is helaas geen optie omdat de subnetbroadcast bij alle clients moet aankomen.

Het DHCP probleem is dus al geconcentreerd tot één poort ( dus een switch die erachter hangt ).

Het detecteren van rogue DHCP servers is niet zo heel moeilijk met een sniffer vindt je het MAC address binnen no time.

Dat we DHCP gebruiken kunnen we niet vanaf. Maar veel mensen gebruiken tegenwoordig Windows Connection Sharing, Sygate ed. met een DHCP server enabled .

Een ping -f blijft even een goeie oplossing totdat je de dader fysiek hebt gevonden, de DHCP server die als eerste reageert geeft nl. de lease uit tenzij de rogue nog optijd een DHCP nack kan sturen ( maar dit doet de dhcp van connection shareing of sygate ed. niet ) een rogue linux doet dit wel dus dan krijgt niemand meer een ip toegewezen achter die switch.

Opzich blijft het een leuk item om over te babbellen.

Tnx voor alle reply's

[Verwijderd]

Zoveel last van rogue cq andermans DHCP servers in je eigen netwerk?
Ben ik toch heel nieuwsgierig naar de network layout geworden nu

Hehe het is een netwerk dat een weekend staat waar veel mensen het komen abusen en alle clients die er komen te staan zijn niet van ons ...

Nou moet je het wel kunnen raden toch

[ Voor 1% gewijzigd door Verwijderd op 21-02-2003 10:30 . Reden: fout in de code ]

[blackd]

-> NT

[Verwijderd]

blackd schreef op 21 February 2003 @ 12:51:
-> NT

Misschien iets van Network security maken ofzo ? offuh Security algemeen .... zou die ook mooi in passen

[Verwijderd]

iedere dhcp server zijn ip adres is genoteerd in de lease op de client dus die dhcp server is zo gevonden. ksnap het probleem dus niet helemaal.

ipconfig /all zou op een slachtoffer voldoende moeten zijn.

[ Voor 20% gewijzigd door Verwijderd op 21-02-2003 16:34 ]

[Verwijderd]

Als je netwerk-id b.v. 10 is en iemand deelt leases uit met network-id 192.168 kan je dus alleen zoeken op het mac adress dit is alleen te vinden over managed switches en op je core kan je vinden achter welke poort de switch zit.

Aan de hand van je netwerk tekeningen kan je dus vinden waar die poort op uit komt. Het gaat hier ook niet ovet het vinden van DHCP servers. Dat is stukje koek.

[ Voor 1% gewijzigd door Verwijderd op 21-02-2003 20:04 . Reden: :P ]

[Guru Evi]

Een beetje goeie Switch laat je poorten blokkeren (Layer3-switch) en blokkeer dan de BOOTPS poort in de richting van je eigen netwerk (je kunt richtingen instellen in de meeste firewalls/switchen he)
De server geeft op de BOOTPS poort een DHCP lease in de richting van de BOOTPC poort. De client geeft eerst een broadcast van de BOOTPC poort. Als je nu voor de clients de BOOTPS poort sluit in de richting van je netwerk is je probleem opgelost.

[Verwijderd]

Hmm je kan het per poort dichtgooien omdat de server de bootps poort gebruikt en de client de bootpc poort. Hierdoor kan je de bootps packets die van de poort waarachter je server farm zit en dus ook je dhcp server toelaten en op de overige poorten packetjes met als source poort bootps ( UDP ) blocken.

read

---
zoals ik al eerder vertelt heb zijn niet alle switches managed en dan nog moeten zie iets hebben als een access-lists wat dus niet alle managed switches hebben .... ik praat hier over meer dan 42 switches aangesloten op een extreme networks core ... niet 2 switches ofzo met een gigabit uplinkje ertussen ....

plaatje van de core op 2002

[ Voor 47% gewijzigd door Verwijderd op 21-02-2003 20:03 ]

[Verwijderd]

Niet manageble switches is zowiezo al niet erg professioneel en ik neem toch wel aan dat je routeerd op je backbone switch anders vraag je om de genoemde problemen.

[Verwijderd]

elke switch die we kunnen krijgen is welkom .... het netwerk is plain ... geen vhosts ... geen routatie .. wel QoS en een access-list, dit geeft meer voordelen als nadelen in ons geval. Een paar DHCP servertjes moeten we dus maar accepteren.