Apache Logfiles IP anonymisieren DSGVO

So, dann schreibe ich mal meine "Lösung", wobei das erst ein Testlauf ist, der gerade mal 2 Stunden alt ist

Der Hintergrund: Komplett abschalten oder sofort anonymisieren kann ich die Server Logfiles nicht, ich brauche echte IPs für mod_security und Fail2Ban und eben auch, wenn Angriffe auf das System laufen. Das erste was der Hoster bei einer Abuse-Meldung will, sind IPs. Alles wäre nicht mehr erfassbar, wenn die IP sofort anonymisiert, also erst gar nicht komplett gespeichert wird.

So, was mache ich nun oder teste ich? Die IPs werden in den Apache Serverlogs (access.log und error.log, bzw. Log vom vHost) ganz normal gespeichert. Erst wenn Logrotate ins Spiel kommt, dann wird anonymisiert. Also in der Regel einmal am Tag, je nach Servereinstellung. Kann aber auch eine Woche sein. Kommt halt drauf an, wie Logrotate konfiguriert ist.

Zu bearbeiten, also zumindest hier bei Debian. Ubuntu sollte gleich sein und die meisten anderen wohl auch.

/etc/logrotate.d/apache2

Die Änderungen sind rot markiert.

/var/log/apache2/*.log {
        daily
        missingok
        rotate 7
        compress
        delaycompress
        notifempty
        create 640 root adm
[COLOR=#FF0000]#sharedscripts[/COLOR]
        postrotate
                if /etc/init.d/apache2 status > /dev/null ; then \
                    /etc/init.d/apache2 reload > /dev/null; \
                fi;
        endscript
        prerotate
                if [ -d /etc/logrotate.d/httpd-prerotate ]; then \
                        run-parts /etc/logrotate.d/httpd-prerotate; \
                fi; \


[COLOR=#FF0000]cat $1 | /usr/src/anonip.py --column 1 --ipv4mask 12 --ipv6mask 64 --replace 0.0.0.0 --output $1.anonip;
                cp $1.anonip $1;
                rm $1.anonip;[/COLOR]
        endscript
}

Natürlich braucht man auch das Script dafür, das gibt es hier: https://beispiel.rocks/www.privacyfou…ice/anonip.html

Was tut das denn nun?

Bevor Logrotate nun rotiert, wird der Code im "prerotate" ausgeführt und genau dort ist das Script eingebunden. Es ersetzt die letzten 12 Bit bei einer v4-IP bzw. die letzten 64 BIt bei v6. Sollte die Erkennung der IP fehl schlagen, so wird der ganze String mit 0.0.0.0 ersetzt. Das "column 1" dient der Performance, denn die IP ist per default in Spalte 1. Sollte das Log geändert worden sein, so kann das natürlich eine andere Spalte sein. Jedenfalls sollte die angegeben werden, damit nicht alles durchsucht werden muss.

Das Script erzeugt also aus dem aktuellen Log, das gerade verarbeitet werden soll erst mal eine anonymisierte Kopie mit der Endung. anonip. Das ist wichtig, da es nicht direkt in das Original-Log schreiben kann. Gut, kann es schon, aber dann ist es eine Endlosschleife (selbst erlebt). Ist dieses anonymisierte Log erstellt, dann kopiert es den Inhalt in das Original-Log und löscht die "Kopie". Auch das ist wichtig, denn die Kopie würde beim nächsten Durchlauf nicht ersetzt, sondern erweitert werden. Also löschen lassen.

Wenn das durch ist, dann rotiert Logrotate das geänderte und nun anonyme Log einfach weg, so wie jedes andere Log auch.

Ach ja, fast vergessen und das ist mehr oder weniger das Wichtigste. Die Angabe "sharedscripts" muss auskommentiert oder gelöscht werden. Ist diese vorhanden, dann sendet der Apache nicht den Pfad vom aktuell zu bearbeitenden Logfile, sondern den allgemeinen Aufruf "/var/log/apache2/*.log", was natürlich nicht funktionieren kann. Man möchte ja ein bestimmtes File anonymisieren und nicht per Wildcard einen ganzen Ordner.

Für Google noch extra: DSGVO, Datenschutzgrundverordnung

Der Post war auch nicht wegen der Frage. Vielleicht habe Ihr ja eine bessere Lösung. Der war eigentlich nur dazu, dass man mal was findet, also eher für Google. Findet tut man ja letztendlich im Netz viel, aber keiner sagt genau, wie es geht. Anleitungen zum sofortigen anonymisieren gibt es genug, ebenso zig Hinweise auf anonip, aber keiner schreibt, wie man das als Bulk-Tool nutzt, sondern eben immer nur, wie man jede Log-Zeile in Echtzeit abarbeitet. Letzteres hat aber zwei Nachteile. 1) gar keine IPs mehr, also auch kein Fail2Ban und 2) läuft dann für jedes Log (access und error von jeder Domain) eine Python-Instanz. Ist auch doof.

Ach ja, "zeigen" muss sich das hier auch noch, schaut aber nicht schlecht aus...

81.38.112.0 - - [16/May/2018:20:34:45 +0200]
81.38.112.0 - - [16/May/2018:20:34:46 +0200]
134.101.240.0 - - [16/May/2018:20:34:50 +0200]
134.101.240.0 - - [16/May/2018:20:34:50 +0200]
134.101.240.0 - - [16/May/2018:20:34:50 +0200]
2003:c9:33df:bc97:: - - [16/May/2018:20:34:56 +0200]
2003:c9:33df:bc97:: - - [16/May/2018:20:34:56 +0200]
2003:c9:33df:bc97:: - - [16/May/2018:20:34:56 +0200]

Wegen Hoster... Einige haben den Schritt schon gemacht und anonymisieren die IPs in den Serverlogs. Und ja, man muss löschen wenn die Daten nicht mehr gebraucht werden. Dass man aber gar nicht speichern darf ist falsch, das darf man schon, wenn man informiert. Aber eben halt nur so lange, wie es nötig bzw. erlaubt ist. Ob das mit DSGVO noch so ist, keine Ahnung, aber früher waren es 14 Tage.

Und ja, das zieht sehr weite Kreise. Airport denkt sogar schon darüber nach den Dienst "Bot-Trap" einzustellen, weil der mit gekürzten IPs schlicht nicht funktionieren kann.

Strato schreibt z.B. dazu:

"Aus datenschutzrechtlichen Gründen wird in den Logfiles der Hostname bzw. die IP-Adresse des Clients, der Ihre Website aufruft, anonymisiert. .... Eine anonymisierte IP-Adresse behält maximal 24 Stunden ihre Gültigkeit. Danach würde aus derselben Ausgangs-IP-Adresse eine andere "anonyme" IP-Adresse werden"

Die anonymisieren also sofort und nach 24 Stunden ist selbst diese Pseudo-IP nicht mehr brauchbar.

1und1 speichert die Logs für 9 Wochen, dann löschen sie (bei Hosting und Managed Servern), aber mit dem Hinweis:

"Aufgrund von Datenschutzrichtlinien zu personenbezogenen Daten werden die IP-Adressen der Aufrufer in den Log-Dateien nach 7 Tagen mit einem 'x' anonymisiert."

Zitat

der hat gar keine Möglichkeit da Einfluss drauf zu nehmen, was der Hoster speichert.

Dann hat er ein Problem und sollte sich einen anderen Hoster suchen.

Zumal, wenn fremde persönliche Daten dort gespeichert werden, man ohnehin einen AV braucht und in dem steht dann drinnen, was der Hoster sammelt und was er mit macht und wie lange.

Also derartige News lese ich schon gar nicht mehr. Heute nur eine, da ging es eben auch um die IP-Speicherung wobei das aber auch Quatsch war, denn da ging es um einen Sonderfall wegen der Telekom.

Aber, Thema Hoster. Das ist ein anderer Bereich. Vorstellen kann ich es mir auch nicht, ich weiß auch nicht, was Strato wirklich tut, aber ich muss mich auf den AV verlassen. Wenn der nicht stimmt, dann haben beide Seiten ein Problem.

Zwischenwort, um es anders zu sagen: Wenn Du auf Deiner Webseite ein Bild von meinem Server einbindest, dann sendest Du auch Daten an mich. Das muss eventuell in die DSE. Aber es gibt keinen Vertrag, Du hast mich nicht damit beauftragt, die Daten zu sammeln. Somit bin ich hier für die Verarbeitung verantwortlich und Du musst drauf hinweisen.

Zwischenwort 2: Das z.B. eben mit der Anonymisierung und meinem Kalendersystem. Ich erfasse hier jeden Tag ca. 1 Mio fremde IPs, nur weil meine Kunden den Kalender bei sich einbauen. Die Kunden wissen nicht, was ich erfasse und haben mich auch nicht damit beauftragt. Daher die Anonymisierung, weil nun schon 12 nach einem AV von mir fragten. Und auf einen AV lasse ich mich nicht ein, denn der hat viel weitreichendere Folgen.

Zitat

Warum? nicht der Seitenbetreiber speichert die Daten, sondern der Hoster.

Das Problem ist, man hat mit dem Hoster einen Vertrag. Der speichert die Daten ja nicht einfach so, sondern eben weil der Kunde einen Vertrag mit ihm hat und eben auch Statistiken möchte. Die Speicherung wird ja wohl irgendwo in den AGB oder sonst was stehen. (Wenn nicht, anderes Thema) Du kannst ja auch selbst hosten, dann bleiben die Daten in der eigenen Firma.

Der Hoster ist in der Lage, diese Daten einzusehen, oder Mitarbeiter oder oder oder. Ob die das tun, das ist nicht die Frage, es reicht aber die "Möglichkeit". Und genau deswegen braucht man den AV.

Und die Speicherung der IP ist eben nicht zulässig, also nicht ohne Grund und nicht auf unbegrenzte Zeit (Das war es schon jetzt nicht. Genau der Grund, warum diverse Linux-Derivate das Logrotate per default auf 14 Tage stellten. Früher waren das mal 52 Wochen.). Daher anonymisieren die normalen Hoster eigentlich alle, weil sie selbsterklärend nicht gegen den Datenschutz verstoßen wollen. Einige bieten den Kunden auch die Option, Logfiles komplett zu deaktivieren. Das kann dann der Kunde selbst entscheiden, wenn der der Meinung ist "Eh, Ihr sollt hosten und nicht ungefragt private Daten erfassen".

Das Problem an der Sache. Die Gesetzgeber sind wohl alle verblödet, denn die wissen wohl nicht, dass das Internet nur aus IPs besteht und ohne gar nicht funktioniert.

Handybesitzer... Ganz anderes Thema. Denn was der Provider speichert, egal was, das kommt von Dir, sind Deine Daten! Die Ip, wenn einer auf Deine Webseite geht, ist aber nicht Deine.

Edit: Ich glaube auch, dass das heißer gekocht als gegessen wird, aber so ganz ohne ist das nicht, wenn man bedenkt, dass zig namhafte US-Firmen ihren Betrieb in der EU einstellten, weil sie der DSGVO nicht gerecht werden können. Habe heute auch mit einem großen Unterkunftsanbieter telefoniert, Alex, dir sagte ich den Namen. Auch von denen weiß ich, dass viele US-Anbieter die Kooperation beendet haben und nun sind sie auf der Suche nach Firmen in der EU. Wollten mein komplettes Portal mit aufnehmen.

Edit 2: Aber das geht hier im Thread nun zu weit. Der war wirklich nur für das Forum und Google, weil es eben zum Bulk-Import von anonip nix gibt und das was es gibt funktioniert nicht, wenn man nicht weiß, dass $1 den String der Webseite enthält und das eben auch nur, wenn man "sharedscripts" deaktiviert. Das Netz ist voll mit "geht nicht", aber keiner schreibt wirklich eine Lösung. Die selbst bzw. der Hinweis in die Richtung steht im Apache-Bug-System.

Also so wie es scheint, läuft das sehr gut, habe es nun auch schon auf allen Servern laufen. Hier und da verhaspelt sich das Script mal und anonymisiert nicht von 1.2.3.4 zu 1.2.3.0, sondern zu 1.2.0.0 aber das ist die Seltenheit. So 1 mal von 1000 Logeinträgen und auch nicht weiter tragisch. Das aber auch nur bei v4-Adressen. v6-IPs scheinen den "Bug" nicht zu haben. Ist wohl dadurch bedingt, dass es nicht mit Oktets sondern mit Bytes arbeitet.

Aber, ich muss sagen, es läuft.

Und man kann weiter damit spielen. Ich mache das nun ja mit max 24 Stunden, also jeden Tag wird nachts rotiert, daher max, denn wenn der Logeintrag 5 Min vorher kommt, dann ist er auch direkt weg. Kann man auch aufboren auf das Log von gestern, also das access.log.1, dann hat man max. 48 Stunden echte IPs. Oder noch einen Schritt weiter und eines der anderen Files nehmen. Hier im Fall sind die gezippt, aber das spielt keine Rolle. Entweder nicht zippen lassen, oder eben im Prerotate das Ding erst entpacken, durch anonip jagen und dann selbst wieder komprimieren.

Ehrlich gesagt, und das ist das Gute an der DSGVO, ich habe mich noch nie so intensiv mit Logrotate beschäftigt wie die letzten 7 Tage, genauso wie mit SetEnvIf, damit man gar nicht erst jeden Mist loggt, den man ohnehin nicht braucht. Webseiten ja, aber wer braucht schon Favicons und so Zeug