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!