RackBlogger

Es war nun einige Wochen lang recht still hier im Blog, ich habe mir vorgenommen das wieder zu ändern.

Los geht’s aus aktuellem Anlass mit Klartext-Passwörtern. Das Controlpanel “Plesk” steht derzeit wieder im Kreuzfeuer, da laut dem Sicherheitsexperten Brian Krebs ein sogenannter “0day exploit” die Runde macht und gleichzeitig die Sicherheitslücke vom Februar 2012 für bittere Nachwirkungen sorgt. Damals konnte durch eine SQL-Injection in der Remote-API von Plesk völlig anonym auf betroffene Systeme zugegriffen werden, wobei im großen Stile die Benutzerpasswörter ausgelesen wurden. Diese speichert Plesk in der Tabelle psa.accounts unverschlüsselt und nicht gehashed.

Parallels hat natürlich reagiert und neben dem Bugfix auch ein Tool zur Massen-Änderung von Passwörtern bereitgestellt. Blöd ist nur, dass die kompromittierten Passwörter nicht auf eine Blacklist gesetzt wurden - so haben viele Endkunden die neuen (kryptischen) Passwörter einfach wieder zurück geändert. Wie will man sonst auch seine Kunden dazu “zwingen”, wirklich ein neues Passwort zu verwenden?

Nun, die Tatsache, dass in einer Remote-API eine SQL-Injection möglich war, ist eigentlich schon schockierend genug - es gibt viele Methoden um so etwas zu vermeiden (von der statischen Code-Analyse bis zur Verwendung von Prepared Statements). Aber das Passwörter jeglicher Art im Klartext gespeichert werden ist kein Programmierfehler, sondern meiner Meinung nach grobe Fahrlässigkeit. Auf Unix/Linux-System werden seit zig Jahren alle Account-Passwörter gehashed (anfangs nur mit crypt(), inzwischen schon mit komplexen SHA256-Hashes). MySQL ist nun auch nicht gerade für maximale Zugriffssicherheit bekannt (zumindest möchte ich mal behaupten, dass es für einen normalen Systembenutzer einfacher ist, in MySQL einzusteigen als /etc/shadow auszulesen).

Es gibt durchaus das Problem, dass einem Controlpanel ein reiner Hash des Benutzerpassworts nicht reicht - das ist beispielsweise bei E-Mail-Passwörtern häufig der Fall. Wir lösen das so, indem E-Mail-Clients sich nur über das CRAM-MD5-Verfahren am Mailserver anmelden dürfen (PLAIN macht keinen Sinn, da Passwörter völlig unverschlüsselt über den Äther gesendet würden). Auf dem Mailserver kann statt dem Klartext-Passwort nun das “vorgehashte” Passwort abgelegt werden - eine Speicherung im Klartext ist überflüssig (bei Dovecot ist es das Passwort-Schema CRAM-MD5).
Warum Plesk aber selbst das Admin-Passwort mit einem einfachen Shell-Befehl ausgeben kann, entzieht sich meiner Vorstellungskraft. Und wie mit diesem Panel betriebene Webserver eine PCI-Zertifizierung erhalten, obwohl wissentlich kritische Passwörter unverschlüsselt bleiben, ist ebenfalls fragwürdig.

Programmierfehler kann jeder machen - keine Frage. Ich kann auch nicht dafür garantieren, dass es bei LiveConfig keine Sicherheitslücken gibt (das wird vermutlich niemand können). Wir können aber unser Bestes tun, um so etwas zu vermeiden und im “worst case” den potenziellen Schaden zu minimieren: Passwörter werden grundsätzlich nur als gesalzene Hashes gespeichert, kritische Daten (etwa Private Keys für SSL-Zertifikate) werden stark verschlüsselt, SQL-Injections durch Prepared Statements unmöglich gemacht, und so weiter. Ein System ist eben nur so sicher wie seine schwächste Stelle.

Und zum Thema “automatische Passwörter” folgt in Kürze der nächste Beitrag.

Ach ja, bis heute werden in Plesk 10 (v10.4.4#36) die Passwörter nicht verschlüsselt!

Nach einem Update auf einer CentOS 6.2 Instanz unter VirtualBox bootete diese komischerweise immer direkt in eine Kernel Panic.

Das Problem ließ sich lösen, indem man in den Systemeinstellungen der VM den Chipsatz von “PIIX3″ auf “ICH9″ ändert.

(nur falls noch jemand dieses Problem hat - erspart viel Debugging…)

Ja, da ist es nun: das Ergebnis monatelanger Arbeit wird in zwei Wochen (am 01.03.2011) auf der CeBIT präsentiert - unsere Serververwaltungssoftware LiveConfig.

Vor über sechs Jahren habe ich mich im Rahmen meiner Studienarbeit quasi “akademisch” mit dem Thema Serververwaltung beschäftigt. Eine umfangreiche Analyse der verfügbaren Produkte brachte einige gemeinsame Schwachpunkte zu Tage, die bis dato offenbar noch niemand angegangen ist. Außerdem hatte ich so die Gelegenheit, mal völlig frei die “Wunsch-Software” zur Serververwaltung zu skizzieren. Erst 2008 habe ich den Entschluss gefasst, die Ideen von damals in einem kommerziellem Produkt umzusetzen. Spätestens die Teilnahme am Businessplan-Wettbewerb Nordbayern brachte so viel positives Feedback, dass wir Mitte 2009 mit der Entwicklung “from scratch” begonnen haben - weitere Vollzeit-Entwickler wurden eingestellt, Fördermittel beantragt, Kontakte geknüpft - und nun isses soweit.

Wir sind tatsächlich mit einem eigenen Stand (Reihe 9, Stand B20) auf der CeBIT 2011 in Hannover vertreten (was ich mir vor 15 Jahren als Schüler nie hätte träumen lassen ). Dort werden wir LiveConfig in aller Ausführlichkeit präsentieren und den ersten 1000 Interessenten auch eine kostenlose Business-Lizenz anbieten.

Was ist nun das Besondere an LiveConfig? Das auffälligste Merkmal dürfte sein, dass LiveConfig in C/C++ programmiert ist. Alles was für die SSL-geschützte Weboberfläche notwendig ist, ist fest integriert. Administratoren können so also beliebige Versionen von Perl oder PHP auf dem Server installieren, ohne das Control-Panel zu zerschießen. Von manchen anderen Lösungen werden auch regelmäßige Probleme mit PHP-Extensions (insbesondere IonCube Loader) berichtet - das kann es mit LiveConfig nicht geben.

Dabei ist der Code nicht komplett “geschlossen”: die kniffligen Aufgaben, also die tatsächliche Erzeugung der Konfigurationsdateien, werden mit Lua-Scripts erledigt. Lua ist eine sehr einfach erlernbare Sprache und die Scripte liegen im Quelltext vor - können also ohne Probleme an eigene, eventuell exotische Anforderungen angepasst werden.

Der zweite große Unterschied zu vielen anderen Lösungen ist, dass sich LiveConfig minimal-invasiv verhält. Konkret bedeutet das, dass LiveConfig die jeweils eingesetzte Linux-Distribution automatisch erkennt und die von dieser bereitgestellten Softwarepakete konfiguriert. Wer mit LiveConfig etwa einen Webserver verwaltet, bekommt also nicht von uns irgendwelche “eigenen” Apache- und PHP-Pakete aufgedrückt, bei denen er dann bei Updates erstmal warten muss. Im Gegenteil - wir passen uns sogar der Konfigurationsstruktur der jeweiligen Distribution an. Das heißt bei Debian beispielsweise, dass wir unsere vHosts auch in /etc/apache2/sites-available/ anlegen und mit “a2ensite” aktivieren. Das geht so weit, dass man LiveConfig rückstandslos wieder vom Server deinstallieren könnte und alle Dienste im zuletzt konfigurierten Zustand weiter laufen würden.

Meiner Meinung nach hat es normalerweise seinen Grund, warum sich jemand für oder gegen eine bestimmte Distribution entscheidet - seien es persönliche Kenntnisse, Fortbildungen oder unternehmensinterne Richtlinien. Und LiveConfig orientiert sich eben möglichst an den Bedürfnissen des Administrators.

Das Ganze hat natürlich seinen Preis - wir brauchen hier im Team verschiedene Spezialisten für die einzelnen Distributionen, aber das bekommt man gut in den Griff. Nicht zuletzt haben wir eine echt coole Testplattform auf Xen-Basis aufgebaut, in der jede Nacht für alle von uns ausdrücklich unterstützten Distributionen die Software komplett compiliert, installiert, getestet und wieder deinstalliert wird. Sollte mal ein Bug auftauchen (nobody’s perfect), dann können wir über die Testplattform sicherstellen, dass dieser dauerhaft beseitigt ist.

So - genug getextet. Wer Interesse hat, den lade ich herzlich auf die Website http://www.liveconfig.com ein. Die Download-, Demo- und Shop-Seite schalten wir erst zur CeBIT frei - bis dahin wird noch etwas poliert und die letzten Feedbacks unserer heimlichen Betatester berücksichtigt. Diskussionen zu LiveConfig sowie jegliche Fragen dazu sollten am besten direkt im LiveConfig-Forum erfolgen (daher schließe ich auch die Kommentare zu diesem Blog-Beitrag).

Als Webhoster hat man es (leider) immer wieder mal mit betrügerischen Bestellungen zu tun. Da wir bei Neukunden die Zugangsdaten prinzipiell nur per Post versenden, hält sich der Schaden aber in Grenzen. Sollte es ein Kunde wirklich mal eilig haben, finden wir auch eine Lösung.

Gestern kam aber eine Bestellung herein, die zeigt, wie schamlos manche Betrüger sind. Auftraggeber war eine ziemlich große, wohltätige Institution, die mit einer ihrer Domains angeblich zu uns umziehen wolle. Nun haben wir aber so eine Art “Frühwarnsystem”, das anhand einiger Faktoren (die ich hier natürlich nicht aufzählen werde) die Bestellung als “verdächtig” markiert hat. Also war ich einfach mal so frei, bei der angegeben Rufnummer (die tatsächlich der Organisation gehört) anzurufen um mich mit dem angeblichen Besteller verbinden zu lassen. Natürlich war die genannte Person dort nicht bekannt…

Wahrscheinlich wird nun Strafanzeige gestellt - wenn auch mit leider recht geringen Erfolgsaussichten.

Immer wieder ist ja mal vom “Internet-Führerschein” die Rede.

Soeben habe ich beschlossen, dafür zu sein. Denn einen Führerschein kann man jemandem auch wieder wegnehmen.

Wenn man auf der Autobahn in die falsche Fahrbahnrichtung fährt, ist der Führerschein weg. Ohne Diskussion. Und soeben hätte einer unserer Kunden seinen Internet-Führerschein verloren. Ohne Diskussion.

Der Anstand verbietet es, an dieser Stelle über eigene Kunden zu lästern - aber manchmal wird die eigene Geduld schon arg strapaziert.
Andererseits wäre das Leben ohne manche “besondere” Kunden ja auch langweilig - die sind praktisch das Salz in der Suppe. Andauernd nur kompetente Admins und Agenturen - wer will das schon?

Ein neuer Marktbegleiter (wenn man den überhaupt als solchen bezeichnen darf) hat besonders kompakt formulierte AGB. Die Rechtschreibung wurde unverändert übernommen:

1. Kein Illegaler Content ! Wenn rechtliche Schritte unternoomen werden Sie zur rechenschafft gezogen!

2.Keine Kündigungsfrist!

3.Downloads und Pronogrhische Inhalte  sind verboten ansonsten wird Ihr Account gesperrt!

Mal unabhängig davon: viele AGB sind tatsächlich unnötig aufgeblasen, weil dort nochmal viele Sachen aufgeführt werden die ohnehin im BGB geregelt sind, oder teilweise sogar gegen das AGBG verstoßen (vor allem viele salvatorischen Klauseln). Je kürzer, desto besser. Als derzeit abschreckendstes Negativ-Beispiel fällt mir da spontan Apple ein.

Ich liebe diese Anrufe…

Ich erreiche gerade bei [DSL-Provider] nur die Warteschleife und wollte daher Sie einfach mal fragen… ich komme nicht an meine E-Mails. Mein Internet geht auch nicht. Können Sie mir da helfen?

Ist natürlich schön wenn die Kunden uns so gut erreichen können - helfen können wir leider trotzdem nicht.

Seit heute bin ich wieder halbwegs “normal” im Büro, und schon holt mich der tagtägliche Wahnsinn eines Webhosters ein.

Da haben wir einen größeren Kunden (AG), bei dem die letzte Lastschrift geplatzt ist und heute die nächste Mahnstufe dran wäre. Was sehe ich auf deren Website? Den Flyer einer Abschieds-Veranstaltung, und keine fünf Tage später erfolgte die Insolvenzmeldung.
Unsere Forderungen sind schon an den Insolvenzverwalter herausgegangen (ja, seit heute haben wir eine Funktion in unserem Abrechnungssystem, welche aus der OPOS-Liste automatisch eine Forderungsanmeldung generiert *seufz*). Ob auch eine Anzeige wegen Vorsatz angebracht ist, wird noch überprüft.

Dann haben wir da den Kunden, für den wir letzte Woche bereits zum dritten Mal (!) Malware von seiner Typo3-Website entfernt und ihn zum Updaten der Installation aufgefordert haben. Diesmal fiel der Kunde durch eine Flut von SpamCop-Meldungen auf, die bei uns eintrafen. Auf seinem Webspace fand sich die dazugehörige Phishing-Site sowie ein Potpourri aus PHP-Shells, Malware, und vielem mehr. *seufz*

Und dann haben wir noch den Kunden, der für ein neues Projekt einen CatchAll-Mailaccount benötigte. Der Blick auf seine neue Website zeigt dann auch schon den Grund: für das Angebot kostenloser Wegwerf-Mailadressen.
Keine gute Idee, da man in Deutschland somit als Kommunikationsanbieter gilt und sich dann auch um BNetzA, TKÜV usw. kümmern darf. Nicht zuletzt tun mir unsere Mailserver jetzt schon leid.

Ich freue mich schon, wenn ich heute wieder heim darf.