HowTo IP-Logging ausschalten
Auf dieser Seite wird erklärt, wie der Betreiber von Web-Angeboten die Speicherung der Zugriffsdaten der Nutzer unterbinden kann. Dies ist eine sinnvolle Geste, da jede unnötige Datensammlung Gefahren birgt. Angesichts des NSA-Skandals ist dies allerdings ein Tropfen auf dem heissen Stein: Wer sowieso die Kommunikation mitschneiden kann, noch bevor sie beim Server ankommt, der ist nicht auf die Logs angewiesen, die der Server dann anschliessend führen könnte. —lynX 03:09, 24. Jul. 2013 (CEST)
Inhaltsverzeichnis
Vermeidung von IP Logging im Internet
An dieser Stelle sollen zunächst Anleitungen bzw. links gesammelt werden, wie man Webanwendungen u.ä. konfigurieren oder modifiziern muss, damit keine IPs geloggt werden (ausser wenn es gewollt ist wie bei Login-Sessions o.ä.)
Apache
http://www.daten-speicherung.de/index.php/echtzeit-anonymisierung-von-server-logfiles/
Squid
Ein verbreiteter Open Source Proxy: setzen wir in der Firma ein, in der ich arbeite. Hier meine Anmerkungen, wie man ihn als anonymen Proxy konfiguriert, was ich dort schon aus Datenschutzgründen (Vorschrift der Datensparsamkeit) tun musste:
Logging anonymisieren
Das ist relativ einfach, wenn man es weiss (und eine einigermaßen aktuelle squid-Version, d.h. ab 2.5, verwendet), es genügt eine Zeile in der Konfigurationsdatei (überlicherweise squid.conf, meist in /etc oder /etc/squid, evtl. aber auch z.B. in /usr/local/etc):
client_netmask 255.255.255.0
z.B. wenn man ein Subnetz 192.168.0.x oder 172.20.20.x für die zu schützenden IPs persönlich zuordenbarer clients verwendet. Das Ergebnis im Log: die letzte Stelle, die für die Zuordnung alleine maßgeblich ist, wird für alle clients auf 0 gesetzt, d.h. anonymisiert.
Anmerkung 1: angenommen, die privaten clients befinden sich z.B. in 192.168.0.n, d.h. haben Adressen von 192.168.0.1 bis 192.168.0.255 o.ä., und man hat weitere Adressen wie z.B. 192.168.1.x o.ä. in der DMZ, in der i.a. nur von admins updates via proxy eingespielt werden, dann beschränkt obige Anonymisierung gezielt nur die schützenswerten Adressen, man kann durchaus noch sehen, ob in der DMZ irgendwelchen nicht von den Admins gewünschten http-Kommunikationen laufen (z.B. XSS auf Webservern o.ä.).
Anmerkung 2: die Versionen bis 2.4, die sich genauso konfigurieren lassen, hatten ein (eher geringes) information leak in Bezug auf Logging zusätzlicher Informationen in Extra-Logs (z.B. die oft durchaus interessanten user agents, gibt dies doch ein Bild von der Nutzung diverser Browser). Dort wurden nämlich die IPs nicht maskiert! Zwar werden die timestamps im normalen und z.B. agent log unterschiedlich geschrieben und bei mehreren Usern zur gleichen Zeit ist so auch keine Zuordnung möglich, was aber bei einzelnen Usern doch die Anonymisierung aufhebt.
Informationsleck zu besuchten Seiten abdichten
Mindestens ebenso unerwünscht wie das interne Default-IP-Logging ist die Zurückverfolgbarkeit von besuchten Websites aus auf ursprüngliche, interne IP-Adressen von (von dort gesehen) "hinter" dem Proxy.
Das lässt sich ab squid V2.5 (bis V2.4 hieß die Direktive anonymize_headers mit etwas verkürzter Syntax) so in der obigen Konfigurationsdatei erreichen:
visible_hostname proxy.example.com
wenn proxy der hostname und example.com der (interne oder auch nicht) DNS-Eintrag des Proxy Servers ist. Außerdem sind folgende Regeln für den Header Zugriff erforderlich bzw. empfehlenswert:
Hinweis: ab V3 gibt es diese Direktiven (header_access) so nicht mehr - da muß nochmal nachgebohrt werden --Bodo Thiesen 16:38, 6. Jun. 2009 (CEST)
header_access X-Forwarded-For deny all
header_access Via deny all
verbieten IP-Informationen im Header, aus denen Rückschlüsse über die beteiligten internen IPs möglich sind.
header_access From deny all
header_access Server deny all
header_access WWW-Authenticate deny all
header_access Link deny all
unterbinden weitere information leaks: in verschiedenen Abfragen ergänzt squid nämlich sonst weitere interne IP Adressen im Header, z.B. für links etc. Das braucht die besuchte Seite nicht zu wissen und wird daher ebenfalls unterdrückt.
Wer möchte kann noch eine Agent Anonymisierung einbauen, die verhindert, dass die Site den konkreten Browsertyp ermitteln kann (nur http, vor JS sei hier ausdrücklich gewarnt! s.u.), vor Kollateralschäden bei MSIE only sites sowie evtl. fehlerhafter ECMAscript ("JavaScript" oder JS) Ausführung aufgrund der evtl. falsch gestellten Browserweiche sei aber ausdrücklich gewarnt (von der Verwendung des MSIE ist ohnehin aufgrund seiner klaffenden Sicherheitslöcher dringend abzuraten):
header_replace User-agent Mozilla 5./0 (compatible) Opera or Gecko
ist z.B. eine nicht existierende, sozusagen den kleinsten gemeinsamen Nenner der Gecko-basierten Browser (Firefox, SeaMonkey/Mozilla etc.) sowie von Opera bildende Agent Maske. Sie wirkt aber nur, wenn zusätzlich (vgl.o.) die Regel
header_access User-agent deny all
angegeben wird!
Anmerkung 1: es gibt nicht nur aus Sicherheitsgründen (overflows/exploits bzw. XSS=cross site scripting) den Zwang, Internetbrowser aktuell zu halten, teils sind es ebenfalls Informationslecks zu besuchten Seiten, die mit solchen Updates behoben werden! Außerdem empfiehlt sich stets die default-Abschaltung von Cookies, JavaScript und IFrames, die oft neben Sicherheitslöchern auch unerwünschte Informationen abfragen lassen, was in Opera sehr einfach möglich ist, indem sich diese gezielt auf bestimmten, vertrauenswürdigen Seiten wieder einschalten lassen, obwohl es generell für alle anderen aktiviert bleibt. Bei Firefox sind dazu Add-ons nötig. Auch Flash Inhalte sind hier gefährlich, denn sie können ebenfalls JS (2) ausführen! (Flashblock für Firefox ist hier sinnvoll, evtl. in Opera den plugin gar nicht erst installieren)
Anmerkung 2: auch wenn man squid so sorgfältig als anonymen Proxy konfiguriert hat, hängt der Grad der Anonymität nicht unwesentlich von der Zahl der Nutzer ab — mehr Nutzer zur selben Zeit sind hier besser, haben aber natürlich andererseits einen negativen Effekt auf die Latenz und Übertragungsrate pro User. Zum Nulltarif ist dies eben nicht zu haben.
Wordpress und Mediawiki
phpBB
Hintergrund: phpBB ist ein weit verbreitetes Forumsystem. Das System verwendet die IP Adresse des jeweiligen Benutzers und speichert dieses mit - zur Nachverfolgung von Forenaktivitäten.
Ziel: Wir können phpBB dauerhaft abändern, sodass die Software nur die Harmlose IP Adresse "127.0.0.1" speichert. Die Adresse "127.0.0.1" bezeichnet stets den Servercomputer, auf dem sie Software läuft.
Zu Beachten: Generell ist es weniger empfehlenswert eine Software zu ändern. Dadurch erlöschen etwaige Hilfsbereitschaft der Entwicklergemeinde oder Garantieansprüche gegenüber dem Hersteller. Zudem können ungewollte und unvorhersehbare Auswirkungen in der Zuverlässigkeit, Sicherheit oder Funktionalität der Software oft eintreten. Besser ist es, wenn die Forenbenutzer selbst die Verantwortung in die Hand nehmen und Anonymisierungssoftware wie TOR einsetzen. Dennoch ist hier die notwendige Veränderung beschrieben.
Versionen: Es gibt derzeit zwei interessante Versionen von PHP BB, die aktuelle "Stable release" - phpBB 2.0.22 und die sich noch in der Entwicklung befindlichen phpBB 3.0.Beta5.
phpBB 2.0.22 Anleitungen für Webmaster mit Root Zugriff. 1) Du machst ein Backup deiner Webseiten und Datenbanken. 2) Du wechselst in das Verzeichnis, in dem die Software auf dem Webserver sich befindet. 3) Du lädst die Patch-Datei noip_patch_phpbb-2.0.22.txt in das Verzeichnis herunter. 4) Mit "patch common.php noip_patch_phpbb-2.0.22.txt" wendet man die Patch-Datei an. Wenn du die Anwendung namens "patch" auf deinem System nicht hast...WTF? Unter Windows gibt es die Anwendung hier: http://gnuwin32.sourceforge.net/packages/patch.htm 5) Jetzt überprüfst du, dass dein Forum noch korrekt funktioniert. Andernfalls spielst du dein Datei-Backup wieder ein.
Anleitungen für Webmaster mit FTP Zugriff. 1) Du machst ein Backup deiner Webseiten und Datenbanken. 2) Mit deinem FTP-Client verbindest du dich mit deinem Web-Hoster. 3) Du wechselst in das Verzeichnis in dem du phpBB gespeichert hast. 4) Du lädst diese Datei hier "common.php" hoch, dabei überschreibst du der vorhandenen Datei mit demselben Namen. 5) Jetzt überprüfst du, dass dein Forum noch korrekt funktioniert. Andernfalls spielst du dein Datei-Backup wieder ein.
phpBB 3.0.Beta5
Anleitungen für Webmaster mit Root Zugriff.
1) Du machst ein Backup deiner Webseiten und Datenbanken.
2) Du wechselst in das Verzeichnis, in dem die Software auf dem
Webserver sich befindet.
3) Du wechselst in das Unterverzeichnis "includes".
4) Du lädst die Patch-Datei noip_patch_phpbb-3.0.b5.txt in das
Verzeichnis herunter.
5) Mit "patch common.php noip_patch_phpbb-3.0.b5.txt" wendet man die
Patch-Datei an. Wenn du die Anwendung namens "patch" auf deinem System
nicht hast...WTF? Unter Windows gibt es die Anwendung hier:
http://gnuwin32.sourceforge.net/packages/patch.htm
6) Jetzt überprüfst du, dass dein Forum noch korrekt funktioniert.
Andernfalls spielst du dein Datei-Backup wieder ein.
Anleitungen für Webmaster mit FTP Zugriff. 1) Du machst ein Backup deiner Webseiten und Datenbanken. 2) Mit deinem FTP-Client verbindest du dich mit deinem Web-Hoster. 3) Du wechselst in das Verzeichnis in dem du phpBB gespeichert hast. 4) Du wechselst in das Unterverzeichnis "includes". 5) Du lädst diese Datei hier "session.php" hoch, dabei überschreibst du der vorhandenen Datei mit demselben Namen. 6) Jetzt überprüfst du, dass dein Forum noch korrekt funktioniert. Andernfalls spielst du dein Datei-Backup wieder ein.
Anmerkung: Wenn du Root-Zugriff hast, kannst du natürlich die FTP-Variante verwenden. Das Patchen ist aber viel cooler :)
ZIP-Archiv mit den erwähnten Dateien: noIP_PHPBB.zip
Quelle: [1]
Joomla
So ich hab den Joomla Quellcode genauer analysiert und einen Weg gefunden, wie man Cookies für normalsterbliche Seitenbesucher abschaltet, aber trotzdem einen Frontend Login zur Verfügung stellen kann, bei dem dann auch ein Cookie gesetzt wird.
Es ist eigentlich ganz einfach:
/index.php Zeile 107 wieder entkommentieren (s.u.)!
/includes/joomla.php Zeile 697 auskommentieren:
// setcookie( $sessionCookieName, '-', false, '/' );
-> Das wars schon. Wird ein Loginversuch unternommen, wird durch ein gesetztes "force_session" im POST Header weiter unten im Code doch noch ein Session Cookie erzeugt.
Es ist etwas merkwürdig, daß es keine Konfigurationsoption gibt, die Cookie Abschaltung auch für Dummies ermöglicht, da der gesammte Code eigentlich so geschrieben ist, daß das ganz leicht einzubauen wäre.
Es gibt allerdings noch ein paar Stolpersteine: Ich bastle momentan mit der "Fabrik" Komponente. Die startet interessanterweise eine PHP Session auf eigene Faust. Da gibts also doch wieder ein Cookie. Ich werd versuchen, auch diesem Komponentchen das noch auszutreiben. Kann gut sein, daß noch andere Komponenten sich solche Späße erlauben.
Außerdem muß man natürlich noch dran denken, die Statistikfunktionen abzuschalten, sonst gibts ein "mosvisitor" Cookie. (Aber das ist ja bereits hinlänglich bekannt hier! :-) )
Zuguterletzt hat Joomla noch ein "jos_user_template" Cookie. Das wird verwendet bei dem TemplateChooser Modul. Von diesem Modul sollte man also die Finger lassen!
Wenn man außerdem noch ganz mega-sicher gehen will, daß dem Benutzer ja keine bösen Cookies über den Weg laufen, sollte man noch eine Stelle in der Datei
/offline.php Zeile 25: // session_start();
auskommentieren. Diese Datei wird angezeigt, wenn man in der Konfiguration "Seite offline" auswählt oder wenn die Datenbank nicht mehr zu erreichen ist.
Aus mir völlig rätselhaften Gründen wird hier eine PHP Session gestartet obwohl das absolut null Sinn macht, da Joomla im Frontend keine PHP Session benutzt, sondern seine eigene baut, und wenn das Admin Backend nicht mehr zu erreichen ist, ist eh alles zu spät, da braucht man auch keine Session mehr. Ist wohl ein Überbleibsel aus alten Mambo Tagen...
Quelle: [2]
