Cache Traffic fürs Blog: November 2022 – Part II

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.

Linux am Dienstag – Programm für den 6.12.2022

Der Nikolaustag ist eine Linux am Dienstag 😀 Ob der auch Linux benutzt? 😉

Linux am Dienstag – Programm für den 6.12.2022

Dienstag Abend ab 19 Uhr geht es u.a. um:

  • Linux – Apple GPUS bekommen Linux Treiber
  • Sicherheit – Angriffe auf alles und Jeden, Ihr werdet schon sehen 🙁
  • Sicherheit – ACER Laptops mit SecureBoot Lücke
  • Datenschutz – Twitterbenutzerdaten veröffentlicht
  • Vortrag – Ein Blick auf Plasma Mobile (Marius)

und andere IT-Newsbeiträge aus aller Welt. Wie jede Woche per Videokonferenz auf https://meet.cloud-foo.de/Linux .

Hinweis: Die bisherigen Vorträge findet man unter https://linux-am-dienstag.de/archiv/ .

Cache Traffic fürs Blog: November 2022

Ich habe da mal was für Euch mitgebracht. Für den einen oder anderen Blogger dürfte das interessant sein.

Cache Traffic fürs Blog: November 2022

Ihr wißt ja, daß ich vor einigen Wochen mein Blog hinter ein ATS Cache gestellt habe, weil der Seitenaufbau schon langsam wurde. „WordPress“ und die Begriffe „Klein. Schnell. Effektiv“ gehen echt schon lange nicht mehr zusammen 🙁

Da das Cache von sich aus keine vernünftigen Statistiken produzieren kann, die länger als 24h Stunden sind, habe ich im Oktober selbst was gebaut, daß uns diese Daten erzeugt hat. Immer gegen 23:59 wird die tägliche Cache Statistik ausgewertet.

DatumDomainCachedUncached
2022-11-01marius.bloggt-in-braunschweig.de6.89111.800
2022-11-02marius.bloggt-in-braunschweig.de6.49712.632
2022-11-03marius.bloggt-in-braunschweig.de6.24320.164
2022-11-04marius.bloggt-in-braunschweig.de5.10121.138
2022-11-05marius.bloggt-in-braunschweig.de4.53021.964
2022-11-06marius.bloggt-in-braunschweig.de6.2293.870
2022-11-07marius.bloggt-in-braunschweig.de6.0067.245
2022-11-08marius.bloggt-in-braunschweig.de6.78315.956
2022-11-09marius.bloggt-in-braunschweig.de7.07217.213
2022-11-10marius.bloggt-in-braunschweig.de8.55518.834
2022-11-11marius.bloggt-in-braunschweig.de8.8569.707
2022-11-12marius.bloggt-in-braunschweig.de6.72212.182
2022-11-13marius.bloggt-in-braunschweig.de6.3075.880
2022-11-14marius.bloggt-in-braunschweig.de6.2139.338
2022-11-15marius.bloggt-in-braunschweig.de1.9881.233
2022-11-16marius.bloggt-in-braunschweig.de3.8144.008
2022-11-17marius.bloggt-in-braunschweig.de5.1633.015
2022-11-18marius.bloggt-in-braunschweig.de5.6136.415
2022-11-19marius.bloggt-in-braunschweig.de4.9324.733
2022-11-20marius.bloggt-in-braunschweig.de5.0375.112
2022-11-21marius.bloggt-in-braunschweig.de5.1949.478
2022-11-22marius.bloggt-in-braunschweig.de5.9418.449
2022-11-23marius.bloggt-in-braunschweig.de5.4864.567
2022-11-24marius.bloggt-in-braunschweig.de5.1548.515
2022-11-25marius.bloggt-in-braunschweig.de4.9974.073
2022-11-26marius.bloggt-in-braunschweig.de4.6604.586
2022-11-27marius.bloggt-in-braunschweig.de4.6737.226
2022-11-28marius.bloggt-in-braunschweig.de5.0616.082
2022-11-29marius.bloggt-in-braunschweig.de5.2858.368
2022-11-30marius.bloggt-in-braunschweig.de5.7578.426
Summe November452.969170.760282.209

Jetzt cached so ein Cache natürlich nicht nur PHP Seiten, sondern alles von CSS, JS über GIF bis TXT und HTML.

d.b. ich hatte keine 452.969 Seitenaufrüfe 🙂 Die genaue Zahl läßt sich nur Ahnen, bzw. dafür müßte man die Webserverlogs vom Blog analysieren.

Hauptproblem

es gibt über 1200 Seiten im Blog, die alle die gleichen CSS Dateien haben, und sich ggf. auch JS, PNGs etc. teilen. Diese 1200 Seiten werden auch regelmäßig aufgerufen, sei es durch Google oder weil Menschen da auf interessante Links geklickt haben, auf der Suche nach Lösungen.

Das liegt daran, daß statische Elemente für alle Seiten gleich sind und gecacht werden, was ja der Sinn der Übung war. Da die in allen Seiten drin sind, tauchen die natürlich auch bei ungecachten Webseitenaufrüfen als „gecacht“ auf. d.b. der Anteil der statischen Randelemente wie Css,JS,Png sind in der gecachten Zahl stark überrepräsentiert, in der Zahl der ungecachten aber praktisch nicht vorhanden.

Da nur stark frequentierte Seiten, wie z.B. die Startseite im Blog oder echt gut laufende Artikel, überhaupt gecacht werden, weil die Cachezeit z.Z. bei 30 Minuten liegt, tauchen die übermäßig in der gecachten Zahl auf und sind in der ungecachten Zahl und mit wenigen Aufrüfen enthalten. (Hinweis: die müssen da auftauchen, weil wenn es nicht im Cache ist, muß es ja einmal min. nachgeladen werden, was ein ungecachter Aufruf ist).

Das führt uns dazu, daß die ungecachte Zahl (in der Liste oben: rechts) hauptsächlich die alten Beiträge beinhaltet und die gecachte Zahl alle statischen Inhalte und hauptsächlich die Startseitenaufrufe beinhaltet.

Jetzt könnte man eine statistische Untersuchen machen und feststellen, daß 9/10 gecachten Aufrüfen auf Grafiken etc. gingen. Meint, ~ 17.000 Aufrufe auf die Startseite bleiben da übrig, der Rest steckt in der ungecachten Zahl.

Die setzt sich so zusammen

Für Euch stürze ich mich natürlich in alle Mühen und hab mal die Serverstatistiken bearbeitet. Da das Cache eine eindeutige IP benutzt um auf den Backendserver zuzugreifen, konnte ich alle Zugriffe für November ausfiltern.

Das waren OHNE CSS,javascript,Jpg,Gif,Png : 234.469

Wenn man sich das genauer ansieht, findet man da drin RSS Zugriffe, Suchen nach Tags und Kategorien. Filtern wir die mit aus, bleiben 114.919 reine Seitenaufrufe übrig OHNE die gecachten Startseitenaufrüfe, also fast alles außer „/“ . Wir dürfen annehmen, daß es ein insgesamt mauer November für das Blog war mit ca. 131.000 Abrufen. Da hat das Blog mit knapp 250.000 schon bessere Monate gesehen. Aber, Transparenz bedeutet ja, nicht nur die guten Monate zu zeigen, sondern auch mal weniger gute 😉

Ganz genau bekommt man die Zahlen wegen des Caches nicht mehr zusammen, außer man wertet dauerhaft die Zugrifflogs vom Cache aus, was für eine Statistik Anwendung recht anspruchsvoll sein wird. Vielleicht baue ich da mal was 😉 Ich gehe davon aus, daß der statische Anteil weniger als 9/10 ist, was mehr Seitenzugriffe auf „/“ zur Folge hätte.