PHPGangsta - Der praktische PHP Blog

Ihr habt es wahrscheinlich schon alle mitbekommen, es klafft ein riesiges Loch in der häufig eingesetzten OpenSSL-Bibliothek. Webserver, Mailserver, Jabberserver, alles was irgendwie mit Verschlüsselung zu tun hat ist gefährdet. Ist bereits OpenSSL 1.0.1 bis 1.0.1f im Einsatz (das ist die aktuelle Version, seit 2 Jahren verfügbar) steht ein dringendes Update an auf 1.0.1g.

Nicht betroffen sind OpenSSL 1.0.0 und 0.9.8. Nicht betroffen ist auch OpenSSH (wichtiger Unterschied).

Die Lücke hat den Namen „Heartbleed“ bekommen und ist unter der CVE-Nummer CVE-2014-0160 verzeichnet.

Mit Hilfe dieser Lücke können Angreifer auf „die nächsten 64KB“ des Arbeitsspeichers des Prozesses zugreifen. „Die nächsten“ ist aber variabel, je nachdem wo er gerade landet im Arbeitsspeicher, sodass mit einer gewissen Wahrscheinlichkeit auch der private SSL-Schlüssel zu finden ist. Dieser kann nun von außen ausgelesen werden, ohne dass es Logeinträge gibt, also völlig unsichtbar. Mit Hilfe dieses Private Keys kann der Angreifer die aufgezeichneten Trafficdaten der Vergangenheit entschlüsseln, aber auch in Echtzeit in der Zukunft den Traffic entschlüsseln. Er kann außerdem per Man-in-the-Middle anderen vorgaukeln dass sein Server gültig ist für die jeweilige Domain, und damit Phishing betreiben.

Sehr ausführliche Informationen befinden sich auf der Seite heartbleed.com.

Was ist zu tun:
Weiterlesen »

So, damit es nicht heißt mein Blog wäre in 2011 nicht via IPv6 erreichbar gewesen ist meine letzte Aktion dieses Jahr meinen Webserver via IPv6 erreichbar zu machen. Da mein Hoster nun auch endlich IPv6 für virtuelle Server anbietet war das ziemlich einfach: Man mußte im Kundenbereich die IPv6 Konnektivität aktivieren und 10 Minuten warten. Und schon war der Server via IPv6 erreichbar:

$ ifconfig venet0 | grep inet6
inet6-Adresse: 2a01:238:42b6:2a00:e661:84eb:4a08:ee54/128 Gültigkeitsbereich:Global
inet6-Adresse: ::1/128 Gültigkeitsbereich:Maschine

Dann mußte ich gerade noch den nginx neu kompilieren für die IPv6 Funktionalität (wurde eh mal wieder Zeit, war noch eine alte 0.8.53 Version), sodass ich nun die aktuelle 1.0.11 verwende:

Weiterlesen »

Den Traffic einer ganzen Seite herauszufinden ist nicht sonderlich schwer in Zeiten von awstats, webalizer und diversen anderen Apache-Log-Analyzern.

Doch ich wollte damals bei meinem eigenen Browsergame den Traffic pro eingeloggtem User messen. Idee war damals, den „Free Accounts“ 100MB pro Monat zu schenken, falls mehr benötigt wird, muss ein Premium-Account her.

Doch wie stellt man das an? Das Apache-Log hilft nicht wirklich, denn dort kann man nicht die einzelnen (eingeloggten) User unterscheiden. Ich habe damals 3 Lösungen gefunden:

• mit dem Output Buffer von PHP arbeiten, Stringlänge bestimmen und mitloggen, dann Seite an den Browser schicken
• Irgendwie die IP-Adressen des Users merken, und dann das Apache-Log durchparsen und rechnen.
• die Apache-Extension mod_log_sql

Möglichkeit 1 sieht dann ungefähr so aus:

<?php
ob_start();

// some html content here

$trafficbytes = strlen(ob_get_flush());
// insert traffic into database

?>

Habe es nie ausführlich getestet, aber ich denke es ist langsam (da das HTML erst am Ende geflushed wird anstatt zwischendurch schon Häppchen zu verschicken). Außerdem muß man sich noch um Bilder kümmern, denn die sollen ja auch mitgezählt werden. Dazu würde ich eine Rewrite-Rule empfehlen, die bei jedem Bildrequest noch schnell ein php-Script ausführt. Auch das beeinflusst natürlich die Performance des Besuchers und des Webservers.

Die zweite Möglichkeit ist nicht ganz einfach umzusetzen. Die IP-Adresse allein ist nicht sonderlich aussagekräftig, einen Benutzer damit zu verfolgen recht aufwändig. In Zeiten von Proxies (Grüße an AOL), Neueinwahl bei DSL, mehrere Benutzer hinter einem Heimrouter etc reicht das nicht aus, um darüber den Benutzer zu bestimmen, gerade wenn Bruder und Schwester gemeinsam über eine Leitung im Internet sind usw.

Die dritte Alternative ist das Apache-Modul, welches ich dann auch genutzt habe: mod_log_sql. Dieses bindet man einfach in die entsprechene Apache-Config ein, und schon wird ein zusätzliches Log erzeugt, nämlich in der Datenbank. Dies kann man entweder für alle Seiten tun, oder nur für bestimmte VirtualHosts. Welche Spalten dort gefüllt werden sollen, in welcher Reihenfolge und mit welchen Daten, konfiguriert man in der apache-Config. Hier eine Beispielkonfiguration (hier für Linux, für Windows sieht es ähnlich aus: .dll statt .so usw.):

LoadModule log_sql_module modules/mod_log_sql.so
LoadModule log_sql_mysql_module modules/mod_log_sql_mysql.so

LogSQLLoginInfo mysqli://apacheloguser:apachelogpwd@localhost/apachelogdb
LogSQLCreateTables On
LogSQLMachineID mylocalmaschine
LogSQLTransferLogFormat AbHIhMmpRSstTUuvz
LogSQLTransferLogTable ztraffic_access_log
#LogSQLNotesLogTable ztraffic_notes
LogSQLCookieLogTable ztraffic_cookies
#LogSQLHeadersInLogTable ztraffic_headers_in
#LogSQLHeadersOutLogTable ztraffic_headers_out
LogSQLWhichCookies UserID     # hier könnten noch mehr Cookies stehen

Man kann alternativ zur eigenen Cookie-Tabelle auch ein bestimmtes Cookie mit ‚c‘ und „LogSQLWhichCookie“ in die access_log schrieben lassen. Hier eine Liste der Informationen, die man speichern kann.

Damit das Modul funktioniert, muß man noch das Modul „unique“ aktivieren, entweder per

a2enmod unique_id

oder via Einkommentieren von

LoadModule unique_id_module modules/mod_unique_id.so

Apache reload. Wenn man danach eine Seite besucht, liest man folgendes im apache error log:

[Tue Sep 01 19:59:46 2009] [notice] mod_log_sql: child established database connection
[Tue Sep 01 19:59:46 2009] [error] mysql_query returned (1)
[Tue Sep 01 19:59:46 2009] [error] table does not exist, preserving query
[Tue Sep 01 19:59:46 2009] [error] table doesn't exist...creating now
[Tue Sep 01 19:59:47 2009] [error] tables successfully created - retrying query
[Tue Sep 01 19:59:47 2009] [notice] query successful after table creation

Die Tabelle wurde also erfolgreich angelegt. Das Ergebnis sieht dann so aus:

Der Inhalt der Tabelle (nur 1 Zeile):

Wäre dieser Test-Request kein 304er (Not Modified), hätten wir bei „bytes_sent“ auch eine Traffic-Angabe.

Mit Hilfe der Cookie-Tabelle können wir dann zB einmal täglich den Traffic jeden Users berechnen und in die entsprechende User-Tabelle füllen. Die Log-Tabelle sollte man dann wieder aufräumen und nicht länger benötigte Zeilen löschen.

Übrigens ist das Modul nur für Linux supported. Unter Windows kann man es zwar auch kompilieren, das ist aber mehr hohem Aufwand verbunden. Ich habe damals (2004) durch Zufall eine kompilierte Version gefunden. Die ist aber heute nicht mehr brauchbar, da sie für eine sehr alte Apache-Version kompiliert wurde.

Wenn ihr Fragen habt, fragt! Oder wenn ihr evtl. bessere Lösungen kenn, her damit! Oder was könnte man noch alles anstellen mit diesen Apache-Logs in einer Datenbank?

—————————————————-

Weitere interessante Links zum Thema:

Anleitung für Debian Etch

Die offizielle Webseite des Moduls