Zugschlusbeobachtungen

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.

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.

Auf einem Webserver möchte ich nicht, dass phpmyadmin, das Dokumentations-Wiki und das awstats von überall verfügbar sind. Andererseits möchte derjenige, der das CMS auf eben dieser Maschine betreut, genau diese Webapplikationen jederzeit und von überall benutzen können. Was tun?

Wer einen Server in einschlägig bekannten Netzwerksegmenten (sprich: Bei den großen Housing-Anbietern) betreibt und wenigstens von Zeit zu Zeit mal in dessen Logs guckt kennt es: Irgendwelche Rechner aus Fernost oder anderswo werfen dem ssh-Daemon wild zusammengewürfelte Kombinationen aus Username und Passwort zu und tun dies mit einer bemerkenswerten Persistenz. Und wenn man auf dem System “fremde” User hat, lebt man als Admin stets mit der Angst, dass einer der Versuche der Angreifer irgendwann mal Erfolg hat.

Gegen diesen Typ der Brute-Force-Angriffe sind einige Wässerchen gewachsen, und ich möchte eine kleine Auswahl davon in diesem Artikel vorstellen.

Florian hat im April 2007 eine Notiz über PKI-loses TLS unter Verwendung von selbstsignierten Zertifikaten veröffentlicht. Er ist ja immer für provokative Aussagen gut, und in der Notiz erklärt er seine Beweggründe gut und hat bei mir einen Denkprozess ausgelöst.

Ich werd das in den nächsten Monaten mal für den einen oder anderen Dienst, z.B. OpenVPN, ausprobieren und gucken, ob dieser Ansatz in der Praxis funktionieren könnte. Für die Anwendung im Webumfeld sehe ich ja eher schwarz, weil dank der verDAUung des Internets ein https-Server mit selbstsigniertem Zertifikat gemeinhin als unsicherer angesehen wird wie ein Server mit unverschlüsseltem http. Weil bei Ersterem der Browser weint, und bei Zweiterem nicht.

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.

Hallo Dirk, zu Deinem Artikel möchte ich noch hinzufügen, dass Serendipity 1.0.2 ein Security-Update ist, das XSS Vulnerabilities behebt.

Man möchte dieses Update also nicht verzögern, sondern unverzüglich installieren!

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.

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.

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.

Die Artikelreihe zum Thema “Trennung von Webanwendungen untereinander”, die mit fastcgi, suphp und zwei Artikeln über das klassische suexec begann, findet heute ihren vorläufigen Abschluss mit dem Setup, für das ich mich letztendlich entschieden habe.

Da auf dem von mir angepeilten Zielsystem nur eine Handvoll Präsenzen mit ähnlich wenigen verschiedenen Webanwendungen ins Hosting kommen wird, könnte ich mich für eine Lösung entscheiden, deren Skalierungsverhalten sie für “richtiges” Hosting uninteressant macht. Jede Webapplikation bekommt einen eigenen apache, der gleich unter einer nicht priviligierten uid gestartet wird und auf einem hohen Port von 127.0.0.1 Verbindungen annimmt. Das Mapping auf die “offizielle” IP und Port 80 übernimmt ein zentraler “normaler” apache als reverse proxy.

Dieser Artikel entstand ursprünglich im Jahr 2006. Fünf Jahre später hat auch Debian es geschafft, mehrere apache-Instanzen “ordentlich” zu unterstützen, und ganz ohne gepatchte Scripts. Diese überarbeitete Version dieses Artikels beschreibt die Vorgehensweise unter dem in 2011 aktuellen Debian squeeze.

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.

In Fortsetzung der Artikelreihe zur Entfernung von PHP-Scripts aus dem Accountkontext des Webservers ist heute FastCGI an der Reihe.

Kurzzusammenfassung aus der Theorie: Es ist vermutlich performanter als suexec und suphp, bringt aber weder Erleichterung in der Handhabung noch in der Sicherheit.

In diesem Artikel bekommt auch das debianhowto.de apache2-php-fcgi-HOWTO sein Fett weg.

Schon bei den Vorarbeiten zu diesem und diesem Artikel hat man mir sehr nahegelegt, suphp anzugucken. Das habe ich heute getan.

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.