Sicherheit im Wohnheimnetz = Ourmon & SurfIDS?!…

Nachdem ich vor einigen Wochen im Linux-Magazin einen kurzen Artikel ueber Ourmon gelesen habe, habe ich es jetzt auch bei uns im Wohnheim aufgesetzt. Mir sind die Worte der DFN-Cert Leute immer noch im Kopf, die sagten: „Nur weil die Netzwerkmonitoring Loesungen die Sie vor 2-3 Jahren implementiert haben heute keine Gefahren mehr anzeigen, heisst es noch lange nicht, dass es auch keine mehr gibt. So wie sich Viren, Wuermer, Rootkits weiterentwickeln und neue Wege gehen, muss man auch bestaendig seinen Blick darauf anpassen.

Der neue Blickwinkel und die neue Strategie heisst deswegen bei mir: Netflows oder vergleichbares aufzeichnen / betrachten und Honeypots aufstellen. Part eins, das mit den Netflows, ist damit initial abgedeckt. Ourmon ist installiert und liefert Daten und Graphen der Standartkonfiguration. Es folgt die naechsten Tage noch eine Anpassung (z.B. Monitoring des Port 445 zur Erkennung von Conficker bzw. anderen MS-RPC-Schnittstellenschwachstellenausnutzenden Dingern).

Part zwei sind Honeypots. Dafuer habe ich mir (nach tollen Gespraechen beim SNT) das Intrusen-Detection-System SurfIDS ausgeguckt. Es baut auf die Honeypotsoftware Nepenthes auf, und ist als low interaction Honeypot auch ganz gut geeignet fuer Wohnheimnetze. Fuer high interaction Honeypots braeuchte ich nen Kollegen der Ahnung hat ;-)
SurfIDS kommt bald, alles zu seiner Zeit. Am liebsten wuerde ich in jedem Wohnheim in Goettingen einen Sensor aufstellen, aber dafuer muss ich erstmal die Hauptinfrastruktur schaffen. Freu mich schon drauf!

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.

DatenG(eorg)A(ugust)U(niversitaet)

Jetzt schreibe ich doch noch einen Eintrag in die alte DB vor dem Umzug, naja, dann mach ich den mysqldump halt nochmal. Aber den DatenGAU an unserer Uni kann ich nicht unerwaehnt lassen…

Himuro, alte Socke, gegen Dich haben wir doch auch immer unsere Studentendaten abgeglichen. Nun biste wech… Und nu is auch so einiges mehr wech. Zum Beispiel die Daten die Du weltweit oeffentlich verteilt hast.

Ich bin mal gespannt, wie es jetzt auch mit der Nutzerverwaltung des Studentenwerkes weitergeht, die waren ja schliesslich auch noch an Ihn angeschlossen. Es gibt bestrebungen eine eigene Nutzerverwaltung aufzubauen, obwohl es ein IdentityManagement der Uni/GWDG gibt… Naja, mal schaun…

Wer in der oben genannten Liste nach meinem Namen sucht wird auch bei diesem fuendig. Erfahren von der Luecke hab ich heute Nacht ueber eine Mail auf der Goettinger Chaosliste wo auf einen Artikel bei Netzpolitik aufmerksam gemacht wurde. Dort ist auch eine erste kurze Stellungnahme der Uni zu lesen. Inzwischen sind auch Artikel auf Heise und Golem zu finden. Mal gucken wie es weitergeht… ;-)

[Update]