Exim security update (CVE-2010-4345)

Aufgrund eines kritischen Fehlers (Buffer Overflow) im Mail Transfer Agent (MTA) Exim ist es möglich beliebigen Schadcode auf einem nicht gepatchten Server auszuführen. Die Patches zur Behebung der Sicherheitslücke wurden soeben auf sämtlichen Kunden-Servern installiert um unsere Infrastruktur gegen eventuelle Angriffe zu schützen.

Kunden die unsere Cloud-Server Angebote nutzen müssen sich um nichts weiter kümmern, die Sicherheitspatches wurden im Rahmen der Managed-Services bereits eingespielt.

Weiterführende Links:
http://www.exim.org/lurker/message/20101207.215955.bb32d4f2.en.html
http://bugs.exim.org/show_bug.cgi?id=1044
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4345


Apache 2.2.11 und PHP 5.2.8 auf allen Systemen verfügbar

Nachdem am Montag morgen die Server mit der aktuellen Version des Apache und PHP wurden, gab cPanel gestern Abend die Version 2.2.11 des Apachen frei. Da das Update eine Sicherheitslücke schließt wurde heute morgen das Update des Apachen erneut durchgeführt. – Da es sich um einen kleineren Eingriff handelte verlief alles problemlos und ohne Unterbrechung.

Spätestens heute Mittag hätte das Update für den erneuten PCI Compliance Scan eingespielt werden müssen.


Apache 2.2.10 und PHP 5.2.8 auf allen Systemen verfügbar

Im geplanten Wartungsfenster von 04:30h – 06:30h heute früh konnten alle System- und cPanel-Updates eingespielt werden. Bis auf einen kurzen Ausfall von ca. 5 Minuten verlief das Update problemlos. – Durch den erhöhten Ressourcenbedarf des Updateprozesses kam es zu leichten Verzögerungen bei der Seitenauslieferung.

Gleichzeitig wurden die Webserver- und Datenbankkonfigurationen weiter optimiert und an die wechselnden Anforderungen angepasst.


cPanel: Nameserver TTL sämtlicher Domains ändern

cPanel ist nach wie vor unser absoluter Favorit, wenn es um web-basierte Konfigurationstools für Webserver geht. Neben der Fülle an Funktionen und Möglichkeiten macht sich ein Nachteil schnell bemerkbar, wenn man versucht viele DNS-Einträge auf einmal zu aktualisieren. Diese Funktion sucht man im cPanel Menü leider vergeblich.

Durch einen kleinen Trick lässt sich das Ganze allerdings sehr schnell über den SSH-Zugang erledigen.

Backup erstellen

mkdir /var/named/backup
cp /var/named/*.db /var/named/backup/

TTL ändern

Um die TTL-Zeiten von 86400 auf 300 zu ändern wird folgender Befehl ausgeführt:

/usr/bin/replace '86400' '300' -- /var/named/*.db

Das Ganze wiederholen wir gleich für den viel zu großen Wert von 3600000:

/usr/bin/replace '3600000' '1209600' -- /var/named/*.db

Nameserver ändern

Auch die Nameserver lassen sich so bearbeiten:

/usr/bin/replace 'ns.oldname.de' 'ns.newdnsname.de' -- /var/named/*.db

Serial aktualisieren

Damit die Änderungen beim folgenden Neustart auch erkannt und an die anderen Nameserver weitergegeben werden, muss die Serial noch aktualisiert werden:

sed -i 's/200[0-9]{7}/2008110307/g' *.db*

Dieser Befehl bewirkt, dass alle Serials auf das heutige Datum 03.11.2008 aktualisiert werden. Die 07 am Ende des Datums steht für die Anzahl der heutigen Änderungen und wird mit jeder weiteren Änderung um 1 erhöht.

Nameserver neustarten

Damit die Änderungen verarbeitet und weitergegeben werden, muss der Nameserver kurz neugestartet werden. – Ein kurzer Klick auf den entsprechenden Menüpunkt genügt.

Wer möchte kann während des Neustarts die Datei /var/log/messages mit tail beobachten. Wenn alles korrekt verarbeitet wurde, sollten jetzt sehr viele Zonentransfers stattfinden.


cPanel: mod_deflate (gzip) einrichten und Traffic sparen

Mit dem Apache Modul mod_deflate ist es möglich reine Textdateien wie z.B. HTML, CSS, JS und XML komprimiert an den Browser zu versenden. Meistens lassen sich diese Dateien durch Kompression auf 20% – 30% ihrer Ausgangsgröße verkleinern was zu einer enormen Trafficeinsparung führen kann. Ein netter Nebeneffekt ist die verkürzte Ladezeit, welche sich gerade bei Usern mit schmalbandigen Internetverbindungen bemerkbar macht. – Die durch das Modul verursachte etwas höhere Serverlast sollte auf den heutigen Servern kaum ins Gewicht fallen.

Ein großer Vorteil von mod_deflate gegenüber mod_gzip besteht darin, dass kein User durch die Kompression „ausgeschlossen“ wird. Zu Beginn jeder Übertragung teilt der Browser dem Server mit, ob dieser komprimierte Inhalte verarbeiten kann. Ist der Browser nicht dazu in der Lage wird dies von mod_deflate erkannt und sendet die Inhalte unkomprimiert an den Browser.

Die Einrichtung von mod_deflate gestaltet sich dank EasyApache recht einfach. Zuerst muss ein neuer Apache konfiguriert und kompiliert werden. Um mod_deflate zu verwenden genügt es, dass entsprechende Modul zu aktivieren und den Apache zu kompilieren. – Dieser Vorgang dauert, je nach Leistung des Servers, einige Zeit und sollte aufgrund kurzer Aussetzer des Betriebes in einem nächtlichen Wartungsfenster durchgeführt werden.

Sobald der Apache kompiliert und gestartet wurde muss das Modul noch konfiguiert werden. Dies lässt sich am einfachsten über den folgenden Menüpunkt im WHM erledigen:

Service Configuration => Apache Setup => Include Editor => Pre VirtualHost Include => All Versions

In diese Textbox wird nun die folgende Konfiguration kopiert:

<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/css
</IfModule>

Die neue Konfiguration wird über den Button „Update“ gespeichert und der Apache neugestartet.

Anschließend kann mit dem GZIP-Tester die Konfiguration und der Kompressionsgrad geprüft werden.


Systemupdates erfolgreich beendet

Im geplanten Wartungsfenster von 02:30h – 03:30h heute früh konnten alle System-, cPanel- und Spamfilter Updates eingespielt werden. Obwohl mit einer kurzen Unterbrechng von 5 – 10 Minuten gerechnet wurde, blieben alle Systeme erreichbar. – Durch den erhöhten Ressourcenbedarf des Updateprozesses kam es zu leichten Verzögerungen bei der Seitenauslieferung.

Gleichzeitig wurden die Webserver- und Datenbankkonfigurationen weiter optimiert und an die wechselnden Anforderungen angepasst. – Im Test wurden die Magentoshops nach der Optimierung 0.2 bis 0.3 Sekunden schneller geladen, andere Systeme zeigten keine Veränderung.