0-Byte-VoIP-Daemon-DoS mit Bordmitteln verhindern

[aldee]

Nachdem ich das iptables-length-Modul zum Laufen bekommen habe, stellte sich mir natürlich die Frage, wie man die Box dazu bekommt, auch nach einem Neustart eine iptables-Rule, die "böse" 0-Byte-UDP-Pakete ausfiltert, zu beherzigen.

Das firewall-cgi eignet sich ja derzeit nur für Standard-Regelsätze. Ich bin das dann über die debug.cfg angegangen, die sieht jetzt wie folgt aus:

sed 's#iptables -A FIREWALL_FWD -j DROP#iptables -A FIREWALL_FWD -j DROP\n\n     iptables -A INPUT -m length -p udp --dport 5060 --length 0 -j DROP#' /etc/init.d/rc.firewall >/var/tmp/rc.firewall
chmod 755 /var/tmp/rc.firewall
mount --bind /var/tmp/rc.firewall /etc/init.d/rc.firewall
/etc/init.d/rc.firewall restart

Nicht schön, aber zumindest funktioniert's. Evtl. hilft es ja jemandem weiter.

Zu beachten wäre evtl. noch, dass bei dieser Alternative Änderungen im firewall-cgi einen Neustart der Box möglicherweise nicht mehr überleben (nicht getestet). Sollte das der Fall sein, per Telnet auf die Box, umount /etc/init.d/rc.firewall, Änderungen im firewall-cgi durchführen, Box neu starten (oder debug.cfg ausführen).

Ansonsten kann man die rc.firewall natürlich auch direkt vor Kompilierung des images ändern, sprich, folgende Zeile hinzufügen:

iptables -A INPUT -m length -p udp --dport 5060 --length 0 -j DROP

In beiden Fällen muss das iptables-length-Modul installiert sein. Dazu müssen im make menuconfig vom ds-mod folgende Optionen zusätzlich zum "normalen" Firewall-Support (etwa durch Auswahl des firewall-cgi) aktiviert werden:

Advanced options ---> Kernel modules ---> net ---> ipt_length.o
Advanced options ---> Shared libraries ---> iptables ---> libipt_length.so


Edit: das scheint nicht wirklich zuverlässig zu funktionieren. Selbst mit Blockieren sämtlicher udp-Pakete auf Port 5060 mittels iptables lässt sich das Ding zumindest nach Versand zahlreicher 0-Byte-Pakete abschießen. Da geht IMO etwas Merkwürdiges vor. Wenn jemand weiß, woran es liegt, immer her damit ;-).

Der voipd lässt sich auch auf einem anderen Port starten. Theoretisch sollte es also möglich sein, einen Proxy auf der Box aufzusetzen, der entsprechend vorfiltert. Soweit ich sehe, ist der Sourcecode der voipd-Applikation ja nicht verfügbar :-(.

Das da:

Jan 21 19:09:24 fritz user.err voipd[1823]: 0.0.0.0:5060: recvfrom failed (0) - No such file or directory (2)
Jan 21 19:09:28 fritz user.err voipd[1823]: BUG csock_senddgram: called with NULL socket
Jan 21 19:09:28 fritz user.err voipd[1823]: sipudp: senddgram failed (212.227.15.197:5060)
Jan 21 19:09:28 fritz user.err voipd[1823]: BUG csock_senddgram: called with NULL socket
Jan 21 19:09:28 fritz user.err voipd[1823]: sipudp: senddgram failed (212.227.15.225:5060)
Jan 21 19:09:28 fritz user.err voipd[1823]: BUG csock_senddgram: called with NULL socket
Jan 21 19:09:28 fritz user.err voipd[1823]: sipudp: senddgram failed (212.227.15.198:5060)
Jan 21 19:09:39 fritz user.err voipd[1823]: BUG csock_senddgram: called with NULL socket
Jan 21 19:09:39 fritz user.err voipd[1823]: sipudp: senddgram failed (212.227.15.197:5060)
Jan 21 19:09:39 fritz user.err voipd[1823]: BUG csock_senddgram: called with NULL socket
Jan 21 19:09:39 fritz user.err voipd[1823]: sipudp: senddgram failed (212.227.15.225:5060)
Jan 21 19:09:39 fritz user.err voipd[1823]: BUG csock_senddgram: called with NULL socket
Jan 21 19:09:39 fritz user.err voipd[1823]: sipudp: senddgram failed (212.227.15.198:5060)

sollte ansonsten vermutlich nicht allzu schwer zu umgehen sein.

 

[doppelfritz]

Hallo,
die nächsten AVM-Updates sollen die Boxen vor 0-Byte-Packets schützen. Daher braucht man das meiner Meinung nach nicht selbst machen.

 

[aldee]

Die aktuellen Firmware-Versionen beinhalten bereits eine Korrektur. Nichtsdestotrotz halte ich es für bedenklich, dass sich die Box gegenüber iptables derart "ignorant" verhält ;-).