Archiv der Kategorie 'Hosting'

Die SSL-Revolution

Mittwoch, den 19. November 2014

Ich glaube, heute haben viele CAs so richtig kotzen müssen :-)

Heise: Let’s Encrypt - Mozilla und EFF mischen den CA-Markt auf
DAS ist genau das, was bitter nötig und schon längst überfällig war! Ich hoffe, dass das tatsächlich so kommt und die Gelddruck-Lizenzen der CAs damit auslaufen. Wir werden da insbesondere mit LiveConfig natürlich auch dran bleiben. Das war ja schon lange mein Traum: mit ein paar Mausklicks SSL für eine Domain aktivieren… :-)

iX Rootserver-Umfrage

Donnerstag, den 27. März 2014

Die iX führt zum 25jährigen Jubiläum eine Umfrage zum Thema Root-Server durch. Als Dankeschön für die Teilnahme (bis 11.05.2014) winken attraktive Preise: ix.de/ix25

Auf der zweiten Seite (Themenbereich “Betriebs-, Daten- und Zugangssicherheit”) wird auch nach dem gewünschten Controlpanel gefragt. Die “richtige” Antwort ist ja wohl klar, oder? ;-)

ix-umfrage.png

PCI-Compliant

Donnerstag, den 27. Juni 2013

Wer es nicht braucht, der sollte die Finger davon lassen - wer es aber braucht, der weiß, wie schwierig das sein kann: PCI-Compliance. Zum Glück gibt es aber LiveConfig: ab der nächsten Version (1.6.4) kann man mit wenigen Mausklicks alle Serverdienste so konfigurieren, dass diese den Scan eines PCI-ASV (Authorized Scanning Vendor) bestehen. Unseren Referenzserver haben wir so bereits erfolgreich durchgetestet:

pci.png

Das bedeutet aber noch nicht, dass der Server somit konform zum PCI-DSS (Data Security Standard) konfiguriert ist - auch wenn Anbieter anderer Controlpanels das gerne so verkaufen. Wir bereiten derzeit eine ausführliche Checkliste dafür vor - weitere Details dazu dann bei Gelegenheit. Unter anderem ist es erforderlich, dass eine Zwei-Faktor-Authentifizierung für Admin-Logins verwendet wird (siehe PCI-DSS 8.2, kann Plesk das? *hüstel*).

Abschließend muss ich aber sagen, dass die aktuellen PCI-Scans ein völliger Quatsch sind. So fällt man beispielsweise durch, wenn für SMTP, POP oder IMAP ein SSL-Cipher genutzt werden kann, der nicht gegen die BEAST-Attacke immun ist. Diese kann man als Angreifer aber nur ausnutzen, wenn man die Möglichkeit hat, große Datenmengen durch den verschlüsselten Übertragungskanal zu senden, auf die man selbst Einfluss hat (z.B. per Java-Applet, JavaScript, etc.). Bei SMTP/POP/IMAP ist das nicht möglich.

Die Einschränkung der SSL-Ciphers führt dazu, dass bei klassischen SSLv3/TLSv1-Protokollen lediglich RC4 als einziger “erlaubter” Chiffre übrig bleibt - und der gilt bekanntlich auch nicht mehr als besonders sicher. [PARANOID]Vielleicht ist nur RC4 erlaubt, weil so bequem alle verschlüsselten Verbindungen via PRISM etc. decodiert werden können?[/PARANOID]

Interessanterweise hat der PCI-Scan aber kein Problem damit, dass bei FTPS-Verbindungen wiederum die BEAST-anfälligen Block-Chiffres erlaubt sind - das ist schon irgendwie inkonsequent.

Zumindest bei den PCI-Scans durch Comodo sieht es übrigens so aus, als ob diese mit Nessus ausgeführt werden (die Scan-Muster auf dem Server sowie einige Einstellungsmöglichkeiten bei HackerGuardian legen das nahe). Wir haben testweise unser System mit OpenVAS geprüft und dabei deutlich ausführlichere und brauchbarere Ergebnisse erhalten als mit dem PCI-Scan-Report. Ein Loblied auf OpenVAS möchte ich in Kürze noch mal in einem separaten Blog-Beitrag singen. :)

Hoppla…

Samstag, den 22. Juni 2013

Seit einigen Tagen beobachten wir eine leicht angestiegene Last auf einem unserer DNS-Server. Nicht nennenswert, aber immerhin im MRTG-Graphen leicht sichtbar.

Nun habe ich in der Prozessliste gesehen, dass der BIND-Prozess derzeit >30% CPU zieht, obwohl quasi nichts Besonderes los ist (der DNS arbeitet nicht als Resolver, sondern löst nur die bei uns gehosteten Domains auf). Erst auf den dritten oder vierten Blick ist mir dann aber etwas Anderes aufgefallen: in der Skala des Graphen für DNS-Anfragen pro Minute steht plötzlich ein “k”. Soll heißen, die Anfragezahlen sind in den letzten Tagen etwa um den Faktor 500 (!) gestiegen. Im Wochen-Graphen sieht man das recht deutlich:

dns-week.png

Ich bin mal gespannt was genau dahinter steckt. Als Erstes werde ich mir mit tcpdump nun mal die Anfragen etwas genauer unter die Lupe nehmen…

Klartext-Passwörter

Freitag, den 13. Juli 2012

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!

CentOS 6.2 & VirtualBox: Kernel Panic

Freitag, den 13. April 2012

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

Proudly presenting: LiveConfig®

Montag, den 14. Februar 2011

lc-productbox.pngJa, 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).

Schamlos

Donnerstag, den 25. November 2010

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.