Zugschlusbeobachtungen

Gestern hat Heise geschrieben, was die Communications Electronics Security Group (CESG), eine Abteilung des britischen Nachrichtendiensts GCHQ, empfiehlt, und was ich schon seit gefühlt 1847 predige: Der Zwang zur regelmäßigen Änderung von Passworten erweist der IT-Sicherheit nicht selten einen Bärendienst.

Nutzer, die einerseits zu immer komplexeren Passworten gezwungen werden, und diese andererseits dreimal in der Woche ändern müssen, neigen - für viele IT-Abteilungen völlig überrschend - dazu, diese Passworte aufzuschreiben, sie überall zu verwenden und sie bei erzwungenen Änderungen nur minimal zu ändern. So findet sich in meinen AD-Passwörtern diesen Monat die Zeichenkette 416, man darf raten woher sie kommt.

Ich bin ja ein großer Fan von Systemen, die den Benutzer für ein komplexes Passwort loben ("Dieses Passwort bekommt auf einer Skala von 1 bis 10 eine 8, wobei die Ähnlichkeit zum alten Passwort zur Abwertung geführt hat") und ihn vielleicht sogar dafür belohnen ("Dieses Passwort ist so herrlich komplex und unterscheidet sich so signifikant von Deinem alten Passwort, dass Du es jetzt 18 Monate behalten darfst"). Ich frage mich, warum sowas heutzutage so selten implementiert wird. Ich hab sowas zwar schonmal gesehen, aber das ist fünfzehn Jahre her, und seitdem nie wieder. Dabei ist diese Idee so nahe liegend.

Ach ja, das Blog gibt es noch. Ich plane seit Monaten, es auf einen neuen Server zu migrieren und dann auch wieder mit Inhalten zu bestücken. Nachdem wir jetzt auch schon bald zwei Jahre in unserem Haus leben, könnte ich langsam mal anfangen, die Baustellen-Highlights zu verbloggen.

This document contains my GPG key signing notes. It is not meant to be accessible from the RSS feed or any overview page of my blog. If it shows up anywhere, please notify me. It is accessible here.

Continue reading "My GPG key signing notes"

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.

Continue reading "Spezifikation von Firewallregeln - do's and dont's"

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 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.

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?

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.

Continue reading "Berufsverbot"

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.

Continue reading "Sind Firewalls noch zeitgemäß?"

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.

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.

Continue reading "Port Knocking für ssh"

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

Continue reading "X509 Certification Authority"

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.

Continue reading "virtually exploitable"

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.

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.

Continue reading "suexec, die nächste"

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

Continue reading "suexec my php, baby^wapache2"