dynaperl

100% porentief rein

Artikel mit ‘Network’ getagged

Frage NAT oder nicht NAT fuer IPv6

Dienstag, 02. Dezember 2008

Angeblich gibt es Streit um die Einführung bzw.  Standardisierung eines NAT Verfahrens für IPV6.  Natürlich gibt es immer wieder Protokolle die ihre Problem mit NAT haben (FTP, SIP, IPSec). Aber welche Probleme kommen erst auf uns zu wenn es für IPv6 kein NAT gibt? Ich für meinen Teil machen regen Gebrauch von NAT. Es bietet eine unglaubliche Flexibilität die für IPv6 nicht mehr vorhanden ist.

Beispiele:

  • HTTP Anfragen auf einen Proxy server umgeleitet (Transparenter Proxy) (DNAT/REDIRECT)
  • Load Balancing (DNAT)
  • Verteilen verschiedener Dienste auf unterschiedliche Hosts (DNAT)
  • Umrouten von Traffic über einen VPN Tunnel (SNAT)

Und gerade bei der Einführung von IPv6 wäre es extrem von Vorteil wenn man zwischen IPv4 und IPv6 NATen könnte.

Die Idee das man bei IPv6 ganz einfach den Netzteil der Adresse tauschen könnte und die Hosts sich dann einfach neue Adressen besorgen ist realitäts fern. Auf jedem Rechner sind IP Adressen an underten Stellen fest vercodet. Es ist also extrem Praktisch intern andere Adressen zu verwenden (die sich nie ändern) als extern und auf dem Router diese zu NATen.

Auch von vorneherei immer /48er Blöcke zu vergeben halte ich für Schwachsinn. So gut wie niemand braucht wirklich so viele (65535*5) Adressen. Das wird nur dazu führen das die Adressen frühzeitig wieder knapp werden. Das war bis jetzt immer so.

TCP-Syn Dos

Samstag, 29. November 2008

Wir hatten heute auf eine Kundenseite ein Dos Angriff per TCP-Syn. Ich habe ein paar Minuten gebraucht um drauf zu kommen. Die beiden Webserver auf denen die Seite liegt ungewöhnlich wenig zu tun. Nur vereinzelnd verirrte sich ein Request ins Logfile. Tcpdump zeigte dann ungewöhnlich viele Syn Pakete. Ein blick auf den Traffic Graph zeigte dann auch 50Mbit/s eingehenden Traffic.

Ich habe dann tcpdump nach tcp-syn Paketen suchen lassen, die Zeile mit der IP-Adressen raus geschnitten, den Port entfernt, sortiert, doppelte IP’s entfernt und gezählt wie oft jede Adresse vor kommt.

tcpdump -pn -i bond0.204 'tcp[13] = 2' | cut -d " " -f 3 | cut -d "." -f 1-4 | sort | uniq -c | sort | tail -10

1086 87.181.77.64
7305 88.71.48.146
30695 87.209.6.253
35020 87.67.221.211
106085 69.111.79.128

Mit den IP’s wurde dann ein ipset gefüttert das die Jungs erstmal ausgesperrt hat. Es wäre wohl zu einfach gewesen wenn das Problem damit beseitigt worden wäre. Nach zwei Stunden ging es wieder los. Diesmal mit etwas mehr Source Adressen (ca. 300 anstatt nur 5).

Ich stellte mich also auf ein längeres Gastspiel ein und aktivierte auf den Webservern tcp_syncookies (was aber komischer weise nicht viel geholfen hat wie sich später raus stellte). Um halb zehn wurde ich von Nagios aus meinem verdienten Feierabend gerissen. Auf dem Router vor den Webservern war die Connection-Tracking Tabelle übergelaufen (nf_conntrack: table full, dropping packet). Also wurden die viel zu niedrigen default Werte erhöht und ein Script geschrieben das die lästigen Störer automatisch blockiert.

Default Werte erhöhen:
echo 262144 > /sys/module/nf_conntrack_ipv4/parameters/hashsize
echo 2097152 > /proc/sys/net/ipv4/netfilter/ip_conntrack_max

Script:

for ip in $(ssh 192.168.100.102 'netstat -ant|grep SYN|sed -e "s/ \+/ /g" | cut -d " " -f 5|cut -d ":" -f 1|sort|uniq -c|sort -g | awk -F" " "\$1 > 30 {print \$2}"');
do
  ipset -T BAD_HOST $ip >/dev/null || {
    ipset -A BAD_HOST $ip;
    echo "ban Host $ip";
  }
done

Fazit
Bisher hat das jetzt gut funktioniert. Es gab früh morgens um halb eins noch mal einen Versuch von dem ich zum Glück nichts mitbekommen habe. Allerdings war der Angriff, wenn man ihn denn überhaupt so nennen darf, eher halbherzig. Zum einen gibt es in so einen Bot Netz wohl mehr als nur eine Handvoll Hosts und zum anderen hätten sie bei einem TCP-Syn Angriff die Quell Adressen fälschen können. Dann hätte ich mit meinem Script schön blöd ausgesehen. Für’s nächste Mal werde ich mir wohl was schönes einfallen lassen müssen.