Aus dem Rechenzentrum

Vorsicht: Rant

Ich hasse FTP — die Warze unter den Dateiübertragungsprotokollen. Ich hasse es wirklich, leidenschaftlich und abgrundtief. Es ist ein veraltetes, unsicheres, umständliches, schlecht designtes Protokoll und es gibt so gut wie keine vernünftigen Implementierungen. Die Clients haben fast alle grauenvolle User Interfaces, sind langsam und gelegentlich auch noch instabil. Auf der Serverseite sieht es auch nicht viel besser aus, das meiste was es da gibt ist weder schnell noch schlank und selbst wenn es das ist ist es fast immer unsicher. (Wir verwenden als FTP-Server-Software übrigens vsftpd, der wenigstens in dem Ruf steht sicher zu sein und den man sich auch nicht so leicht unsicher konfigurieren kann. Lieber wäre uns aber, wenn wir einfach darauf verzichten könnten. Das beste FTP ist kein FTP.)

FTP überträgt alle Passwörter im Klartext, die etwas besser gesicherte Erweiterung FTPS (FTP mit SSL) gibt es zwar schon seit einer halben Ewigkeit, wird aber immer noch längst nicht von jedem genutzt und den meisten Clients kann man auch nicht oder nur schwer beibiegen, daß sie auf gar keinen Fall Passwörter im Klartext übermitteln sollen. Selbst wenn FTPS die Passwörter (oder genauer gesagt den gesamten Kommandokanal) verschlüsselt, verschlüsselt es dann aber nicht die übertragenen Dateien (den Datenkanal), die bei sehr vielen Webanwendungen aber wiederum Klartextpasswörter z.B. für MySQL-Datenbanken enthalten. „Secure“ FTP hat den gleichen Fehler, nur daß es statt SSL halt SSH benutzt um den Kommandokanal zu verschlüsseln, in jedem Fall verschlüsselt es nicht die übertragenen Dateien. Und über das Firewalling von FTP möchte ich gar nicht schreiben, da würde ich mir die Tastatur unter den Fingern zerlegen vor lauter in den Tastenanschlag einfließendem Ärger.

Ich kann auch nicht verstehen, wieso FTP immer noch eingesetzt wird. Ich weiß, daß viele Leute nur so auf die Dokumente auf ihren Webservern zugreifen können, aber ich weiß halt auch, daß enorm viele Programme auch Support für das SSH File Transfer Protocol (SFTP, nicht zu verwechseln mit „Secure“ FTP) oder sogar Secure CoPy (SCP) mitbringen und ich weiß auch daß es mit Putty und sshfs und noch ein paar anderen Programmen (deren Namen mir gerade nicht mehr einfallen) wirklich bequeme Methoden gibt Daten sicher zu übertragen. Es gibt auch haufenweise Anleitungen dazu, die Hälfte davon offenbar von entnervten Admins geschrieben, die sich große Mühe geben die Leute dazu zu bewegen doch bitte endlich kein FTP mehr zu benutzen. Und Webhostinganbieter die kein SSH anbieten, sondern nur FTP… gut ich arbeite bei einem Webhostinganbieter der genau das aus gutem Grund nicht tut, insofern ist es naheliegend, daß ich davon nichts halte, trotzdem: FTP ist sowas von alt und überholt, wenn ein Anbieter nichts neueres zu bieten hat, dann ist sein Angebot es einfach nicht wert. Einen Zahnarzt der außer Zähne ziehen keine neueren Lösungen zu bieten hat, würde man bei Zahnschmerzen ja auch nicht bevorzugt aufsuchen.

Warum FTP immer noch so weit verbreitet ist, will mir einfach nicht in den Kopf. Ich finde das schlimm. Es ärgert mich, daß ich mich mit dem Mist auseinandersetzen muß, es ärgert mich das ich dafür Support leisten muß. (Was nicht heißt, daß ich mich im Ungang mit solchen Supportanfragen dann nicht zusammenreiße und trotzdem schnell und freundlich weiterzuhelfen versuche. Den Ärger spare ich mir dann für Momente wie diesen hier auf.) Es ärgert mich, daß unsere Kunden sich damit rumquälen müssen. FTP soll endlich verschwinden. Telnet ist doch auch weitgehend verschwunden, warum dann nicht FTP?

So, nachdem ich mir nun Luft gemacht habe, kommen wir zum eigentlichen Thema:

Mein Kollege Matthias sprach mich neulich an, weil bei einem Kunden ein Problem mit einem Backup aufgetreten war. Offenbar dauerte das Runterladen der Backups per FTP sehr lange. Matthias hat das Problem auch sofort reproduzieren können und so wußten wir gleich, daß die Downloads nicht einfach lange dauerten, sondern im Gegenteil ganz normal funktionierten, aber vor Beginn jedes einzelnen Downloads eine Wartezeit von 30 Sekunden eingelegt wurde.

Kurze Erklärung des Setups: Die Backups liegen auf einem Backupserver, von wo aus wir sie per NFS auf dem Webserver den der Kunde nutzt einbinden, wobei NFS das Verzeichnis mit den Backups nur im Read-Only-Modus holt. Schreibzugriffe aufs Backup sind also vom Webserver aus nicht möglich.

Deswegen dachte ich auch im ersten Moment, daß die Verzögerung wohl eher daher rühren wird, daß entweder NFS irgendwie gestört ist oder der Backupserver zum Zeitpunkt der Downloads zu viel zu tun hatte. Der Backupserver hatte aber zu dem Zeitpunkt an dem mein Kollege und ich das testeten gerade nichts zu tun und NFS hat auch durchaus funktioniert. Wenn ich dieselben Dateien per SCP runtergeladen habe, dann gab es keine Verzögerung.

Ich habe also etwas in den Logs gestöbert und schließlich diese Einträge in /var/log/messages gefunden:


Feb 14 10:01:59 helium kernel: statd: server localhost not responding, timed out
Feb 14 10:01:59 helium kernel: lockd: cannot monitor 82.98.87.73
Feb 14 10:01:59 helium kernel: lockd: failed to monitor 82.98.87.73


(Am Rande sei hier mal angemerkt, daß das Deuten der Logausgaben von NFS eine arkane Kunst ist die ich — wie 99% der Nutzer und Entwickler von NFS — nicht beherrsche. In der Regel kann ein und diesselbe Logausgabe von NFS für mindestens ein Dutzend verschiedene Fehlerursachen stehen und in beinahe allen Fällen enthält der genaue Text der im Log landet inhaltlich keine sachdienlichen Hinweise zur Problemlokalisierung. Obendrein muß man bei NFS schon dankbar sein, wenn es überhaupt Logausgaben gibt. Mit anderen Worten ist das Logging von NFS das absolut allerletzte, wie wohl jeder der schonmal NFS Fehler debuggt hat und dazu im Internet nach Lösungen suchen mußte sofort bestätigen wird. Diese Logausgabe hier verdient besondere Erwähnung, weil sie ausnahmsweise in der Tat direkt etwas mit dem Problem zu tun hat und vergleichsweise leicht zu deuten ist. Genießt es, sowas sieht man nicht allzu oft.)

Davon auf die Spur gebracht hatte ich bald die Ursache des Problems ausgemacht und gelöst: FTP versucht hier einen Lock auf die Datei zu legen und da dies nicht funktioniert, wartet es auf einen Timeout und kopiert die Datei dann trotzdem. — Warum auch immer. Ich hätte ja ein anderes Verhalten erwartet, aber gut. Bleibt nur noch die Frage, warum FTP hier versucht einen Lock zu erlangen, denn es handelt sich ja um ein Read-Only gemountetes Verzeichnis. Eine ohnehin nur lesbare, aber nicht schreibbare Datei zu locken ist weitgehend sinnfrei. Wie auch immer, die Lösung war recht einfach:

chkconfig nfslock on; service nfslock start

Ich gestehe gerne ein, daß ich nfslock von Anfang an hätte laufen lassen sollen, da es prinzipiell für einen geordneten NFS-Betrieb schon dazu gehört. Mea culpa. Aber ich weigere mich zu begreifen, warum FTP hier einen Lock erreichen will. Ein Lock ist dafür gedacht, damit niemand anderes schreibend auf die Datei zugreift, für Lesezugriffe ist das gar nicht gedacht. Ich möchte an der Stelle nocheinmal darauf hinweisen, daß dieses Problem nicht auftritt, wenn ich diesselbe Datei lokal kopiere oder per SSH oder HTTP runterlade. Im Grunde hat mich FTP hier auf einen Konfigurationsfehler den ich bei NFS gemacht hatte hingewiesen und ich bin dafür auch dankbar — nur bin ich halt auch mittlerweile unfähig etwas über FTP zu sagen ohne mich erstmal ausgiebig über FTP an sich aufzuregen.

Gut, da ich es jetzt eh schonmal nachrecherchiert habe, kann ich mein Wissen hier ja nochmal teilen: Wenn man ein CentOS 5 nur als NFS Client benutzen möchte, dann sollte man den Dienst nfslock laufen lassen (geht aber in vielen Fällen auch ohne). Wenn man NFSv4 verwendet und auf’s ID Mapping wert legt, sollte man zusätzlich rpcidmapd laufen lassen. Wenn man NFSv4 verwendet und authentifizieren oder verschlüsseln möchte, dann sollte man zusätzlich rpcgssd laufen lassen. Wenn man mit CentOS 5 einen NFS Server betreiben möchte, dann muß man die Dienste portmap und nfs laufen lassen (die in dieser Reihenfolge zu starten sind). Auch hier brauch man bei NFSv4 für ID Mapping rpcidmapd, für Authentifikation und Verschlüsselung braucht man aber rpcsvcgssd statt rpcgssd.

Zum Abschluß noch ein weiterer Seitenhieb auf NFS. Beim Lesen der Manpage von rpc.lockd bin ich vor Lachen fast vom Stuhl gefallen, sowas schwammiges und uninformatives ist mir lange nicht mehr untergekommen:

The rpc.lockd program starts the NFS lock manager (NLM) on kernels that don’t start it automatically. However, since most kernels do start it automatically, rpc.lockd is usually not required. Even so, running it anyway is harmless.

Na dann ist ja alles klar.

Wir sind VeriSign-Partner, um SSL-Zertifikate von Thawte, GeoTrust und anderen CAs dieser Gruppe beziehen zu können – immerhin werden diese häufig nachgefragt, und SSL ist ja im Prinzip auch eine gute Sache.

Allerdings nervt VeriSign gewaltig. Jeden Monat bekomme ich Mails mit meiner Accountaufstellung, mitsamt Vertragsbezeichnungen und konkreten Dollar-Beträgen, die ich ausgegeben habe und noch auf meinem Partner-Konto übrig habe – also durchaus sensible Daten. Die kommen unverschlüsselt, was ich für ein Unternehmen aus dem Security-Bereich schon bizarr genug finde. So bizarr, dass ich schon zig Mal und an verschiedene Adressen gefragt habe, worin denn hier die Sicherheit bestehen soll, wenn sensible persönliche Daten unverschlüsselt durch die Gegend gemailt werden, und dass man das doch bitte abschalten solle. Ergebnis? Keine Antwort, egal ob ich eine der generischen Adressen anschreibe oder meinen „persönlichen Account-Manager“, der namentlich unter der Mail genannt wird. Das stinkt mir schon mal gewaltig, wenn ein Unternehmen, bei dem ich jedes Jahr einige tausend Dollar lasse, sich nicht mal dazu in der Lage sieht, auf simple E-Mails zu antworten.

VeriSign ist aber noch anstrengender. Es kommen nämlich auch noch ständig Promotion-Mails rein, und jetzt seit neuestem auch noch eine Umfrage, die ich bitte ausfüllen möge und an die ich heute schon wieder erinnert wurde. So langsam reicht es mir. Wer uns kennt, weiß, dass wir nicht nur unsere Kunden, sondern auch unsere Lieferanten genau so höflich, professionell und vor allem auch herzlich behandeln, wie wir selbst gerne sowohl als Kunde als auch als Lieferant behandelt werden möchten. Das hat VeriSign aber im Lauf der Monate kräftig verspielt, denn wenn ich eins nicht haben kann, dann ist das „Kundenbeziehungsmanagement“, bei dem der Kunde die Beziehung selbst managen soll, unter anderem, in dem er irgendwelche Arbeiten erledigen soll, mit dem der Anbieter „messen“ will, wie „zufrieden“ man ist. Denn, ganz klar: „Your opinion is extremely valuable to us“! So extremely valuable, dass man sich die Mühe gemacht hat, ein Script anzuwerfen, das automatisiert dem gesamten Kundenbestand den Bauch pinselt und gleichzeitig anquengelt, man möge jetzt doch bitte auch noch kundtun, wie zufrieden man ist. In Sachen „Kundenbeziehung“ kommt das einer Bankrotterklärung nahe, denn Hand aufs Herz: Gäbe es tatsächlich eine Kundenbeziehung, dann wüsste das Unternehmen ja bereits, ob ich zufrieden bin oder nicht.

Daher nun also:

Dear VeriSign Partner Program Loyalty Team,

As part of our commitment to improve our partner program, I wrote to you last week to solicit your feedback about your experience with the VeriSign Partner Program. Although I understand the many constraints on your time, your opinion is extremely valuable to us.

Obviously, you do not understand the many constraints on my time, otherwise you wouldn’t constantly annoy me with such mailings.

We will ensure that your feedback is reviewed and used to drive improvements in the partner experience.

I don’t trust that.

For example, I constantly receive monthly accounting statements containing financial details of my account via unencrypted mail. I asked my account manager three times about VeriSigns understanding of security which obviously does not include the encryption of sensible data, which is baffling enough for a „security“ company.

I never got a single response.

That’s not the kind of company I’d invest even five minutes for your dumb „surveys“ if you’re simply not able to listen to things I tell you personally.

The survey will take about 5 to 10 minutes to complete. To access the survey, please click the Web address below.

Your mail is sent as multipart/alternative, containing both a HTML variant and a plain text variant.

The plain text variant does not contain a link at all. Are you really a company of Internet professionals?!

The HTML variant contains a link to the survey, which is unencrypted. Are you really a company of data security experts?!

To remove yourself from receiving future Symantec promotional mailings http://www.verisign.com/compref and update your communication preferences and user profile.

When I open that link, I get a redirect to …

https://forms.verisign.com/websurveys/servlet/ActionMultiplexer?Action_ID=ACT2000&WSD_mode=3&WSD_surveyInfoID=500&toc=…&brand=01&country=26&cid=…

… which provides a HTML page consisting of the word „null“ and nothing else. Are you really a company of Internet professionals?!

I never opted in into receiving such promotional mailings, and I’m not willing to invest any time to click through an obviously broken site of „communication preferences“. I’m paying you for getting SSL certs. Story finished. For God’s sake, stay away from me with your „promo“, „survey“ and „loyalty“ rubbish.

Regards,
Jonas Pasche

Wir setzen auf den meisten unserer Server qmail bzw. netqmail als MTA ein und erfreuen uns dabei an den vielen Vorzügen, die das Maildir-Format bietet. Zwar kommt dabei meistens ein zusätzliches Tool wie vpopmail oder vmailmgr zum Tragen, was virtualisierte Mailuser bietet; auf unserer Hosting-Plattform Uberspace.de bieten wir aber ganz offiziellen Support für ein „echtes“ Maildir des betreffenden Systemusers. Die netqmail-Dokumentation erläutert dazu in INSTALL.maildir:

The system administrator can set up Maildir as the default for everybody by creating a maildir in the new-user template directory and replacing ./Mailbox with ./Maildir/ in /var/qmail/rc.

Und so sieht das Setup bei uns dann auch aus: Ein /var/qmail/bin/maildirmake /etc/skel/Maildir legt ein Standard-Maildir an, was beim Anlegen eines neuen Users automatisch in dessen Home-Verzeichnis übertragen wird, und qmail-local stellt Mails, die an den Systemuser adressiert sind, dorthin zu.

Nicht völlig überraschend zeigt sich aber, dass traditionelle Mailboxen in einem zentralen Verzeichnis wie z.B. /var/spool/mail derart fest im Betriebssystem verankert sind, dass es mehr als einen Klimmzug braucht, das System sauber an Maildirs anzupassen. Das fängt schon ganz vorne an:

useradd

Beim Anlegen von Benutzern wird standardmäßig eine (leere) Mailbox in /var/spool/mail/$USER angelegt, bzw. in dem Verzeichnis, das in der /etc/login.defs (siehe dort) via MAIL_DIR angegeben ist. Maildirs werden aber nicht unterstützt; genausowenig Mailboxen, die nicht in einem zentralen Verzeichnis liegen, sondern im Home-Verzeichnis des Benutzers. Dieses Anlegen lässt sich nur über die Einstellung CREATE_MAIL_SPOOL=no in der /etc/default/useradd abschalten – was hier ja durchaus Sinn ergibt, denn durch das Anlegen eines Maildirs in /etc/skel haben wir diesen Punkt ohnehin erledigt. (Mit herkömmlichen Mailboxen funktionierte das nicht, da /etc/skel ja die Vorlage für das Home-Verzeichnis des Users ist, die herkömmlichen Mailboxen aber zentralisiert und damit außerhalb des Home-Verzeichnisses liegen.)

$MAIL

Diese Umgebungsvariable wird von verschiedenen Programmen benutzt, um zu identifizieren, wo denn die Mails eines Users liegen. Hier fackelt CentOS 5 nicht lange – in /etc/profile steht hart kodiert:

if [ -x /usr/bin/id ]; then
        USER="`id -un`"
        LOGNAME=$USER
        MAIL="/var/spool/mail/$USER"
fi

Das ist für unsere Zwecke ergo völlig unbrauchbar. Die /etc/profile selbst anzupassen, empfiehlt sich nicht, weil die Änderungen sonst bei jedem Update des setup-RPMs (zu dem diese Datei gehört) hinfällig wären. Stattdessen bietet sich ein Einzeiler in /etc/profile.d an:

# cat /etc/profile.d/maildir.sh 
export MAIL=~/Maildir/

/etc/login.defs

Die man page der login.defs erklärt offenherzig:

Much of the functionality that used to be provided by the shadow password suite is now handled by PAM. Thus, /etc/login.defs is no longer used by programs such as: login(1), passwd(1), su(1)

Trotzdem ist die Datei noch da und wird von einigen Programmen genutzt. Sie sieht im Kopf wie folgt aus:

# *REQUIRED*
#   Directory where mailboxes reside, _or_ name of file, relative to the
#   home directory.  If you _do_ define both, MAIL_DIR takes precedence.
#   QMAIL_DIR is for Qmail
#
#QMAIL_DIR      Maildir
MAIL_DIR        /var/spool/mail
#MAIL_FILE      .mail

Fängt man erstmal an, an dieser Datei – vermutlich erfolglos – herumzubasteln, bekommt man wirklich graue Haare. Die naheliegendste Variante, nämlich den Eintrag QMAIL_DIR durch Entfernen des Rautenzeichens zu aktivieren, ist überraschenderweise keine gute Idee; dass die man page diese Einstellung gar nicht erwähnt, lässt schon tief blicken. So sieht’s dann nämlich aus:

# useradd dummy
configuration error - unknown item 'QMAIL_DIR' (notify administrator)

Fan-tas-tisch. Die NEWS-Datei der shadow-utils erklärt denn auch, dass die Einstellung aus der login.defs entfernt wurde – und zwar 2005. Interessanterweise kennt die man page auch die Einstellung MAIL_FILE nicht, sondern ausschließlich MAIL_DIR. Sie weiß aber auch gleich zu verkünden, dass nur usermod und userdel diese Einstellung benutzen – und useradd sowieso nicht. Was aber sehen wir in src/useradd.c?

      if (strcasecmp (create_mail_spool, "yes") == 0) {
              spool = getdef_str ("MAIL_DIR") ? : "/var/mail";
              file = alloca (strlen (spool) + strlen (user_name) + 2);
              sprintf (file, "%s/%s", spool, user_name);
              fd = open (file, O_CREAT | O_WRONLY | O_TRUNC | O_EXCL, 0);
              [...]
      }

Ist also glatt gelogen; useradd benutzt die Einstellung sehr wohl. Die man page von useradd bekräftigt das auch und erwähnt nicht nur MAIL_DIR, sondern auch MAIL_FILE und behauptet:

The MAIL_DIR and MAIL_FILE variables are used by useradd, usermod, and userdel to create, move, or delete the user´s mail spool.

Das ist nun wiederum auch gelogen, denn wenn MAIL_FILE statt MAIL_DIR gesetzt ist, macht useradd damit … überhaupt nichts. Und auch usermod und userdel, die beim Löschen eines Users dessen Mailbox aus dem zentralen mit MAIL_DIR angegebenen Verzeichnis löschen, unternehmen in Bezug auf Mail schlicht gar nichts, wenn MAIL_FILE gesetzt ist.

Nun, noch weiter in die Tiefe wollen wir hier nicht gehen. Belassen wir es dabei, dass das, was in der /etc/login.defs steht, das, was in der zugehörigen man page steht, das, was in den man pages von useradd, usermod und userdel steht, und schließlich das, was im Code der shadow-utils steht, erheblich voneinander abweicht und sich oftmals sogar widerspricht – kurz, das Ganze funktioniert nur dann sauber, wenn man exakt den traditionellen Standard benutzt: Mailboxen in einem zentralen Verzeichnis.

mailx

CentOS benutzt das mailx-Paket, um den Befehl mail bereitzustellen. Die meisten kennen den Befehl vornehmlich zu dem Zweck, um auf der Kommandozeile direkt Mails via Pipe versenden zu können (some-command | mail recipient@domain.tld). Allerdings ist mail auch ein Mailreader, der auf die Umgebungsvariable MAIL zurückgreift – was von daher erstaunlich ist, weil diese Variable gerade nicht zu denen gehört, die mail laut man page konsultiert:

Mail utilizes the HOME, USER, SHELL, DEAD, PAGER, LISTER, EDITOR, VISUAL and MBOX environment variables.

Trotzdem wird sie benutzt und zeigt dann auch gleich, wieso hier ohnehin Hopfen und Malz verloren ist:

$ mail
/home/jonas/Maildir/: Is a directory

Das mailx-Paket von CentOS hat also schlicht keinen Maildir-Support. Mit dem aktualisierten Paket, das sich in CentOS 6 findet, wird das offenbar kein Problem mehr sein, aber darum soll es hier ja nicht gehen.

bash

Hier endlich mal ein Lichtblick: Die bash unterstützt die Umgebungsvariable MAIL und kann auch korrekt mit Maildirs umgehen. Sie benutzt es, um standardmäßig alle 60 Sekunden nach neuen Mails zu suchen und den Benutzer zu informieren, und das klappt auch:

$ echo | mail $USER ; sleep 60 ; true
You have new mail in /home/jonas/Maildir/

PAM

Möchte man auch direkt beim SSH-Login über neue Mails informiert werden, so kann dies zeitgemäß mit pam_mail.so erledigt werden. Dazu braucht’s nur eine Zeile (danach sshd-Neustart nicht vergessen, sonst wirkt es nicht):

$ tail -1 /etc/pam.d/sshd 
session    optional     pam_mail.so dir=~/Maildir

Die Angabe von dir ist nötig, weil pam_mail.so ansonsten ganz traditionell in /var/mail nach einer Mailbox oder einem Maildir sucht (mit anderen Worten: Überraschung! Dass evtl. ein anderes Verzeichnis als MAIL_DIR in /etc/login.defs definiert ist, spielt überhaupt keine Rolle). Es erkennt automatisch, ob es eine Mailbox oder ein Maildir ist, denn eine Mailbox wäre ja eine Datei, während ein Maildir ein Verzeichnis wäre. So sieht es dann in der Anwendung aus:

$ ssh jonas@helium.uberspace.de
You have new mail in folder /home/jonas/Maildir.

Ich habe mal wieder mit der Polizei zu tun und bekomme dabei direkt die Frage beantwortet: Was sind das eigentlich für Leute, die ernsthaft auf Phishing reinfallen?

nach Angaben des Geschädigten, wollte sie am $Datum zu Hause eine Überweisung mittels $Bank Online-Banking durchführen. Bei der Durchschau ihrer E-Mails, stellte sie fest, dass sie eine Nachricht der $Bank erhalten hatte. In dieser Mail wurde sie aufgeforderten wegen einer angeblichen Sicherheitskontrolle, 70 TANs einzugeben. Gutgläubig kam sie dieser Aufforderung nach.

Wenig überraschend:

Am $Datum+2 stellte sie bei einer Kontrolle ihres $Bankkontos fest, dass durch Unbekannt am $Datum+1 – $Betrag € von ihrem Konto abgebucht wurden.

Und hier kommen nun wir ins Spiel: $Bank teilte nämlich im Zuge der Ermittlungen mit, dass die Überweisung von einer IP durchgeführt worden wäre, die in einem unserer Netze liegt. Das ist schon mal ausgesprochen merkwürdig: Die Server, die bei uns laufen, haben keine grafischen Oberflächen und damit maximal textbasierte Browser, mit denen jedes mir bekannte Onlinebanking unbenutzbar ist. Und jeder, der schon mal versucht hat, ein Tool zu schreiben, was sich automatisiert durch ein Onlinebanking-Webinterface durch“klickt“, weiß, dass das nicht so trivial ist, zumal bei vielen Banken inzwischen auch noch reichtlich Javascript zum Einsatz kommt. Aber natürlich bleibt es prinzipiell möglich, auch von einem Server ohne grafische Oberfläche aus so etwas durchzuführen; es ist einfach nur erfahrungsgemäß doch eher unwahrscheinlich, denn die meisten Angriffe sind schlicht gesagt platt und dumm. Aber vielleicht gibt es für $Bank ja ein fertiges Tool für die Script-Kiddies, wer weiß.

Eine theoretische Möglichkeit wäre noch, dass HBCI im Spiel war, was als Schnittstelle ja gerade für die automatisierte Nutzung gedacht ist. Allerdings muss ein Konto üblicherweise erstmal für die Nutzung per HBCI freigeschaltet werden, und ich habe gewisse Zweifel, ob jemand, der gutgläubig 70 TANs auf einer Phishing-Site eingibt, das getan hätte. Davon abgesehen erwähnt das Schreiben der Polizei explizit „Online-Banking“ und verliert kein Wort in Sachen HBCI.

Nun aber der eigentliche Knackpunkt: Die fragliche IP-Adresse liegt überhaupt nicht auf einem Server, sondern gehört zu einem IPMI-Modul. Solche Module, die sich bei Servern häufig direkt auf dem Mainboard befinden oder manchmal auch als Steckkarte nachgerüstet werden können, dienen der Fernwartung und können, vereinfacht gesagt, den Server remote ein- und ausschalten und bieten zudem einen Zugriff auf die Konsole, als wenn man Tastatur und Monitor angeschlossen hätte – sprich, man kann auf diese Weise bereits auf den Bootprozess des Servers zugreifen. Eins aber ist nach meinem Ermessen ausgeschlossen: Dass man auf so einem IPMI-Modul eigene Software so wie beispielsweise einen Webbrowser oder auch nur ein Script, das sich automatisch durch eine Seite klickt, installieren könnte. Das Mini-Betriebssystem dieser Module ist eben fest auf den Chip geflasht. Selbst wenn man über das IPMI-Modul Zugriff auf den Server erlangt hätte und von dort aus dann den Angriff auf das Konto der geschädigten Person gefahren hätte, wäre der Angriff aus Sicht der $Bank dann von der IP des Servers und nicht der IP des IPMI-Moduls gekommen.

Bliebe maximal noch IP-Spoofing. Das hätte aber durch arpwatch auffallen müssen, was ARP-Pakete, die für eine IP plötzlich eine andere MAC-Adresse als bisher kommunizieren, automatisch bemerkt und bei uns am Mirrorport des Uplinks mitläuft. Insofern ist also auch das keine ernsthafte Option, die als Erklärung taugen könnte.

Meine derzeitige Theorie ist ein Zahlendreher – wäre schließlich nicht das erste Mal.

Was schließlich jemanden reitet, 70 (!) TANs auf einer gefälschten Bank-Website einzugeben, erschließt sich mir einfach nicht. Nicht mal meine richtige Bank würde von mir verlangen, das zu tun – ganz davon abgesehen, dass sie schon lange auf automatisch per optischem Leser generierte TANs umgestellt hat, was nebenbei nicht nur sicherer, sondern auch viel bequemer ist. Mir ist einfach ein Rätsel, wieso wir im 21. Jahrhundert die ollen TAN-Listen nicht schon längst abgeschafft haben und uns immer noch mit Phishing herumschlagen müssen.

Wir betreiben seit längerer Zeit einen Storagecluster, auf dessen Basis wir sowohl dedizierte als auch virtuelle Server laufen lassen. Technisch läuft das so, dass die betreffenden Server ohne lokale Festplatten über PXE booten, mit Hilfe von gPXE (früher etherboot) dann per iSCSI ihre Root-Partition vom Storagecluster beziehen und das betreffende System booten. Das läuft 1a und sorgt für eine deutlich bessere Ressourcenausnutzung verglichen mit Failover-Clustern, bei denen pro produktivem Server ein Gerät als Spare daneben steht: Nur der Storagecluster muss redundant sein – die eigentliche Serverhardware nicht, beziehungsweise: Es reicht, für eine ganze Gruppe von Servern nur wenige Ersatzgeräte bereitzuhalten, denn wenn eine Hardware physisch ausfällt, kann man das zentral auf dem Storage liegende System problemlos auf beliebiger neuer Hardware booten lassen.

Allerdings kann einem das auch ziemlich auf den Fuß fallen, und zwar, weil sich „Performance“ in Sachen Datenübertragung primär in zwei Faktoren ausdrückt: Dem Durchsatz einerseits; der Latenz andererseits. In der Theorie war uns das allen bekannt, aber das plastischste Beispiel dafür haben wir erst im Zusammenhang mit dem Storagecluster gefunden – leider erst im produktiven Betrieb, wie es nun so ist. Insofern ist es auch ein Beispiel dafür, dass auch wir im Laufe unserer Arbeit noch so einiges dazulernen, und manches davon durchaus nicht im stillen Kämmerlein, sondern weil’s gerade brennt.

Um einen kurzen Exkurs für diejenigen zu machen, die mit Latenz und Durchsatz nicht viel anfangen können:

Man stelle sich eine vierspurige Autobahn vor. Es gibt keine Geschwindigkeitsbegrenzung. Die Autobahn kann also im Prinzip auch von Raketenautos befahren werden, und da sie vier Spuren hat, können sogar vier Raketenautos gleichzeitig darauf fahren. Oder auch ein paar mehr. Nur dann, wenn’s richtig viele werden – dann gibt es Stau. Die Latenz ist gering (man kann rasen), aber die Bandbreite begrenzt (nur vier Spuren).

Umgekehrt: Eine kilometerbreite Schotterstrecke. Selbst Raketenautos können hier nur 50 km/h fahren. Aber dafür können hier hunderte Autos in diesem Tempo nebeneinanderfahren – ohne dass es Stau gibt. Es gibt hohe Latenzen (die Straße ist schlecht), aber viel Durchsatz (sehr breite Straße).

Hat man nun mit einem übers Netzwerk erreichbaren Storage zu tun, so spielen hier zwei Komponenten eine Rolle: Einerseits die Netzwerkkarte; andererseits das Plattensystem, also die Kombination aus RAID-Controller und physischen Festplatten. Dass auf der Netzwerkebene manchmal nicht nur nur die Bandbreite („Ich hab DSL Soundsovieltausend!“), sondern auch die Latenz eine Rolle spielen kann, weiß jeder, der viel online zockt und hier gerne besonders schnelle Ping-Zeiten hätte – und dann für eine FastPath-Option von seinem DSL-Provider oft mit einem kleinen Aufpreis zur Kasse gebeten wird. Ganz klar: Will ich schnell vorankommen, spielt – bei leerer Straße – keine Rolle, ob mir zwei oder hundert Spuren zur Verfügung stehen, sondern die Straße muss eben gut ausgebaut und nicht nur geschottert sein.

Netzwerkkarten sind Paradebeispiele für Geräte, die äußerst niedrige Latenzen aufweisen (die Latenzen, die man sich mit FastPath beim DSL wegkaufen muss, entstehen erst an anderer Stelle). Die Bandbreite steht auf der Packung: 100 MBit/s (Fast Ethernet) oder 1000 MBit/s (Gigabit Ethernet) sind hier gängige Größen. Gigabit Ethernet heißt: Es können 1000 MBit pro Sekunde übertragen werden, also etwa 128 MB. Eine konventionelle Serial-ATA-Festplatte überträgt demgegenüber 300 MB pro Sekunde – also mehr als doppelt soviel. Aber dafür ist eine Festplatte ein Gerät, wo sich erstmal physisch irgendwelche Teile drehen, ein Schreib-/Lesekopf sich bewegen muss … und das heißt: Es gibt Latenzen. Die Zugriffsgeschwindigkeit „normaler“ Festplatten liegt heute so um die 10ms – was zwar schnell klingt, aber bei einer Netzwerkverbindung liegt die Latenz bei weit unter 1ms, ist also um eine satte Größenordnung kleiner.

Beim Einsatz von netzwerkbasiertem Storage könnte man also zunächst meinen, dass dann hier die schlechte Zugriffsgeschwindigkeit von Festplatten die geringe Latenz der Netzwerkkarte schnell vergessen lässt, und dass die ach so schicke Bandbreite einer Festplatte keine Chance hat, weil die Daten ja zuvor erst noch durch eine Netzwerkkarte gequetscht werden müssen, die deutlich weniger Bandbreite hat. Von beidem also das Schlechteste? Nein, nicht ganz. Denn zum einen verteilt der RAID-Controller im Storage die Zugriffe auf viele Festplatten, was deren hohe Latenz entschärft. Zum zweiten muss darauf sowieso nicht gewartet werden, denn der RAID-Controller besitzt einen eingebauten batteriegepufferten Cache, und es reicht, wenn sich zu schreibende Daten dort befinden. Physisch auf Festplatten schreiben kann der RAID-Controller die Daten auch später.

Insofern: Latenzprobleme gibt’s bei diesem Aufbau eher weniger. Aber eben schmalere Bandbreite. Würde man das Setup auf lokale Festplatten umstellen, hätte man bessere – aber dann auch mehr Latenz. Gute Voraussetzungen also für ein Vom-Regen-in-die-Traufe-Problem. Und so sieht es aus:

Der erste große Bereich bis zur senkrechten Linie 1 zeigt den Betrieb eines Servers im Storage-Cluster, also via iSCSI; die rote Kurve zeigt dabei vereinfacht gesagt, wieviel Prozent seiner Zeit der Server darauf gewartet hat, mit dem Plattensystem interagieren zu können. Hier ist deutlich erkennbar, dass diese Kurve zwar im Allgemeinen relativ niedrig ist, aber immer wieder hässliche Peaks hat – Peaks, in denen man ls -l eingibt und sich fragt: Was zur Hölle dauert hier so lange? Ein klares Zeichen für einen Engpass.

Die Linie 1 markiert nun den Moment, an dem wir den Server aus dem Storagecluster und auf ein baugleiches System mit lokalen Platten umgebaut haben. Kurz vorher zeigen zwei Peaks der roten Linie die zwei vorab durchgeführten Datensynchronisationen an; eine grobe am Abend und dann noch eine für die letzten Änderungen mitten in der Nacht.

Der Abschnitt zwischen 1 und 2 zeigt nun deutlich: Das war nicht nur vom Regen in die Traufe; das war vom Regen sogar bis in den Brunnen, ganz tief unten. Soll heißen: Obwohl die lokalen Festplatten eine wesentlich höhere Bandbreite haben, zieht ihre schlechtere Latenz das System noch viel massiver in den Keller. Auf der Haben-Seite steht, dass es im Grunde keine schlimmen Peaks mehr gibt. Umgekehrt muss zähneknirschend festgestellt werden, dass die Festplattenlast nun eigentlich einen einzigen durchgehenden Peak darstellt.

Wir haben während dieser Zeit bereits einen Replikationspartner aufgesetzt, der via DRBD den gesamten Datenbestand auf ein baugleiches System übertragen und aktuell gehalten hat – diesmal aber nicht auf ein RAID1, sondern auf ein RAID0. (Wem das nichts sagt: Beim RAID1 werden die Daten einer Festplatte 1:1 auf eine zweite gespielt. Beim RAID0 hingegen werden Schreibzugriffe auf beide Festplatten verteilt – finden also grob gesagt doppelt so schnell statt.)

Die Linie 2 zeigt nun den Zeitpunkt, an dem wir auf das andere Gerät – das mit dem RAID0 – umgeschaltet haben. Unmittelbar danach haben wir auf dem vorherigen Gerät das RAID1 ebenfalls durch ein RAID0 ersetzt und die Daten zurücksynchronisiert, was der Grund dafür ist, wieso die rote Kurve hier erstmal nicht signifikant runtergeht.

Aber dann: 6 Uhr morgens; Linie 3. Die Rück-Synchronisation ist abgeschlossen – und das System atmet förmlich auf. Es ist gut erkennbar, wie sämtliche Kurven den gesamten Freitag über keinerlei Peaks zeigen. Vor allem, wenn man das mit Montag, Dienstag und Mittwoch – also ebenfalls Werktagen – vergleicht, ist das ein massiver Fortschritt. Die Maschine ist nun effektiv rund um die Uhr zu 90% untätig, so wie es sein soll, um für plötzliche Lastspitzen, wenn mal wieder ein Kunde Fernsehwerbung schaltet, anständig gerüstet zu sein.

Gut erkennbar ist nebenbei der Peak, der mit 4 eingekringelt ist. Der lässt sich nicht vermeiden: So sieht das aus, wenn die tägliche Datensicherung einmal alle Daten auf dem Festplattensystem anschauen muss, um festzustellen, ob sie in die inkrementelle Sicherung neu übertragen werden müssen. Aber selbst dieser Peak ist, verglichen mit den Peaks an anderen Tagen zur gleichen Uhrzeit, fast schon zu vernachlässigen.

Für viele Unternehmen ist der Handel mit den Adressen der Kunden schon lange ein florierendes Geschäft, und genauso lange ärgere ich mich auch schon darüber (was auch der Grund dafür ist, dass Adresshandel mit unseren eigenen Kundendaten nicht in Frage kommt).

In den positiven Fällen wird man im Verlauf einer Bestellung ausdrücklich gefragt, ob man damit einverstanden ist, dass die Daten auch an andere Unternehmen weitergegeben werden. Das ist ohne Frage die kundenfreundlichste Variante, insbesondere, wenn es hierbei um eine Checkbox geht, die nicht automatisch vorausgewählt wird.

Was aber ist, wenn das nicht der Fall war? Diese Frage stellte ich mir, nachdem ich letzte Woche überraschend einen anderthalb Zentimeter dicken Katalog von Printus ins Haus flatterte (sofern man bei diesem Umfang noch von „flattern“ sprechen kann), einen Tag darauf noch einer vom gleichen Kaliber von Büro Plus, und noch einige Tage später ein weiterer Wälzer von Office Discount. Insgesamt also rund 5 Zentimeter, die jetzt meinen Altpapiercontainer freuen. Auffällig ist, dass alle drei Kataloge praktisch die gleiche Dicke haben und auch eine vergleichbare Aufmachung. Auch ist das Anschriftenfeld jeweils in identischem Aufbau und identischer Qualität bedruckt; nur die ID-Nummern, die offensichtlich meinen Datensatz identifizieren, unterscheiden sich. Was wiederum identisch ist, ist die dreistellige Nummer in der rechten unteren Ecke, die, wie ich nun weiß, die Datenquelle angibt – in meinem Fall die Firma Tintenfux, bei der ich kürzlich Toner bestellt habe.

Ich muss Printus und Office Discount zugute halten, dass beide Unternehmen auf meine Anfrage nach der Herkunft meiner Daten zügig und vollumfänglich geantwortet haben. Der anfängliche Eindruck, dass die Unternehmen doch irgendwie zusammengehören müssen, bestätigte sich zumindest für diese beiden (Büro Plus hat bisher nicht geantwortet): Die Antwortschreiben beider Unternehmen, die mich darum bitten, noch die dreistellige Nummer aus dem Adressfeld mitzuteilen, sind bis aufs Wort identisch.

Spannend hierbei finde ich, wenn Unternehmen HTML-Mails erstellen und dabei ein wenig stümperhaft arbeiten. Ein im Text eingefügtes „www.office-discount.de“ wird nämlich offensichtlich automatisch zu einem Link – nur dass ein Link, dem die Protokollangabe http:// fehlt, nicht etwa den Host dieses Namens aufruft, sondern eine Datei dieses Namens, relativ zum aktuellen Verzeichnis. Und weil das Mailprogramm „schlau“ ist und weiß, dass beim Versand einer Mail das relative Verzeichnis unter die Räder käme … notiert es das mit im Link, der somit lautet:

file:///\\schmid.local\VOL1\daten\pr\ks\ZAB\Datenschutzformulierungen\www.office-discount.de

Und bei Printus ist es natürlich genauso falsch, und – Überraschung – bis ins vierte Unterverzeichnis völlig identisch:

file:///\\schmid.local\VOL1\daten\pr\ks\KrampfeS\www.printus.de

Etwas Recherche später ist auch klar: Printus, Office Discount und Büro Plus haben auch jeweils die selben Geschäftsführer, und auf Nachfrage bestätigte mir auch Office Discount, dass auch Tintenfux selbst zur Unternehmensgruppe gehört:

Ihre Anschrift haben wir von der Firma tintenfux erhalten. Die Firmen büroplus, Hamburg; office discount, Neufahrn; Printus, Offenburg und tintenfux, Offenburg gehören zu einer Unternehmensgruppe, sind jedoch rechtlich selbständige Unternehmen. Wir gingen davon aus, dass die Angebotspalette auch aus den Katalogen für Sie von Interesse sein könnte.

Sonderlich weit ist meine Adresse also nicht gereist.

Die Frage, die sich mir nun stellte, war: Dürfen die meine Daten weitergeben? Denn wie Office Discount selbst schreibt: Auch wenn alle Unternehmen die gleichen Geschäftsführer haben, so sind es ja dennoch unterschiedliche juristische Personen, deren Datenaustausch den Vorgaben des Bundesdatenschutzgesetzes genügen muss.

Wie so oft poltern in Foren genervte Werbeempfänger und kloppen sich mit Hobby-Anwälten, wobei sich das Niveau der Diskussion oft auf „Ich glaube“ und „Es gab da mal ein Urteil“ und „Mein Bekannter hat gesagt“ reduziert und das, was dann wirklich Klarheit bringen könnte, außen vor bleibt: Nämlich die Quelle. Deshalb bringe ich die jetzt. Erstmal den rohen Gesetzestext, § 28 Abs. 3a BDSG:

(3a) Wird die Einwilligung nach § 4a Absatz 1 Satz 3 in anderer Form als der Schriftform erteilt, hat die verantwortliche Stelle dem Betroffenen den Inhalt der Einwilligung schriftlich zu bestätigen, es sei denn, dass die Einwilligung elektronisch erklärt wird und die verantwortliche Stelle sicherstellt, dass die Einwilligung protokolliert wird und der Betroffene deren Inhalt jederzeit abrufen und die Einwilligung jederzeit mit Wirkung für die Zukunft widerrufen kann. Soll die Einwilligung zusammen mit anderen Erklärungen schriftlich erteilt werden, ist sie in drucktechnisch deutlicher Gestaltung besonders hervorzuheben.

(Was nun folgt, ist keine Rechtsberatung. Dazu wäre ich als Nicht-Jurist auch nicht befugt. Es ist vielmehr eine Auseinandersetzung mit einem Gesetzestext auf Basis gesunden Menschenverstands, nicht auf Basis juristischer Qualifikation.)

Zunächst einmal für mich ein wenig überraschend: Es ist durchaus legitim für ein Unternehmen, die Einwilligung in die Weitergabe von Adressen nicht explizit einholen zu müssen. Es scheint vielmehr ausreichend, in seinen Vertragsbedingungen zu vermerken, dass der Kunde mit Auftragserteilung auch in eine Adressweitergabe zu Werbezwecken einwilligt – zumindest sofern die Schriftform zum Einsatz kommt.

Etwas fraglich erschien mir die Definition der Schriftform: Sind AGB, die auf der Rückseite eines Papierformulars aufgedruckt sind, anders zu behandeln, als AGB, die sich – oft nur sehr versteckt – auf einer Website finden? Nun, offensichtlich ist das tatsächlich so. Der Gesetzestext unterscheidet hier nun mal ausdrücklich zwischen der Schriftform (für die die Vorgabe, die Einwilligung in eine Datenweitergabe deutlich hervorzuheben, wohl unzweifelhaft ist) und „anderen Formen“, wobei bei jenen anderen Formen die elektronische noch eine Sonderstellung einnimmt. Die Pflicht zur „schriftlichen Bestätigung des Inhalts der Einwilligung“ dürfte daher nach meinem Verständnis beispielsweise bei einer telefonischen Einwilligung zum Tragen kommen, wo es auch durchaus Sinn ergibt, weil eine telefonische Einwilligung anders kaum nachgewiesen werden könnte.

Die Anforderungen an eine elektronische Einwilligung sind dann aber dementsprechend erstaunlich gering: Sie muss protokolliert werden (kein Problem – ohne AGB-Bestätigung würde ja sowieso die ganze Bestellung nicht ausgeführt), der Inhalt muss abrufbar sein (kein Problem – AGB steht im Web), und der Einwilligung muss widersprochen werden können (kein Problem – einfach noch ein Feld in der Datenbank). Über eine gesonderte Hervorhebung ist hier nichts zu lesen.

Damit wird in dieser Frage aus meiner Sicht schwammiges Terrain betreten. Denn ich habe ja nun gerade keine Einwilligung in der Form „[X] Meine Daten dürfen weitergegeben“ erteilt, sondern lediglich „[X] Ich akzeptiere die AGB“ angeklickt. Für die Schriftform sieht der Gesetzestext einen ausdrücklichen Passus für den Fall vor, dass die Einwilligung nicht ausdrücklich im Bestellformular steht, sondern in den AGB „versteckt“ wird. Aus welchem Grund sollte das gleiche Prinzip bei AGB auf einer Website nicht gelten?

An diesem Punkt wird wohl nur ein Rechtsanwalt verbindlichere Informationen zur Auskunft geben können, wobei sich selbst juristisch ausgebildete Personen in meinem Bekanntenkreis in der Beurteilung nicht sicher sind. Es läge also durchaus im Bereich des Möglichen, dass der von mir durchgeführte Vorgang schon überhaupt nicht als eine Einwilligung im Sinne des Gesetzes betrachtet werden kann, denn die Einwilligung wurde mir ja sozusagen „untergeschoben“. In ähnlich gelagerten Fällen wie beispielsweise der Zusendung eines Newsletters wurde inzwischen oft genug geurteilt, dass die Einwilligung dazu eben gerade nicht in AGB untergebracht werden darf, sondern explizit angefragt werden muss, z.B. mit einer Checkbox – und diese Checkbox darf auch nicht automatisch vorausgewählt sein.

Wenn doch schon für die Zusendung eines eigenen Newsletters nach einer Bestellung recht hohe Hürden aufgestellt werden, so würde mich doch sehr wundern, wenn eine Weitergabe von Daten an andere viel geringere Hürden besitzt; handelt es sich hierbei doch um einen weitaus schwerwiegenderen Eingriff in meine Datenhoheit.

So oder so muss ich zumindest bei den Vorgaben zur Schriftform immer ein wenig schmunzeln: Offensichtlich geht der Gesetzgeber ganz pragmatisch davon aus, dass die meisten Leute die AGB ohnehin maximal kurz überfliegen. Andernfalls wäre mir nicht erklärbar, wieso einzelne Passagen von Gesetz wegen besonders hervorgehoben werden müssen.

Festzuhalten bleibt aber: Kundenfreundlich ist eine untergeschobene Einwilligung zur Weitergabe der Adressen in keinem Fall. Insofern habe ich wenig Verständnis dafür, wenn Tintenfux nun „bedauert“, dass ihr Vorgehen bei mir zu „Verärgerung“ geführt hat. Dass Kunden es typischerweise nicht wünschen, dass ihre Daten zum Zweck der Werbung weitergegeben werden, ist ja nun kein Geheimnis. Wäre Tintenfux und mit ihm die ganze Printus-Gruppe wirklich daran interessiert, Kunden nicht zu verärgern, müssten sie eben vielleicht einfach mal Zufriedenheit über Profit stellen.

Sehr geehrter Herr Krings,

in Ihrem Beitrag Das Ende des E-Privilegs in The European vom 04.01.2011 ziehen Sie eine Parallele zwischen heute bereits stattfindender Spamfilterung einerseits und der von führenden Politikern geforderten Einführung von Internetsperren und -filtern andererseits. Leider greifen Sie direkt im ersten Absatz schon zu den so oft als Totschlagargument genutzten „Darstellungen von Kindesmissbrauch“, was eine wirklich sachliche Debatte durch eine völlig unnötige Emotionalisierung des Themas leider nicht gerade einfach macht.

Dass Sie nun die Parallele zwischen diesen beiden Themen ziehen und daraus argumentativ abzuleiten versuchen, dass, wer Spam filtert, auch Kinderpornos filtern müsse, kann ich als Systemadministrator, der in beiden Bereichen durchaus mit den erforderlichen technischen Mitteln vertraut ist, so nicht stehenlassen. Die Unterschiede zwischen beiden Arten von Eingriffen in den Datenverkehr könnten kaum größer sein.

Zunächst einmal geht es bei allen Diskussionen um Internetsperren und -filter um eine Einflussnahme,

• die staatlich verordnet und kontrolliert wird,
• die auf geheimen Sperrlisten basiert, und
• die für das gesperrte Ziel nicht nachvollziehbar ist.

Damit unterscheidet sie sich in allen wesentlichen Punkten völlig von der Einflussnahme der Provider auf den E-Mail-Verkehr.

Zunächst einmal geschieht Spamfilterung in aller Regel mitnichten „heimlich“, wie Sie durch die Formulierung „teilweise ohne Wissen ihrer Kunden“ suggerieren. Vielmehr ist in der überwiegenden Mehrheit aller mit Providern geschlossener Verträge Spamfilterung ein integraler Vertragsbestandteil, der zudem von Providern auch mitnichten tief in den AGB versteckt wird, sondern offensiv beworben wird und für viele Kunden sogar ein wichtiges Entscheidungskriterium darstellt.

Weiterhin ist diese Art der Filterung nicht staatlich verordnet, sondern eine freiwillige Entscheidung. Selbst wenn sich ein Kunde möglicherweise nicht aktiv für eine Spamfilterung entschieden hat, sondern diese eben einfach eines von vielen Ausstattungsmerkmalen des geschlossenen Vertrags war, so bieten doch praktisch alle Provider die Möglichkeit, jene Spamfilterung für einzelne Kunden zu deaktivieren. Sollte dies nicht möglich sein, steht es jedem immer noch frei, einen Provider zu wählen, der keine Spamfilterung vornimmt, oder auch schlicht und einfach seinen eigenen Server im Internet zu betreiben und damit selbst bis ins letzte Detail über eine Filterung selbst zu entscheiden.

Spamfilterung geschieht außerdem nicht geheim. Sie geschieht im Fall von DNS-basiertem Blacklisting, wie Sie es in Ihrem Artikel ansprechen, anhand öffentlicher Datenbanken, die nicht nur Auskunft darüber geben, welche IP-Adressen als „spammy“ bekannt sind, sondern oft auch, warum. Auf diese Weise kann jeder Mailserverbetreiber jederzeit nachprüfen, ob er auf einer dieser Blacklists steht; er kann dafür eine Begründung abrufen; und vor allem: Er kann bei seriösen Blacklists durch ein Delisting auch aktiv darauf Einfluss nehmen. Bei anderen Arten von Spamfilterung stehen objektiv nachprüfbare Verfahren dahinter, die ebenfalls öffentlich sind.

Schließlich und endlich ist Spamfilterung nachvollziehbar, und zwar dergestalt, dass ein Empfänger eine E-Mail zwar erhält, sie aber gesondert markiert ist oder in einen gesonderten Ordner abgelegt wird. Oder aber die E-Mail wird abgelehnt; in diesem Fall erhält der Absender aber eine entsprechende Benachrichtigung (Bounce) zurück, die ihn darüber informiert, dass seine E-Mail nicht zugestellt wurde.

Einer der Hauptkritikpunkte an den geforderten Internetsperren und -filtern ist, dass der Betreiber einer legalen Website, die zu Unrecht auf die Sperrliste gelangt ist (und die Erfahrungen aus anderen Ländern zeigen, dass das nicht nur im Einzelfall passiert), keine Möglichkeit hat, davon zu erfahren und somit auch nicht, sich juristisch dagegen zu wehren: Weder wird er darüber informiert, dass die Kommunikation mit einem Seitenbesucher unterbunden wurde, noch kann er durch Abfrage einer Datenbank erfahren, ob er auf der Sperrliste gelandet ist. Verstehen Sie mich nicht falsch: Nicht, dass es im Falle von Kinderpornographie wünschenswert wäre, solche Listen öffentlich zu führen – aber es ist ein weiterer Punkt, der verdeutlicht, dass Sie in Ihrem Artikel Äpfel mit Birnen vergleichen.

Sehr geehrter Herr Krings, es besteht ein himmelweiter Unterschied zwischen einer staatlich verordneten Informationskontrolle und einer vertraglich vereinbarten Spamfilterung, die vom Kunden ausdrücklich erwünscht und in seinem Auftrag durchgeführt wird. Schon an diesem Punkt ist eigentlich jedes weitere Argument überflüssig: Ihre Parallele funktioniert nicht. Sie funktionierte nur in dem einen Ausnahmefall, dass ein Provider den E-Mail-Verkehr seiner Kunden ohne deren Wissen oder sogar gegen deren Weigerung beeinflusst. Solches Providerhandeln ist ohne Frage strafbar, wurde aber auch immer schon entsprechend gerichtlich geahndet. Mit der breiten Realität der Spamfilterung in marktüblichen Providerbeziehungen hat Ihr Argument hingegen absolut nichts zu tun.

Sie schreiben schließlich, Provider sortierten Post vor, und zwar „im Gegensatz zur Deutschen Post oder anderen analogen Postdienstleistern“. Hier ist Ihnen sicherlich nur versehentlich entgegangen, dass die Bundesagentur für Arbeit – also eine Einrichtung des Bundes – bereits seit Monaten alle an sie gerichteten Briefe durch die Deutsche Post öffnen, digitalisieren und sortieren lässt und das unter dem Begriff der „eAkte“ offensiv als eine Errungenschaft bewirbt, ganz entgegen der Unkenrufe von Datenschützern, die damit genauso einen Verstoß gegen das Postgeheimnis sehen, wie Sie es offensichtlich in der Spamfilterung allgemein sehen. Ganz ehrlich? Wenn ich die Wahl hätte, ob ein Mensch meine Post öffnet und sortiert und dabei auch durchaus Kenntnis von ihrem Inhalt nehmen kann, oder ob meine Mails durch eine Maschine verarbeitet werden, deren Programmcode offen einsehbar ist und die anhand von objektiven Kriterien und öffentlicher Datenbanken über die Verarbeitung entscheidet, dann fiele meine Wahl klar zugunsten der Maschine aus, die ungeachtet staatlicher Einflussnahme nach meinen Interessen filtert.

Die Providerprivilegierung ist von daher mitnichten überholt. Spamfilterung ist ein Paradebeispiel für effektive und pragmatische Problemlösung, die von Anbietern und Kunden gewünscht wird. Sie als vermeintlichen Beleg für eine grundsätzliche Filterung und Sperren aller Art heranzuziehen, zeugt in meinen Augen von wenig Sachkenntnis und einer gehörigen Portion Populismus. Lassen Sie doch die Kinderpornografie als Argument einfach mal weg und versuchen Sie dann noch, sachlich überzeugend für providerbasierte Sperren und Filter zu werben. Ich bin gerne Ihr Gesprächspartner.

Freundliche Grüße,
Jonas Pasche

Die letzten zwei Tage waren schlimm. Der eigentliche Plan war, den beiden Knoten unseres größten Storage-Clusters (2 x 16 Festplatten im DRBD-Verbund) angesichts gestiegenen Datendurchsatzes zwei zusätzliche GBit-Netzwerkschnittstellen zu verpassen, um die Bandbreite für iSCSI zu erhöhen.

Der Einbau der zusätzlichen Netzwerkkarten verlief auch prima und von Kunden unbemerkt – da bei einem manuellen Failover des aktiven Knotens im Storagecluster die angeschlossenen Systeme maximal 5-10 Sekunden kurz bei Plattenzugriffen hängen, fällt nicht mal mitten am Tag ein solcher Failover auf.

Bei der Konfiguration der zusätzlichen Netzwerkschnittstellen hörte der Spaß dann leider auf. Das eingeplante Bonding ließ sich um’s Verplatzen nicht im laufenden Betrieb aktivieren; ein Netzwerk-Restart tat sowohl DRBD als auch Heartbeat alles anderes als gut; noch ein menschlicher Fauxpas dazu … und schon hatten wir alle Hände voll zu tun damit, um den gesamten Cluster wieder zu stabilisieren. Doch darum soll es hier nicht gehen. Im Lauf des heutigen Vormittags haben wir im Team unsere Pläne und unsere Erfahrungen vom Vortag durchgesprochen und uns schließlich dazu entschieden, anstelle von Bonding die zusätzliche Ports über einen zusätzlichen Switch laufen zu lassen und einige der besonders iSCSI-intensiven Knoten dann dorthin zu verlagern. Und damit fingen die Unwägbarkeiten dann erstmal so richtig an.

Alle angeschlossenen Hosts haben keine lokalen Festplatten. Sie booten via PXE direkt aus dem Cluster und bekommen via iSCSI ihre Root-Partition. Der PXE-Server befindet sich dabei mit je einer Schnittstelle an jedem Switch, kann also beide Netzbereiche bedienen.

Wir haben nicht schlecht gestaunt, als der PXE-Bootvorgang – der immer mit einem DHCP-Request beginnt – am einen Switch so problemlos läuft wie immer; versuchten wir es jedoch am anderen Switch, so dauerte es eine halbe Minute, bis per DHCP eine IP bezogen wurde. Über PXE wird dann gPXE (früher Etherboot) geladen, was dann auch iSCSI-fähig ist und das eigentliche System einbindet. Dafür macht es selbst auch noch einmal einen DHCP-Request – und der schlug (dank eines kürzeren Timeouts) schließlich ganz fehl. Der Server bootet nicht.

Nun hatten wir bereits via tcpdump herausgefunden: Die DHCPDISCOVER-Pakete kommen gar nicht erst am DHCP-Server an – erst nach besagter halber Minute. Ein Serverproblem ist von daher auszuschließen. Der DHCP-Request wird hier direkt von der Netzwerkkarte gestellt – ist also auch nichts, wo man einfach mal eben --verbose oder --debug angeben könnte. Sollte etwa … der Switch?

Problematisch ist immer, wenn man es nicht mit einem konkreten Programm oder einer konkreten Fehlermeldung zu tun hat. Wonach sollte man googlen? Switch? DHCP? Timeout? Alles Begriffe, die viel zu generisch sind, um (auch in Kombination) vernünftige Treffer zu liefern. Aber nach längerem Stöbern fanden sich in der Tat Beschreibungen wie

A little further analysis with other devices has determined that the SFE2000 simply is not passing every DHCP Discover request. It seems to work every 4th or 5th request, the others being dropped

Hat zwar nichts mit unserem Switch-Modell zu tun, aber ein Anhaltspunkt, dass ein Problem jener Art existiert. Jemand anders meldet:

dhcpcd not sending DHCPDISCOVER/-REQUEST at boot, timing out

in dessen Diskussionsverlauf schließlich ein vages

On a switched network I would be suspect of the switch just in case it is being clever somehow

zutage tritt. Und schließlich:

Checking with the comms gurus they said to check for a switch feature called „portfast“. Google finds quite a bit on it if you are not familiar with it already.

Klare Sache, „checking with the comms gurus“ werde ich ab sofort in meinen Sprachgebrauch mit aufnehmen, und „portfast“ hat sich als genau das richtige Stichwort herausgestellt – obwohl alle Beteiligten angaben, das würde nur Cisco- und HP-Switche betreffen, während wir einen 3com haben.

Fürs Protokoll: Es ist die Kommunikation aus eingeschalteten Spanning Tree Protocol und ausgeschaltetem Portfast. Nicht, dass wir das Spanning Tree Protocol benutzen würden oder wollten – es war einfach standardmäßig eingeschaltet. Und es sorgt dafür, dass beim Aktivieren des betreffenden Switchports zunächst eine Art „Lernphase“ einsetzt, bevor dann – etwa 30 Sekunden später – die ersten Pakete tatsächlich über den Port laufen können.

Aus genau diesem Grund kommen die DHCPDISCOVER-Requests auch erst so spät durch – und für gPXE sogar zu spät. Kaum dass wir Spanning Tree deaktiviert hatten, lief alles genauso fix wie am anderen Port. Durchatmen, weitermachen.

Heute lag eine Anfrage einer Kundin auf meinem Tisch, die eine Datenbank voller MySQL-Tabellen hatte. Der Zeichensatz der Datenbank und aller Tabellen und Spalten war latin1_german_ci. Dumm nur, dass die Applikation überall UTF8-kodierte Werte reingeschrieben hat – was hier und da so ein bisschen funktionierte, an anderen Stellen aber so gar nicht. In phpMyAdmin wurden alle Umlaute aber fehlerhaft dargestellt, und damit stand dann auch fest, dass da einfach Murks passiert war (denn wir wissen ja, phpMyAdmin hat immer recht, siehe hier).

Nun ist aber das Problem, dass die nachträgliche Änderungen der Spalten in phpMyAdmin erstens mühselig ist und zweitens auch gar nichts bringt, weil MySQL dabei die Inhalte der Spalten auch gleich (in seine Sinne) korrekt konvertiert. Die einzige Möglichkeit ist, die Spalte auf eine binäre Spalte vom Typ BLOB zu ändern, weil hierbei die Zeichensatzangabe verlorengeht, was wir hier auch explizit wollen – sie ist ja falsch. Das ist aber noch viel unglaublich aufwendiger.

Auf der Shell lässt sich das Problem aber schließlich trivial lösen. Zunächst dumpen wir die gesamte Datenbank, und dabei geben wir an, dass latin1 als Zeichensatz verwendet werden soll – auf diese Weise dumpt MySQL die Daten so (falsch), wie sie in den Spalten stehen; da sind sie ja als latin1 kodiert. Dann ändern wir alle Kollations- und alle Zeichensatzangaben im SQL-Dump von latin1 auf utf8 – wobei die Daten, genauer gesagt die Bytes aber ja unverändert bleiben. Anschließend wird alles wieder in MySQL gefüttert.

Und so sieht’s aus (es wird eine .my.cnf mit hinterlegten Zugangsdaten vorausgesetzt, damit keine Passworteingabe erfolgen muss):

mysqldump --default-character-set=latin1 mydatabase mydatabase.sql

cat mydatabase.sql |
  sed 's/latin1_german_ci/utf8_general_ci/g;' |
  sed 's/latin1/utf8/g;' |
  mysql mydatabase

Fertig! In phpMyAdmin sicherheitshalber kontrollieren, dass alle Spalten als utf8 kodiert sind und gleichzeitig auch die Umlaute korrekt angezeigt werden. Und da wir die Zeichensatzänderung nicht bei Dumpen, sondern beim Einspielen des Dumps „on the fly“ machen, liegt mit mydatabase.sql dann auch gleich noch ein Backup des Originalzustands vor, falls alles schiefgehen sollte.

Problematisch wird die Sache nur, wenn nur einige Tabellen oder – noch schlimmer – nur einige Spalten einiger Tabellen falsch kodiert sind. In diesem Fall wäre dann doch eher professionelle Hilfe gefragt – oder viel Handarbeit. ;-)

Irgendwann, in hoffentlich noch recht vielen Jahrzehnten werde ich zurückblicken können und beurteilen, in welchem Jahr die Welt gekippt ist. Ich meine damit den Zeitpunkt, an dem öffentliche Meinung und Selbstjustiz ein stärkeres Gewicht gewannen als die Rechtsstaatlichkeit.

Heute ist so ein Tag, an dem ich das Gefühl habe: Vielleicht wird das der Tag sein, an den ich später zurückdenken werde und im Schaukelstuhl sitzend seufzen werde: Damals hat alles angefangen.

MasterCard wickelt keine Zahlungen an WikiLeaks mehr ab.

Nehmen wir einfach mal dieses plakative Beispiel. Man kann „MasterCard“ nun, einige Stunden später, auch durch „VISA“ ersetzen. Oder durch „PayPal“, von denen ohnehin niemand etwas anderes erwartet hätte. Oder durch „Postfinance“. Aber bleiben wir mal bei MasterCard. Deren Sprecher Chris Monteiro ließ verlauten:

MasterCard rules prohibit customers from directly or indirectly engaging in or facilitating any action that is illegal

Das klingt für sich genommen eigentlich nicht schlimm; geradezu nachvollziehbar. Die Sprengkraft steckt in der Implikation, dass WikiLeaks illegal sei. Und hier beginnt die Geschichte, ein echter Aufreger zu werden.

WikiLeaks ist nämlich durchaus nicht illegal. Zumindest hat bisher niemand ein Gesetz nennen können, gegen das WikiLeaks verstößt. Es wurde auch keine Anklage wegen irgendetwas erhoben, geschweige denn ein Verfahren geführt oder gar ein Urteil erwirkt. Und auf welcher Basis denn bitte auch? Geheimnisverrat? Unsinn. Den Geheimnisverrat hat nämlich nicht WikiLeaks begangen, sondern derjenige, der WikiLeaks die Dokumente zugespielt hat. Ich bin kein Experte im amerikanischen Recht, aber zumindest was das deutsche Recht angeht, hat Udo Vetter eine lesenswerte Bewertung verfasst.

Insofern ist die Ansage MasterCards nichts weiter als eine unternehmerische Meinung. Und steht damit nicht alleine da: Ein Senator ruft Webhoster dazu auf, ihren Kunden den Saft abzudrehen, wenn jene WikiLeaks-Inhalte hosten. Sarah Palin fordert öffentlich dazu auf, Julian Assange als Terroristen zu jagen und WikiLeaks zu hacken. Kurz: Gewählte Volksvertreter rufen dazu auf, Vertragsbruch und illegale Handlungen gegenüber einer Organisation auszuüben.

Ich stehe hier nun etwas fassungslos und frage mich:

Wenn all diese Leute das Treiben von WikiLeaks für illegal halten, wieso führen sie dann kein ordentliches Gerichtsverfahren? Haben sie kein Vertrauen darin, dass ihr Rechtsstaat funktioniert?

Ich bin der Überzeugung, sie haben vielmehr Furcht davor, dass der Rechtsstaat am Ende möglicherweise schlicht und einfach zu einer anderen rechtlichen Bewertung kommen könnte als sie selbst. Und in der Furcht, am Ende von höchster Stelle gesagt zu bekommen, dass man im Unrecht ist, wählt man lieber den Weg der medialen Hetze und der Diskreditierung – dass Julian Assange, der Mann hinter WikiLeaks, sich derzeit Vergewaltigungsvorwürfen ausgesetzt sieht, macht es nicht besser: Egal, ob sich diese Vorwürfe – die ja nun so gar nichts mit WikiLeaks zu tun haben – als wahr oder als haltlos herausstellen, so helfen sie doch mit, die Person Assanges öffentlichkeitswirksam zu diskreditieren, und WikiLeaks im Nebensatz gleich mit.

Ich habe wenig Schwierigkeiten damit, wenn irgendwelche Leute dazu aufrufen, WikiLeaks und die unterstützenden Personen und Organisationen zu boykottieren. Jeder darf seine Meinung äußern, auch wenn sie dämlich ist; dafür haben wir hierzulande genauso wie in Amerika Meinungsfreiheit. Ich habe aber große Schwierigkeiten damit, wenn gewählte Volksvertreter sich dahingehend äußern, die sich schon allein durch ihre Wahl einer besonderen Verpflichtung, dem Rechtsstaat und nicht der Selbstjustiz die Treue zu halten, ausgesetzt sehen sollten.

Ich habe weiterhin wenig Schwierigkeiten damit, wenn ein Unternehmen sich im Großen und Ganzen nicht dafür interessiert, mit wem es Geschäfte macht, sondern sich einzig und allein darauf stützt, ob die Geschäfte legal sind oder nicht: Pecunia non olet; Geld stinkt nicht. Anders wäre mir nicht erklärbar, dass MasterCard keine Schwierigkeiten damit hat, die Mitgliedsbeiträge für den Ku-Klux-Klan zu verarbeiten – einer Organisation, die auf ihrem Beitrittsformular unverholen fordert, zu unterschreiben:

I am white and not of racially mixed descent. I am not married to a nonwhite. I do not date nonwhites no do I have nonwhite dependents.

Ich betone: Ich kann damit leben, wenn ein Unternehmen wie MasterCard sagt: Die Organisation ist nicht verboten; also sehen wir auch keinen Grund, warum wir keine Geschäfte mit ihnen machen können sollten. Freiheit ist immer die Freiheit der Andersdenkenden – selbst wenn mir persönlich bei der Lektüre der KKK-Website die Galle hochkommt: Das muss aushaltbar sein; meine Sichtweisen passen auch nicht jedem.

Wenn nun aber MasterCard sich von sich aus auf das dünne Eis begibt, Geschäftsbeziehungen mit Organisationen abzubrechen, die sie für illegal halten, ohne dass sie im juristischen Sinne für illegal erklärt wurden, dann ist das Gleichheitsprinzip damit gebrochen. Wenn MasterCard einzelne Kunden aufgrund unternehmerischer Entscheidungen ablehnt, dann treffen sie damit auch eine Aussage über alle verbleibenden Kunden. Und ich stehe reichlich verständnislos da, wenn ein Unternehmen keine Schwierigkeiten darin sieht, mit einer rechtsradikalen, rassistischen Organisation Geschäfte zu machen, sich aber gleichzeitig einem ganz simplen Organ der Presse, so umstritten es auch sein mag, verweigert. So ist es nun mal: Wer andere nicht bewertet, über den fälle ich auch kein Urteil. Wer hingegen anfängt, seine Kunden nach einer unternehmenseigenen Ethik zu bewerten, der muss damit leben, dass ich auch meine eigene Kundenbeziehung mit ihm einer Ethikprüfung unterziehe – nämlich meiner. Und die fällt für MasterCard nach dem heutigen Tag nicht sehr positiv aus.

Es juckt mir in den Fingern, meine MasterCard zu kündigen – die private wie auch die geschäftliche. Einerseits bin ich mir völlig im Klaren darüber, dass das nichts ändern wird und ich mir von daher vermutlich nur selbst schade, nicht zuletzt, weil viele es sich gar nicht erlauben können, einfach so auf eine Kreditkarte zu verzichten und es schon von daher keine allzu große Kündigungswelle geben wird – was MasterCard sicher auch weiß. Andererseits sagt das trotzige Kind in mir: Na und? Wenn ich nicht anfange; wer sollte es dann tun? Wer sollte mir folgen, wenn ich selbst den Schritt nicht gehe? „Politik mit dem Einkaufskorb machen“ ist ein Satz, der mich schon seit der Schulzeit fasziniert, nicht zuletzt, weil er mir ein Gefühl von Macht gibt, in einer Welt, in der ich mich inzwischen oft machtlos fühle. Aber diene ich dann nicht letzten Endes vielmehr meinem eigenen kleinen wohligen Gefühl als der Sache selbst; als dem Anliegen, rechtsstaatliche Mittel vor ein öffentlichkeitswirksames „Das ist zwar nicht verboten, aber es ist BÄH“ zu stellen? Oder ist es doch etwas, womit ich mir ein Stück Freiheit sichere – oder zurückhole?

Und schließlich: Ich richte mich ja gegen MasterCard, nicht gegen das „Prinzip Kreditkarte“ an sich. Was aber bleibt zu tun, wenn es zwar einen „freien Markt“ aus mehreren Kreditkarten-Anbietern gibt, aber jeder dieser Anbieter meint, seine Marktmacht politisch einsetzen zu müssen? Was, wenn es keine Alternativen gibt? Mit PayPal will ich sowieso schon lange nichts mehr zu tun haben, schon aufgrund der entsetzlichen Kundenbetreuung und der Kontensperrungen nach Gutsherrenart, die jetzt bei WikiLeaks einfach nur ihre Fortsetzung finden und mich nicht weiter wundern. Irgendwann stellt sich dann doch die Frage: Wenn sich alle Kreditkartenunternehmen (für mich) ins Aus geschossen haben; wenn auch die „normalen“ Banken dazu übergehen, Kunden auch ohne juristische Begründung abzulehnen – wer bleibt denn dann noch?

Ich habe etwas Sorge, mich hier in Paranoia und Aktionismus zu verrennen. Deshalb habe ich bisher keine Kündigung an MasterCard abgeschickt, sondern möchte erst noch drüber schlafen.

Ein Gefühl, dass heute ein wichtiger Teil eines gesellschaftspolitischen Umschwungs stattfand, der mir nicht gefällt, bleibt.