DDoS Beteiligung bei öffentlichem DNS
Wer einen öffentlichen DNS Resolver betreibt, wird früher oder später die Aufmerksamkeit von DDoS Aktivisten auf sich ziehen.
In der Regel erlaubt man beim Betrieb eines Bind DNS Server nur die Auflösung der eigenen Domains:
# vi /etc/bind/named.conf allow-recursion { none; };
Oft ist auch die rekursive Auflösung über weitere DNS Server für beliebige Domains auf einzelne IP-Adresskreise freigeschaltet:
# vi /etc/bind/named.conf forwarders { 208.67.222.222; 8.8.8.8; }; allow-recursion { 10.0.0.x/32; };
Wer seinem Provider und öffentlichen DNS Servern nicht vertraut, erlaubt sich vielleicht den Luxus einen komplett öffentlichen DNS Resolver zu betreiben:
# vi /etc/bind/named.conf forwarders { 208.67.222.222; 8.8.8.8; }; allow-recursion { any; };
Hier kommen die DDoS Aktivisten auf den Plan. Entdecken sie einen offenen DNS Resolver, wird er ganz schnell in eine DDoS Attacke gegen diverse Domains integriert. Tausende von Anfragen wie die folgende werden aufgelöst:
18-Aug-2013 14:57:59.622 client 37.187.67.114#56818 (ietf.org): query: ietf.org IN ANY +E (46.4.179.236)
Der schlaue Admin wird jetzt erstmal Response Rate Limiting (RRL) aktivieren:
# USE="rrl" emerge bind -av # vi /etc/bind/named.conf rate-limit { responses-per-second 1; window 10; }; # /etc/init.d/named restart
Hier muss man die Werte natürlich an die eigenen Bedürfnisse anpassen. Ein DNS Server für wenige DSL Anschlüsse benötigt andere Werte wie ein DNS Server für eine große Firma und ihre Außendienstmitarbeiter.
Doch die Aktivisten sind nicht dumm. Die Abfragen werden einfach auf mehrere Server verteilt:
# grep 'ietf.org' /var/log/named/queries.log \ |cut -d' ' -f4|cut -d\# -f1|sort|uniq 1.1.1.1 110.81.107.222 168.62.23.92 168.63.125.125 178.16.65.94 186.146.21.238 192.119.149.2 193.215.6.139 194.105.152.102 195.36.6.33 198.24.160.43 ...
Also wird der Admin wieder aktiv … diesmal mit fail2ban. Dazu richtet er im ersten Schritt die notwendigen Logging Optionen ein:
# vi /etc/bind/named.conf logging { channel queries-log { file "/var/log/named/queries.log"; \ severity info; print-time yes; }; category queries { queries-log; }; }; # /etc/init.d/named restart
Jetzt installiert er fail2ban:
# emerge fail2ban -av # rc-update add fail2ban default
Danach richtet er eine Regel ein:
# vi /etc/fail2ban/jail.conf [named-ddos-udp] enabled = true filter = named-ddos action = iptables[name=named, port=domain, protocol=udp] logpath = /var/log/named/queries.log maxretry = 5 # vi /etc/fail2ban/filter.d/named-ddos.conf [Definition] _daemon=named __pid_re=(?:\[\d+\]) __daemon_re=\(?%(_daemon)s(?:\(\S+\))?\)?:? __daemon_combs_re=(?:%(__pid_re)s?:\s+%(__daemon_re)s \ |%(__daemon_re)s%(__pid_re)s?:) __line_prefix=(?:\s\S+ %(__daemon_combs_re)s\s+)? failregex = %(__line_prefix)sclient#.*: query: ietf.org IN ANY \+E ignoreregex = # /etc/init.d/fail2ban start
Glücklich wie ein Schneekönig stellt er nach kurzer Zeit fest, dass er die Aktivisten ausgesperrt hat:
# iptables -nvL fail2ban-named Chain fail2ban-named (1 references) pkts bytes target prot opt in out source destination 961 69192 REJECT all -- * * 46.109.0.56 0.0.0.0/0 reject... 713 51336 REJECT all -- * * 93.213.67.35 0.0.0.0/0 reject...
Tauchen in der Liste die IP’s der eigenen Firma, oder anderer regulärer DNS Server auf, sollte man eine Whitelist in der fail2ban Konfiguration anlegen.
Nach zirka einer Stunde will er sein stolzes Schild nochmal glänzen sehen und stellt fest, dass er gelumpt wurde!
18-Aug-2013 15:54:17.690 client 2.124.209.118#60592 (Edelion.su): query: Edelion.su IN ANY +E (46.4.179.236)
Die Aktivisten nutzen den DNS Resolver jetzt einfach für eine andere Domain … aber der Admin gibt nicht auf.
Wenn für eine Domain zu viele Anfragen gestellt werden, müsste das RRL anschlagen, also aktiviert er auch hier das Logging:
# vi /etc/bind/named.conf logging { channel default-log { file "/var/log/named/named.log"; \ severity info; print-time yes; }; category default { default-log; }; }; # /etc/init.d/named restart
Jetzt erscheinen die Übeltäter auch in dieser Datei:
18-Aug-2013 16:01:04.248 info: client 186.227.62.78#52034 (Edelion.su): rate limit slip response to 186.227.62.0/24 for Edelion.su IN ANY (05977b29)
Diese Information wird wieder in eine fail2ban Regel umgewandelt:
# vi /etc/fail2ban/jail.conf [named-ddos2-udp] enabled = true filter = named-ddos2 action = iptables[name=named2, port=domain, protocol=udp] logpath = /var/log/named/named.log maxretry = 5 # vi /etc/fail2ban/filter.d/named-ddos2.conf [Definition] _daemon=named __pid_re=(?:\[\d+\]) __daemon_re=\(?%(_daemon)s(?:\(\S+\))?\)?:? __daemon_combs_re=(?:%(__pid_re)s?:\s+%(__daemon_re)s \ |%(__daemon_re)s%(__pid_re)s?:) __line_prefix=(?:\s\S+ %(__daemon_combs_re)s\s+)? failregex = %(__line_prefix)sinfo: client#.*: rate limit slip response.* ignoreregex = # /etc/init.d/fail2ban reload
Prompt tappen die ersten in die Falle:
# iptables -nvL fail2ban-named2 Chain fail2ban-named2 (1 references) pkts bytes target prot opt in out source destination 1167 84024 REJECT all -- * * 72.8.190.52 0.0.0.0/0 reject... 2964 213K REJECT all -- * * 79.121.40.234 0.0.0.0/0 reject...
Jetzt haben es die Aktivisten schwer. Wird eine Domain aus Regel 1 gefunden, landen die IP’s auf der Sperrliste. Wechseln sie die Domain und sind zu gierig, schlägt Regel 2 zu und setzt die IP’s auch auf die Sperrliste!
Ich bin gespannt, was man sich als Nächstes einfallen lässt!