Captain's blog

Mit der (partiellen) Umstellung von Linux- auf Apple-Clients im Heimnetz war es an der Zeit, über Anpassungen am vorhandenen Ubuntu-Fileserver nachzudenken. Möglichkeiten für den Zugriff per Netzwerk gibt es immerhin zuhauf:

- NFS, als Netzwerk-Filesystem unter Unix gestartet, und seit langem erprobt. Recht zügig bei der Arbeit, leider nicht allzu bekannt für Sicherheit
- SMB, der Versuch aus Redmont, eine Alternative zu NFS zu finden
- SSH- / FTPFS, als FUSE-Erweiterungen, leider nicht allzu performant
- AFP, Apples natives Netzwerk-Dateisystem. Recht fix, und durch SSL-Verschlüsselung auch entsprechend sicher.

Wo die Wahl im Linux-Umfeld naturgemäß auf NFS fällt, habe ich mich aus Performance- und Sicherheitsgründen entschlossen, parallel dazu Netatalk als Fileserver für meine Apple-Hardware aufzusetzen. Als zusätzliches Schmankerl soll das MacBook seine Backups per Time Machine nicht per USB, sondern zentral auf den Server sichern.

Ein paar minimale Hürden gibt es hierzu jedoch zu meistern:

Wer ein öffentlich erreichbares (Unix-) System betreibt, kennt die Problematik der diversen gescheiterten Anmeldeversuche per SSH. Hervorgerufen durch Bots, die triviale Kombinationen und Passworten durchprobieren, müllen sie Logfiles zu, und finden schlimmstenfalls sogar wirklich einen Luser, der ein leicht zu erratendes Passwort nutzt.
Lösungen für dieses Problem sind (nicht nur hier) bereits mehrfach angesprochen worden; angefangen bei einfachen Maßnahmen wie der Verlegung des Port von 22 auf einen anderen, nicht standardgemäßen. Nutzung von SSH-Public Keys. Weiter über Paketfilter und eigens hierfür entwickelte Tools wie z.B. denyhosts oder fail2ban.

Eine gänzlich andere Möglichkeit, die darüber hinaus noch weitere Vorteile bietet ist die Authentisierung über Einmalpassworte. In Verbindung mit einer Zwei-Faktorauthentisierung (wie sie z.B. RSA mit den SecureID-Tokens) vormacht kommt zusätzlich zum Passwort noch eine Besitzkomponente hinzu. Ohne Token, das das OTP anzeigt, ist kein Zugang möglich.

Leider lohnen sich der Kauf dieser Token für den "Privatgebrauch" nicht wirklich, immerhin existieren mittlerweile (freie) Projekte, die diese Technik sehr kostengünstig ermöglicht. Das wohl vielversprechendste ist hier wohl FreeAuth.
Statt eines Hardwaretokens kommt hier das (in den allermeisten Fällen eh vorhandene) Handy zum Einsatz, das mit Hilfe eines kleinen Stückchen Java-Software die Funktion schnell und einfach nachbildet.

Nachdem Mattias Schlenker im Rootforum alleine durch die Umschreibung der Vorteile von Jails einen kleinen FreeBSD-Hype ausgelöst hat, interessierte mich eine solche (im "Standardumfang" nicht enthaltene) Lösung natürlich auch gerade unter OpenBSD. Immerhin bedeutet eine "virtuelle" OS-Instanz vor allem eine weitere erhöhte Sicherheit.

Fündig in diesem Fall wurde ich bei sysjail, das Jail-Konstrukte mit Hilfe des systrace-Frameorks umsetzt, das seinerseits eine sehr mächtige (aber dennoch einfache) RBAC-Imlementierung für System Calls darstellt. Somit lässt sich der "Komfort" eines Jails noch durch zusätzliche Sicherheit kombinieren, da sich so sehr feingranular einschränken lässt, was in der VM erklaubt ist.

Im Zuge des (hoffentlich) bald fertigen Artikels über Crypto-Filesysteme unter Linux habe ich kürzlich endlich einmal ein Projekt in Angriff genommen, das ich schon längst einmal angegangen sein wollte: die Verschlüsselung des gesamten Systems auf der Festplatte.
Im Gegensatz zu einem meiner älteren Artikel, der die Verschlüsselung von /home und Swap mit Hilfe des (mittlerweile obsoleten) Cryptoloop-Systems beschreibt, kommt in diesem Fall DM-Crypt inklusive der LUKS-Erweiterung(en) zum Einsatz. Glücklicherweise sind die meisten Werkzeuge für das Vorhaben bereits unter Dapper bereit, ein paar Hürden galt es jedoch zu überwinden.

Inspiriert ist dieses kurze Howto durch einen Blogeintrag von Sternensucher, sowie einem (eigentlich veralteten) Thread im Ubuntu-Forum.
Obwohl das Vorhaben sicherlich auch aus einem laufenden System heraus machbar wäre, wird das System im folgenden komplett neu installiert.

Bevor es losgeht, noch der obligatorische Disclaimer:
1. Dieses Howto richtet sich an Personen, die (wenigstens ungefähr) wissen, was sie damit anstellen. Die hier vorgestellte Vorgehensweise hat sich für mich als stabil und gangbar erwiesen. Sollte das bei dir nicht der Fall sein, kann ich dich (zur Zeit) nur schlecht bis gar nicht supporten.
2. Eine Datensicherung bereits im Vorfeld ist unabdingbar.
3. Solltest du deine Daten (durch dieses Howto, eine vergessene Passphrase, whatever) verlieren, übernehme ich keine Verantwortung dafür.

Da auch das geklärt ist, kann's ja nun losgehen:

Seit Tagen schlage ich mich mit dem Problem eines Bekannten herum, dem seine Platte mit seiner alten Suse-Installation abgeraucht ist. Der Rechner stand bei ihm zuhause, und hat via Cyrus Imap seine knapp 3 GB Mails (größtenteils geschäftlich) verwaltet.

Aus Performance- und anderen Gründen ist er bei der Gelegenheit auf einen Rootserver "umgezogen", und nutzt nun auch zu seiner vollsten Zufriedenheit Zimbra. So weit, so gut, seine alten Mails waren aber dadurch auch nicht wieder dort, wo er sie gerne hätte. Somit hieß es also, einem anderen (neueren) Cyrus klarzumachen, dass er die Mails und Ordnerstrukturen aus dem (immerhin vorhadenen) Backup wieder korrekt einliest.

Da ich mich vor ein paar Jahren schon einmal mit einem ähnlichen Problem befasst hatte, werde ich daher nun die Möglichkeit nutzen, die Lösung dafür einmal niederzuschreiben, bevor ich beim nächsten Mal wieder tagelang fluchen muss.

Seitdem mir mein Boss gestern eine UMTS-Karte von T-Mobile für Bereitschaftseinsätze in die Hand gedrückt hat, schlage ich mich nun zum ersten Mal mit diesem Thema unter Linux herum. Nach der Lektüre einiger Seiten, die aber eher auf Vodafone als Provider und kppp für die Konfiguration / Einwahl ausgerichtet sind, war noch ein wenig Sucherei im Internet nötig, um die Karte vollständig zur Mitarbeit zu bewegen.

Daher nun dieses kleine "Mini-Howto" in der Hoffnung, anderen diese Sucherei abnehmen zu können. Die hier genannte Vorgehensweise ist (von mir) ausschließlich unter der aktuellen Ubuntu-Entwicklerversion (Dapper Drake) getestet, sollte aber eigentlich relativ distributionsneutral sein:

Um nicht selbst ständig wieder auf die Nase zu fallen, wenn ich mal wieder (die verdammt coole Groupware) Zimbra auf Debian installiere, gibt's hier ein ganz ganz kleines "Mini-Howto".

Zwar gibt es bereits einen "Alpha-Installer", der für sich allein genommen schon recht gut funktioniert, wenn diverse Pakete fehlen, geht das Vorhaben allerdings ganz schnell in die Hose:

Beim gestrigen durchstöbern meiner RSS-Feeds fiel mir bei Martin McKeay's Network Security Blog ein neues (?) Howto zur "Härtung" von Linux-(Produktions-)Systemen ins Auge.

So, nach den etwas dürftigen beiträgen der letzten paar Tage gibt's heute endlich mal wieder was "richtiges":

Da ich mich mit dem mittlerweile in Sarge enthaltenen Exim 4 (vor allem in dieser Konfiguration) ganz und gar nicht (mehr) anfreunden kann, setze ich mittlerweile auch auf meinen privaten Servern nur noch Postfix ein.

Der größte Vorteil Exims, die Filterung von hereinkommenden Mails anhand des Inhalts (z.B. mit Hilfe von SpamAssassin) kann Postfix in diesem Umfang leider bei weitem nicht bieten.
Im Gegensatz dazu ist Postfix zum Glück so modular aufgebaut, dass sich selbst dieses Manko mit relativ einfachen Mitteln beheben lassen würde. Dazu ist der "mitgelieferte" smtpd schlicht und ergreifend durch den Mail Avenger zu ersetzen. Dieser stellt einen "hochkonfigurierbaren, MTA-unabhängigen SMTP-Daemon" dar, der in der Lage ist, Mails noch im SMTP-Dialog zu filtern, um so Spam und Viren direkt (also ohne sie anzunehmen) abweisen zu können.

Wem die Möglichkeiten von Tools wie nmap, p0f, tcpdump, AirSnort, hping oder (sogar) dsniff nicht weit genug gehen, wird an Scapy seine helle Freude finden.

Der Vorteil an all diesen (extrem mächtigen) Produkten ist dabei gleichzeitig oft ihr Nachteil: jedes für sich allein genommen ist auf ein sehr spezielles Aufgabengebiet zuschnitten, bietet aber weniger (bis keine) Möglichkeiten, etwas zu tun, das der Programmierer nicht vorgesehen hat. Im Gegensatz dazu umschreibt die Scapy-Webseite das Programm als "powerful interactive packet manipulation program"...und besser kann man es kaum sagen.

Im Hinblick auf mein vorgestriges Posting ("Spaß mit ICMP") werde ich heute einmal etwas näher auf kernelseitige Einstellungen eingehen, die das Netzwerken unter Linux beeinflussen, und vor allem (un-) sicherer machen. Wenn ich an den ziemlich peinlichen Fehltritt bezüglich sysctl denke, ist eine kleine Auffrischung für mich selbst wohl auch einmal bitter nötig...

Linux bietet die Möglichkeit, Kerneleinstellungen im laufenden Betrieb über das (virtuelle) /proc-Filesystem einzusehen und zu verwalten. Das gesamte Filesystem wird komplett über den Hauptspeicher des Systems abgebildet, auch wenn sich schon manch einer erschreckt hat, wenn er sich die Größe einmal angeschaut hat.
Die Informationen aus /proc können zum Teil extrem nützlich sein, da sie ein sehr genaues Abbild des Systems darstellen: hier findet man z.B. sämtliche Informationen über aktuell laufende Prozesse, anhand denen man einige sinnvolle Rückschlüsse ziehen, und beispielsweise (schlecht) versteckte Dienste aufspüren kann. Dazu aber in einem anderen Posting, zunächst einmal geht's hier um netzwerkspezifische Einstellungen...

Vor ein paar Tagen hat VMWare den Player herausgebracht, mit dem es möglich ist, im Vorfeld erstellte Images auch ohne die große Kaufversion der Software zu nutzen.

Erwartungsgemäß hat es nicht lange gedauert, bis ein paar findige Köpfe auf die Idee gekommen sind, sich einmal näher damit auseinanderzusetzen. Beim rumspielen haben sie dann herausgefunden, wie sich das Image dahingehend manipulieren lässt, dass das darin enthaltene Betriebssystem mit extrem einfachen Mitteln "ausgetauscht" werden kann.

Wer mehr wissen möchte, schaut sich einfach das passende hack a day-Tutorial an. Viel Spaß beim basteln.

Vor ein paar Tagen habe ich (wie berichtet, siehe "Verwandte Links") meinen Spaß am ICMP-Protokoll entdeckt. Das Werkzeug meiner Wahl ist das dort vorgestellte sing. Je mehr ich mich damit auseinandersetze, desto mehr "nützliche" Anwendungsgebiete tun sich mir auf.

Die Idee, USB-Sticks mit seiner favorierten Linux-Distribution zu bestücken ist ja nicht neu. Selbst der iPod Nano fasst ein vollständiges SLAX (das seinerseits auf Slackware beruht).

Sicherheitstechnisch betrachtet ist das Booten eines "sauberen" Systems auf einem nicht vertrauenswürdigen Rechner schon einmal die halbe Miete. Wem das allerdings immer noch nicht paranoid genug ist, findet auf Debian-Administration ein sehr gutes Tutorial das beschreibt, wie sich Debian vollständig verschlüsselt auf einem USB-Stick unterbringen lässt. Immerhin sind diese heutzutage immerhin so groß, dass sie ein sehr komplettes System fassen können.
Vor einem Hardware-Keylogger schützt einen allerdings leider auch die stärkste Verschlüsselung nichts...was aber nichts ist, was sich nicht z.B. via xvkbd lösen ließe.

Ich finde das Projekt jedenfalls so interessant, dass ich's demächst (wenn irgendwann einmal wieder Zeit da ist ) unbedingt mal ausprobieren werde...auch wenn ich mich, wenn ich mal (ausnahmsweise) ohne Laptop unterwegs bin schon irgendwie etwas "nackt" fühle.

Heutzutage dürfte es wohl kaum noch Firmen geben, die ihre Netze nicht durch eine Firewall gegen "Angriffe" aus dem Internet abschotten. Richtig gehandhabt, stellen diese auch einen recht wirksamen Schutz dar...sofern man die Tatsache außer Acht lässt, dass die meisten Angriffe immer noch von innen ausgehen.

Da der "Weg nach außen" aber meist durch eine recht restriktive Firewall-Policy "gesperrt" ist, finden sich immer wieder neue, kreative Ideen, wie diese Blockade doch zu durchbrechen ist. Ein gutes Beispiel hierfür ist das auf der letztjährigen BlackHat-Konferenz von Dan Kaminsky vorgestellte OxymanDNS (Download), das in der Lage ist, nahezu beliebigen Traffic via DNS zu tunneln.