Bluetooth-Kopfhörer-Verbindung

Ich hatte lange das Problem, dass kurz nachdem Bluetooth-Verbindungsaufbau von meinem Arch Linux (Thinkpad x220) die Verbindung wieder beendet wurde.

Die Lösung:

# Verbindung beenden (falls noch nicht geschehen), dann:
pactl load-module module-bluetooth-discover

Via Ubuntu Forums

Dauerhaft aktivieren sollte man vielleicht diese Zeilen in /etc/pulse/default.pa

.ifexists module-bluetooth-policy.so
load-module module-bluetooth-policy
.endif

.ifexists module-bluetooth-discover.so
load-module module-bluetooth-discover
.endif

Measures against Slowloris attacks

In a Slowloris attack a client (or a botnet) opens a large amount of connections to a web server and holds them open. It does not send complete requests so you might find no request of the attacker in an Apache log — quite devious. So… The malicious client continues to open new connections using incomplete requests while Apache is waiting for complete requests in order to serve the client. Meanwhile, regular clients cannot open new connections and thus do not get to be served by the host — the site gets unresponsive.

I just wanted to share my experience with anti slowloris measurements on small-scale Apache webservers.

Apache 2.2.15 comes with mod_reqtimeout. The module’s default settings work out of the box. During my own local slowloris attack http latency fluctuated quite a lot but Apache remained responsive. If you are using Apache 2.2.15, go for mod_reqtimeout and you are done.

Debian 5.0 provides Apache 2.2.9 only and there is no mod_reqtimeout for this version.

My first choice for Apache 2.2.9 was mod_qos which I got compiled smoothly. When an attack is launched, http latency rises sharply for about five seconds. After that, latency normalizes quickly. A quite impressive result. OTOH, while there were no obvious problems reported by site users, the module spammed Apache’s error log with backtraces which forced me to search for another solution.

Next option was mod_antiloris which is a very small module with just over 5 kb of source. It compiled smoothly and worked out of the box. There are no configuration options though. During an attack, http latency rises quickly and remains high. The site gets somewhat less responsive but Apache continues to answer requests. Not as impressive as mod_qos but at least it does not clog error.log with backtraces so I am sticking with mod_antiloris for the time being.

Keep in mind that I have only tested attacks from a single client. A botnet executing a slowloris attack is a completely different story.

And BTW: YMMV.

If you have a different approach for plain Debian systems, feel free to comment.

MySQL macht “Peng”…

Heute hatte ich es wieder einmal mit einem abgeschossenen MySQL-Server zu tun, dieses Mal von einem Neukunden. Zur Abwechslung hat dieses Mal der Hoster (!) an der Maschine herumgespielt und sie ohne den Kunden zu informieren während des Betriebs neu gestartet — ohne die Dienste herunterzufahren.

Da fässt man sich nur noch an den Kopf. Das Resultat war natürlich klar — die Datenbank war kaputt.

Was tun… Einen Dump des aktuellen Stands der Datenbank ziehen ging nicht. Schreibzugriffe verhindern per LOCK ging nicht. Per MySQL reparieren ging auch nicht, denn die betroffenen Tabellen waren zum Teil InnoDB-Tabellen, die man lt. MySQL nicht reparieren kann. Ich habe dann den MySQL-Server neu installiert und vorher /var/lib/mysql aufgeräumt. Nun wirds interessant: Ein einige Stunden altes Backup, von dem ich annahm, dass es keine Fehler hatte, konnte ich zwar einspielen. Beim ersten Starten des MySQL-Daemons wurde kein Fehler angezeigt — bei den folgenden Neustarts aber schon: Fehlerhafte Tabellen…. WTF?

Das konnte nicht sein. Ein Problem mit dem Dateisystem konnte es auch nicht sein. Testweise habe ich die MySQL-Dateien auf eine andere Partition geschoben. Das Ergebnis war das gleiche. So langsam gingen mir die Ideen aus, wie ich das Problem schnell beheben konnte. Die nächste Idee: Wenn InnoDB-Tabellen nicht repariert werden können, nehmen wir eben MyISAM-Tabellen. Also den Dump entsprechend manipuliert und wieder eingespielt — voila. Ohne REPAIR wohlgemerkt.

Der Kunde war gerettet und der Abend gleich mit.