EDV – Ende der Vernunft

Archiv für die Kategorie „Sicherheit“

Ich bin durch Zufall auf den Artikel Server effizient verwalten, Kosten reduzieren im Rechenzentrum beim Tecchannel gestoßen. Darin auch ein Abschnitt über RFID:

Auf jeder Höheneinheit (HE) eines Racks befinden sich drei RFID-Transponder, die den Server beim Einbau in das Rack identifizieren. Der genaue Standort jedes Servers wird Auf diese Weise kontaktlos erfasst und dokumentiert. Auf den passiven RFID-Transpondern lassen sich Kenndaten der im Rack montierten Komponenten speichern.

Klingt intressant. Nur was ist mit Sicherheit? Bei RZ-Betreibern mit Kundenbetrieb wird es bestimmt sehr intressant. Ich glaube kaum, das es ein Intresse daran gibt, das Infrastrukturdaten quasi Public Domain werden. Selbst bei ansonsten geschlossenen Rechenzentren liesse bestimmt mal eine ‘Führung’ organisieren. Eine Vorstellung die mir das kalte Grausen über den Rücken jagt.

Mal ganz davon ab stellt sich die Frage, ob RFID an dieser Stelle wirklich ein Problem löst, ausser die Faulheit der RZ-Verantwortlichen in Fragen der Inventarisierung auszubügeln.

Als guter Administrator sperrt man den Rechner, wenn man den Arbeitsplatz verlässt. Unter KDE 3.5 habe ich eine Zeit lang kbluelock benutzt, welches automatisch den Rechner sperrt, wenn ich mich mit dem Bluetooth-fähigen Handy zuweit entferne. Das funktioniert auch hinreichend zuverlässig, es sei denn man ist zu schnell zu Fuß, dann steht man einen kurzen Augenblick vor dem gesperrten Rechner.

Trotzdem traue ich dem Ding nicht. Vielleicht bin ich schon zu lange darauf konditioniert auf den Sperr-Knopf von KDE zu drücken. Ich sehe dann sofort den Bildschirmschoner und weiss das die Sperrung aktiv ist. Ich denke mal das fehlt mir, denn wenn ich mit kbluelock arbeite sehe ich den Desktop wenn ich gehe und wenn ich zurückkomme ist er auch wieder da. Es bleibt das Mißtrauen, ob er überhaupt gesperrt war. Da kann ich irgendwie nicht raus aus meiner Haut.

Die Secure Shell (SSH) ist heute das Maß der Dinge wenn es um einen sicheren Zugriff auf Server geht. Nichts ist allerdings so gut, das man es nicht noch ein bischen verbessern könnte. Besonders wenn man etwas mehr Kontrolle über die Dinge haben möchte, muss man ein wenig Hand anzulegen.

Kontrolle sichern

Zuallererst gilt es dem Benutzer die Kontrolle über das authorized_keys-File zu entziehen, denn die später beschriebenen Maßnahmen haben keinen Sinn, wenn der Benutzer sie einfach umgehen kann. Denn normalerweise liegt diese Datei im Home-Verzeichnis des Benutzer und er könnte sie einfach löschen und neu erstellen. Genau an dieser Stelle wird angesetzt, indem man auf den betroffenen Systeme die /etc/ssh/sshd_config ändert:

AuthorizedKeysFile /etc/ssh/authorized_keys/%u

Durch diese Änderung liegen die Key-Files in /etc/ssh/authorized_keys/ und tragen den Namen des Benutzers. Durch entsprechende Dateiberechtigungen können Änderungen nur noch durch Root vorgenommen werden:

# ls -l
insgesamt 16
-rw-r----- 1 root joern 397 25. Dez 23:13 joern
-rw------- 1 root root  396 25. Dez 16:53 root

Zugriff absichern

Nun können Restriktionen für die SSH-Session im Key-File hinterlegt werden:

from="*.aumund.org",no-port-forwarding,no-X11-forwarding,no-pty ssh-rsa AAAAB3NzaC1yc2[..]EyqAw== joern@cm-master

Dieser Benutzer darf sich also nur von Hosts der aumund.org Domäne einloggen, es gibt kein Port- und X11-Forwarding und auch keine interactive Shell. Alle Optionen finden sich in der Man-Page (man sshd im Abschnitt AUTHORIZED_KEYS FILE FORMAT)

Sicheres Automatisieren

Mit SSH lassen sich wunderbar einfach Aufgaben automatisieren. Normalerweise nimmt man dazu einen Key ohne Passphrase. Wem das nicht reicht steht vor einem Problem: Der ssh-agent funktioniert nur solange man angemeldet ist. Hier hilft KeyChain aus, denn es setzt einen SSH-Agenten pro Benutzer und nicht einen pro Session.

Die Benutzung ist sehr einfach. Nach der Installation erweitert man die .bash_profile des betroffenen Benutzers:

/usr/bin/keychain ~/.ssh/id_rsa ~/.ssh/id_dsa
source ~/.keychain/${HOSTNAME}-sh > /dev/null

Beim nächsten Anmelden wird dann die Benutzer-Session aufgesetzt

KeyChain 2.6.8; http://www.gentoo.org/proj/en/keychain/
Copyright 2002-2004 Gentoo Foundation; Distributed under the GPL

 * Initializing /home/joern/.keychain/cm-master-sh file...
 * Initializing /home/joern/.keychain/cm-master-csh file...
 * Initializing /home/joern/.keychain/cm-master-fish file...
 * Starting ssh-agent
 * Warning: can't find /home/joern/.ssh/id_dsa; skipping
 * Adding 1 ssh key(s)...
Enter passphrase for /home/joern/.ssh/id_rsa:
Identity added: /home/joern/.ssh/id_rsa (/home/joern/.ssh/id_rsa)

und steht nun bis zum nächsten Reboot(!) zur Verfügung. An der Sache mit dem Reboot sollte man immer denken, wenn man Aufgaben automatisiert hat, ansonsten kann es zu ernsten Problemen kommen.

Referenzen:
Playing with OpenSSH public keys
Secure, Automated, Key based SSH

• Playing with OpenSSH public keys – What seems not to be well known is that apart from public keys you can also place additional options in your authorized_keys file
• 2 Cheat Sheets for Incident Handling – Maybe your system just got hacked [..] Here are two cheat sheets that may help
• LaserMouse – :)

Es muss schon eine kleine Ewigkeit her sein, als ich den letzten Virus per Mail bekommen habe. Umso erstaunter war ich gestern als dann doch einer den Weg in meine Inbox gefunden hatte. Es war auf den ersten Blick zu erkennen, obwohl sich die Autoren richtig Mühe gegeben haben. Nach entpacken der Zip-Datei sah es zuerst tatsächlich nach ein Doc-Datei aus, aber dann fiel mir auf das nach vielen Leerzeichen doch noch .exe erschien. Eben hochgeladen zu Virustotal und gesehen, das nur wenige Malware-Scanner den Inhalt kannten. Also die Mail bei ClamAV eingereicht und tatsächlich:

Dear ClamAV user,

The following submissions have been processed and published:
- 4893789 Email.Trojan-39

Die Welt ist wieder ein Stückchen sicherer geworden *angeb*

Die OpenSSL-Schwachstelle in Debian Etch, Ubuntu von Feisty bis Gutsy und alle anderen Derivaten kann man getrost als GAU bezeichnen, denn die Konsequenzen können dramatisch sein. Leute die öfters mit Verschlüsselung zu tun haben wird der Satz

It is strongly recommended that all cryptographic key material which has
been generated by OpenSSL versions starting with 0.9.8c-1 on Debian
systems is recreated from scratch

alarmierend genug sein. Ubuntu ist da deutlicher:

This includes the automatically generated host keys used by OpenSSH, which are the basis for its server spoofing and man-in-the-middle protection.

Genau, eigentlich jeder mit einen Server auf dem eines der obigen Betriebs-Systemen läuft ist damit direkt von dieser Sicherheitslücke betroffen. Um, zum Beispiel auf einen Root-Server, bei Debian Etch neue Keys zu erzeugen sollte man zur Sicherheit eine zweite SSH-Session aufmachen, dann die alten Keys löschen und neue erzeugen:

 # apt-get update && apt-get -y upgrade
# cd /etc/ssh
# rm ssh_host_*
# /var/lib/dpkg/info/openssh-server.postinst configure

Danach ausloggen, den alten Key aus der ~/.ssh/know_hosts löschen und neu verbinden. Fertig.

Früher waren es Goldbarren, heute Hardware. Ist bestimmt auch viel leichter zu Geld zu machen:

Thieves impersonating policemen stole more than $4 million in equipment from a Verizon Business data center in northern London Thursday night, according to UK papers, who are describing the incident as an “Ocean’s Eleven” heist.
‘Ocean’s 11′ Data Center Robbery in London

Ok, ich brauch 10 Leute. Durchgeknallte, Geeks, Nerds, Schweißer, Fahrer, Organisator und nen Zigarren-Raucher. Achne, das war das A-Team.

Well, it’s good to know that Microsoft is at least keeping their security flaws up to date

Kommentar in Bruce Schneiers Blog zum Thema Fake Zufallsgenerator in Vista SP1.

Das immer mehr Open-Source in kommerziellen Produkten verwendet wird, darüber hatte ich schon berichtet. Die Software wird dadurch nicht unbedingt sicherer, wie man hier sehr schön sehen kann:

Achja, und Root-Passwörter für Mysql werden sowieso überschätzt.

• Increase Linux TCP performance – Größer ist immer gut
• Storm Worm’s Fast Flux Networks – Ein paar schicke Bilder zum Storm Worm
• Never Trust Sat-Nav! – Und der Kerl hat noch Glück. Andere fahren in Flüsse! via reddit
• The Internet On One Disk – Die haben einfach den ganzen Pr0n weggelassen