Serendipity und IPv6

Saturday, October 6. 2012

Serendipity ist die Software, die dieses Blog liefert, und wegen eines IPv6-bezogenen bug dieser Software war dies blog mehr als einen Tag offline. 
Serendipity hat ein plugin Spamschutz mit einer Reihe von Möglichkeiten, Kommentarspam zu bekämpfen, und eine davon ist, erkannte Spammer per IP vom Zugang zum Blog auszuschliessen. Das hat sich hier gegen bestimmte Serienspammer erstaunlich gut bewährt. 

Bis der erste Spammer mit einer IPv6-Adresse gelogt wurde, danach war mein blog weg.

Das Problem ist: 

serendipity_event_spamblock.php patzt bei der Behandlung von IPv6-Adressen. IPv4 sind kürzer als IPv6 Adressen.
(IPv4: 4 Teile x 3 Stellen + 3 Trenner = 15 Zeichen  IPv6: 8 x 4 + 7 = 39). Darauf ist das plugin nicht eingerichtet.
Wenn man in der config des Plugin "SPAM IP Adressen via HTaccess blocken? " 'Ja' ankreuzt und eine IPv6-IP als Spam erkannt worden ist, dann schreibt das Plugin in die .htaccess etwas ähnliches wie:
 
#SPAMDENY
Deny From 205.189.73.46 205.189.73.64 208.89.211.173 217.157.179.122 24.62.10.133 
2607:5300:10:60 31.135.196.229 37.10.106.185 37.10.112.228 37.10.116.107 37.10.116.35 
#/SPAMDENY
 
Problematisch ist der Eintrag '2607:5300:10:60' Das ist keine gültige IP sondern nur die vordere Hälfte einer IPv6. Und so bekommt man nun bei jedem Versuch, das Blog zu laden, eine wunderschöne 500er-Fehlermeldung mit dem Hinweis auf 'invalid IP'
 
Das Hackstück aus der .htaccess zu löschen hilft auch nicht, denn mit dem naechsten Spammer wird der ganze deny from... - Block neu aus der Datenbank gelesen und eingeschrieben, incl. des fehlerhaften Eintrags. Die zuständige Tabelle heisst serendipity_spamblock_htaccess und ist wohl auch gleich die Schuldige an dem Bug. 
 
Diese Tabelle hat zwei Felder, timestamp vom Typ varchar(19) unsigned und ip vom Typ varchar(15). Eine Breite von 15 ist fuer legacy IPs grad recht, für IPv6 ist das ein Fehler. Benötigt wird eine Feldbreite von varchar(39). 
 
Massnahmen:
- Breite des Feldes ip auf 39 hochsetzen
- alle (in meinem Fall nur 1) defekte IPv6 löschen
o shell öffnen, 
o mysql -u (username) -p (und passwort)
o use (datenbankName)
o delete from `serendipity_spamblock_htaccess` where (`ip` like "%:%");
- auf den nächsten Spammer mit IPv6 warten...

Some minor edit to this blog, save, and instead of the usual messages I get an error message  incorrect key file for table ./database/serendipity_entries.MYI; try to repair it! Collateral damage: text has not been saved.

I tried Google to find some attempts to downplay the issue, possibly just a hd completly used. But this is not what has happened for me, tmpfs still has 505MB left and the Index file mentioned in the error report is just 320Kb. So I search on and find check table und repair table. The documentation recommends a prior backup. then:

mysql -u root -p
use database;

CHECK TABLE serendipity_entries;

 
(output denotes the table as corrupt)
 
REPAIR TABLE serendipity_entries;
 
+------------------------------+--------+----------+----------+
 
| Table                        | Op     | Msg_type | Msg_text |
 
+------------------------------+--------+----------+----------+
 
| web31db1.serendipity_entries | repair | status   | OK       |
+------------------------------+--------+----------+----------+
 
and that's it, savine works again.

IPv6 - manches geht, manches nicht

Wednesday, February 8. 2012

Bei webmin war ich der festen Ansicht, dass IPv6 nicht geht und nie gehen wird. Ich hatte mal so eine Bemerkung auf der Projektseite gelesen, und da es in perl ist (perl considered harmful)... Stimmt aber gar nicht (mehr): 

aktuelle Versionen von webmin lassen sich mit einem mausklick Ipv6-enablen, alles, was sie dazu brauchen, ist, ein package:

 apt-get install  libio-socket-inet6-perl

Anschliessend nach Webmin/Webmin Configuration/Ports and Adresses/  und dort Accept IPv6 connections? mit Yes, fertig!
 
Der richtig dicke Vorteil von IPv6 ist ja, dass nun endlich die IPs nicht mehr knapp sind und man ganz ohne portumleitung und derlei Grauslichkeiten Clients und Server wieder end to end zusammenbekommt, auch wenn zwischen ihnen ein oder mehrere dsl mit dynamischen IP(v4) sind. Beispiel VPN oder Monitoring.
Erm, ja, ausser man hat auf openVpn gesetzt. Oder man versucht, zu nagios/icinga auf zu überwachenden Maschinen einen nrpe-server zu installieren. Der nrpe-Server horcht aber nur auf IPv4 und aus ist. Jetzt prokel ich in einem inoffiziellen Fork
E
in freundlicher Blogger verweist mich auf den icinga - nrpe, den hatte ich zuvor wohl übersehen. Einen Erfolg kann ich aber auch damit bislang nicht vermelden, mehrere Anläufe, buchstabengetreu oder mitdenkend den Angaben des Link zu folgen kompilierten fehlerfrei, blieben dann aber doch im ersten Test stecken:
/usr/local/icinga/libexec/check_nrpe -H 127.0.0.1 -n
CHECK_NRPE: Error receiving data from daemon.
hmm. Sachdienliche Hinweise richten sie bitte an die Kommentarfunktion weiter unten...
 
Mysql ist auch nicht ganz auf IPv6 eingerichtet, jedenfalls 5.1.49 aus debian/squeeze. 
netstat -tulpn|grep mysql
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      19179/mysqld
und auf ::1 lauscht er eben nicht. Eine erhellende Diskussion zum Thema fand ich, und darin einen Link zu mysql 5.5 für squeeze, erprobt habe ich dies aber nicht.
 
 iftop gibt eine gute Übersicht über den Verkehr im Netzwerk, aber in debian squeeze nur für IPv4. Squeeze kommt mit iftop 0.17-16, IPv6 support gibt es erst ab 0.17-17 - leider ist auch in squeeze-backports nichts dabei.

 

(Page 1 of 1, totaling 3 entries)