PHPGangsta - Der praktische PHP Blog

In der iX 11/2009 fand ich einen sehr interessanten Artikel zum Thema „Zu sorglose Speicherung und Weitergabe von IP-Adressen?“. Wir als Informatiker machen uns da eher selten Gedanken drüber, und lassen einfach die Standard-Einstellungen der Software so wie sie sind. Dass dies aber ein Problem sein kann (oder werden kann) zeigt der Artikel recht deutlich.

„IP-Adressen sind nicht personenbezogen“ war mein erster Gedanke, denn es gibt für mich keine Möglichkeit, aus einer IP-Adresse den Namen oder Anschrift des Benutzers herauszufinden.
Das stimmt allerdings nur so lange wie wir über dynamische IP-Adressen reden. Wenn Privatpersonen statische IP-Adressen besitzen, sieht es schon etwas anders aus, denn darüber kann man eine spezielle Person längere Zeit beobachten, auch wenn man nicht direkt an seinen Namen herankommt. Auch bei Firmen ist die Situation eine andere, denn diese kaufen häufig ganze IP-Bereiche, und die Besitzer von IP-Bereichen sind z.B. im RIPE-Register einsehbar, also zurückverfolgbar. Zwar nicht auf eine Person, aber auf eine Firma.

Doch wir wissen auch, dass die Provider (zumindestens einige) Auskunft geben, wem eine bestimmte IP-Adresse zugeteilt wurde, Gott sei Dank nicht jedem Anfragenden, aber mindestens die Staatsanwaltschaft sowie die Vertreter der Rechteinhaber können das mittlerweile, je nachdem an welchen Provider man gerät und wie er zu diesem Thema steht. Da wir aber nicht trennen können zwischen dynamischen und statischen IP-Adressen, müssen wir eher davon ausgehen, dass sie personenbezogen sind, konsequenterweise müssen wir alle IPs gleich behandeln.

Warum sind personenbezogene Daten etwas besonderes? Wir als Entwickler und Betreiber müssen dann besondere Schutzmaßnahmen ergreifen, damit die Daten bestmöglich geschützt sind. Für Kreditkarteninformationen wissen wir das und es ist auch einleuchtend, aber IP-Adressen werden aktuell von fast niemandem als besonders schützenswert angesehen. Die Webserver (Apache, IIS und alle anderen) speichern standardmäßig zu jedem Request die IP-Adresse in einer einfachen Log-Datei.

Natürlich brauchen wir genau die IP-Adressen auch hier und da, um den Dienst am Laufen zu halten, beispielsweise um fehlgeschlagene Login-Versuche mitzuloggen. Auch hat nahezu jeder irgendeinen Apache-Log-Parser laufen, der täglich Statisiken generiert über die Besucher, deren Herkunftsland etc. Stichworte sind da Webalizer, AWStats, Piwik usw. Es gibt Meinungen, die besagen, dass man zur Gefahrenabwehr oder im Fehlerfall Logdateien braucht und für eine gewisse Zeit erheben und aufbewahren darf. Doch das geht einigen schon zu weit in Richtung „verdachtsloser Aufzeichnung des Surfverhaltens“.

Etwas komplizierter wird es, wenn wir diese Daten (die IP-Adressen) an andere Dienstleister senden. Hä, tun wir das? Ja, das tun wir, wenn auch meistens unbewußt! Wenn wir beispielsweise Geo-Location-Dienste nutzen, schicken wir die IP-Adresse zu einem solchen Dienst, und bekommen das Land/Stadt zurück. Natürlich gibt es auch Offline-Datenbanken, aber in der Praxis nutzen viele wahrscheinlich den Online-Dienst. Google Analytics gehört natürlich auch zum Problemfeld, wo wir die Informationen über Besucher an einen amerikanischen Dienstleister weitergeben.

Auch gibt es im Apache die Einstellung, ob Reverse-DNS-Abfragen gemacht werden sollen, die dann geloggt werden. Das selbe gilt für SMTPs wie beispielsweise Postfix, die Reverse-DNS- und DNS-Abfragen machen, um die Gültigkeit einer Domain, das Vorhandensein eines MX-Eintrags, den Reverse-DNS-Eintrag etc. zu prüfen. Des weiteren senden wir zwecks einer DNS-Blacklist-Prüfung die IP-Adresse an einen Blacklist-Dienst (DNSBL, z.B. Spamhaus, NixSpam).

Wir gehen also mit den IP-Adressen unserer User nicht sonderlich sparsam um. Und genau das klarzumachen war Ziel des Artikels, mit dem Aufruf, bereits Vorbereitungen für Pseudonymisierung und andere Methoden zu treffen, um dem Datenschutz gerecht zu werden. Der Autor rät sogar, seine Dienste so aufzubauen, dass man auf die Speicherung auch ganz verzichten können sollte. Wie das ganze mit IPv6 weitergeht bleibt auch noch abzuwarten, wenn jede Person einen mehr oder weniger festen IP-Bereich bekommt, mit all den Vor- und Nachteilen.

Wer sich mit Virtualisierung beschäftigt, kommt um VMWare nicht herum. VMWare Workstation haben sicherlich einige von euch schon ausprobiert, sobald es dann aber in Richtung „Server-Virtualisierung“ geht wird die Luft schon dünner.

Wenn man Virtualisierungssoftware (auch Hypervisor genannt) grob unterteilen möchte, gibt es 2 Arten:

1. Hypervisor, die direkt auf der Hardware laufen („bare metal“, also selbst eine Art Minibetriebssystem) und kein Host-Betriebssystem benötigen. Bekannte Produkte sind hier VMWare ESX, der kostenlose VMWare ESXi, XenServer Hypervisor, Microsofts Hyper-V, Sie werden auch als „Type 1“ oder „Native VM“ bezeichnet.
2. Applikationen, die auf einem Betriebssystem installiert werden, und dann als Programm gestartet werden. Bekannte Vertreter sind da Sun’s Open Source VirtualBox, VMWare Workstation/Server, Microsoft Virtual PC, KVM, UML, Linux VServer, OpenVZ, Virtuozzo und viele weitere. Sie werden auch als „Type 2“ oder „Hosted VM“ bezeichnet.

In der zweiten Kategorie unterscheidet man dann zwischen „Full Virtualization“ und „Paravirtualization“. Ersteres kann unveränderte Gäste starten, sprich jedes Betriebssystem auf dem Markt, während bei Paravirtualization das Gastbetriebssystem weiß, dass es virtualisiert wird und es angepasst sein muss an diese Situation, es geht also nicht mit jedem Betriebssystem.

Bei den Bare-Metal-Hypervisor gibt es natürlich Hardware-Einschränkungen, da sie direkt auf der Hardware laufen und nicht eine so große Treiber-Unterstützung mitbringen können wie moderne Windows- oder Linux-Betriebssysteme. Daher sollte man sich vorher informieren, ob beispielsweise ESXi auf seiner Hardware überhaupt läuft.

Um etwas mit ESXi zu testen, habe ich mir für zuhause mal einen USB-Stick erstellt mit der ESXi-Software drauf, und davon gebootet. Der Hypervisor bootete auch erfolgreich, jedoch bliebt er beim Laden der USB-Module stecken. Mein Mainboard (ein MSI 790FX GD70) wird also nicht unterstützt. Um trotzdem zu testen, startete ich es in der Firma mal testweise in VMWare Fusion. VMWare Fusion ist quasi das selbe wie VMWare Workstation, nur für Mac. Doch auch hier startete der Hypervisor nicht vernünftig, da ein Hypervisor innerhalb eines Hypervisors nicht unterstützt wird. Doch Dank eines Blog-Artikels habe ich es dennoch ans Laufen bekommen, und nun kann ich ESXi ausgiebig testen.

Ich habe also ein Mac OS X, darauf VMWare Fusion, darin wiederum ESXi installiert, und auf dem ESXi laufen dann weitere Betriebssysteme (aktuell ein Ubuntu 9.10 und Debian Lenny). Damit ich den ESXi administrieren kann, benötigt man VMWare vSphere, welches wiederum nur unter Windows läuft. Also habe ich unter Fusion noch eine Windows Virtual Machine laufen.

Ihr merkt schon, es macht Spass, soviele Betriebssysteme, teilweise verschachtelt, laufen zu lassen 😉

Die Kollegen von webmasterpro haben mich auf ihre neue Verlosung hingewiesen. Falls sich also ein .Net/C#/Silverlight/Azure – Interessierter hier herumtreibt, sollte er an der Verlosung zu den Tickets teilnehmen. Dazu ist einfach nur ein Kommentar dort zu hinterlassen.

Es gibt volle 3 Tage Konferenzteilnahme in Darmstadt für die 2010 stattfindende Basta! zu gewinnen.

Ich kann mich noch nicht dazu durchringen, ein umfassendes Urteil über Google Wave abzugeben, aber der erste Eindruck ist sehr ernüchternd. Es kommt mir so vor wie ein webbasierter Messenger, bei dem man mehrere Personen in Räume einladen kann und viel Zeit verbraten kann. Nebenbei noch Dateien tauschen. Nichts was man mit Threaded Emails oder ICQ/Jabber nicht auch machen könnte.

Mag sein, dass da noch mehr ist, oder mittels Gadgets da noch mehr möglich ist, aber bisher hatte ich noch nicht soviel Zeit, es im Detail zu betrachten. Deshalb noch kein ausführlicher Artikel.

Wer sich selbst ein Bild machen möchte, kann hier gern in den Kommentaren einen Pieps sagen, habe noch 7 Einladungen zu verschenken an Interessierte.

So, nun habe ich etwas Zeit gehabt und auf die suchmaschinenfreundliche URL-Struktur umgestellt. Vorher hatte ich umgestellt auf /%post_id% , sodass Artikel unter
https://www.phpgangsta.de/630
verfügbar waren. Das war primär dafür gemacht, dass ich diese kurzen URLs in Twitter nutzen kann, da ich Short-URL-Dienste hasse (man weiß nie was dahinter versteckt ist).

Nun habe ich die Struktur umgestellt auf /%postname% , sodass der selbe Artikel nun standardmäßig so verlinkt ist:

Taugt Zend_Queue etwas?

ABER: Da ich die kurzen URLs nicht verlieren wollte (und die Links in Google/Twitter weiterhin funktionieren sollen) habe ich meine .htaccess noch angepasst, sodass ich nun beide Formate nutzen kann. In Twitter kann ich also weiterhin meine geliebten Kurz-URLs nutzen, im Blog wird allerdings der Postname genutzt. Meine .htaccess sieht nun so aus:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /

RewriteRule ^([0-9]+)$ /?p=$1 [R=301,L]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

Falls also in der URL nur Zahlen vorkommen, sende ich einen „301 Permanent Redirect“ auf die URL ?p=<id> , diese URL wandelt WordPress dann nochmals um und leitet auf die URL mit dem Postnamen um. In Google sollten nun also bald die Artikel nur noch mit dem Postnamen erscheinen und die ID-URLs bald verschwinden. Ich bin gespannt, ob das so klappt.

Um nur einen 301 Redirect zu nutzen hätte ich ein kleines Script schreiben müssen, welches aus einer ID die Postname-URL herausfindet (Datenbank?) und dann redirected. Ob das einfach ist und vor allem bei zukünftigen WordPress-Updates noch funktioniert würde ich bezweifeln, und soweit ich weiß sind 2 Redirects kein Problem, oder hat jemand andere Informationen?

Jedenfalls funktioniert es nun so wie ich möchte, und Google werde ich in den nächsten Tagen mal beobachten.