Zugschlusbeobachtungen - Security

My GPG key signing notes

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Mon, 04 Oct 2010 10:07:09 +0200

Spezifikation von Firewallregeln - do's and dont's

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Mon, 11 Jan 2010 10:29:40 +0100

Wenn eine Applikation über das Netz kommuniziert, funktioniert sie natürlich nur dann, wenn das Netz zwischen den beteiligten Maschinen diese Kommunikation auch durchleitet. Das ist im Internet üblicherweise der Fall; beim Übergang zwischen privaten Netzen und dem Internet in aller Regel nicht: Dort ist eine Firewall im Einsatz, die üblicherweise nach der Deny-all-Strategie alle Kommunikation blockiert, die nicht explizit freigegeben ist.

Auf diese Weise wird man im allgemeinen für eine neue Applikation eine Anpassung an der Firewall vornehmen müssen - es sei denn, die Applikation gibt sich Mühe, wie ein Dienst auszusehen, der üblicherweise freigegeben ist. Das tun zunehmend viele Applikationen und geben sich durch Benutzung von http als Transportprotokoll als Webclient und Webserver aus, was in vielen Firewalls direkt freigegeben ist. Doch dies ist Stoff für einen anderen Artikel.

In diesem Artikel möchte ich davon schreiben, wie die Spezifikation aussehen soll, damit der Firewalladmin auch weiß, was er für eine neue Applikation in seiner Firewall freischalten soll. In vielen Dokumentationen über (freie oder kommerzielle) Software findet man Listen von Ports, die mehr oder weniger vollständig und mehr oder weniger korrekt sind. Leider trifft in den meisten Fällen das “weniger” zu.

Doch zunächst ein paar Grundlagen zum Thema TCP/IP. Damit man in der Firewall nicht zu viel freigeben muss, sollten die notwendigen Kommunikationsbeziehungen möglichst eng beschrieben sein. Eine TCP/IP-Kommunikationsbeziehung fast aller Mainstreamprotokolle beschreibt ein Fünftupel, bestehend aus Source-IP, Destination-IP, Protokoll, Source-Port und Destination-Port.

Wenn ein Client C mit einem Server S sprechen möchte, dann ist das Protokoll, das er dafür benutzen möchte, in der Applikation festgelegt. TCP wird für Datenübertragung benutzt, bei der man sich darauf verlassen möchte, dass die Daten bei ihrer Ankunft am Ziel korrekt und vollständig sind, und bereit ist, dafür erhöhten Netzaufwand und unregelmäßige Übertragungszeiten in kauf zu nehmen. UDP benutzt man üblicherweise, wenn es sich nur um winzige Datenmengen (z.B. DNS-Anfragen und ihre Antworten) handelt oder es eher darauf ankommt, dass Daten entweder gar nicht oder halbwegs zeitlich passend ankommen (Streaming, Telefonie etc).

In beiden Fällen würfelt sich der Client normalerweise einen seiner freien Ports aus und benutzt diesen als Source-Port. Der Destination-Port ist meist mit der Applikation festgelegt und bestimmt auf der Seite des Empfängers den Prozess, bei dem das Paket abgeliefert werden soll. In der Programmierung funktioniert das so, dass der Serverprozess sich an den von ihm gewünschten Port bindet, ihn sozusagen “abhört” (im englischen nennt man das passender “listen on the port”) und alle dorthin gesendeten Daten empfangen kann.

So hat eine DNS-Anfrage üblicherweise das Protokoll UDP (Protokollnummer 17), die Destination-IP des Nameservers und den Destination-Port 53. Der Server dreht bei seiner Antwort das Tupel um und sendet seine Antwort mit Source-Port 53 mit der IP des Clients als Destination-IP und der vom Client als seinen Source-Port gewählten Portnummer als Destination-Port. Das sieht “auf dem Kabel” in etwa so aus:

01: proto=UDP srcip=192.168.218.21 srcport=49221 dstip=206.251.36.94 dstport=53
02: proto=UDP srcip=206.251.36.94 srcport=53 dstip=192.168.218.21 dstport=49221

Hier hat sich der Client also den Port 49221 gewürfelt. Die Antwort des Servers kommt bei der Client-Applikation an, weil sie an den Port 49221 geschickt wurde - der Client kann also die Antwort anhand des Destination-Ports des Antwortpaketes der Frage zuordnen.

Bei TCP (Protokollnummer 6) ist’s im Prinzip dasselbe, nur dass schon der Verbindungsaufbau (also bevor überhaupt ein Bit Nutzdaten geflossen sind) aus drei Paketen (dem sogenannten Dreiwegehandshake) besteht. Hier dasselbe für TCP und eine kurze http-Anfrage:

01: proto=TCP flags=SYN srcip=192.168.218.21 srcport=37734 dstip=81.169.179.176 dstport=80
02: proto=TCP flags=SYN,ACK srcip=81.169.179.176 srcport=80 dstip=192.168.218.21 dstport=37734
03: proto=TCP flags=ACK srcip=192.168.218.21 srcport=37734 dstip=81.169.179.176 dstport=80
04: proto=TCP flags= srcip=192.168.218.21 srcport=37734 dstip=81.169.179.176 dstport=80
05: proto=TCP flags= srcip=81.169.179.176 srcport=80 dstip=192.168.218.21 dstport=37734
06: proto=TCP flags= srcip=81.169.179.176 srcport=80 dstip=192.168.218.21 dstport=37734
07: proto=TCP flags= srcip=192.168.218.21 srcport=37734 dstip=81.169.179.176 dstport=80
08: proto=TCP flags=FIN srcip=81.169.179.176 srcport=80 dstip=192.168.218.21 dstport=37734
09: proto=TCP flags= srcip=192.168.218.21 srcport=37734 dstip=81.169.179.176 dstport=80
10: proto=TCP flags=FIN srcip=192.168.218.21 srcport=37734 dstip=81.169.179.176 dstport=80
11: proto=TCP flags= srcip=81.169.179.176 srcport=80 dstip=192.168.218.21 dstport=37734

Das bedarf dann doch einer kleinen Erklärung: Die Pakete 01 bis 03 sind der Dreiwegehandshake für den Verbindungsaufbau (SYN, SYN/ACK, ACK). In Paket 04 übermittelt der Client seinen http-Request, der in Paket 05 vom Server quittiert wird. Paket 06 ist die (in ein Paket passende) Antwort; Paket 07 die dazu gehörende Quittung. Da der Server keine weiteren Daten zu übermitteln hat, signalisiert er in Paket 08 den Wunsch des Verbindungsabbaus (FIN). Paket 09 ist die Quittung dafür; die Pakete 10 und 11 sind der Verbindungsabbau seitens des Clients und die dazu passende Quittung.

Abgesehen von den oben gezeigten Standardfällen gibt es noch einen ganzen Haufen von Sonderfällen. So hat ESP als IP-Protokoll keine Portnummern, so dass ein Paket einer ESP-Verbindung nur durch das Tripel Source-IP, Destination-IP, Protokollnummer 50 (ESP) klassifiziert werden kann. In einigen wenigen Protokollen spielt die Absenderportnummer eine Rolle; und wieder andere wenige Protokolle benutzen TCP UND UDP, dies aber auf derselben Portnummer. Und dann gibt es natürlich “kranke, firewallfeindliche” Protokolle wie ftp, SIP, nfs, amanda, RPC (inklusive MS-RPC), bei denen die Portnummern für den “eigentlichen” Dienst beidseitig erst durch eine Unterhaltung der beteiligten Systeme durch eine Steuerverbindung auf einem wohldefinierten Port ermittelt werden.

Wir sehen auch, dass im allgemeinen die Kommunikation zwischen zwei Systemen nahezu immer bidirektional stattfindet. Nur in ganz wenigen Sonderfällen (von denen mir gerade partout keiner einfallen möchte) versendet die eine Seite ein Paket, ohne sich jemals für eine Antwort oder Quittung zu interessieren. Glücklicherweise braucht man sich darum in der Regel heutzutage bei halbwegs aktuellen Firewalls nicht mehr zu kümmern: Es reicht, wenn man für eine erwünschte Kommunikationsbeziehung das jeweils erste Paket erlaubt; die direkt oder indirekt dazu gehörenden Pakete werden von der Firewall automatisch als solche erkannt und automatisch durchgelassen. Das trifft meist auf die direkten Antwortpakete zu, aber bei besseren Systemen auch auf kompliziertere Fälle wie den unabhängigen Datenkanal bei “kranken” Protokollen wie ftp oder zur Verbindung gehörende ICMP-Fehler wie “host unreachable” oder “fragmentation needed”.

Für die beiden oben zitierten Paketdumps reichen also zwei Regeln:

proto=UDP srcip=192.168.218.21 srcport=49221 dstip=206.251.36.94 dstport=53
proto=TCP flags=SYN srcip=192.168.218.21 srcport=37734 dstip=81.169.179.176 dstport=80

Halt, stop. Da ist noch was zu viel: Der Source-Port wird vom Client jeweils neu ausgewürfelt; wir dürfen die Firewallregeln also nicht ganz so eng fassen, wenn der Dienst auch beim zweiten Zugriffsversuch noch funktionieren soll:

proto=UDP srcip=192.168.218.21 dstip=206.251.36.94 dstport=53
proto=TCP flags=SYN srcip=192.168.218.21 dstip=81.169.179.176 dstport=80

Wie wir alle wissen, benutzt DNS im Normalfall UDP, fällt aber bei manchen Fehlern auf das (langsamere, aufwändigere) TCP zurück - beispielsweise wenn die Antwort nicht mehr in ein Antwortpaket passt. Also braucht’s noch eine dritte Regel, die den DNS-Sonderfall abdeckt:

proto=TCP flags=SYN srcip=192.168.218.21 dstip=206.251.36.94 dstport=53

Bei TCP ist es zweckmäßig, nur “erste” Pakete durchzulassen, die auch korrekterweise das SYN-Flag gesetzt haben. Sonst lässt man im Zweifel Pakete bis zum Host durch, von denen wir schon wissen, dass sie nicht koscher sind, und dass der Host sie eh nur verwerfen wird.

Auf Unix-ähnlichen Systemen gibt es noch eine weitere Unterscheidung: Die Ports 1-1023 bleiben dem Benutzer root vorbehalten; nur Prozesse, die als root laufen, dürfen diese Ports des lokalen Systems verwenden. Man sieht deswegen in Firewallregeln wie den oberen oft die Begrenzung auf die “hohen” Ports ab 1024. Eine solche Begrenzung bringt aber keine zusätzliche Sicherheit, denn ein Prozess, der einen der “niedrigen” Ports benutzen darf, könnte genauso gut einen “hohen” Port verwenden. Ich empfehle deswegen das KISS-Prinzip und den allgemeinen Verzicht auf Beschränkungen des Source-Ports bei so einfachen Regeln.

Aus diesen Informationen dürfte klar sein, dass an Herstellerdokumentationen “erlauben Sie Port 80 TCP/UDP” oder “Wir benutzen die Ports 514 und 443 incoming und outgoing” oder “benötigt: Port 1024-65535” wenig Sachkenntnis beteiligt war. Wer stur nach solchen Regeln arbeitet, reißt sich große Sicherheitslöcher in seine Infrastruktur und ist nur noch durch das vielleicht vorhandene NAT vor den fatalen Folgen solcher Konfigurationsfehlern geschützt - oder eben nicht.

Je länger die Portliste, desto höher ist die Wahrscheinlichkeit, dass manche dieser Ports nur noch aus historischen Gründen in der Liste stehen und von der Applikation seit etwa 1948 nicht mehr genutzt werden. Gerne sieht man das bei Applikationen, die unter Windows entweder Laufwerke mappen wollen oder in irgend einer Art mit dem Active Directory sprechen: Microsoft hat diese beiden Zugriffsmethoden in den letzten zehn Jahren mehrfach umspezifiziert und jedes Mal neue Ports verwendet, und die älteren Portnummern braucht man nur, wenn auch noch ältere Versionen im Einsatz sind. In aktuellen Netzen reißt man sich damit potenzielle Sicherheitslöcher, denn auch die aktuellen Server lauschen natürlich im Interesse der Rückwärtskompatibilität auch auf den “älteren” Ports.

Viele andere Ports aus solchen ellenlangen Listen werden nur dann benötigt, wenn man ein bestimmtes obskures Feature der Software verwendet. Oder ein Eintrag in einer Portliste ist schlicht und einfach inkorrekt. Auch schon passiert: Ein essentiell wichtiger Port steht aus irgend einem Grund nicht in der Liste und lässt die Applikation auch dann subtil versagen, wenn man die Portdokumentation sklavisch in Firewallregeln konvertiert hat.

Deswegen lautet meine Empfehlung ganz klar, vom Hersteller einer Software gelieferte Portlisten komplett zu ignorieren und aus tcpdump und Firewall-Log herauszudestillieren, welche Kommunikationsbeziehungen die Applikation im gegebenen Anwendungsszenario wirklich zu benutzen gedenkt. Das funktioniert allerdings selten auf Anhieb, weil oftmals der nächste Port erst benutzt wird, wenn der Zugriff auf den erstfreigegebenen Port erfolgreich war. Man ist also gut beraten, wenn man die Applikation entweder selbst bedient oder den Anwender vorher darauf vorbereitet, dass man mehrere Iterationen von “probier’s nochmal, ah ja, moment” benötigen wird bis die Applikation benutzbar sein wird - denn sonst wird einem diese Trial-and-Error-Methode gerne als unstrukturiertes oder unfähiges Vorgehen missinterpretiert. Außerdem muss man darauf vorbereitet sein, im Rahmen dieser Vorgehensweise auch die obskureren Funktionen der Software bis hin zum “Agent-Update auf dem Client” auszuprobieren, denn sonst fällt einem die Sicherheitspolicy vielleicht irgendwann im laufenden Betrieb schmerzhaft auf den Fuß.

Wenn man die aufwändige Phase einmal abgeschlossen hat, wird man nicht selten mit einem schlanken, gut dokumentierten Regelwerk belohnt, von dem man weiß, dass es keine unnötigen Risiken enthält. Außerdem bekommt man durch die Arbeit mit dem Firewall-Log und tcpdump ein Gefühl für die Kommunikation und genug Erfahrung mit den Tools, um später im Fehlerfall souverän mit den Tools umgehen zu können und deren Ausgabe sinnvoll interpretieren zu können. Und es erspart einem unnötige Aktionen mit der Glaskugel um zu raten, was der Hersteller mit seiner unvollständigen Dokumentation, die nicht selten stur aus einer Portliste ohne Protokoll- und Richtungsangabe besteht, wohl gemeint haben könnte.

Abschließend noch eine Wunschliste: Wenn Ihr den Firewallbetreuern Eurer Anwender einen großen Gefallen tut, dann beschreibt die Kommunikationsbeziehungen Eurer Software vollständig. Das bedeutet also im Zweifel eine Liste wie hier:

name=DNS proto=(UDP/TCP) srcip=(1) dstip=(2) dstport=53
name=http proto=TCP srcip=(1) dstip=ivanova.notwork.de,*.zugschlus.de dstport=80
name=amanda-control proto=UDP srcip=client dstip=server dstport=10080
name=amanda-data proto=TCP srcip=client srcport=50000 dstip=server dstport=50000-50100

(1)=IP-Adresse des lokalen Systems
(2)=Full Service Resolver für das lokale System

Dokumentation gehört zum Regelwerk dazu, denn man möchte auch in zwei Jahren noch verstehen, warum man das, was da drin steht, auch reingeschrieben hat. Deswegen liefert Eurem Firewaller bitte auch, wie das System heißt, für das da die Regeln eingetragen werden sollen, und was es tut. Er wird dann noch das aktuelle Datum und Euren Namen dazuschreiben, und dann ist die Dokumentation brauchbar.

Wenn es sich um ein Testsystem handelt, ist es sinnvoll, die damit verbundenen Regeln zeitlich zu beschränken. Dazu muss der Firewaller aber wissen, dass es ein Test ist, und wie lange er voraussichtlich dauern wird. Manche Firewallsysteme können bei jeder Regel sofort ein Verfallsdatum dazuschreiben. ab der die Regel automatisch nicht mehr angewendet wird. Sonst muss man das halt manuell mit Kommentaren im Regelwerk machen. Geht auch.

Scan eingehender Mail auf Malware

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Fri, 07 Nov 2008 18:30:43 +0100

Dadurch, dass mein Mailsystem in seiner Eigenschaft als Nichtwindows nicht besonders anfällig gegen Malware ist und ich auch nicht blind auf jeden Anhang klicke, leiste ich mir seit einigen Jahren den Luxus, dass der Clamav auf meinem Mailserver nur die Malware ablehnt, die ich explizit konfiguriert habe. So werde ich die lästigsten Störer automatisch los und habe trotzdem einen Überblick darüber, was im Moment so an Malware unterwegs ist, weil der Clamav natürlich auch Malware, die nicht auf der Reject-Liste steht, markiert.

Es gab zwischendrin eine Zeit, da kam ungefähr gar nichts. So wenig jedenfalls, dass ich ernsthaft darüber nachgedacht habe, die CPU-Zyklen für den Scan eingehender Mail auf Malware einzusparen und den Mailvirenscanner abzuschalten.

Gut, dass ich das nicht gemacht habe, denn in den letzten zwei bis drei Wochen kommt durchaus wieder Malware per Mail in signifikanter Menge (also mehr als zwanzig pro Tag). So hat der Clamav wieder ein wenig mehr zu tun, und ich werde in Zukunft nicht mehr so schnell darüber nachdenken, einen nicht störenden Sicherheitsmechanismus wegen “irrelevant, braucht man heutzutage nicht mehr” abzuschalten.

Funktastaturen sind immer noch böse

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sat, 01 Dec 2007 17:39:20 +0100

Funktastaturen sind dafür, dass sie gegenüber klassischen Tastaturen eigentlich nur Nachteile haben, erschreckend weit verbreitet. Sie sind nur unwesentlich weniger unhandlich wie kabelgebundene TastBaturen, fressen dafür Batterien wie blöde, verringern den Kabelsalat nicht - und unsicher sind sie oft auch.

Funktastaturen sind besonders im Firmenumfeld fast ausschließlich dort zu finden, wo mit vertraulichen Strategiedaten umgegangen wird, nämlich in der Chefetage. Dort sind die Informationen, die tagein, tagaus in die Tastaturen gehämmert werden, in aller Regel sensibler als dort, wo es aus Kostengründen keine Funktastaturen gibt (sie aber eventuell sinnvoller wären). Schließlich erwartet man gerade von den großen Herstellern mit L und mit M, dass sie sich ein Mindestmaß über die Vertraulichkeit der über die meist proprietären Funkstrecken Gedanken machen.

Schon vor fünf Jahren konnten meine Kollegen mit ihren L-Tastaturen die Eingaben der Firma eine Etage höher abgreifen, und laut heise online hat es jetzt die mit einem dem Stand der Technik von 1540 entsprechenden 8-Bit-XOR-Schlüssel gesicherten Funktastaturen von M erwischt. So eine “Verschlüsselung” reicht gerade, um dem Laien zu zeigen, dass da keine Klartextdaten über die Luftschnittstelle gehen; einem mit unterdurchschnittlicher Energie ankommenden Angreifer hält so eine “Sicherheit” geschätzt dreieinhalb Sekunden stand, und dann liegen alle getippten Passworte und Buchhaltungsdaten dem Mithörer weit offen.

Und so muss meine Empfehlung weiterhin lauten: Finger weg von Funktastaturen. Und wenn es partout ein Statussymbol sein muss, oder der Einsatz einer Funktastatur ausnahmsweise mal Sinn und Zweck haben (z.B. bei einem Entertainment-PC, den man auch vom Sofa aus bedienen können will), sollte man wenigstens das Geld für eine Bluetooth-Tastatur in die Hand nehmen: Das ist ein offener Standard, dessen Sicherheit zwar nicht berauschend gut ist, aber eine derartige Peinlichkeit, wie sie sich Vendor M mit seinen Produkten geleistet hat, ist dort eher nicht zu erwarten.

Ach ja, übrigens: Wenn Ihr mich richtig ärgern wollt, nehmt mir meine kabellose Maus weg. Besonders mit Bluetooth ist das Klasse, wenn das Notebook das Bluetooth-Interface bereits eingebaut hat und man am Notebook überhaupt nichts einstöpseln muss und die Maus trotzdem einfach funktioniert. Aber das Konzept war wohl zu einfach und nicht proprietär genug, denn Vendor L hat die MX 900 schon vor vielen Monaten aus dem Programm genommen.

Dysfunktionales Yahoogroups

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sat, 26 May 2007 08:34:53 +0200

Die Raptor-Mailingliste hat hat Ende 2005 ihren Hoster verloren und der Moderator hat sie umgezogen. Zu Yahoogroups. Grmbl.

Da kann man zwar subscriben als wäre es eine Mailingliste, aber in Wirklichkeit gibt es natürlich “Mehrwert”. Zum Beispiel den Mehrwert, dass man sich für jeden Scheixx anmelden muss. So zum Beispiel auch dafür, wenn man gucken will, warum Mails nicht ankommen in der Liste.

Die letzte Mail, die ich über die Liste bekommen habe, ist vom 30. April. Das ist für eine Liste, die normalerweise gut über zehn Beiträge pro Monat sammelt, eine schon verhältnismäßig lange Pause. Und die Mail, die ich am 16. Mai an die Liste geschrieben habe, ist noch nicht angekommen.

Ich frage mich nun: Ist die Liste technisch gestört, oder ist sie “nur” tot und ich habe bei meiner Einreichung etwas falsch gemacht? Leider braucht man zur Ermittlung dieses Status eine Yahoo-ID, die ich nicht habe, und wenn ich versuche herauszufinden ob vielleicht automatisch eine angelegt wurde, fragt er haufenweise persönliche Daten ab, die ich sicher beim subscribe nicht angegeben habe, und will dann ein nicht funktionierndes Captcha gelöst haben.

Warum hätte man nicht einfach einen Mailinglistenservice nehmen können?

Berufsverbot

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 21 Sep 2006 10:38:28 +0200

Das Bundesministerium der Justiz bereitet einen Gesetzentwurf vor, der den Schutz vor Computerkriminalität mit strafrechtlichen Maßnahmen verbessern soll. Und handelt Deutschland erneut den Verlust von zahlreichen hochqualifizierten Arbeitsplätzen im Hochtechnologiesektor ein.

Der Gesetzentwurf zur Änderung des StGB fügt einen neuen Paragrafen 202 c “Vorbereiten des Ausspähens und Abfangens von Daten” in das Strafgesetzbuch ein.

Wer eine Straftat nach § 202 a oder § 202 b vorbereitet, indem er

Passworte oder sonstige Sicherungscodes, die den Zugang zu Daten (§ 202 a Abs. 2) ermöglichen, oder

Computerprogramme, deren Zweck die Begehung einer solchen Tat ist, herstellt, sich oder einem anderen verschafft, verkauft, einem anderen überlässt, verbreitet oder sonst zugänglich macht,

wird mit Freiheitsstrafe bis zu einem Jahr oder mit Geldstrafe bestraft.

§ 202 a ist heute schon “Ausspähen von Daten”; § 202 b wird “Abfangen von Daten”.

Es wird also in Zukunft verboten sein,

Proof of Concepts für Schwachstellenausnutzung zu erstellen (“herstellen”)
Bugtraq, Full Disclosure oder ähnliche Mailinglisten auch nur abonniert zu haben (“sich verschaffen”)
Schwachstellenanalysen durchzuführen (da man sich vorher Tools entweder verschaffen oder herstellen muss)
“Live Hacking” als Schockeffekt in Seminaren (“sonst zugänglich machen”)
Linux-Distributionen, die nmap oder nessus enthalten zum Download bereitzuhalten (“verbreiten”)

Was bleibt einem Security-Consultant in Deutschland dann noch als Arbeitsmöglichkeiten offen?

Ich glaube, ich muss doch auf Schafzucht oder Lokführer umsatteln. Qualifizierte Arbeitsplätze sind in Deutschland wohl unerwünscht.

Sind Firewalls noch zeitgemäß?

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Wed, 19 Jul 2006 13:55:36 +0200

Die meisten restriktiven Security Policies haben inzwischen ein Alter von drei bis fünf Jahren erreicht. Damals hat man das als Policy niedergelegt, was im gerade führenden Fachbuch stand, und somit auch schon einige Jahre auf dem Buckel hatte. Auf solch einer alten Policy aufgesetzte Sicherheitsmaßnahmen, die typischerweise das böse Internet mit einer (!) Firewall von dem einen (!) internen Netz abtrennen und bestenfalls eine kleine Handvoll Servicenetze (vulgo “DMZ”, wobei “mehr als ein Servicenetz” immer noch mit “Respekt! Das ist aber gut durchdacht!” kommentiert wird) beinhalten, sind in der heutigen Welt kaum mehr zeitgemäß; es ist Zeit, hier anzusetzen.

Mit Policies auf dem technischen Stand von vor fünf Jahren ist heute ein messbarer Sicherheitsgewinn kaum mehr erreichbar. Zu sehr verschwimmen in den letzten Jahren die Netzgrenzen, werden durch Inter-, Extra- und Intranet, VPN-Tunnel, UMTS, Wireless LAN, Mobile Devices, Suspendmodi und andere Dinge immer weiter aufgeweicht, so dass eine einzige klassische Firewall am Unternehmenseingang heute nicht mehr zeitgemäß ist. Mit solchen Lösungen erreicht man nur, dass die Leute, die die Arbeit machen, bei ihrer Leistungserbringung massiv behindert werden, was die IT-Kosten in ihrer Gesamtheit in astronomische Höhen treibt. Außerdem bauen die Leistungsträger sich in so einer Umgebung policykonforme Workarounds, die nur deswegen policykonform sind, weil es sie zum Zeitpunkt der Policyerstellung schlicht noch nicht gab und sie deswegen in der Policy nicht verboten sind. Interessant finde ich übrigens, dass es kaum eine Security Policy gibt, die die in der Technik seit 20 Jahren übliche Maxime “Es ist alles verboten, was nicht ausdrücklich erlaubt ist” (vulgo “default deny”) zur Grundlage hat. Nein, die meisten Policies ergehen sich in seitenlangen Listen von Dingen, die bei sofortiger Entleibung niemalsnie passieren dürfen. Das Ergebnis ist der GAU: Hohe Kosten bei nur mäßigem Sicherheitsniveau.

Nun, wie schon so oft: Kris Köhntopp hat das schon vor Jahren ausgeforscht. Seine Präsentation über Mobile Devices spricht mir aus der Seele, und er hat natürlich Recht. Besonders seine Aussage, dass die Benutzer immer kreativer werden, je restriktiver die Policy ist, ist eine viel zu selten in dieser Deutlichkeit ausgesprochene Wahrheit.

Was lernen wir daraus? Eine Security Policy ist nur dann sinnvoll, wenn man sie aktuell hält. Wobei “aktuell” nicht nur heißt, dass man die technischen Weiterentwicklungen, die den Sinn der alten Policy in Frage stellen, verbietet - nein, das wird man eh nicht durchhalten können, weil viele dieser technischen Weiterentwicklungen als Spielzeug für die Entscheider taugen und man deren Verbot deswegen eh nicht wird durchhalten können. Es ist vielmehr sinnvoll, die existierende Policy in regelmäßigen Abständen - am besten innerhalb eines formellen Review-Prozesses - zu hinterfragen und zu modernisieren. Das bedeutet freilich auch, dass manche Verbote aufgehoben oder abgeschwächt gehören und man sich nach anderen Wegen zur Reduktion des Risikos umsehen muss. Die Security wird in den nächsten Jahren wieder näher an die Daten selbst, also an die Server, heranrücken müssen, und dafür wird Geld in die Hand genomen werden müssen. Als Belohnung winken schneller ablaufende, weniger kostende IT-Projekte in der Zukunft.

Viele Unternehmen werden externen Rat nötig haben, und zwar sowohl im Prozess der Policyanpassung als auch bei der Umsetzung der neuen Policy. Es wird viel zu tun geben - fragen Sie bitte jemanden, der sich auskennt!

Microsoft über den Umgang mit kompromittierten Systemen

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sun, 21 May 2006 09:06:42 +0200

Im Microsoft Technet stehen von Zeit zu Zeit echte Perlen. Aber die hier ist so gut (und so wahr), dass ich sie sogar hier zitieren muss.

Jesper M. Johansson, Ph.D., CISSP, MCSE, MCP+I, seines Zeichens Security Program Manager bei der Microsoft Corporation, schreibt in einem Artikel mit dem Titel “Help: I Got Hacked. Now What Do I Do?” aus dem Mai 2004:

You can’t clean a compromised system by patching it. Patching only removes the vulnerability. Upon getting into your system, the attacker probably ensured that there were several other ways to get back in.
You can’t clean a compromised system by removing the back doors. You can never guarantee that you found all the back doors the attacker put in. The fact that you can’t find any more may only mean you don’t know where to look, or that the system is so compromised that what you are seeing is not actually what is there.
You can’t clean a compromised system by using some “vulnerability remover.” Let’s say you had a system hit by Blaster. A number of vendors (including Microsoft) published vulnerability removers for Blaster. Can you trust a system that had Blaster after the tool is run? I wouldn’t. If the system was vulnerable to Blaster, it was also vulnerable to a number of other attacks. Can you guarantee that none of those have been run against it? I didn’t think so.
You can’t clean a compromised system by using a virus scanner. To tell you the truth, a fully compromised system can’t be trusted. Even virus scanners must at some level rely on the system to not lie to them. If they ask whether a particular file is present, the attacker may simply have a tool in place that lies about it. Note that if you can guarantee that the only thing that compromised the system was a particular virus or worm and you know that this virus has no back doors associated with it, and the vulnerability used by the virus was not available remotely, then a virus scanner can be used to clean the system. For example, the vast majority of e-mail worms rely on a user opening an attachment. In this particular case, it is possible that the only infection on the system is the one that came from the attachment containing the worm. However, if the vulnerability used by the worm was available remotely without user action, then you can’t guarantee that the worm was the only thing that used that vulnerability. It is entirely possible that something else used the same vulnerability. In this case, you can’t just patch the system.
You can’t clean a compromised system by reinstalling the operating system over the existing installation. Again, the attacker may very well have tools in place that tell the installer lies. If that happens, the installer may not actually remove the compromised files. In addition, the attacker may also have put back doors in non-operating system components.
You can’t trust any data copied from a compromised system. Once an attacker gets into a system, all the data on it may be modified. In the best-case scenario, copying data off a compromised system and putting it on a clean system will give you potentially untrustworthy data. In the worst-case scenario, you may actually have copied a back door hidden in the data.
You can’t trust the event logs on a compromised system. Upon gaining full access to a system, it is simple for an attacker to modify the event logs on that system to cover any tracks. If you rely on the event logs to tell you what has been done to your system, you may just be reading what the attacker wants you to read.
You may not be able to trust your latest backup. How can you tell when the original attack took place? The event logs cannot be trusted to tell you. Without that knowledge, your latest backup is useless. It may be a backup that includes all the back doors currently on the system.
The only way to clean a compromised system is to flatten and rebuild. That’s right. If you have a system that has been completely compromised, the only thing you can do is to flatten the system (reformat the system disk) and rebuild it from scratch (reinstall Windows and your applications). Alternatively, you could of course work on your resume instead, but I don’t want to see you doing that.

Ein weiser Mann. Ich wünsche mir, dass einige Manager in Zukunft auf diesen weisen Mann hören.

Gefunden hab ich das übrigens bei Dirk, und der hat’s von El Loco.

Port Knocking für ssh

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Wed, 03 May 2006 22:50:00 +0200

ixs berichtet über eine neue mögliche aus der Ferne ausnutzbare Schwachstelle in OpenSSH, und ich nutze die Gelegenheit, für etwas Forschung im Bereich Port Knocking.

Port Knocking ist eine Technik, bei der ein auf einem System im Internet laufender Dienst erst dann für die IP-Adresse eines Clients sichtbar wird, wenn dieser Client vorher eine Folge von vorab festgelegten Paketen an den Host geschickt hat. Das ganze ist natürlich eine Art Security by Obscurity, und ähnelt den Mechanismen von Geheimdiensten, bei denen man erst vom Agenten angesprochen wird, wenn man sich zuerst in der Nase gebohrt, dann die Brille zurechtgerückt und schließlich etwas vom Boden aufgehoben hat.

Eine kurze Suche im Debian-Archiv fördert die Package knockd zu Tage, die einen Daemon und einen Client enthält, mit dem man Port Knocking umsetzen kann. Mit einer schön einfachen konfiguration kann man den knockd dazu veranlassen, nach Empfang gewisser Pakete bestimmte Kommandos auszuführen. Hier ein Beispiel:

[opencloseSSH]
        sequence         = 1234:udp,8765:tcp,54321:tcp
        seq_timeout      = 5
        start_command    = /sbin/iptables --append dynamic -s %IP% -p tcp --dport 22 -j ACCEPT
        tcpflags         = syn
        cmd_timeout      = 60
        stop_command     = /sbin/iptables --delete dynamic -s %IP% -p tcp --dport 22 -j ACCEPT

In diesem Beispiel legt der knockd eine iptables-Regel an, die den Zugriff auf TCP-Port 22 von einer IP genau dann erlaubt, wenn innerhalb von fünf Sekunden von dieser IP-Adresse ein Paket an UDP-Port 1234, dann ein Paket an TCP-Port 8765 und schließlich ein Paket an TCP-port 54321 empfangen wurde. Diese Regel bleibt 60 Sekunden bestehen und wird danach wieder entfernt.

Sprich: Wenn man knockd verwenden will, braucht’s mindestens ein minimales Paketfiltermanagement auf dem System, denn sonst fehlt das Drumrum. Ich habe zwar mit meinem netfilter-init eine eigene Dauerbaustelle von einem sehr leistungsfähigen (aber auch langsamen) Paketfiltermanager, wollte hier aber auf eine Standardlösung zurückgreifen. Die Auswahl hierfür fiel schnell auf shorewall, weil ich mir das schon lange mal angucken wollte.

Die Shorewall-Package in Debian haut mich nicht wirklich vom Stuhl: Entgegen dem, was ich eigentlich erwarte, kommt sie in keinster Weise vorkonfiguriert, der Paketfilter ist disabled und das Regelwerk leer. Man muss sich also aus den nach /usr/share/doc/shorewall installierten Beispielen aus der Original-Doku sein eigenes Regelwerk zusammenzimmern und bekommt auf diese Weise keine automatischen Updates.

Nun, eine “allow all” Policy ist schnell zusammengezimmert. Das Regelwerk, das im Default gebaut wird, kümmert sich schön um Grenzfälle und ist in diesem Punkt besser als das, was mein netfilter-init bastelt.

Allerdings ist shorewall nicht so “high-level” wie es sich in den Markeingtexten gibt. Auch hier schreibt man Regeln, welches Protokoll und welche Quell-/Zielports von welcher IP auf welche IP erlaubt und verboten sein sollen, wobei es schöne Symboliken für Netze und Interfacegruppen (so genannte Zonen) gibt. Hübsch. Auch gibt es Mechanismen, die nach einer bestimmten Zeit wieder auf den alten Zustand (bzw. “komplett offen”) zurückrollen, wenn die erfolgreiche Aktivierung des Paketfilters nicht vom Bediener bestätigt wird.

Etwas unterentwickelt sind die Blacklistfähigkeiten. Man kann mit einem Shellkommando einzelne IP-Adressen komplett blocken, und diese Blockierung wieder aufheben. Einem Angreifer nur einen Port sperren, oder eine weiter hinten im Regelwerk stehende Reject-Regel für einzelne IP-Adressen aufheben (wie es für das Port-Knocking-Projekt notwendig ist), geht mit Bordmitteln nicht. Leider sind meine Bugs, die ich heute mittag gegen Shorewall geschrieben habe, irgendwo versackt und nichtmal im Exim-Log des Hosts angekommen.

Mit der Kombination aus dem wie oben gezeigten knockd und shorewall funktioniert Port Knocking auf nechayev.zugschlus.de inzwischen ziemlich gut, ich bin zufrieden. Ich werd mir das mal ein paar Tage angucken und dann überlegen, ob ich es auf die anderen Hosts ausdehne.

knockd enthält auch einen Client, mit dem man die notwendigen Pakete verschicken kann. Das einzige, was noch fehlt, ist eine Hook-Option im Openssh-Client, um den knock-Aufruf automatisch in das ssh-Kommando einzuklinken. Bugreport ist eingereicht.

X509 Certification Authority

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Fri, 14 Apr 2006 15:44:00 +0200

In diesem Artikel samme ich Links zu Literatur und HOWTOs über den Aufbau lokaler X.509 Certification Authorities.

David Pashley: Becoming a X.509 Certificate Authority. Inklusive einiger interessanter Artikellinks für “further reading” am Ende des Artikels.

virtually exploitable

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 19 Jan 2006 09:59:42 +0100

Seit Jahren schon unke ich darüber, dass Virtualisierung a la vmware, Xen und Co zwar sehr kostensenkend und vereinfachend sein kann, aber mit einer Reduktion des Sicherheitsniveaus einhergeht. Und auch seit Jahren werde ich dafür belächelt und die virtuelle Umgebung trotzdem weiter ausgerollt.

So erfüllt es mich mit wenigstens etwas Befriedigung, dass der von mir vorhergesagte Fall inzwischen eingetreten ist: Durch einen Buffer Overflow im vmware-NAT-Treiber ist - sowohl unter Linux als auch unter Windows - die Übernahme des Gastgebersystems möglich. Und da dieser Treiber ziemlich weit unten im Gastsystem eingreift, gibt’s die root- und/oder Administratorprivilegien gratis und franko gleich dazu. Dazu, dass dieser Exploit ausgerechnet (oder
erwartungsgemäß?) die kommerzielle Virtualisierungsvariante vmware betrifft, sag ich lieber nichts, denn die entsprechende Lücke in einer der freien Alternativen kommt bestimmt.

vmware hat gepatched und eine korrigierte Version ohne diese Schwachstelle herausgegeben, die alle vmware-Admins nun bitte schnellstmöglich auf ihre Systeme ausrollen mögen.

Es bleibt das etwas schale Gefühl, Recht gehabt zu haben mit der Unkerei. Gut tun tut das irgendwie nicht.

To self-signed or not to self-sign?

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 08 Dec 2005 14:52:05 +0100

Auf der Nesus-Mailingliste fand ich heute eine Mail, deren Autor sich darüber wundert, dass
Nessus bei einem Self-Signed Certificate keine Warnung wirft.

Schließlich ist das eine schlechte Security-Maßnahme weil auf diese Weise Man-in-the-Middle-Attacken möglich werden. Das sei insbesondere im kommerziellen Umfeld ein Problem.

Nun, meine Meinung dazu ist, dass es sicherer sein kann, ein selbstsigniertes Zertifikat selbst zu verifizieren als sich blind auf die durchaus durchwachsenen Prozesse einer kommerziellen CA zu verlassen.

Ach ja, die oben zitierte Mail kam von einem Verisign-Mitarbeiter.

suexec, die nächste

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sun, 27 Nov 2005 11:27:02 +0100

In Fortsetzung von suexec my php, baby^wapache habe ich gestern suexec auf dem ersten Produktivsystem verfügbar gemacht, und einige Unzulänglichkeiten im Debian-Setup gefunden.

Die Umstellung des Zielsystems von apache auf apache2 ging erschreckend schmerzfrei vonstatten. Die einzige Falle dabei war, dass einige Dinge (z.B. der ScriptAlias auf /usr/lib/cgi-bin) bei apache in der Serverkonfiguration steht, bei apache2 aber (IMO sinnvollerweise) in den virtual host geschrieben werden muss. Es waren also minimale Änderungen an der kopierten virtual-host-Konfiguration notwendig.

Dann suexec. Ich bin natürlich wieder in die Falle getappt, dass ich erwartet habe, dass das cgi mit den Rechten des Fileowners läuft, und ich habe wieder übersehen, dass suexec ein eigenes Log (/var/log/apache2/suexec.log) schreibt. Als nächstes musste ich die userbezogenen virtuellen Hosts von ~user/.www/www.virthost.example nach /var/www/virtual-hosts/user/www.virthost.example verschieben, da Debians suexec nur cgi-bins aus /var/www suexecen mag. /var/www/virtual-hosts muss man dann in der Konfiguration für den default virtual host auf “deny from all” setzen, damit man die Inhalte der virtual hosts nicht zusätzlich noch über den default virtual host erreichen kann. Das ist auch der Grund für die dazwischen eingeschobene Verzeichnisebene.

So weit, so gut, für die cgi-bins der Benutzer.

Nun möchte ich allerdings, wenn ich schon suexec am Start habe, auch gerne die aus Debian-Packages kommenden cgi-Scripts suexecen. Und das ist ein Punkt, wo ich vorerst bei einem knackingen “geht nicht” angekommen bin.

suexec suexect nur, was in /var/www liegt. Debian-Packages werfen ihre cgi-scrips aber nach /usr/lib/cgi-bin

suexec kann für jeden Virtual Host nur auf einen User suexecen. Bei den Scripts aus Debian-Packages wäre es aber sinnvoll, unterschiedliche Scripte auf unterschiedliche User zu mappen.

Also wird man wohl in den sauren Apfel beissen und sich darauf verlassen müssen, dass das, was aus Debian-Packages kommt, hinreichend sicher ist, dass man es mit den Rechten des Webservers laufen lassen kann. Auch wenn das bedeutet, dass einige Logs für www-data writeable sein müssen, was ich persönlich so richtig ätzend finde.

suexec my php, baby^wapache2

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sat, 08 Oct 2005 01:47:00 +0200

Von einem der auszog, seine PHP-Scripts nicht mehr als www-data laufen zu sehen.

Auf der Suche nach einer Lösung für ein Standardproblem

Während meiner ISP-Zeit habe ich es nur in zwei Bereichen geschafft, den Rat eines Kollegen (“Du kannst Dich nicht mit allem auskennen”) zu beherzigen: Webserver und RADIUS. Der bewusste Verzicht auf RADIUS-Kenntnisse wäre heute im ISP-Bereich ein Hindernis, und Webserver-Knowhow versuche ich derzeit durch kleinere private Projektchen aufzubauen.

Eins dieser Projektchen war der Bau eines Webservers, bei dem PHP-Scripts nicht mit den Rechten des Webservers laufen, sondern mit den Rechten des Benutzers. Auf Servern, bei denen die Betreiber der virtuellen Server sich nicht gegenseitig vertrauen, ist das eine Grundanforderung, die gar nicht sooo leicht zu befriedigen ist. Apache bringt zwar schon seit geraumer Zeit suexec mit, das eigentlich genau diese Aufgabe erledigen soll. Allerdings arbeiten die großen Hoster teilweise aus historischen Gründen mit grotesk gepatschtem suexec, so dass man die Berichte, die man aus diesen Ecken bekommt, für ein privates Feldwaldundwiesenprojekt nicht umsetzbar sind. Die im Web ergooglebaren Dokumentationen sind allesamt durchwachsen, und nicht selten so voller Widersprüche, dass man am besten mit dem Lesen aufhört, ehe man völlig verwirrt ist.

Kurze Recherche zeigt, dass suexec sowieso ein Auslaufmodell ist. Irgendwann wird apache2 mit dem perchild threaded model so weit sein, dass für jeden virtuellen Host ein eigener Apache-Prozess mit den entsprechenden Rechten läuft, was alle heuten Probleme lösen dürfte. Aber, “This MPM is not currently expected to work correctly, if at all.” Also lieber erstmal die Finger weg. Den Spezialfall PHP bekommt man heute mit suphp erschlagen, aber das ist ein Projekt für die nächsten Tage. Mein aktuelles Vorhaben war, die Geschichte von der Pike auf zu lernen, und das heißt definitiv klassisches suexec.

suexec ist ein Wrapper für CGI-Scripts, der vom Apache aufgerufen dank suid root erstmal seine Privilegien eskaliert, nach Prüfung einer ganzen Latte von Preconditions seine Rechte auf die des “target users” reduziert und schließlich endlich das CGI-Script aufruft. Nun, wenn ich hier von CGI spreche, meine ich auch CGI. Da perl und php normalerweise als Apache-Modul gerufen werden, kann man da nicht mit suexec eingreifen. Also muss man die Scripts als CGI aufrufen, was zu einem Performanceverlust führt. Das machen die großen Hoster auch nicht anders, also ist dieser Weg so verkehrt nicht.

Also: mod_php raus, php4-cgi installiert und die (einfache) Konfiguration für “PHP als CGI” durchgeführt.
Dabei fällt schon auf, dass die apache2-Packages von Debian ziemlich schlau gebaut sind: Jede Apache-Erweiterung bringt in ihrer Package entsprechende Konfigschnipsel mit, die der Administrator mit den Scripts a2{en|dis}{mod|site} ein- und ausschalten kann. Gute Arbeit, das fühlt sich viel besser an als die wilden Debconf-Orgien (“Pondering....... Doing Magic......”) der apache-1.3-Packages. Ist halt wieder eine typische Debian-Geschichte mit vielen kleinen Dateien, die apache aber dank seines flexiblen Konfig-Parsers automatisch zusammenstellen kann; update-apache2.conf gibt es - glücklicherweise - nicht. Kris wird dieses Setup sicher nicht gefallen, ich mag es. Schön finde ich auch, dass suexec, das sehr stark zur compilezeit konfiguriert wird, in der Debian-Package sinnvoll parametriert daherkommt.

Die CGIs im Userdir ~/public_html laufen auf Anhieb unter meinem User. Allerdings ist’s etwas komplexer, das auch ausserhalb des Userdirs hinzubekommen. Ursache dafür ist, dass ich mir selbst ein Bein gestellt hatte. Ich ging fälschlicherweise davon aus, dass auch ausserhalb des Userdirs suexec seine Rechte auf die des Users fallen lässt, dem die Datei gehört, in dem das CGI-Script steht; sozusagen ein auf den Webserver übertragenes suid-bit. Das stimmt aber nicht: Für suexec ausserhalb des Userdirs muss man innerhalb der Definition des virtual hosts explizit mit der Direktive SuexecUserGroup einen Target-User und eine Target-Group angeben, sonst fällt suexec transparent und kommentarlos auf den Fallbackuser zurück, der www-data heißt und man somit der Meinung ist, dass das suexec gar nicht aufgerufen würde. Nachdem dies endlich verstanden war, war der Weg zum ersten als mh laufenden CGI aus /var/www nicht mehr weit.

PHP als CGI unter suexec ist ein bisschen schwieriger. Bei einem über eine Action aufgerufenen php zählt nicht der Ablageort des PHP-Scripts, sondern der Ablageort des PHP-Binaries - und das liegt natürlich bei Debian weder innerhalb des Webspaces, noch gehört es dem richtigen User. Also wird man für jeden User, der PHP verwenden wird, ein eigenes PHP-Binary innerhalb des Webspaces brauchen, das obendrein auch noch dem richtigen User gehören muss. Ausserdem braucht’s wohl noch eine passende Action-Direktive für jeden Virtuellen Host; das hab ich allerdings noch nicht ausprobiert, weil ich immer nur mit einem virtuellen Host gearbeitet habe. Kaum macht man’s richtig, funktioniert’s auch schon, und mein passthru(“id”) sagte ordentlich id=1001(mh). Erfolgserlebnis.

Was lernen wir daraus: Auch wenn man erwartet, zu wissen was in der Doku steht, kostet Querlesen gerne mal einen Tag Zeit, weil man die wichtigen Informationen mehrfach überliest. de.comm.software.webserver ist für Fragen dieser Gewichtsklasse überfordert, ausser Bastian Blank hat sich niemand zur Antwort auf meine Fragen motivieren können.

Dasselbe gilt für #apache in Freenode, dessen Niveau bedauernswert niedrig ist und wo die Leute größtenteils nicht einmal wussten, was suexec ist. Das beste Debugging-Tool ist nach wie vor strace, weil man damit dem Prozess so weit auf die Finger gucken kann, dass man irgendwann mal zu dem Schluß kommt “das ist aber nicht so wie ichs aus der Doku erinnere, lasst mal lieber genau nachlesen”.

Nächste Projekte: suphp, und dann endlich die erste eigene s9y-Testinstallation.

Bugtraq b0rken. For me.

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Mon, 03 Oct 2005 14:14:38 +0200

Seit Oktober 2004 habe ich über die Bugtraq-Mailingliste genau eine (in Ziffern: 1) Mail bekommen, und das war im Juli 2005. Trotzdem sagt der Mailinglisten-Robot, ich sei subscribed.

Begeisterung aller Orten.