Realtime logfile/traffic analyses (apache webserver)

Live „top 10“ useragents
~$: cat access.log | awk -F '"' '{print $6}' | sort | uniq -c | sort -nr | head

„Top 10“ useragents certain date and hour (grep pattern may differ)
~$: grep '12/Sep/2011:15' access.log | awk -F '"' '{print $6}' | sort | uniq -c | sort -nr | head

„Top 20“ referrers from the last 5000 hits
~$: tail -5000 access.log | awk '{print $11}' | tr -d '"' | sort | uniq -c | sort -rn | head -20
~$: tail -5000 access.log | awk '{freq[$11]++} END {for (x in freq) {print freq[x], x}}' | tr -d '"' | sort -rn | head -20

Top 20 IPs from the last 5000 hits
~$: tail -5000 access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20
~$: tail -5000 access.log | awk '{freq[$1]++} END {for (x in freq) {print freq[x], x}}' | sort -rn | head -20

Top 20 URLs from the last 5000 hits
~$: tail -5000 ./access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20
~$: tail -5000 ./access.log | awk '{freq[$7]++} END {for (x in freq) {print freq[x], x}}' | sort -rn | head -20

Top 20 URLs requested from a certain ip from the last 5000 hits
~$: IP=1.2.3.4; tail -5000 ./access.log| grep $IP | awk '{print $7}' | sort | uniq -c | sort -rn | head -20
~$: IP=1.2.3.4; tail -5000 ./access.log | awk -v ip=$IP ' $1 ~ ip {freq[$7]++} END {for (x in freq) {print freq[x], x}}' | sort -rn | head -20

real time analysis with apachetop
HowTo: monitor your website in real time with apachetop
/usr/sbin/apachetop -f /path/to/your/log/access.log

Zugriff auf eigene Bilder von fremder Domain sperren

Bilderklau ist im Internet leider allzu verbreitet! Wenn aber nicht einmal eine Kopie von dem Bild gemacht wird, sondern das Originalbild direkt im fremden Quelltext eingebunden wird, hat der Seitenbetreiber des Originalbildes nicht nur unnötig höheren Traffik, sondern auch noch eine höhere Serverlast zu bemängeln.

Um diese Art des Bilderklaus zu unterbinden, kann eine kleine RewriteRule z.B. in einer .htaccess Datei eingesetzt werden:

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?eigene-domain.tld(/)?.*$ [NC]
RewriteRule .*\.(gif|jpe?g|png)$ [F,NC]

Was passiet hier nun?

Wenn der Referer leer ist, oder nicht die eigene Domain ist, dann wird der Zugriff auf alle Dateien mit der Endung .gif, .jpeg, .jpg oder .png verboten. Wenn leere Referer zugelassen werden sollen, einfach die erste Zeile mit RewriteCond entfernen (nicht jeder Browser sendet den Referer (korrekt) mit).

Weitere Domains zulassen

Um weiteren Domains den Zugriff auf die Dateien zu erlauben, muss diese einfach in einer RewriteCond hinzugefügt werden.

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?eigene-domain.tld(/)?.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://(www\.)?andere-eigene-domain.tld(/)?.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://(www\.)?erlaubte-fremde-domain.tld(/)?.*$ [NC]
RewriteRule .*\.(gif|jpe?g|png)$ [F,NC]

Andere Anwendungen/Dateiendungen

Die Liste der zu sperrenden Dateien, bzw. Dateiendungen kann einfach ergänzt werden (letzte Zeile, RewriteRule), so lassen sich dann z. B. auch PDF/DOC/etc. Dateien sperren.

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?eigene-domain.tld(/)?.*$ [NC]
RewriteRule .*\.(gif|jpe?g|png|pdf|doc)$ [F,NC]

Nicht sperren, sondern alternativen Inhalt zeigen

Statt den Zugriff zu sperren, kann man auch einen alternativen Inhalt/alternative Datei ausliefern. Dies könnte z.B. ein anderes Bild/Dokument sein, in dem auf den Datenklau hingewiesen wird. Diese Methode spart zwar keinen Traffik oder Serverlast, kann aber auch wirksam sein ;)

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?eigene-domain.tld(/)?.*$ [NC]
RewriteRule .*\.(gif|jpe?g|png)$ /do-not-steal.gif [NC]

neues Zend Framework Rewrite

Seit einiger Zeit findet sich im Quickstart Tutorial (englisch) des Zend Frameworks eine neue verbesserte RewriteRule:

Wird das mod_rewrite Modul unter Apache verwendet, wird empfohlen, eine .htaccess Datei mit folgendem Inhalt im Hauptverzeichnis der Domain (DocumentRoot) abzulegen:

# public/.htaccess
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]
RewriteRule ^.*$ /index.php [NC,L]

Was passiert hier nun?

Die Umgebungsvariable REQUEST_FILENAME beinhaltet laut Apache-Dokumentation den vollen Pfad zur Datei oder zum Script entsprechend der Anfrage (z.B. /var/www/domain.tld/public/css/style.css).

Die drei Bedingungen (RewriteCond) prüfen nun, ob diese/s Datei/Script eine tatsächlich existierende Datei (s), symbolischer Link (l) oder ein Verzeichnis (d) sind. Wenn ja: leite die Anfrage unverändert durch und beachte keine weiteren Regeln ([L] = Last/Letzte Regel), also kein Rewrite und Ende der Prüfung. Wenn nein: Schreibe die Anfrage zu /index.php um. Das NC bewirkt, dass nicht zwischen Klein- und Großschreibung unterschieden wird (NC = no case-sensitive).

Besonderheit bei Deklaration der Rewrite Bedingungen/Regeln innerhalb eines VirtualHost
Die zuvor aufgezeigten Bedingungen gelten für die Deklaration innerhalb einer .htaccess Datei. Gleichermaßen kann das Rewriting natürlich auch innerhalb einer VirtualHost Definition deklariert werden.

Jedoch ist bei einer Deklaration innerhalb eines VirtualHosts zu beachten, dass die Umgebungsvariable REQUEST_FILENAME hier nicht den vollen, sondern den relativen Pfad vom DomainRoot beinhaltet.

In den Bedingungen muss daher die Umgebungsvariable DOCUMENT_ROOT zusätzlich vorangestellt werden!
Der Rest bleibt erhalten.

# innerhalb VirtualHost Deklaration
RewriteEngine On
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} -s [OR]
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} -l [OR]
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]
RewriteRule ^.*$ /index.php [NC,L]