Xen, BackupPC und speed2fritz && Freetz

Mit allem habe ich mich an diesem Wochenende sehr intensiv und zum Ende auch erfolgreich beschaeftigt. Ich wollte zu alldem noch was schreiben, aber ich bin zu platt, deswegen nur die Ergebnisse:

  • Xen – Ersten produktiven Xen-Server unter Debian vollstaendig aufgesetzt, 3 Maschinen in domUs migriert, Monitoring der VMs via Nagios
  • BackupPC – Bevor das Backup von unserem Wohnheim-Webserver ausgefuehrt wird, werden nun die MySQL DBs darauf via Skript gesichert
  • speed2fritz && Freetz – Meinen Speedport W701V neu geflasht und Freetz hinzugefuegt. Jetzt u.a. mit WOL-Webinterface

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. :-)

Viele Server updaten 2

Vor einigen Tagen hatte ich kurz ueber die Problematik geschrieben, wie man mehrere Debian-Server mit einem Befehl updaten kann. Ich hatte das mit einer kurze for-Schleife in bash gemacht die mir da ausreichte und gesagt ich wuerde mir onall noch einmal genauer angucken.

Heute nacht gabs nun von Debian wieder ein update, libxml2, und mein Nagios blinkte rot. Das hab ich zum Anlass genommen um nun eine „richtige“ Loesung zu implementieren. Es fiel nicht auf onall sondern auf pssh. Der Grund ist ganz einfach, dass pssh bei mir im portage-Tree ist, und onall nicht ;-)

Kurz 2-3 Ueberlegungen vorweg. Ich habe eine ssh-Key Infrastruktur ohne Passwort aufgebaut dafuer. Das ist natuerlich ein Sicherheitsrisiko. Ich empfinde es dennoch als sicher, da die Rechner alle nur in privaten Netzwerken sind bzw., wenn Sie feste IPs haben, via iptables beschraenkt sind. Bei den wichtigsten Servern ist darueber noch der standart SSH-Port veraendert und natuerlich ist der Zugriff ueberall noch per AllowUsers oder AllowGroups (man sshd_config) geregelt… Auch kann ich nur von einem bestimmten Rechner ohne Passwort mit dem entsprechenden Key zugreifen und der ist sicher ;-)

Nun zur eigentlichen Einrichtung:

  • pssh installieren
  • SSH-Key generieren -> ssh-keygen -t dsa -f ~./ssh/myKey
  • den Inhalt von ~./ssh/myKey.pub auf den remote Hosts in ~./ssh/authorized_keys kopieren
  • remote in der ~./ssh/authorized_keys vor den Key einfuegen from=“11.22.33.22″ um den Zugang auf diese IP zu beschraenken
  • remote die /etc/sudoers editieren und folgende Zeile einfuegen:
    USERNAME  HOSTNAME =  NOPASSWD: /usr/bin/aptitude
    wobei USERNAME der Benutzername mit dem key ist und HOSTNAME der hostname des Rechners ist. NOPASSWD muss so als solches stehenbleiben.

Jetzt kann man das ganze einmal testen ob es geklappt hat. Mit ssh USER@IP sollte man sich nun mit dem entsprechenden User auf dem entsprechenden Host ohne Passwort einloggen koennen. Wenn das geklappt hat kann man ausprobieren ob man sudo aptitude upgrade ausfuehren kann ohne Fehlermeldung das man nicht root sei. Geht das beides ohne Probleme nun zu pssh.

Von dem Rechner aus von dem ich nun die Verbindungen zu meinen Servern aufbauen kann muss nun noch einige Kleinigkeiten erledigt werden. Als erstes brauche ich eine Textdatei in der alle hosts drinstehen zu der ich eine Verbindung aufnehmen moechte. Fuer jede IP eine Zeile und bei Bedarf hinter die IP noch mit Doppelpunkt den Port dahinter. Bsp:

11.22.33.44
11.22.33.55:82
11.22.33:66
11.22.33.77:89

Ich habe die Datei einfach in ~/arbeit.ips bzw. eine zweite ~/privsv.ips abgespeichert. Bevor wir nun mit pssh testen koennen ob alles funktioniert bzw. die Updates ausfuehren muss noch der ssh-agent geladen werden mit unserem key. Dafuer einfach in der bash ssh-agent ausfuehren und anschliessend ssh-add. Beides sollte keine Fehlermeldungen ergeben.

Nun ist es soweit. Mit dem Befehl:

pssh -h arbeit.ips -o /tmp/psshtest uptime

koennen wir nun gucken ob alles funktioniert. Es sollte eine Ausgabe kommen ungefaehr so:

me@hostname ~/ $ pssh -h arbeit.ips -o /tmp/psshtest uptime
[1] 09:30:03 [SUCCESS] 11.22.33.44
[2] 09:30:03 [SUCCESS] 11.22.33.55 82
[3] 09:30:03 [SUCCESS] 11.22.33.66
[4] 09:30:03 [SUCCESS] 11.22.33.77 89
me@hostname ~/ $

Der Output des Befehls befindet sich in /tmp/psshtest/11.22.33.* Wenn alles weitere geklappt hat dann happy:

pssh -h arbeit.ips -o /tmp/psshout sudo aptitude upgrade -y

Einige koennen nun ankommen und sagen, dass das doch viel zu kompliziert sei. Mit Sicherheit argumentieren, oder auch damit, dass es doch viel einfachere Tools fuer Debian wie z.B. cron-apt, mit dem ich die Systeme doch auch up-tod-date halten koennte. Meine Antwort darauf ist: Ja, weiss ich. Ja kenne ich. Ich moechte aber immer noch die Updates per Hand einspielen um zu wissen was ich da einspiele.