Ihr dachtet, ich wäre fertig? Es gäbe nur eine Schätzung? Genaue Stats sind nicht möglich? Hmm… dachte ich auch erst, aber es kam anders 🙂
Cache Traffic fürs Blog: November 2022 – Part II
In einem Anfall von Programmierwahn, Trotz und etwas Glück konnte ich doch noch gute Analysen auf die Datenbasis von ATS machen und schaut mal, was dabei rauskam:
Experten erkennen jetzt natürlich sofort die Ausgaben eines des ältesten Webanalysetools: Webalizer
Da wäre eine optisch neu aufgehübschte Version mal echt super. Vielleicht ist da was in der Mache 😉
Da bekommen wir jetzt eine nette Übersicht über die Tage und Zugriffe auf die URLS und das offenbart ein echtes Problem… nicht für mich, für die Hacker 😉 Weil wir die Stats jetzt vor dem Cache bekommen, sehen wir natürlich auch die IPs dazu. Daher kann Webalizer jetzt auch wieder ausrechnen, wieviel aus jedem Land dabei war ( nicht im Artikel zusehen ). Beim Durchlesen der Liste mußte ich allerdings sehr, sehr oft den Kommentar „Hackerangriff“ abgeben, weil man seine Klientel schon kennt: .RU, .CN, .VN, .IN usw. usw.
Wie man sieht, war /xmlrpc.php ein sehr beliebtes Angriffsziel. Blogs brauchen das File aus historischen Gründen für die Vernetzung und die Android App. Für einen regulären Webseitenbetrieb ist das aber nicht nötig. Deswegen gibts in meinem Blog da auch einen HTACCESS Zugriffsschutz für die Datei, so daß die Hacker allesamt daran scheitern, wenn sie versuchen darauf zuzugreifen. Das hält die natürlich nicht ab, weil deren Scripte so blöde sind, tausende male die Webseite mit Schrott aufzurufen und ein 401 ( Auth Required ) als Antwort zu bekommen. 65k Zugriffe waren es nicht nur, weil im Cache erst noch ein entsprechender Blocker integriert werden muß, sondern weil das ganze Botnetze sind. Da kann man viele IPs blocken und trotzdem kommen die massenhaft an. Ungefiltert wären das zwischen 250k und 500k pro Monat. Nicht selten habe ich an einem Tag auch mal 125k Versuche gemessen.
Die 401 Blockage hat für meinen Server den Vorteil, daß kein PHP ausgeführt wird, wenn die angreifen, was deutlich spürbar zur Serverperformance beiträgt. Kann ich Euch auch nur anraten. Nehmt gleich noch die „/wp-login.php“ und das „/wp-admin“-Verzeichnis dazu, da sollte auch niemand reinkommen, außer Euch.
Die Entry Points sind sehr spannend, weil die deutlich zeigen, daß das Blog primär via RSS Feeds eingebunden ist, deswegen ist /feed/ die dickste Startseite, von den Hackern mal abgesehen 😉
An den TOP 30, wovon Ihr nur 15 seht oben, sieht man auch das Interesse an älteren Beiträgen z.B. /2020/03/02/xrdp-und-der-schwarze-bildschirm/ was immerhin 114x im November ausgerufen wurde. Da werde ich mir aber die gesamt Auswertung im nächsten Jahr mal ansehen. Ich hatte schon lange den Verdacht, daß WP selbst da viel zu wenig anzeigt.
Wie habe ich das jetzt gemacht?
Die Zugriffslogs vom ATS ( Apache TrafficServer ) liegen im Binärformat vor. Mit einem ATS Befehl kann man das in lesbare Zeilen umwandeln. Das sieht dann so aus:
1670194793.518 1259 185.136.205.XXX TCP_MISS/200 757 POST http://marius.bloggt-in-braunschweig.de/xmlrpc.php – DIRECT/marius.bloggt-in-braunschweig.de text/xml
Das kann aber kein Analysetool, daß ich bei einer schnellen Suche finden konnte, analysieren. Daher dachte ich mir: bau es doch einfach selbst in das Apacheformat um, dann kann Webalizer das machen. Ein bisschen JAVA später, weil Bash war mir zu anstrengend, und wir hatten das Apache Format. Da Webalizer früher schon für uns gearbeitet hatte auf den Servern, war noch alles vorhanden. Also mußte man es nur noch aufrufen und das Ergebnis in ein webfähiges Verzeichnis kopieren:
/usr/bin/webalizer -X -p -K 12 -k 12 -A 30 -C 30 -R 30 -S 30 -U 30 -e 30 -E 30 -g 5 -j \
-c /etc/httpd/webstats/$DOMAIN -n „$DOMAIN“ \
-o /var/www/html/stats/$DOMAIN /tmp/webstats.log
/tmp/webstats.log ist natürlich das File, daß vom Java-Konvertiertool erzeugt wurde. Ihr könnt Euch denken, daß ich so ein Cache nicht nur für mich laufen lasse, sondern, daß das auch andere mitbenutzen, weil es einfach echt nützlich ist. Deswegen gibt es die Auswertung dann auch für alle anderen Domains. In der angegebenen Config -c /etc/httpd/webstats/$DOMAIN stehen dann alle notwendigen Angaben, wo Webalizer die Zwischendaten speichern soll. Was Ihr da braucht, findet Ihr in der Webalizer Manpage oder im Web.
Danach noch einen Webaccount aufgesetzt, erzeugte Files hinkopiert und fertig ist die Statsseite für ATS-Cachseiten \o/
Rein technisch kann man natürlich jedes andere Apachestatstool einsetzen. AWstats war mir jetzt zu unflexibel, was die Pfade und Config betrifft.