RackBlogger

Pornos für Server-Admins!

http://porn.serverbear.com

:-)

Wir haben einen Kunden in der Stadt A. Die Rechnungen werden von der Buchhaltung in der Stadt B bearbeitet. Nun wurde die gute Firma aufgekauft, von einem Unternehmen im Ausland (C). Von den letzten vier Rechnungen haben wir nun bereits drei mal die Anschrift geändert - und hier geht es nicht um großartige Umsätze, sondern nur ein paar Domainregistrierungen.

Heute kam die zuletzt gestellte (und schon seit einigen Wochen überfällige) Rechnung wieder mit dem Wunsch einer Adressänderung zurück - aber diesmal hat sich die zuständige Buchhalterin des Kunden selbst übertroffen: wir mögen die Rechnungen künftig bitte an eine von der Rechnungsanschrift abweichende Rechnungsadresse schicken. Adressiert also an “B”, ausgestellt aber an “C”. Und damit wir alles richtig machen, wurde sogar ein Entwurf für ein Deckblatt angefertigt und mitgesendet.
Bei aller Flexibilität und Liebe zum Service - das geht dann echt zu weit. Wenn der Kunde die Rechnungen woanders als an der Empfängeradresse bearbeitet, möge er bitte seine Hauspost bemühen. Und mit einer solchen Formulierung haben wir die Rechnung heute auch wieder zurückgesendet.

Letzte Erinnerung: ab morgen gelten neue rechtliche Vorschriften bei Online-Geschäften mit Endkunden. Unsere “Buttons” sind inzwischen soweit angepasst.

Persönlich halte ich von dieser Sache übrigens absolut überhaupt nichts. Schließlich haben nun vor allem Anbieter dubioser Leistungen rechtssichere Rahmenbedingungen bekommen, bei denen es Endkunden nun schwerer fallen dürfte, geschlossene Verträge aufzulösen… :-/

Eben hab’ ich mit einem Kunden in Kiel telefoniert und während des Gesprächs mehrfach Möven im Hintergrund schreien hören. Und sofort hat sich im Kopf ein Bild von einer norddeutschen Strand-Idylle gebildet.

Nach dem Telefonat entstand dann hier die Idee, ob wir nicht auch typisch bayrische Hintergrundgeräusche in Telefonate einblenden sollten. Kuhglocken oder Blasmusik?

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!

Ein sehr interessanter Artikel auf wired über ein 9-jähriges Mädchen, dass über das ihr angebotene Schulessen gebloggt hat, hat mich eben sehr an einen meiner ersten Blogbeiträge erinnert.

Was will uns dieses Verkehrsschild sagen?

Wen es interessiert: dieses Schild hat tatsächlich eine tiefere Bedeutung, steht alles in einem Wikipedia-Artikel. Wenn nur alles so eindeutig geregelt wäre…

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…)