Archiv der Kategorie 'Hosting'

Port 25 gesperrt

Mittwoch, den 22. Juni 2016

Interessante Methoden eines… naja… “Mitbewerbers”, um den eingehenden Spam zu reduzieren. :auslach:

Port 25 gesperrt

Kostenloses SSL mit Let’s Encrypt & LiveConfig

Freitag, den 4. Dezember 2015

Gestern um 19:00 ist die Zertifizierungsstelle “Let’s Encrypt” in den öffentlichen Betrieb gestartet. Somit kann nun jedermann kostenlose Domain-validierte SSL-Zertifikate erhalten, die von allen gängigen Browsern akzeptiert werden.

pic-letsencrypt.jpg

LiveConfig ist übrigens die erste Controlpanel-Software, die Let’s Encrypt direkt unterstützt. Dank früher Teilnahme an der Beta-Phase konnten wir das auch gut testen und “tunen”, so dass alle LiveConfig-Kunden seit gestern Abend mit SSL loslegen können. :)
Die Bedienung ist möglichst einfach: beim Anlegen eines SSL-Zertifikats erfasst man statt RSA-Schlüssel, CSR usw. einfach nur den Domainnamen und setzt eine Checkbox für Let’s Encrypt - das war’s. Im Handbuch ist das alles genauer beschrieben.
(wem es noch nicht aufgefallen ist: RackBlogger wird seit dem 17.11.2015 mit einem Let’s Encrypt SSL-Zertifikat ausgeliefert ;) )

Die Industrie für Domain-validierte (DV) SSL-Zertifikate wird damit ziemlich umgekrempelt. Erste große CAs bieten in Rahmenverträgen schon “Flatrates” für Großkunden an. Wettbewerb belebt den Markt. :) Aber weder Webhoster noch Zertifizierungsstellen werden mit drastischen Einbußen rechnen müssen, schließlich dürfte die Nachfrage nach den Extended-Validation (EV) Zertifikaten - die mit der “grünen Adresszeile” - nun auch deutlich steigen.

Entgegen vielem falschen Halbwissen oder gezielter Desinformation so mancher SSL-Anbieter ist ein kostenloses SSL-Zertifikat an sich genauso sicher wie ein EV-Zertifikat für 1000,- Euro pro Jahr. Das Zertifikat dient nur dem Schlüsselaustausch zwischen zwei Verbindungsstellen - die Qualität der Verschlüsselung selbst wird direkt zwischen dem Client und dem Server vereinbart und ist somit ausschließlich von deren Software abhängig.
Der Unterschied ist nur die Identitätsprüfung des Zertifikatsinhabers: während bei DV-Zertifikaten nur geprüft wird ob der Antragsteller Zugriff auf die Domain hat, wird bei EV-Zertifikaten tatsächlich geprüft ob der Inhaber auch im juristischen Sinne existiert und korrekt ist (z.B. durch Personalausweis-Kopie, Handelsregisterauszug, usw.). Bei allen EV-Zertifikaten (egal ob für 10,- Euro im Sonderangebot oder das Business-Zertifikat für 1299,- Euro) kommt am Ende aber das selbe heraus: ein X.509-Zertifikat mit den geprüften Inhaberdaten.
Auch hier gilt also: Wettbewerb belebt das Geschäft.

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