Vista und Macintosh Probleme mit DHCP-Server

Mal eben zum festhalten… Es gab in hier in Goettingen in verschiedenen Wohnheimen (z.B. C-Weg und Kolosseum) Probleme mit neu aufgesetzen Routern. Der DHCP-Server vergab IP-Adressen, die dann Vista oder Macintosh Clients nicht mehr annahmen. Bei diesen Clients entwickelte sich eine DHCPDISCOVER – DHCPOFFER Kommunikation, zu einem DHCPREQUEST kam es nicht mehr. Workaround war in den Wohnheimen fuer eine kuerzere oder laengere Zeit, bei all diesen Clients dann die IP fest von Hand einzutragen. Bei einem DHCP-Server eine doch sehr unschoene Loesung.

Erst hab ich ein bisschen im Netz gesucht und gedacht es wuerde an dem bekannten Broadcast-Problem liegen (MS-Knowledgebase Artikel). Wars aber nich. Nach einigem Konfigurationsdateien lesen war dann der Fehler lokalisiert. Es lag an dem:

 server-identifier hostname;

in der /etc/dhcp3/dhcpd.conf (bzw. in den Wohnheimen in der entsprechenden .skel Datei des eingesetzten netconfig-Skripts). Das einmal geaendert in

 server-identifier 123.123.123.123;

machte alle vorher aufgetretenen Probleme obsolet. Und nu fuer die Suchmaschinen-Welt:

Debian Etch. Ubuntu, DHCP, DHCP-Server, Vista, Macintosh, Apple, OS X, dhcpd.conf, kein DHCPREQUEST, nimmt IP nicht an, Broadcast

check_rogue – Nagios Plugin zum erkennen von rogue DHCP

Bereits vor einiger Zeit schrieb ich darueber, dass wir bei uns im Wohnheim Probleme mit einem rogue DHCP hatten. Vorlon schrieb in einem Comment, das auch das SANS Diary das Problem beschreibt. Auch Heise war das ganze inzwischen einen Artikel wert! Wir haben bei uns im Internettutorium verschiedene Gegenmassnamen ergriffen, die fuer andere evtl. auch von Interesse sein koennen, deswegen an dieser Stelle mal kurz festgehalten:

Sperrung via iptables

Bei uns in der Firewall wird die gesamte Range in der die „boesen“ DNS-Server stehen auf Port 53 gesperrt. Der Zugriff wird geloggt, und stuendlich checken wir die Logfiles, ob es einen Zugriff gab. Wenn ja, dann gibts ne Mail.

Die iptables-Regeln im Firewall Skript lauten wie folgt:

iptables -F ukr_dns
iptables -X ukr_dns
iptables -N ukr_dns
iptables -A ukr_dns -j LOG -m limit --limit 90/h --log-prefix "FW: MALDNS "
iptables -A ukr_dns -j REJECT
iptables -I FORWARD -p udp --dport 53 -d 85.255.112.0/255.255.255.0 -j ukr_dns
iptables -I FORWARD -p tcp --dport 53 -d 85.255.112.0/255.255.255.0 -j ukr_dns

Der dazugehoerige crontab-Einzeiler-Eintrag lautet wie folgt:

0 *     * * *    root    /bin/grep MALDNS /var/log/syslog | grep -v CRON | \
mail -e -s "MALDNS-Report /bin/date -I" vir-reports@mydomain.tld

check auf rogue DHCP mit Nagios

neben dieser mehr schadensbegrenzenden Massname wenn bereits etwas passiert ist, ueberpruefen wir unser Netz auf rogue DHCP Server mit einem Nagios-Skript. Das Skript ist ein Wrapper zu dhcp_probe.
Leider ist dhcp_probe nicht direkt fuer Debian Linux verfuegbar. Das bedeutet im Klartext, dass ein bisschen Handarbeit angesagt ist, zumal es auch unter Debian Linux erst nach einer Modifikation von libnet funktioniert.

Als erstes muss man natuerlich die benoetigten *-dev Pakete installieren und wenn nicht bereits passiert auch die build-essential

aptitude install libpcap-dev build-essential

Das installieren vom libnet-dev Paket aus apt wuerde das compilieren von dhcp_probe nicht zu einem Erfolg bewegen, da die in Debian etch enthaltene Version eine wichtige Funktion nicht mitbringt. Siehe dazu auch den entsprechenden Eintrag in der INSTALL.dhcp_probe. Deswegen lautet der naechste Schritt libnet herunterzuladen, entpacken und entsprechend zu patchen.

wget http://www.packetfactory.net/libnet/dist/libnet.tar.gz
tar -xzvf libnet.tar.gz

Wie in der bereits verlinkten INSTALL.dhcp_probe unter Punkt 2. beschrieben nun die beiden Dateien ./src/libnet_cq.c und ./include/libnet/libnet-functions.h bearbeiten, den entsprechenden Code unten einfuegen. Der Dreisatz aus ./configure, make sowie make install als root fuehrt einen dann zum gewuenschten Ergebnis.
Ab dieser Stelle ist nun auch ein compilieren von dhcp_probe von Erfolg gekroent.

wget http://www.net.princeton.edu/software/dhcp_probe/dhcp_probe-1.2.2.tar.gz

entpacken, compilieren und installieren. Wenn man bis zu diesem Punkt ohne Fehler gekommen ist, ist schon der grossteil der Arbeit geschafft. Es fehlt noch dhcp_probe zu konfigurieren. Eine Beispiel-Konfigurationsdatei liegt dem Quelltext mit bei. Einfach aus dem entpackten Verzeichnis heraus ein

cp extras/dhcp_probe.cf.sample /etc/dhcp_probe.cf

machen und durchlesen. Der wichtigste Eintrag ist der Punkt legal_server, bei dem evtl. intendiert vorhandene Server angegeben werden sollten. Uebrigens ein guter Punkt bei dem man testen kann, ob dhcp_probe auch gut funktioniert.

Wenn all diese Vorraussetzungen erfuellt sind, kommt es endlich zu dem Nagios wrapper Skript fuer dhcp_probe. Die folgende Datei /usr/lib/nagios/plugins/ ablegen:

Nun noch fix in Nagios ein command und definiert:

/etc/nagios2/commands.cfg

define command{
        command_name    check_rogue
        command_line    $USER1$/check_rogue
        }

und schon kann ich den Check auf dem Client einrichten, auf dem das Skript liegt und dhcp_probe installiert ist. Bei uns sieht das ganze dann so aus:

nag_rogue_ok

nag_rogue_detected

Ja, ich weiss, das das Plugin nicht schoen geschrieben ist, aber es tut seinen zweck. Und an dieser Stelle nochmal herzlichen Dank an Matthias, Alex und Sebastian bei der Hilfe das ganze zu entdecken und zu beheben etc. :-)

Supportanfragen: HALL OF FAME

Ich muss das jetzt so langsam mal festhalten. Eigentlich koennt ich auch nen eigenen Blog aufmachen damit, aber ich bleibe mal bei diesem hier. Wie ihr ja alle wisst habe ich taeglich first-level-support Userkontakt, obwohl das nicht wirklich mein Job ist, egal. Oft ist es ja auch extrem witzig, so dass auf meiner Unterlippe noch Stunden spaeter die Bissspuren zu sehen sind…

Hier mal kurz drei echt gute Anfragen festgehalten:

  1. Anruf: „Herr Toenjes, …. *pause* … *schluck* …. ich habe das Internet geloescht!“
    Ich konnte mir nicht verkneifen darauf zu Antworten: „Ich seh mal nach ob ichs noch auf CD im Schrank hab.“ … Nachdem der User sein Firefox-Icon wieder auf dem Desktop hatte, war das Problem geloesst…
  2. Email: „Sehr geehrter Herr Toenjes. Ich sitze gerade vor meinem Dienstrechner und mein Internet geht hier nicht, deswegen schreibe ich Ihnen diese Email…“ <- Da scheint jemand elementare Zusammenhaenge begriffen zu haben!
    Nachdem die Startseite im Browser des Users wieder zu einer existierenden Seite zeigte, war das Internet repariert….
  3. Neben mir steht eine voellig aufgeloeste junge Frau: „Sir, my internet is broken. It used to work for 2 years without any problem, and now it’s just gone… I can’t do anything anymore, can you help me please?“ …. Die Loesung war das druecken der F11 Taste in Firefox…..

to be continued