Wohnzimmerhostblogger

Auf heise.de wurde heute der Heartbleed-Check von lastpass.com referenziert.Die Software ist aber absoluter Müll und sollte nicht für eine qualifizierte Aussage darüber, ob ein Server für Heartbleed anfällig ist oder nicht herangezogen werden.

Nach allem Anschein, scheint die Software nur zu prüfen, welche Server-Software (HTTP-Header "Server") verwendet wird und ob diese eventuell OpenSSL verwendet. Zusätzlich wird noch geprüft, wann das Zertifikat ausgestellt wurde und ob dieser Zeitpunkt vor vergangenem Dienstag (dem 8.4.2014) liegt.

So etwas als Heartbleed-Test zu verkaufen ist falsch und grob fahrlässig. Zu raten, ob eine Software die sich im HTTP-Header als "Apache" ausgibt folglich auch OpenSSL verwendet ist schon falsch. Es ist mit Apache auch möglich GnuTLS zu verwenden. Statistisch gesehen tut das niemand, aber möglich ist es. Zudem ist es notwendig zu prüfen, ob die Heartbeat-Extension überhaupt im TLS-Handshake angeboten wird bzw. praktisch genutzt werden kann - nichts von beidem geschieht hier. Ich habe sowohl Server getestet, die OpenSSL 0.9.8 verwenden (und Heartbeat gar nicht können), die OpenSSL 1.0.1 ohne Heartbeat (-DOPENSSL_NO_HEARTBEATS) verwenden und solche, die mit der aktuellsten nicht anfälligen OpenSSL-Version laufen. Alle werden als gefährlich eingestuft.

Weiter ist auch das Gültigkeitsdatum im Zertifikat kein Hinweis darauf, dass das Zertifikat vor dem 8.4.2014 ausgestellt wurde. Wird ein Zertifikat wegen Kompromittierung des Schlüssels ausgetauscht, erhält man unter Umständen das selbe Zertifikat nur für einen anderen privaten Schlüssel. Das Zertifikat ist daher nicht mehr anfällig. Legitim wäre der Test, wenn man in der CRL des Ausstellers nachsieht, ob das Zertifikat zwischenzeitlich widerrufen wurde - das wird aber wenig praktikabel sein.

Leider hat auch heise.de in diesem Fall mächtig daneben gegriffen, nachdem mich schon die Bild-ähnlichen Überschriften zu diesem Thema aufgeregt haben, haben sie es nun auch inhaltlich unterstrichen.Zu LastPass sei gesagt, dass sie es bestimmt gut gemeint, aber eben schlecht gemacht haben. Immerhin funktioniert der Test in diese eine Richtung falsch: Lieber einmal zuviel falsch warnen als einmal zuviel entwarnen.

Auch wenn die Fragen hierzu bisher nicht so oft kamen, wie ich mir das erhofft hätte, mag ich mal ein wenig erzählen, wie wir in den letzten 2,5 Tagen den Heartbleed-Bug von OpenSSL erlebt haben:

Als am 7.4. gegen 19:30 das OpenSSL-Update kam, klang alles noch recht harmlos. Erst das Security Advisory eine Stunde später verdeutlichte dass da etwas im Argen lag. Wir haben dementsprechend gleich für den nächsten Morgen ein Dringlichkeits-Update angesetzt. Ich war auch versucht, das ganze noch am selben Abend durchzuziehen, aber irgendwie war mir das zu heikel, OpenSSL ist immerhin ein zentraler Bestandteil der Webserver-Software.

Am nächsten Morgen gab es dann recht schnell ein Software-Updates, einen Test im "Trockendock" und dann das Rollout auf sämtliche Server, die OpenSSL 1.0.1 nutzen - das ist mittlerweile der Großteil aller Server. Irgendwie war mir Angst und Bange, aber es ging alles gut. Und auch alle folgenden Tests waren erfolgreich.

In der Zwischenzeit haben wir mit unserem Partner für SSL-Zertifikate geklärt, wie wir am einfachsten die diversen über uns verkauften bzw. auch bei uns eingesetzten SSL-Zertifikate möglichst einfach tauschen und die alten Zertifikate widerrufen können. Die Situation ist insofern neu für uns, als das vielleicht schon mal ein private Schlüssel abhanden gekommen ist (nicht bei uns) und ein einzelnes Zertifikat getauscht werden musste. So viele potentielle Tauschvorgänge auf einmal ist hingegen komplett neu für uns.

Ich habe heute dann alle Kunden, die ein SSL-Zertifikat über uns eingekauft haben, wie auch alle Kunden, die SSL-Zertifikate bei uns hochgeladen haben (um sie auf dem Webserver zu nutzen), per Mailing informiert. Zum einen ist es wichtig zu wissen, dass auch wir Webserver im Einsatz hatten, die für diesen Fehler anfällig waren, und die Bedrohung nun erst einmal vorüber ist.
Für alle die hierfür auch noch Geld in die Hand genommen haben, war es vielleicht auch besonders wichtig, dass wir jedes bei uns gekaufte Zertifikat kostenlos umtauschen.

Damit ist die Aufarbeitung des Heartbleed-Problems bei uns eigentlich abgeschlossen. Abgesehen von den etlichen Zertifikaten, die es nun gilt auszutauschen. Das wird aber weit weniger Stressig als alles was wir bisher in dieser Sache zu tun hatten

Ein Kunde fragte kürzlich per E-Mail wie er denn am besten und automatisiert Seine Datenbanken bei uns sichern kann.

Reflexartig überlegte ich kurz, wie ich seinen Wunsch am besten beantworten kann. Solange bis ich mir vor den Kopf schlug: Der Kunde sichert seine MySQL-Datenbank natürlich genau so wie wir es auch tun würden, nämlich über SSH mittels mysqldump:

Dazu legt man am besten (s)einen SSH-Public-Key in der Datei /homes/{Benutzer}/.ssh/authorized_keys ab und schreibt sich einen Skript, der so etwas wie

ssh -p 622 -o PasswordAuthentication=no {Benutzer}@{Domain} "mysqldump -u{Benutzer} -p{Passwort} {Datenbank}" > {Datenbank}.sql

regelmäßig ausführt. Und fertig.

An den Gedanken, dass wir im normalen Webhosting mittlerweile auch SSH-Zugänge (primär für SCP, SFTP und RSync) rausgeben muss ich mich wohl noch gewöhnen.

Ich hatte schon mehrfach ein Kribbeln in den Fingern und wollte es schon früher hier geschrieben haben, aber so 100% abgeschlossen war die Sache bis dahin nicht. Ab heute gilt das für mich nicht mehr, ich darf schreiben:

Unsere SEPA-Umstellung ist komplett abgeschlossen.

Seit Anfang 2014 haben wir konsequent ausgehende Zahlungen auf SEPA umgestellt und uns dann Mitte Januar auf die Umstellung des Lastschrift-Verfahrens und alles was damit zusammenhängt konzentriert, was auch perfekt funktioniert hat. Heute habe ich dann die ersten Zahlungseingänge (aus SEPA-Lastschriften) auf unserem Konto festgestellt. Herrlich!

Einziger Wermutstropfen: Die Lastschriften haben wir nicht zu dem auf der Rechnung angegebenen Datum ausgelöst, sondern ein paar Tage später. Ich glaube aber nicht, dass das wirklich jemanden stören wird außer mir selbst. Wobei ich auch der jenige war, der diese Verzögerung ein wenig paranoid herbeigeführt hat indem ich jede SEPA-XML-Datei vorab manuell gelesen geprüft habe - vergebens.

Bei der Konvertierung der bestehenden Einzugsermächtigungen in SEPA-Mandate haben wir uns noch einem externen Werkzeug bedient. Den "normalen" Zahlungsverkehr führen wir hingegen mit eigener Software durch, die im wesentlichen ein OOP-Interface für PHP zur Validierung der Zahlungsaufträge und Generierung von SEPA-XML-Dateien bereitstellt. Wer schändlicherweise noch nicht umgestellt hat und/oder an der Software Interessiert ist, darf gerne einen Link zum Repository erfragen. Aktuell kann die Anwendung Zahlungsaufträge (Payment Initiation, "PaIn") nach dem Rulebook DE-2.7 generieren und unterstützt dabei "normale" Überweisungen (pain.001.003.03) ohne Purpose und die drei Lastschrift-Typen (pain.008.003.02) "Basis-Lastschrift" (CORE und COR1) sowie "Firmen-Lastschrift" (B2B). Das gewünschte Ausführungsdatum lässt sich entweder für die gesamte Nachricht und/oder für einzelne Aufträge angeben.

Gerade erreicht mich von einem Geschäftspartner der Newsletter in dem sie unter anderem berichten, dass sie ihren Geschäftsbereich "Hosting" zum 31. Dezember 2013 einstellen.

2 Minuten später ist deren Webseite nicht mehr erreichbar. Ob es da einen Zusammenhang gibt?! Ist ja quasi auch Hosting...

Ich habe gerade eben auf einem Testsystem im Rechenzentrum einen Kernel installiert, der neben normalem TCP auch Multipath-TCP nach RFC 6824 überstützt.

Bei Multipath-TCP werden Datenverbindungen zwischen Client und Server - sofern verfügbar - auf mehrere Internet-Leitungen aufgeteilt um eine höhere Geschwindigkeit aber auch eine gewisse Ausfallsicherheit zu erlangen - grob gesagt so etwas wie Bonding/Trunking auf Layer 4.

Noch gilt das ganze als experimentell und so wird auch dieses Testsystem einige Zeit laufen bevor es dieser Kernel auf einen "richtigen" Webserver schafft. Aber spannend ist dieser Ansatz schon, zumal ich erst kürzlich im Zug über den Hotspot geflucht habe und ein "Fallback" auf eigenes UMTS funktionierte und besonders Multipath-TCP für so ein Szenario perfekt geeignet ist. Denkt man jetzt noch an unseren VPN Gateway, die Möglichkeit diesen auch per TCP anzusprechen und lässt dabei den Umstand, dass man TCP nicht über (MP)TCP tunneln sollte weg, ergibt sich ein nahezu perfektes Anwendungsszenario.

Auch iPhone/iPad-Nutzer könnten sich freuen (sofern MPTCP dort für "normale" Anwendungen und nicht nur Siri zur Verfügung steht), würde doch der Wechsel zwischen Mobilfunknetz und WLAN leichter.

Kleine Notiz für mich selbst:
Wenn schon das Hinzufügen des ersten Slave zu einem frischen Bonding-Interface fehlschlägt mit dem Fehler "Invalid Argument" fehlschlägt, sollte man die MTU der beiden Interfaces prüfen.

Hintergrund:
Für ein internes Projekt wollte ich mehrere VPN-Tunnel in einem Bond zusammenfassen. Auf den VPN-Tunneln selbst ist die MTU wegen des Protokoll-Overhead kleiner als auf normalen Devices, das Bonding-Interface wurde aber mit dem Standard von 1500 Bytes erstellt und versuchte diese Einstellung auf die Slaves zu übernehmen - was nicht ging (dafür habe ich extra Kernel-Quelltext gelesen). Kurz nach dem erstellen des Bonds die MTU auf den kleinsten gemeinsamen Nenner zu setzen schaffte hier Abhilfe.

Wer sich jetzt fragt, wozu das gut sein soll, der darf gespannt sein

Was tut man als erstes wenn der Strom ausfällt? Richtig! Man schaut, ob das Handy noch eine Internet-Verbindung hat und pingt das Rechenzentrum in der selben Stadt an.

Puh! Alles in bester Ordnung und läuft

Hier im Rechenzentrum in Stuttgart ist bei unserem Dienstleister leider ein Switch defekt, was zu Verbindungsproblemen führen kann. In jedem Falle ist es langsam!

Der Switch wird jetzt ordentlich getauscht und danach sollte alles wieder gut sein - bis dahin bitte etwas Geduld und Verständnis =)

Als ich gestern Abend "markt" auf WDR angeschaut habe, kam dort auch ein Beitrag, der offensichtlich vom "Ratgeber Internet" (20.07.13, 17:03 ARD) recycelt worden ist.

Für "Menschen vom Fach" birgt der Beitrag "Überwachung total? Das  große Spionage-Experiment" ggf. nicht viel neues, spannend fand ich nur, dass die Journalisten vom WDR die erste Befragte mit der Aussage "Ich habe nichts zu verbergen" gewählt und einen Tag unbemerkt begleitet haben. Den 6 minütigen Fernsehbeitrag halte ich für sehr Anschauungswert - besonders für Menschen, die eben genannte Aussage gerne selber treffen.

Link zur Webseite
RTMP-URL

Ein Kunde meldete sich gestern bei uns im Support, dass die Weiterleitung seiner E-Mails von seiner web.de-Adresse an seine Mailbox bei uns nicht mehr funktionieren würde. Als Fehlercode unseres Mailservers gab er "tw:byrA" an.

Eigentlich merkwürdig, denn diesen Fehlercode generiert ausschließlich unser E-Mail-Gateway, der für die Annahme von E-Mails aus dem Internet zuständig ist, und auch nur dann wenn Absender und Empfänger der E-Mail im SMTP-Dialog identisch sind - ein typisches Zeichen für Spam und auch nichts, was bei "normalem" E-Mail-Verkehr vorkommen sollte - nicht zuletzt weil die Domain an die die E-Mail gerichtet ist bei uns gehostet wird und in der Theorie nur unser E-Mail-Server befugt ist E-Mails für diese Domain zu versenden.

Ich musste aber feststellen, dass der genannte Fehlercode vollkommen korrekt ist, meine Test-E-Mail kam nicht durch und anstatt an mich sendete web.de die Fehlermeldung hierzu an den Kunden zurück (was ich zur Vermeidung von Backscatter gerade noch so verkraften kann). web.de scheint beim Weiterleiten von E-Mails im SMTP-Dialog den Absender dem Empfänger gleich zu setzen, dort taucht weder der reale Absender, noch ein mit SRS maskierter originaler Absender oder die E-Mail-Adresse des web.de-Kontos für das/von wo aus die E-Mail weitergeleitet wird.

Ich konnte dem Kunden leider nicht wirklich helfen. Die Regel leitest zum einen gute Dienste und zum anderen halte ich sie für gut begründet. Die einzige Alternative hier war ein umsteigen von der web.de-Weiterleitung auf unseren Abholdienst, der regelmäßig per POP3 die Mailbox bei web.de abfragt und neue E-Mails entsprechend weiterleitet. Damit funktioniert die Weiterleitung zwar nicht mehr unmittelbar, jedoch immerhin zeitnah. 

Wer kennt das nicht? Man sitzt bei einem Kaffee im Cafe und schreibt an einem asyncronen SMTP-Client... Da dies ja ein Entwicklungsschritt ist, arbeitet man auf einem vertrauten SMTP-Server und liest beim Testen den SMTP-Dialog mit:

> 220 ******************************************
< EHLO qccore2-test.virtual.tiggersystems.info

> 250-mail.tiggerswelt.net
> 250-PIPELINING
> 250-SIZE 104857600
> 250-VRFY
> 250-ETRN
> 250-XXXXXXXA
> 250-AUTH PLAIN LOGIN
> 250-AUTH=PLAIN LOGIN
> 250-ENHANCEDSTATUSCODES
> 250-8BITMIME
> 250 DSN

Huch? Merkwürdig! Sowohl das "initial Greeting" des Servers und die StartTLS-Erweiterung in den Server-Features sind "geschwärzt". Was soll denn das? Ich weiß zwar mit welchem Server ich mich da verbinde, insofern ist mir das egal, aber warum darf ich denn angeblich kein StartTLS ausführen?

Da der Client explizit dieses Feature für der TLS-Aushandlung prüft also kurz diesen Check auskommentiert und "brute force" StartTLS versucht:

< STARTTLS
> 502 5.5.2 Error: command not recognized

Böse! Ich möchte ja jetzt keine Verschwörungstheorien a la Snowden und PRISM niederschreiben, aber es ist schon sehr merkwürdig, dass der Hotspot der Telekom verhindert, dass eine SMTP-Verbindung per TLS verschlüsselt werden kann.

Ach ja, nur der Vollständigkeit halber: Lege ich dann eine SSL-Verschlüsselte VPN-Sitzung über diese Verbindung funktioniert es sofort und wie gewünscht:

> 220 mail.tiggerswelt.net ESMTP TiggerMail/1.25
< EHLO qccore2-test.virtual.tiggersystems.info

> 250-mail.tiggerswelt.net
> 250-PIPELINING
> 250-SIZE 104857600
> 250-VRFY
> 250-ETRN
> 250-STARTTLS
> 250-AUTH PLAIN LOGIN
> 250-AUTH=PLAIN LOGIN
> 250-ENHANCEDSTATUSCODES
> 250-8BITMIME
> 250 DSN
< STARTTLS

> 220 2.0.0 Ready to start TLS
[TLS-Aushandlung]
< EHLO qccore2-test.virtual.tiggersystems.info

> 250-mail.tiggerswelt.net
> 250-PIPELINING
> 250-SIZE 104857600
> 250-VRFY
> 250-ETRN
> 250-AUTH PLAIN LOGIN
> 250-AUTH=PLAIN LOGIN
> 250-ENHANCEDSTATUSCODES
> 250-8BITMIME
> 250 DSN

Ich bin ja bekennender IMAP-Fan. Schon in sehr jungen Jahren (mit 14 oder 15 Jahren) fand ich POP3 und Webmail richtig blöd, wenngleich mich die damalige Internet-Situation etwas an POP3 fesselte.

Ich kann jetzt aber nicht nur Lobes- Hymnen auf dieses Protokoll schwingen, denn eine Sache stieß mir schon übel auf, als ich das erste mal von der technischen Seite her einen Blick auf dieses Protokoll warf:
Es gibt eine Vielzahl grundsätzlich wohldefinierter Server-Antworten ("Responses"), die recht lose oder an ein bestimmtes Kommando über die Verbindung übertragen werden. Das Format ist dabei eigentlich immer

 <ID-or-untagged> <Response> [<Code>] <Response-specific stuff>

allerdings wird es spätestens, wenn man mittels SELECT bzw. EXAMINE eine Mailbox öffnet, denn dann kommen auf einmal die Responses EXISTS, RECENT, FETCH und EXPUNGE ins Spiel und die verhalten sich anders. Dort ist es dann immer im Format

<untagged> <Number> <Response>

 Muss das sein? Wäre es nicht sinnvoller gewesen die Nummern bzw. Anzahlen gleich hinter den Response zu setzen oder die Dinger gleich als "Codes" umzusetzen, so wie es z.B. auch bei UNSEEN, UIDNEXT und UIDVALIDITY ist? Überhaupt sieht dieses Misch-Masch an Responses und Codes beim öffnen eine Mailbox sehr komisch aus.

Das musste jetzt mal raus!

Das Wetter ist super, ohne Frage! Nur vielleicht ein wenig zu heiß.

Aus Jux und Tollerei habe ich gerade einmal einen Sensor im Rechenzentrum ausgelesen, der im hinteren Teil eines Racks platziert ist. Das mit dem "hinteren Teil" ist wichtig, denn der geübte Leser wird sich erinnern dass die Maschinen seit 2010 in einem Raum mit getrennen Kalt- und Heiß-Gängen stehen. "Hinten" ist in diesem Fall also "da wo heiß ist", zwar ist die Temperatur hinten im Rack sicherlich noch etwas kühler als auf dem tatsächlichen Gang, wo schlussendlich auch unsere Nachbarn ihre warme Abluft hinpusten.

Mit aktuell 33,5 °C ist es da aber noch ca. 5 °C kühler als im Büro und somit sehr verlockend. Vom Kalt-Gang will ich gar nicht erst anfangen. ICH WILL DA HIN!

Aktuell würde sowieso ein Hardware-Tausch anstehen, somit wäre ein Besuch also gerechtfertigt. Da ich dafür aber erst einmal 16 KG wuchten müsste fällt das wohl aus

Irgendwie hat es sich heute ziemlich komisch angefühlt:

Den Mittag über saß ich mit jemandem zusammen, der sich Hauptberuflich mit dem Thema Compliance beschäftigt und wir haben natürlich auch dieses Thema grob angeschnitten. Als ich zurück im Büro war, bekam ich von einem Geschäftspartner einen erfreuten Anruf bei dem man sich für ein kleines (persönliches) Geschenk meinerseits bedanke.

Das Geschenk hat mich zwar weniger als ein Strauß Blumen gekostet und ich tat es auch eher um mich für die sehr menschliche und freundliche Zusammenarbeit der Vergangenheit zu bedanken (als vielleicht einen Vorteil für die Zukunft heraus zu "arbeiten") aber irgendwie hab ich mich danach richtig unwohl gefühlt. Mit dem Thema Compliance sollte ich mich wohl definitiv noch einmal mehr auseinander setzen...