Archive for the ‘DHCP’ Category

Warum schaltet sich dieser verdammte DHCP-Dienst am Windows Server ständig ab? Was hat das mit IPv6 zu tun?

5 Dezember 2016

Irgendwie stand ich gerade auf dem Schlauch und hab mich mit einem Problem länger als nötig beschäftigt um am Ende festzustellen, die Lösung ist logisch und ganz einfach. Es ging los, dass bei einem Kunden der Speedport gegen eine Fritzbox ausgetauscht werden sollte.

Zu Beginn war alles ganz einfach, Internetverbindung war schnell da. Aber dann gab es Probleme im Netz mit den Client-Rechnern nach einem Neustart. Dazu muss man wissen, dass bei der Fritzbox der IPv4-DHCP ausgeschaltet wurde. Egal wie oft man nun am Windows Server den DHCP-Server neu gestartet hat, er funktionierte immer kurz und war dann wieder ausgeschaltet. Sowas kennt man wenn ein zweiter DHCP-Server im Netz ist. Also nochmal auf der Fritzbox versichert, dass der Ipv4-DHCP ausgeschaltet war. Am Ende war nur noch der Server mit dem Client mit der Fritzbox verbunden. Klappte aber immer noch nicht!

Wo schaut man nach, wenn man solche Probleme hat? Richtig, in der Ereignisanzeige. Also kurz nach den DHCP-Server Logs geschaut:

Get-WinEvent -ListLog *dhcp*|select logname

LogName
——-
Microsoft-Windows-Dhcp-Client/Admin
Microsoft-Windows-Dhcp-Client/Operational
Microsoft-Windows-Dhcp-Server/FilterNotifications
Microsoft-Windows-Dhcp-Server/Operational
Microsoft-Windows-DhcpNap/Admin
Microsoft-Windows-DhcpNap/Operational
Microsoft-Windows-Dhcpv6-Client/Admin
Microsoft-Windows-Dhcpv6-Client/Operational

Ah alles klar:

Get-WinEvent -LogName Microsoft-Windows-Dhcp-Server/Operational -MaxEvents 10

TimeCreated                   ProviderName                                             Id Message
———–                   ————                                             — ——-
17.12.2015 12:52:43           Microsoft-Windows-DHCP-Server                           106 Die Rese
17.12.2015 12:52:43           Microsoft-Windows-DHCP-Server                           107 Die Rese
17.12.2015 12:49:25           Microsoft-Windows-DHCP-Server                           106 Die Rese
17.12.2015 12:48:23           Microsoft-Windows-DHCP-Server                           107 Die Rese
25.11.2015 09:12:51           Microsoft-Windows-DHCP-Server                           106 Die Rese
25.11.2015 09:12:24           Microsoft-Windows-DHCP-Server                           107 Die Rese
21.05.2014 14:25:11           Microsoft-Windows-DHCP-Server                           106 Die Rese

Wie 2015? Ich hab aktuell Problem und nicht 2015! Hä? Was geht hier. Auf jeden Fall ist es wie immer man sucht überall aber nicht an der richtigen Stelle!!!!

Irgendwann dachte ich, dass kann nicht sein und klar es war so. Denn man sollte ja auch wegen DHCP-Server Meldungen nicht bei Microsoft-Windows-DHCP-Server schauen sondern unter SYSTEM!!!! Ich könnte so kotzen…

Also mittels

Get-WinEvent -LogName system -MaxEvents 20

TimeCreated                   ProviderName                                             Id Message
———–                   ————                                             — ——-
05.12.2016 14:52:32           Service Control Manager                                7040 Der Starttyp des Diensts "…
05.12.2016 14:50:02           Microsoft-Windows-GroupPolicy                          1500 Die Gruppenrichtlinieneins…
05.12.2016 14:50:01           Microsoft-Windows-GroupPolicy                          1500 Die Gruppenrichtlinieneins…
05.12.2016 14:49:56           Service Control Manager                                7036 Dienst "Windows Modules In…
05.12.2016 14:49:25           Microsoft-Windows-DHCP-Server                          1043 Es wurde festgestellt, das…
05.12.2016 14:49:05           Service Control Manager                                7036 Dienst "DHCP-Server" befin…
05.12.2016 14:49:01           Microsoft-Windows-DHCP-Server                          1056 Der DHCP-Dienst wird auf e…
05.12.2016 14:45:31           Service Control Manager                                7036 Dienst "DHCP-Server" befin…
05.12.2016 14:45:31           Microsoft-Windows-DHCP-Server                          1054 Der DHCP/BINL-Dienst auf d…
05.12.2016 14:45:31           Microsoft-Windows-DHCP-Server                          1053 Der DHCP/BINL-Dienst hat e…
05.12.2016 14:45:19           Service Control Manager                                7036 Dienst "DHCP-Server" befin…
05.12.2016 14:45:15           Microsoft-Windows-DHCP-Server                          1056 Der DHCP-Dienst wird auf e…
05.12.2016 14:45:03           Microsoft-Windows-GroupPolicy                          1500 Die Gruppenrichtlinieneins…

geschaut und hier tauchen dann auch die üblichen Verdächtigen DHCP/BINL-Meldungen auf! Wenn man nun genauer nachschaut, wird es auch offensichtlich:

Get-WinEvent -LogName system -MaxEvents 20| where {$_.id -eq 1053}| ft message -Wrap

Message
——-
Der DHCP/BINL-Dienst hat einen anderen Server mit der IP-Adresse fe80::3a10:d5ff:fe89:bb02 in diesem Netzwerk ermittelt
, der zu der folgenden Domäne gehört: .

Also wo liegt nun das Problem? Warum hab ich oben immer geschrieben, dass ich den IPv4DHCP ausgeschaltet habe? Na klar, weil die Fritzbox auch noch einen IPv6DHCP hat und dieser munter weiter aktiv war. Und da im Netz nunmal unabhängig von IPv4 und IPv6 nur ein DHCP aktiv sein war, hat sich der Windows DHCP-Server immer schneller verabschiedet!

Also Lösung: Entweder IPv6 ganz abschalten oder den IPv6DHCP abschalten! Besser ist natürlich die zweite Variante.

Mal abgesehen davon, dass ich hätte schneller drauf kommen können. ist mir erst durch diese Geschichte wieder aufgefallen, wie inkonsistent die DHCP-Dienst-Sache unter Windowsservern ist. Einfach nur traurig…

Werbeanzeigen

Was gibt der Registrierungsschlüssel DHCPGatewayHardware her? Oder – wie kann man alternativ per Powershell das DHCP-IPv4-Gateway ermitteln?

28 September 2015

Hier mal etwas für Forensiker. Aus der Not geboren, dass nur eine Fernwartung beim Kunden möglich war – die nur einmal aufgebaut werden konnte, galt es herauszufinden, warum Netzprobleme bei der IPv4-Adressvergabe auftraten. Eigentlich sollten die Clientrechner IP-Adressen im Bereich 192.168.0.X bekommen aber effektiv bekamen fast alle Rechner eine im Bereich 192.168.1.X. Dadurch war kein Internetzugang mehr möglich und auch der Fileserver unter 192.168.0.1 war nicht mehr erreichbar. Da im konkreten Fall ein Speedport mit der Adresse 192.168.0.100 der DHCP-Server war, wurde zunächst eine Station mit einer fixen IP-Adresse im Bereich des Speedport versehen. Von dort aus war dann der Zugriff zum Speedport möglich. Auch das Internet mit einer Fernwartungssitzung klappte dadurch wieder. Jetzt galt es aber rauszubekommen, warum die Rechner teilweise falsche IP-Adresse bekamen. Nur wie macht man das, wenn man auf der einzigen Netzwerkkarte per Fernwartung aufgeschaltet ist?

Zunächst versuchte ich Scapy per Python ans laufen zu bekommen,  um dieses Script ausführen zu können: https://bitbucket.org/secdev/scapy/wiki/doc/IdentifyingRogueDHCPServers. Die Idee war ganz einfach einen Netzwerkmitschnitt über DHCP-Server-Ankündigungen zu machen. Aber leider beschwerte sich Scapy, beim Versuch der Installation, ständig über eine weitere, fehlende Abhängigkeit. Am Ende lief es auf jeden Fall nicht.

Wireshark wäre noch eine Option gewesen, da die WinPCap-Treiber wegen Scapy eh schon installiert waren. Aber Wireshark kann jeder.

Wie immer wäre mir eine Powershell-Lösung die liebste, aber leider gibt es noch nichts Vergleichbares zu Scapy. Bei der Suche nach der Powershell-Lösung bin ich allerdings über diesen Artikel gestolpert: http://www.ingmarverheij.com/read-dhcp-options-received-by-the-client/. Ich hatte zwar beim betreffenden Windows 7 Rechner keinen Eintrag mit DhcpInterfaceOptions aber zumindest der Eintrag DhcpGatewayHardware war vorhanden. Der Eintrag war als REG_BINARY mit dem Wert

c0 a8 01 01 06 00 00 00 e8 fc af ab c0 24

eingetragen. Der Wert von DhcpGatewayHardware ist zu finden unter HKLM\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces\{GUID}.

Per Powershell erreicht man den Wert über

$a = gwmi Win32_NetworkadapterConfiguration
$i = $a | where {$_.Description –like "*Intel*"}

$i.SettingID

$si = $i.SettingID

$ri = Get-ItemProperty -path "registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces\$si" -name dhcpgatewayhardware | select DHCPGatewayHardware

$ri

Bei *Intel* sollte man den Hersteller seiner Netzwerkarte eintragen, für Realtek z. B. *Realt*, wenn es mehrere geben sollte, muss natürlich die betreffende herausgefiltert werden. Das entscheidende dabei ist, dass man die GUID der SettingID bekommt, über welche man weiß wo man in der Registrierung bei den Interfaces suchen muss.

Auf jeden Fall bekommt man am Ende bei $ri z. B.  diese Ausgabe:

DhcpGatewayHardware
——————-
{192, 168, 1, 1…}

Man sieht bereits, dies ist der falsche Wert, der am Anfang dafür gesorgt hatte, dass der Kunde nicht arbeiten konnte. Das interessante dabei ist, 192.168.1.1 entspricht hexadezimal genau “c0 a8 01 01”, die grüne Markierung verdeutlicht nochmal den Zusammenhang. Also ist der Zusammenhang schon mal hergestellt. Der hintere Wert e8 fc af ab c0 24 sieht wie eine MAC-Adresse aus, denn warum sonst sollte Microsoft den Eintrag DhcpGatewayHardware nennen?

Also noch die Bytes 8-14 ausgelesen und daraus eine MAC-Adresse gebastelt:

$mac=$ri.DhcpGatewayHardware[8..14]
$mac=$mac| foreach {$new=""} {$new+="{0:x02}:" -f $_} {$new}
$mac=$mac.TrimEnd(":")

$mac

Nun hat man in $mac die MAC-Adresse des DHCP-Servers, welcher die IP-Adresse 192.168.1.1 geliefert hatte.

Also mal Google bemüht und dies gefunden: http://macaddress.webwat.ch/hwaddr/E8:FC:AF. Hier wird E8:FC:AF Netgear zugeordnet:

Device mac address: E8:FC:AF
Base16 encoding: E8FCAF
producer name: NETGEAR INC.,

producer address:

350 EAST PLUMERIA DRIVE
SAN JOSE CALIFORNIA 95134
UNITED STATES

Jetzt galt es nur noch ein Gerät ausfindig zu machen. Aber mit dem Wissen, dass es sich um ein Netgear Gerät handelte, war der weitere Weg wesentlich einfacher, als wenn es irgendein Gerät im Netz gewesen wäre. Vor allem war dadurch auch klar, dass es sich nicht um einen gefakten bzw. Rogue-DHCP-Server handelte, welcher eine Attacke im Netz ritt.

Übrigens: Bei einem korrekt konfigurierten und funktionierendem Netz bekommt man, bei Anwendung obigen Scripts, einfach das Gateway mit der betreffenden MAC-Adresse, wenn DHCP aktiviert ist.

DHCP Dienst auf Windows SBS2003 startet mit DHCP/BINL-Dienst Fehlermeldung nicht

15 März 2013

Auf einem Windows Small Business Server 2003 mussten beide Netzwerkkarten ausgetauscht. Die eine war für das interne LAN und die andere für das Internet zuständig. Nach dem Zuordnen der fixen IP-Adressen kam es nach dem Neustart des Servers zu dieser Fehlermeldung mit Ereigniskennung 1053 in der Windows Ereignisanzeige unter System:

Der DHCP/BINL-Dienst auf diesem Computer mit Windows Server 2003 für Small Business Server hat einen anderen Server (mit IP-Adresse 192.168.100.2, der zur der Domäne  gehört) ermittelt.

Dabei war die Adresse 192.168.100.2 die Adresse des Gateways, welche im externen Netz auch einen DHCP Server betreibt. Der DHCP-Server konnte zwar manuell gestartet werden aber ging innerhalb ein paar Sekunden sofort mit obiger Fehlermeldung wieder aus. Wie lässt sich dieses Problem nun lösen?

Eigentlich ganz einfach, man schaltet den DHCP im Netz von 192.168.100.0 ab. Aber das ist nicht die Lösung, wenn man darauf keinen Einfluss hat.

Die Lösung brachte dann, als temporär der falsche DHCP-Server ausgeblendet war, also Kabel ziehen und der DHCP-Dienst  lief ohne Probleme an. DHCP Verwaltung geöffnet und nun konnte im betreffenden Server unter Eigenschaften das Register Erweitert geöffnet werden. Dort findet man den Punkt “Verbindungen der Serververbindung ändern”, wo man Bindungen anklickt. Es präsentieren sich die verfügbaren LAN-Verbindungen, wo im besagten Fall tatsächlich beide aktiv waren. Also beim richtigen Netz das Häkchen weg und alles war paletti.