Mal sehen wie lange es dauert, bis dort der erste Spam einschlägt…

Denn, wie sieht das ganze nun aus?

Wir hätten da Google, deren ISPs, Telefónica und die Kunden von Telefónica. Wer zahlt nun was an wen?

Google zahlt seinen Traffic bei seinen ISPs, welche teilweise Peerings mit der Telefónica haben. Peerings sind Vereinbarungen zwischen Providern der Art “Lässt du meinen Traffic durch, lass ich deinen Traffic durch! (gratis)”. Die Kunden von Telefónica zahlen ihre Gebühren für beispielsweise einen DSL-Anschluss. Was Telefónica nun stört ist, dass sie von dem Geld, welches die ISPs, bei denen Google Kunde ist, kassieren, nichts ab bekommen. Wir sehen: Der Traffic ist bereits bezahlt! Nämlich durch Google und den Kunden. Google kauft nichts von der Telefónica und sollte damit auch nichts an selbige zu entrichten haben. Nur ärgert sich die Telefónica, dass sie nur einmal kassiert (bei den eigenen Endkunden) und nicht auch noch von Google Geld für den Traffic bekommt.

Vielleicht löst Google dieses Problem ja einfach selbst, indem es den Zugang zu seinen Diensten aus dem Netz der Telefónica sperrt. Das Telefónica Problem lösen dann die Kunden der Telefónica ganz schnell von alleine…

Um unseren Hostingkunden diese Dinge nicht immer wieder vom neuen erklären zu müssen, haben wir folgenden Artikel über die richtige Umsetzung von E-Mail Formularen verfasst.

1. Empfängeradresse
2. Absenderadressen und Namen
3. Betreffzeilen
4. Kodierung
5. HTML
6. Return-Path

1. Empfängeradresse

Die Empfängeradresse ist niemals durch den Benutzer festzulegen, da ein Formular so 100%ig zum Versand von Spam missbraucht wird. Die Empfängeradresse ist also fest im Programmcode zu codieren. Versteckte HTML-Formularfelder oder $_GET-Parameter sind ebenfalls nicht geeignet, da sie sehr leicht durch einen Angreifer manipuliert werden können.

2. Absenderadresse und Name

Jede Absenderadresse, die ein Benutzer eingeben darf, ist auf Gültigkeit zu überprüfen. Es reicht ausdrücklich nicht aus, dass die Adresse ein @-Zeichen enthält. Eine Überprüfung mittels regulärem Ausdruck ist Pflicht!

Eine Prüfung kann in PHP beispielsweise wie folgt aussehen:

preg_match(“/^[a-z0-9!#$%&'*+\/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+\/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+(?:[a-z]{2,4}|museum|travel)$/i”, $adresse)

Im Falle, dass die Adresse gültig ist, gibt preg_match true, im Fehlerfall false zurück.

Was auf gar keinen Fall in der Absenderadresse erlaubt sein darf, ist das Einfügen von Zeilenumbrüchen. Die Verwendung von <input>-Tags reicht hier nicht aus, da ein Angreifer trotzdem Zeilenumbrüche einschleusen kann. Dadurch ist es einem Angreifer möglich, einer E-Mail beliebige Headerzeilen, beispeilsweise eine To: <empfänger> Zeile, hinzuzufügen. Hierdurch kann ein E-Mailformular zum massenhaften Versandt von Spam missbraucht werden.

3. Betreffzeilen

Betreffzeilen dürfen ausschließlich 7-Bit ASCII-Code enthalten. Also kein ä ö ü ß oder ähnliches!
Sonderzeichen müssen generell umkodiert werden.

In PHP ist dies beispielsweise mit der Funktion mb_convert_encoding möglich.

$betreff = mb_convert_encoding($betreff, “ASCII”, “UTF-8″);

Auch in der Betreffzeile darf auf gar keinen Fall ein Zeilenumbruch akzeptiert werden!
Hier gilt das selbe wie bei der Absenderadresse!

4. Kodierung

Die Kodierung einer E-Mail ist stets im Header anzugeben!
Fehlende Header führen immer wieder zu nicht ordnungsgemäß darstellbaren E-Mails.
Der Entwickler merkt dies meist nicht. Er erstellt seine E-Mails beispielsweise in UTF-8, und liest diese auch mit seinem UTF-8 Client. Die Darstellung ist dann natürlich korrekt. Öffnet nun aber jemand mit einem ISO-8859-1 Client diese E-Mails, sieht er statt Umlauten nur schwarze Kästchen oder Fragezeichen. Professionell wirkt dies definitiv nicht! Zuletzt erlebten  wir so eine Sache mit dem Carsharing der Deutschen Bahn. Hier fehlte die Kodierungsangabe, und in allen E-Mails wurden die Umlaute bei uns nicht korrekt dargestellt!

Die Kodierung gehört also in den Header der E-Mail eingebaut. Beispielsweise so:

Content-Type: text/plain; charset=utf-8

Selbstverständlich ist auf die Verwendung des richtigen Zeichensatzes zu achten!

Zum Schluss möchten wir noch anmerken, dass fehldende Kodierungsangaben von Spamfiltern gerne bestraft werden, da normale Mailclients stets die Kodierung in den Mailheader einbauen!

5. HTML

HTML in E-Mails ist eine tolle Sache, würde Sie nur richtig verwendet werden. Der HTML-Code gehört nicht einfach in den Mailbody. Es gibt da draußen nicht gerade wenige Leute, die keine HTML Mails öffnen. Enthält die E-Mail jedoch anstelle des Textes einfach nur HTML-Code, sieht der Benutzer einfach nur HTML-Code und wird der E-Mail keine besondere Beachtung schenken.
HTML E-Mails sind stets als Multipart-Messages zu versenden! Wir Empfehlen folgenden Artikel: http://www.webcheatsheet.com/php/send_email_text_html_attachment.php

6. Return-Path

Die Angabe eines Return-Path im Mailheader ist beim Versand von E-Mails über einen Webserver unerlässlich. Kann eine E-Mail beispielsweise nicht zugestellt werden, erzeugt der Mailserver eine Bounce-Nachricht an den Absender. Dies ist im Normalfall der Webserver, was zur Folge hat, dass diese Nachricht nicht zugestellt werden kann. Ist im Header eine Return-Adresse angeben, werden die Bounce-Mails an diese Adresse versandt. Eine Headerzeile für einen Return-Path sieht wie folgt aus:

Return-Path: <benutzer@domain.tld>

So bemerkt der Webmaster auch, wenn eine E-Mail nicht zugestellt werden konnte.

Wozu das ganze? Tripwire kann doch auch im Gast laufen und die Integrität aller Dateien prüfen?

Stimmt, aber dann ist es von einem Angreifer innerhalb der virtuelle Maschine leicht manipulierbar!
Da unsere Tripwire Binarys und Configs nicht in der virtuelle Maschine liegen, sind sie für einen Angreifer nicht greifbar. Er weiß nicht mal, dass eine Tripwire Installation existiert (es sei denn, er liest diesen Blogpost)!

Wie funktioniert das ganze?
Ein Script fertigt von dem Gastsystem per LVM einen Snapshot an, welcher dann mit kpartx als einzelne Partitionen gemountet wird. Auf dem gemounteten Read-Only Volume wird dann der Integritätscheck ausgeführt.

So (!) macht ein HIDS sinn.
Wir werden das Script weiter entwickeln und erproben und es später zum Download bereit stellen.

Folgende Zusatzinfos beim Eintrag der Windowsmaschine am Master schaffen Abhilfe:

memory.swap.label swap
memory.swap.draw STACK
memory.swap.info Swap memory used

Bis vor einiger Zeit, haben auch wir uns diese Frage gestellt und haben auch eine Antwort gefunden:
Linux lagert Standardmäßig alles aus, was eher selten gebraucht wird, vollkommen unabhängig davon, wie viel RAM noch frei ist. Der Sinn dahinter ist der, dass so direkt genug RAM frei ist, wenn er denn mal dringend benötigt wird. Diese beschleunigt zwar Desktopsysteme, sorgt insbesondere bei Datenbankservern aber für Frust.

Linux wäre nicht Linux, wenn man dieses Verhalten nicht steuern könnte.
Über die Systemvariabl vm.swappiness lässt sich das Swapverhalten der Speicherverwaltung regeln.
Standardinstallationen (RHEL, Debian, Ubuntu) haben für die Swappiness einen Wert von 60 vorgesehen, was für Desktopsysteme okay ist.

Kommen wir zur Bedeutung des Wertes.
Die Variable kann Werte zwischen 0 und 100 aufnehmen:

• Null bedeutet: Swappe niemals, wenn es sich vermeiden lässt
• Einhundert bedeutet: Swappe alles, was aktuell nicht benötigt wird

Für Server Empfiehlt sich also immer ein Wert von Null.
Mit der folgenden Anweisung können Sie der Variablen den Wert Null zuweisen:

echo 0 > /proc/sys/vm/swappiness

Achtung: Diese Lösung ist nicht persistent, sodass nach einem Reboot der Standardwert von 60 wieder gesetzt ist.
Um die Einstellung gleich beim booten setzen zu lassen, empfiehlt es sich, das ganze in der Datei /etc/sysctl.conf einzutragen:

vm.swappiness = 0

Vor diese Frage stand ich letzten Sonntag und habe einen Weg gefunden, unseren Extreme Networks Summit 200-24 zurück zu setzen!

Das ganze funktioniert wie folgt:

1. Verbindung aufbauen über Serielle Console (9600Baud, 8Bit, 1Stopbit, keine Flusskontrolle), beispielsweise mit minicom (Unix/Linux) oder Hyperterminal (Windows).
2. Vor dem Einschalten die Leertaste gedrückt halten
3. Switch mit der Stromversorgung verbinden

Voila: Sie sehen ein Bootmenü, von welchem aus sie die Standardeinstellungen wiederherstellen können!

Ein Test von meinem Arbeitsplatz aus, konnte den Fehler ersteinmal nicht bestätigen. Nachdem ich erst das DNS geprüft habe (zeigt die Domain auch auf den richtigen Server?), prüfte ich die Logdatei des Webservers. Tatsache: Seine Anfragen wurden blockiert, meine nicht.

Die Ursache war die, dass unser Regelwerk in der Datei 00_asl_rbl.conf, welche aus dem Regelwerk von gotroot.com stammt, eine Regel enthielt, welche die IP-Adresse des Clients in der DNSBL xbl.spamhaus.org nachschlägt und, falls die IP-Adresse gelistet ist, den Zugriff verweigert. Die Liste enthält eigentlich Rechner, welche durch Spam auf Webseiten durch Trojaner / Botnetze beispielsweise aufgefallen sind. Problematisch ist das ganze jedoch deswegen, weil IP-Adressen sich hierzulande normalerweise nach 24 Stunden ändern und dann ein unschuldiger Benutzer eine IP-Adresse bekommen kann, die auf der Blackliste steht. Diesem Benutzer ist der Besuch unserer Seiten dann nicht möglich.

Fazit: Der Einsatz einer  DNSBL in einer WebApplication Firewall kann also schnell dazu führen, dass unschuldige Besucher von der Webseite ausgesperrt werden.
Anders als Mailserver, haben Websurfer normalerweise nämlich keine festen IP-Adressen.

Obwohl wir auf vielen unserer Server natürlich Linux einsetzen, betreffen uns die meisten Exploits für Linux nicht direkt, da wir einen stark gehärteten Linuxkernel einsetzen. Wir setzen bei allen Systemen, wo Kunden direkten Zugriff auf das System (Shell / CGI) haben auf Grsecurity.

Grsecurity ließ uns bereits im Februar 2008 ruhiger schlafen, als es einen lokalen Rootexploit für Linux gab (Vmsplice Bug). Sämtliche auffindbaren Exploits funktionieren auf unseren Systemen nicht. Und so ist es auch nun wieder: Sämtliche Exploits, die wir für die aktuelle Lücke finden konnten, funktionieren auf unseren Systemen nicht.

Seit heute wollen wir die ganze Welt an unseren Paketen, die für KVM-Gastsysteme mit Debian Lenny konzipiert sind, teilhaben lassen, und stellen die Pakete für amd64 unter http://grsec.multicept.de zur Verfügung. Dass wir für Probleme, die durch unsere Pakete entstehen keinerlei Haftung übernehmen versteht sich von selbst.

Nähere Informationen, was im Kernel enthalten ist, was nicht, sowie signaturen werden in den nächsten Tagen folgen. Es lohnt sich also die Seite regelmäßig aufzurufen.