SN:Aktionen/Ideen/AnonIPLog
Problemstellung
Üblicherweise legen Webserver bei jeder Anfrage nach einer von ihnen bereitgehaltenen Seite einen Eintrag im Logfile an, der u.a. die IP-Adresse des Anfragenden enthält. Obwohl in der Rechtssprechung noch umstritten, können diese als personenbeziehbare und damit besonders schützenswerte Daten gesehen werden. Eine Nichterhebung wäre also geboten.
Dem entgegen steht aber das Bedürfnis der Betreiber durch statistische Erhebungen bzgl. der Nutzung ihre Seiten zu verbessern, sowie massenhaft auftretende Zugriffe durch einzelne Nutzer (DoS) zu erkennen.
Als guter Kompromiß erscheint eine Anonymisierung der aufgezeichneten IP-Adressen.
Lösungsansätze
Maskierung
Ausnullen von Adreßbits - siehe [1] - gleichwertig ist das Weglassen dieser Bits
Je mehr Bits ausgenullt werden, desto wahrscheinlicher ist es, daß zwei IP-Adressen aufeinander fallen. Dies erschwert die statistische Auswertung bzw. macht sie unmöglich.
- +: einfach
- -: Behinderung der statist. Auswertung
Hashing
Auf die IP-Adresse wird eine Hash-Funktion (z.B. MD5, SHA-1) angewendet, um sie zu verschleiern.
Da lediglich etwa 4 Mrd. IP-Adressen existieren und moderne Rechner sehr leistungsfähig geworden sind (GPUs errechnen ca. 300 Mio. MD5-Hashes pro Sekunde), ist in diesem Fall die Erstellung einer vollständigen Abbildungstabelle "IP-Adresse => Hash" in kürzester Zeit möglich.
- +: Standardimplementierung für Hashes verfügbar
- -: geringer Aufwand zur Deanonymsierung
Hashing mit Salt
Durch Hinzunehmen (z.B. Anhängen oder Einmischen) einer zufälligen Komponente vor dem Hashen (Salt) löst sich das Problem des möglichen Brute-Force-Angriffs. Der verwendete zufällige Teil sollte keinesfalls abgespeichert werden und ist regelmäßig (täglich?) zu ändern. Eine zu häufige Änderung würde allerdings wieder zu Problemen in der Auswertung führen - Daten, die während des Wechsels erhoben wurden, werden fehlerhaft/unvollständig ausgewertet.
- +: Standardimplementierung für Hashes verfügbar
- +: Einfache Klasse in Ruby verfügbar. Sourcecode auf github. Hängt Zufallsstring (Salt) an übergebene IP und berechnet anschließend SHA1-Summe. Salt ändert sich nach vorgegebenem Timeout
XOR-Maskierung
Webserver sind ggf. stark ausgelastet. Der zusätzliche Berechnungsaufwand zur IP-Anonymisierung im Logfile mittels Hash-Funtionen ist daher nicht wünschenswert. Eine weitere Möglichekit wäre die nötige zufällige, später zu verwerfende Komponente stattdessen ähnlich einem OTP zu nutzen. Das heißt jede gelogte IP-Adresse wird mit den gewählten Zufallsbit XOR-verknüpft und so unkenntlich gemacht. Die Zufallsbits werden nach einem festen Zeitintervall erneuert.
Der "Berechnungsaufwand" (einfache XOR-Verknüpfung) ist hier deutlich geringer, die erzielte Sicherheit sollte ausreichend sein. Durch gezielte "Angriffe" (Zugriffe zu fester Zeit über bekannte IP) läßt sich die Anonymisierung brechen. Bleibt die Frage nach dem Angreifermodell...
- +: einfach, geringe Rechenlast
- -: schwächerer Schutz (ausreichend?)
Binary Random Permutation (BRP)
Für jede neu im Logfile gefundene IP wird eine neue zufällige anomyme IP gewürfelt. Zur Zuordnung bereits aufgetauchter IPs hält der Algorithmus eine Zuordnung (IP => rndIP) vor.
- +: gut dokumentiert/"zitierfähig"
- -: ggf. großer Speicherbedarf
offene Fragen
- Filterung in Echtzeit bei Logerstellung oder Anonymisierung vorhandener Logfiles?
- IPv6-Parsing
- Zeilenumbrüche innerhalb einer IP?
- nötige Qualität des Zufalls (random vs. urandom)
- valide IPs als Ergebnis der Anonymisierung nötig? (z.B. wegen statistischer Auswertungssoftware)
Material
IP-Adressen
Beispiele für Log-Einträge
xyz.xyz.xyz.xyz ist jeweils die zu anonymisierende Herkunfts-IP
- Apache Access Log
xyz.xyz.xyz.xyz - - [11/Oct/2009:09:42:00 +0200] "GET / HTTP/1.1" 200 1774 "-" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; de; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3"
- Apache Error Log
[Sun Oct 11 09:42:06 2009] [error] [client xyz.xyz.xyz.xyz] File does not exist: /var/www/munin/favicon.ico
- E-Mail-Log
- ...