Blog-Stats seit Einführung des Trafficcache

Ich hatte ja letztes Jahr einen Apache Trafficserver vor das Blog geschaltet, damit die Aufrufzeit des Blogs besser wird. Das hat auch funktioniert, führte aber in den Statstools der Webseite, dazu, daß weniger angezeigt wird, weil weniger im WordPress ankommt.

Blog-Stats seit Einführung des Trafficcache

Schauen wir doch mal rein, was im März 2023 wirklich gewesen ist… 😀

Die Liste mit den TOP 30 URLS habe ich um Seiten wie Javascript, CSS, FEEDS usw. bereinigt. Da die bei allen Seiten beteiligt sind, ist klar, daß die mehr Aufrüfe als die echten Seiten haben. Daher die komischen Positionen in der TOP-Liste 😉 An Platz ein war die XMLRPC, weil die Hacker die mit Forenspam bombardieren 😀

Der Anfang des Jahres ist seit Bestehen des Blogs eher schwach besetzt, was ein Blick in die letzten 6 Monate bestätigt:

Die Zahlen für April sind logischerweise noch nicht relevant.

Falls Ihr auch ein Cache haben wollt

Gibt es da mehrere Möglichkeiten: Ihr geht zu CloudFlare, zu meiner Firma, oder setzt Euch das Cache selbst auf. Letzteres ist eine tolle Kompetenzübung in Sachen Web, weil Ihr alle den Spaß erfahren werdet, den ich auch hatte 🙂 Da Ihr den ganzen Loggingkram dann selbst bauen müßt, könnte das den einen oder anderen überfordern. Ist echt nicht für jeden was. Zum Auswerten habe ich Webalizer nutzen müssen, weil alle anderen noch komplizierter Anzubinden waren oder gar nicht erst funktioniert hätten.

Den Apache Trafficserver könnt Ihr aus dem Fedora Repo bekommen, oder bei apache.org .

Linux am Dienstag: Programm für den 12. Oktober 2021

Einen verregneten Dienstag kann man nur durch den Sonnenschein am Abend aufwerten 😀

Linux am Dienstag: Programm für den 12. Oktober 2021

Ab 19 Uhr wenden wir uns wieder mal Themen aus der Linuxwelt zu. u.a. im Programm:

  • Schwachstelle in Apache 2.4.49 – Exploit im Umlauf
    Schwachstelle in Apache 2.4.50 nur Halbherzig gefixt – Weiterer Exploit im Umlauf
    Schwachstelle bei Chrome – Will Google alle User vergraulen?
    Datenschutzskandal bei der SPD in Berlin
    Vortrag: „lokales LUKS verschlüsseltes Raid 10 mit Cloudhostern“ von Marius
    Vortrag: zu ZFS von Mario

Außerdem im Programm: „Exchange Mailserver in der Krise“. Natürlich sind wieder Nachrichten aus aller IT-Welt dabei.

Wie jede Woche per Videokonferenz auf https://meet.cloud-foo.de/Linux .

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

Schwachstellen im Apache Webserver < 2.4.44

Wer Apache als Webserver einsetzt, sollte jetzt aufpassen, denn wir haben jeweils eine  RCE und eine DOS Schwachstelle.

Schwachstellen im Apache Webserver < 2.4.44

In Apache wurden drei Schwachstellen identifiziert und im August behoben. Leider hat man u.a. bei Fedora vergessen, das publik zu machen, deswegen hier die Erinnerung für Euch:

Im HTTP2 Modul sind zwei Schwachstellen enthalten, die zum Crash führen und damit als DOS (Denial of Service) gelten:

important: Push Diary Crash on Specifically Crafted HTTP/2 Header (CVE-2020-9490)
moderate: Push Diary Crash on Specifically Crafted HTTP/2 Header (CVE-2020-11993)

Beide Schwachstellen kann man auch per Konfigurationsänderung abwehren, falls man keine gepatchten Webserver bekommen kann, oder noch nicht hat:

Je nachdem was Ihr für eine Distro habt, wird HTTP2 an verschiedenen Stellen aktiviert. Bei Fedora bietet sich an, eine eigene kleine Config in conf.modules.d/ anzulegen. In die Datei kommen zwei Einträge:

99-mitigate-http2.conf:

H2Push off
LogLevel warn mod_http2.c:error

Dann mit „systemctl httpd restart“ den Server neustarten. Die erste Anweisung behebt die 2020-9490 und die zweite sagt dem HTTP2 Modul, es soll nur kritische Sachen loggen, anstatt auch Warnungen. Das ist wichtig, da Angreifer über einen provozierten Fehler den Logging-Pool der Prozesse stören können und das führt dann zum Crash, was aber nur geht, wenn der Fehler auch geloggt wird.

moderate: mod_proxy_uwsgi buffer overflow (CVE-2020-11984)

Wer mit dem WebSocket Proxy uwsgi arbeitet, der muß updaten, eine Mitigation der möglichen Remote-Code-Schwachstelle ist nicht möglich. Bis zum Update kann man das Modul auch abschalten:

Für Fedora wäre das hier in conf.modules.d/00-proxy.conf:

# LoadModule proxy_uwsgi_module modules/mod_proxy_uwsgi.so

Einfach ein # vor die Ladeanweisung und den Webserver mit „systemctl httpd restart“ neustarten. Natürlich funktionieren die Proxy Tunnel, die auf „uwsgi:://server:port/uri“ lauten, dann nicht mehr. Habt Ihr noch einen vhost konfiguriert, der das benutzen möchte, wird der Start des Webservers nicht funktionieren.

Updates vorhanden

Updates auf die 2.4.46 liegen für Fedora bereit. Für alle, die Ihre Server per Autoupdate versorgen, hat sich das Problem damit bereits erledigt.