Ich möchte Euch diesen großartigen Vortrag von Joanna Rutkowska sehr ans Herz legen. Diese Aufnahme des Linux-Magazin stammt aus dem letztjährigen DFN-Workshop "Sicherheit in vernetzten Systemen" zu dem ich mich fast angemeldet hätte, wenn mir die Tagungsgebühren nicht so hoch gewesen wären. Wenn alle Vorträge ähnlich interessant gewesen sind, hätte ich mich wohl nicht geärgert, hätte ich mich angemeldet.
In Ihrem Vortag hält Rutkowska ein sehr überzeugendes Plädoyer für die Bedeutung des Aspektes der Erkennung von kompromittierten Systemen. Sie kritisiert die einseitige Fokussierung auf den Aspekt der Prävention und trifft damit bei mir voll ins Schwarze, da auch in meinem Bewußtsein die Prävention stehts die größte Bedeutung besaß und Erkennung zwar nicht unbedeutend, aber doch nachrangig war. Denn: wer ein integeres System will, der muß den Einbruch verhindern. Erkennung greift erst im Schadensfall.
Genau hier hakt Rutkowska jedoch sehr überzeugend ein. Sie
argumentiert, dass die Vergangenheit gezeigt habe, dass Systeme,
die man sicher glaubte, nur allzu oft doch kompromittiert werden
konnten, weil Sicherheitslücken ausgenutzt wurden. Hat man nun ein
System, dass eine Lücke hatte, so hat man mit der Prävention ein
Problem. Denn selbst wenn man sofort nach Bekanntwerden der Lücke
einen Patch einspielt, so kann man sich nie sicher sein, dass die
Lücke in der Vergangenheit nicht ausgenutzt worden ist. Prävention
hat also immer eine zeitliche Komponente, eine Geschichte, die
sich rückwirkend nicht ändern lässt. Behebe ich eine Lücke jetzt,
habe ich sie in der Vergangenheit noch lange nicht behoben. Ich
müßte also nach jeder neuen Lücke um die Sicherheit meines Systems
fürchten. Daran änderten auch verbesserte präventive Maßnahmen
nichts.
Anders die Erkennung. Verbessere ich die Erkennung, greift diese
Verbesserung oftmals "zeitlos". Ich erhöhe damit nicht nur die
Wahrscheinlichkeit gegenwärtige Einbrüche zu detektieren, sondern
ich erhöhe ebenfalls die Wahrscheinlichkeit vergangene Einbrüche
aufzuspüren. Systeme zur Prüfung der Systemintegrität sind also im
Grunde die andere Medaille sicherer Systeme. Ohne Detektion macht
Prävention keinen Sinn. Da Prävention keine Sicherheit bieten
kann, müssen wir immer auf der Hut sein, ob präventives Maßnahmen
nicht doch versagten. Sie bemüht das passende Bilder des "Yin-Yan
der Sicherheit". Die Balance muß stimmen und die Erkennung von
Schadsoftware darf nicht als lästiges Stiefkind der Sicherheit
betrachtet werden.
Sie definiert im folgenden verschiedenen Typen von Schadsoftware und klammert einen Bereich, nämlich jenen von selbst installierten Programmen, z.B. von selbstinstallierter Schadesoftware, die die üblichen API's für Programme benutzt und nicht irgendwelche Schwächen ausnutzt oder andere Systembestandteile kompromittiert, aus. Ihre Klassifikation überzeugt ebenso wie die skizzierten Lösungsansätze, die im übrigen auch deutlich machen, warum die Installation von handelsüblicher Antiviren-Software keine Lösung, sondern manchmal sogar Teil des Problems ist.
Ich kann jedem, der sich für dieses Thema interessiert (für IT'ler sollte es m.E. Pflichtstoff sein), nur empfehlen sich das Video und die Slides anzugucken. Das sind 90 sinnvoll investierte Minuten. Ich zumindest habe ein paar Aha-Effekte erlebt und bin dem Linux-Magazin für diesen Service schönen Service, der einige andere interessante Vorträge bietet, dankbar.
Heute wurde mir wieder einmal mehr klar, warum ich OpenSuSE zwar auf dem Desktop, nicht aber auf dem Server einsetze. Aktueller Fall: proftpd läuft bei einem Kunden nicht im Standalone-Betrieb. Der Service forked nicht. Warum? Weil die OpenSuSE-Leute den Dienst tatsächlich mit --enable-devel=coredump,nodaemon,nofork übersetzt haben. Skuriler gehts nimmer.
Seit zwei Jahren ärgere ich mich ständig nach einem Kernelupdate mit VMware rum, weil VMware kein Kernelmodul gegen den neuen Kernel baut. Es ist mittlerweile schon lästige Routine geworden nach dem aktuellen, inoffiziellen "Any-Any-Patch" zu suchen, den Petr Vandrovec, ein VMware-Mitarbeiter, erstellt hat, und den VMware-Installer damit zu patchen.
An die Lösung hab ich mich gewöhnt, weswegen ich in der Vergangenheit im wesentlichen doch eher gute Worte für VMware übrig hatte. Denn: VMware läuft sehr stabil und zuverlässig und ich habe damit in den letzten Jahren sehr erfolgreich eine parallele Windows-Installation vermieden. Leider hat sich das seit OpenSuse 11.0 geändert. Für den aktuellen 2.6.25er Kernel gibt es bis dato für VMware Workstation 5.5 keinen Patch und einen fragwürdigen Patch für die 6.0. Besserung ist wohl erst mit 6.5 in Sicht. Das finde ich nicht akzeptabel und man wird auf der Suche nach Lösungen feststellen, dass das Problem Benutzer der meisten aktuellen Distributionen betrifft. Ich würde fast wetten: wäre VMware Open Source gäbe es längst zuverlässige Patches. Am besten aber wäre es die Virtualisierungslösung würde im Kernel gepflegt. Dann gehörten derartige, nervende u.U. stressende Update-Abenteuer endlich der Vergangenheit an.
Mein nächster Rechner wird Hardware-Virtualisierung unterstützen und dann wird VMware wohl endgültig durch Xen abgelöst.
Update (drei Stunden, ein Telefonat, ein Abendessen und ein Code-Audit später): VMware läuft! Geholfen hat mir folgender Artikel von Peter Velichkov. Hab vorher einen kurzen, aber nicht unkritischen Blick auf den Patch geworfen, da ich mit Patches die irgendwo "in the wild" rumfliegen immer etwas ängstlich bin.
Das Update von 10.3 auf OpenSuSE 11.0 war schmerzfrei und ging flott von der Hand. Neben Softwareaktualisierungen viele Verbesserungen im Detail. Bin recht angetan. Aaaber: warum hat es mir schon wieder den Bootsektor zerschossen? Warum musste ich selbst wieder Hand an grub legen?
Update: Man soll den Tag nicht vor dem Abend loben:
postfix/master[17716]: fatal: 127.0.0.1:smtps: Servname not supported for ai_socktype
Hab den Service erstmal auskommentiert (was eigentich nicht im Sinne des Erfinders ist... Ich benutzte ihn tatsächlich). Hat jemand eine Ahnung woran das liegen könnte?
Update (zehn Minuten später): Problem hat sich geklärt. SuSE hat die /etc/services aktualisiert. Unter 465/tcp steht jetzt urd statt smtps. Den Port beim Service in der master.cf mitzukonfigurieren oder den Eintrag in /etc/services zu ändern hilft.
Ich bin sehr restriktiv im Einsatz von JavaScript. Dies hat drei Gründe:
... auf der PHP Unconference?
B: Instant Messaging wird geblocked.
L: Dann tunnel das doch via ssh.
B: Das geht auch nicht. ssh ist wird auch geblocked.
L: Ja und?
Denn das ist überhaupt gar kein Problem. Mit nur etwas Networking-Know-How und Zugriff auf irgendein vernetztes System kann man nahezu alles tunneln. Meistens geht das sogar sehr einfach. "Die Secure Shell wurde geblocked" heißt in der Regel nur: der Firewall-Administrator hat den Port dicht gemacht. Den verschlüsselten Datenstrom kann eine Firewall naturgemäß nicht inspizieren. Die einfachste Lösung ist also den sshd auf Port 443 (der Standardport für HTTPS) lauschen zu lassen und die Verbindung durch den Proxy aufzubauen. Nichts ist einfacher als das und geht - putty sei Dank - auch auf einem Windozesystem problemlos.
xdebug ist mir seit mehr als einem Jahr ein unentbehrliches Hilfsmittel. Seit fast eben so langer Zeit hatte ich hier vor einen einführenden Artikel zu schreiben. Aber... Entweder es mangelt mir an Zeit und wenn nicht an Zeit, dann an Lust, deshalb wurde daraus nichts. Erfreulicherweise hat die Zend Developers Zone vor ein paar Tagen den ersten Artikel einer Serie zu xdebug von Stefan Priebsch veröffentlicht. Meines Erachtens eine Pflichtlektüre für alle PHP-Entwickler die xdebug noch nicht kennen.
Update (7. Februar 2008): Kristian Köhntopp hat aufgeschrieben wie man vim oder Quanta zum Debuggen mit xdebug einsetzen kann.
Nachdem es mir heute zum dritten Mal passierte hab ich die Nase von Wordpress besch.... Fehlerbehandlung im Falle unzureichender Angaben bei einem Kommentar die Nase gestrichen voll. Was ist passiert? Ich schrieb einen Kommentar, sendete ihn ab, vergaß aber leider das Captcha auszufüllen (beim letzten Male, wo mir dies passierte, wars die E-Mail-Adresse) und bekam eine unschöne Fehlermeldung, dass ich eine Pflichtangabe nicht gemacht hätte. Mein (langer) Text: verloren.
Mein zweiter Versuch (der Text deutlich weniger ausführlich und diesmal sicherheitshalber in dem Editor meiner Wahl mit dem hilfreichen Firefox Add-On It's All Text geschrieben) wurde ebenfalls abgefangen, obwohl ich kritisch jedes Feld prüfte und jede Angabe machte. Was wars diesmal? Der "WP-Hashcash-Test" hätte festgestellt, dass ich leider kein JavaScript aktiviert hätte (natürlich nicht! Ich benutze NoScript), weswegen mein Kommentar leider nicht akzeptiert werden könnte und der unberechtigte Versuch gelogged würde. Ach!?
Eines sei mal gesagt: Clients und Server für Mail und Usenet waren vor zehn Jahren schon viel robuster als dieser Web 2.0-Schrott es heute ist. Wann bitte cached der erste Browser mal POST-Daten? Es wird langsam mal Zeit! Und noch eines sei gesagt: Serendipity mag kein so schönes Admin-Frontend haben, aber robuster ist die Software allemal. Diese geringschätzende Behandlung von Benutzerkommentaren ist einem Kommunikationsmedium unwürdig.
Mich nervt schon seit längerem der missionarische Eifer den manche meiner Bekannten packt seit sie einen Mac besitzen. Um das mal deutlich zu sagen: ich habe keine Lust mehr auf dummes Drohnengeblubber. Zugestanden sei: Eure Geräte haben die schönste Optik. Die verbreitete Vorstellung aber, im Besitz des besten aller Systeme zu sein, die kann man nur als naiv und dumm bezeichnen. Das manches, was zu solchen Bewertungen verführen mag, reine Geschmacksfragen sind, lasse ich in meiner Kritik mal außen vor. Tatsache ist: Mac OS X hat, wie jede verbreitete Betriebssystem, Vorzügen, aber auch Schwächen. Die ach so gepriesene Usability etwa erweist sich als Chimäre: wer gerne und viel mit der Tastatur arbeitet wird die OS X-GUI wenig mögen. Richtig ärgerlich aber sind schon seit langem die Schwächen in Punkto Sicherheitsfragen. Apple schafft es seit Jahren unsichere Software auszuliefern und zeigt dies auch in der jüngst erschienen Version ihres Betriebssystems wieder. Heise Security schrieb dazu:
Die Firewall von Mac OS X Leopard versagte in allen Tests: Sie ist standardmäßig nicht aktiviert und selbst wenn sie der Anwender einschaltet, verhält sie sich nicht so, wie er es erwartet. Netzwerkverbindungen zu nicht-autorisierten Diensten sind weiterhin möglich und selbst in der restriktivsten Einstellung "Alle eingehenden Verbindungen blockieren" lässt sie Zugriffe aus dem Internet auf Systemdienste zu. Auch wenn die hier aufgezeigten Probleme und Ungereimtheiten keine Sicherheitslöcher in dem Sinne darstellen, dass jemand über sie in einen Mac einbrechen könnte, ist Apple gut beraten, schleunigst nachzubessern.
Die Entgegnung, dass Apple dies (zumindest teilweise) mittlerweile getan hat, ändert nichts am Kernproblem und zeigt nur, dass einige Apple-Verfechter wie PR-Drohnen argumentieren, deren primäres Ziel die Verbreitung des Systems ist, nicht aber eine kritische Würdigung dessen. Denn: das Kernproblem ist nicht diese Sicherheitslücke (oder eine der vielen anderen, die in der Vergangenheit aufgetraucht sind), sondern das Apple keine tragfähigen Sicherheitskonzepte entwickelt und seine Produkte vor dem Shipping offenbar nicht auf Sicherheitskriterien hin überprüft. Wie wäre es anders zu erklären, dass gerade so einfach zu entdeckende und behebende Mängel erst durch einen schnellen, einfachen, externen Test auffallen?
Jeder Apple-Gläubige dieser Welt täte mir einen Gefallen (und würde sich nicht länger so blosstellen) wenn er sich mir gegenüber mit missionarischem Eifer zurückhalten würde und die Betriebssystemfrage erst dann wieder aufbrächte, wenn das rationale Denken wieder eingesetzt hat. Ich hab genug Bullshit gehört und hinreichend Weitblick um auch über mein präferiertes Betriebssystem hinausschauen zu können. Wer meint mich mit strunzdoofem Marketing beglücken zu müssen, macht sich nur lächerlich und provoziert mich höchstens dazu mal wieder zu erklären, warum mir im Zweifelsfall ein Windows das kleinere Übel wäre und warum ein modifizierter BSD-Kern noch kein gutes Betriebssystem macht...
Ich bin seit geraumer Zeit ein großer Fan des FUSE-Framesworks. Insbesonderes natürlich wegen dem sshfs, das ich vor rund ein oder zwei Jahren entdeckte. Ein anderes nützliches FUSE-Dateisystem ist ist wdfs, das WebDAV-Verzeichnis transparent ins Dateisystem einhängt. Auch hier ist die Anwendung wieder trivial:
wdfs http://do.main:80/dav/pfad/ ~/Desktop/FUSE -o username=USER -o password=PASSWORT
Sehr praktisch ist auch das EncFS mit dem sich Daten sehr einfach in einem verschlüsseltem Container, z.B. auf einem USB-Stick, ablegen lassen. Im Vergleich zu anderen Lösungen ist die Handhabung von EncFS ein Kinderspiel:
encfs /media/usbstick/crypt ~/Desktop/FUSE
Schade nur, dass es für Windoze keine kompatible Lösung gibt. Die Konkurrenzlösungen wie z.B. truecrypt haben alle den Nachteil das sie Root- bzw. Admininistrationsrechte brauchen. Für Mac-User gibt es übrigens eine eigene macfuse-Implementierung, mit der ein Großteil der unter Linux gebräuchlichen FUSE-Dateisysteme zu benutzen sind.
Einen Überblick über die bisher existierenden Dateisystem gibt es im FUSE-wiki.
Umouten kann man beide Dateisystem übrigens kann einfach mit fusermount -u ~/Desktop/FUSE (oder wenn der User Root-Rechte hat auch mit Rootrechten mit dem gewohnten umount-Befehl).
Das Update war wie gewohnt relativ zeitaufwändig aufwändig, aber weitestgehend schmerzfrei. Ärgerlich: die Updateroutinen schafften es nicht grub ordentlich zu aktualisieren. Ergebnis: das System bootete nach dem Update der Pakete nicht mehr. Der Bootsektor mußte von mir über ein Rettungssystem umständlich von Hand angelegt werden. DAU-freundlich ist das nicht.
Seit geraumer Zeit setze ich den Firefox zunehmend nicht nur zum Entwickeln von Webseiten ein, sondern er verdrängt zumindest momentan den zuvor von mir präferierten Konqueror auf beim normalen surfen. Deshalb war ich in letzter Zeit öfters irritiert, wenn ich mit Google etwas suchte und dann urplötzlich mit der Frage konfrontiert wurde, dass Site XYZ gerne ein paar Cookies setzen möchte und ob ich dies denn zulassen wolle.
Heute war ich genervt und schmiss den Sniffer an. Und tatsächlich: wie
vermutet prefetched der Firefox Web-Seiten. Es ist möglich, dieses
Verhalten zu ändern. In den detaillierten Konfigurationseinstellungen, die
sich mittels about:config finden lassen, befindet sich ein
passender Schalter. Mittels network.prefetch-next kann man
den Mechanismus einfach und schnell ausschalten. Standardmäßig ist er in
Firefox 2.0 aktiviert.
Der genaue Mechanimus war mir allerdings nicht klar. Es gibt haufenweise Links die erklären wie man prefetching abschaltet, aber kaum welche, in denen erklärt wird, wie es läuft. Also guckte ich mir die HTML-Auszeichnungen der Ergebnisseite Googles an...
Nicht nur der Staat schnüffelt. Die privaten Unternehmen stehen dem in nichts nach. Allen voran natürlich Google. Googles Datenhunger ist unersättlich und die Strategie die Google fährt durchaus clever. Die Angebotspalette wird ständig um attraktive Dienste ausgebaut:
Allesamt Dienste (nur eine Auswahl der m.E. wichtigsten), die entweder vielfach nachgefragt werden oder aber das Potential haben in Zukunft stark nachgefragt zu werden. Dazu kommen Desktop-Anwendungen wie Google Desktop, die Google Extensions für den Firefox oder das sehr populäre Picasa. Darüber hinaus bietet Google API auf die Programmierer von Software zugreifen können. So bedient sich zum Beispiel Firefox 2.0 der Anti-Phishing-Technologie von Google. Einer an sich nützlichen Technik, die leider nur den Haken hat, dass damit Google sehr genaue Bewegungsprofile von Benutzern erstellen kann. Dazu bietet Google eine ganze Reihe von von API's für seine großen und kleinen Dienste, die sich zunehmend auch verbreiten. So stieß ich zum Beispiel gestern darauf, dass der neue AJAX-basierende Webmailer RoundCube eine Google API zur Rechtschreibprüfung benutzt, was, wenn dieser Dienst aktiviert ist, im Klartext heißt, dass die gesamten zu prüfenden Inhalte an Google gesendet werden und dort natürlich auch ausgewertet werden können.
Google IST das Microsoft des Webs. Vielleicht ist "Google not evil", aber es hat monopolistische Tendenzen. Tendenzen, die um so besorgender sind, da hier Daten in rauhen Mengen gehorted werden. Daten, die durchaus auch mißbraucht werden können. Es ist Zeit für Datenschutz 2.0.
Nils und ich haben uns heute eine ganze Weile mit Debians Eigentümlichkeiten rumgeschlagen. Ausgangspunkt war die Frage, wie man Anpassungen bei dem Rotationsintervall von Standard-Logdateien, wie z.B. mail.log vornehmen könnte. Man sollte annehmen, dass ein paar simple Modifikationen an der logrotate Konfiguration reichen würden, aber weit gefehlt.
Leider ist Debians Policy alles andere als stringent: die meisten Pakete verwenden logrotate, während einige Pakete eigene Lösungen verwenden. Das syslog-Paket bedient sich des savelog-Tools, in einer für Standardfälle sicherlich arbeitssparenden, aber leider auch recht intransparenten Weise: Zuständig für die Rotation ist der Cronjob sysklogd in /etc/cron.daily/ bzw. /etc/cron.weekly/. Dieser wiederum bedient sich des Tools syslogd-listfiles, welches die aktuelle syslog.conf ausliest und die darin gefunden Dateien nach bestimmten Kriterien rotiert.
Wer das ganze lieber logrotate überlassen will, der lasse sich einfach mit syslogd-listfiles -a alle betroffenen Logdateien ausgeben, füge sie der logrotate-Konfiguration hinzu und lösche einfach den oben genannten Cronjob.
Die Kriterien nach denen Logdateien rotiert werden sind übrigens folgende:
Von Dateien, die täglich rotiert werden, wird ein Backlog von 7 Tagen aufbewahrt. Dateien die wöchentlich rotiert werden 4 Wochen. Eine weitere Inkonsistenz, die nicht nach meinem Geschmack ist.
PS: Wer (wie ich in früheren Installationen) syslog-ng verwendet braucht sich diese Mühe nicht machen. Das Paket syslog-ng verwendet wie gewohnt logrotate.