Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Größere Firewall Lösung - SYN/DDOS Angriffe

Guten Morgen,

ich bin neu in diesem Forum und habe von den Sophos UTM Entwicklern den Hinweis bekommen, mich mit meinem Problem doch einmal an die Community zu wenden, da es doch etwas sehr speziell ist.

In den nächsten Wochen möchten wir eine Endkundenfähige Firewall Lösung anbieten und haben uns dabei entschlossen, Sophos UTM einzusetzen. Grund dafür ist, dass wir bereits seit mehreren Jahren mit Hardware- und Software Appliances arbeiten und dieses Jahr ebenfalls eine Zertifizierung unserer Mitarbeiter vorgesehen ist. 
Wir haben uns daher Gedanken gemacht, wie wir eine Endkundenfähige Firewall Lösung anbieten können, worüber der Kunde u.a. auch VPN Gateways konfigurieren- und administrieren kann und die zudem auch DDOS und SYN Flood Angriffe standhalten kann.

Soweit so gut. Unsere Lösung hieß Virtualisierung. Das heißt, wir virtualisieren Software Appliances auf größeren Hostsystemen auf die der Kunde direkt zugreifen kann. Jeder Kunde hat daher eine eigene kleine Instanz und kann diese nach Bedarf konfigurieren oder von uns konfigurieren lassen. Das funktioniert soweit auch sehr gut, allerdings haben wir in den letzten Wochen einen Kunden dazu bekommen, der regelmäßig unter diversen Angriffen zu leiden hat. Sei es UDP Flood, SYN Flood oder Angriffe, die wir bislang noch nicht identifizieren können. Mit zwei der Angriffe kommt die UTM leider nicht ganz klar und auf diese zwei Angriffe möchte ich weiter eingehen um eventuell jemanden in der Community zu finden, der schon vergleichbare Probleme hatte.

-----------------------------------------------
Allgemeine Informationen
-----------------------------------------------
Hostsystem Hardware
2x Intel Xeon E5-2620
128 GB DDR3-1333 ECC Reg RAM
4x 300 GB SAS im Hardware RAID 10
Adaptec 6405E Hardware RAID Controller
1x Angebunden über 1 Gigabit IPMI
1x Angebunden über 10 Gigabit Fiber - Intel X520-DA2 Ethernet Server Adapter

Angebunden ist der Server im Rechenzentrum direkt mit 10 Gigabit Fiber zum Core Router und darüber direkt in das Internet. Auf dem 10 G Uplink sind verschiedene V-LANs tagged, da wir über die virtuellen Maschinen verschiedene Teilbereiche unseres Netzwerks schützen möchten. 

Als Virtualisierungssystem setzen wir Proxmox in der neusten Version ein auf Debian 7. Hierauf werden die UTMs als KVM VM virtualisiert. Jeder UTM VM weisen wir X 1 G Netzwerkkarten zu. Diese Netzwerkkarten Bündeln wir auf der Astaro über Port Bonding. Dies ermöglicht uns eine Limitierung der nutzbaren Bandbreite unserer Kunden. Ein kleiner Screenshot dazu:

https://www.ip-projects.de/astaro-config.png 

Hier gibt es verschiedene Bondings je nach V-LAN. Natürlich limitieren wir darüber auch die nutzbaren Systemressourcen. Wir möchten ja nicht, dass ein Kunde unser ganzes System lahmlegt.

Alle Sophos Instanzen sind auf der aktuellsten Version, genauso das darunterliegende Debian. 

Auf dem Hostsystem haben wir "net.netfilter.nf_conntrack_max = 500000" eingestellt, um ein Problem aufgrund von dieser Limitierung zu verhindern. 



-----------------------------------------------
Problem 1
-----------------------------------------------
Das erste Problem was wir haben betrifft UDP Floods. Wie bereits erwähnt haben wir einen Kunden, der sich bestens für den Betatest eignet, da er sehr sehr oft unter Angriffen steht. Natürlich möchten wir für diese Problematik eine Lösung bieten.

Vor 2 Tagen kam es zu einer 4,5 Gigabit/s großen UDP Flood auf eine seiner IP-Adressen. Diese Bandbreite kam auch auf der VM an, wie man unter Interfaces auf dem Dashboard der VM beobachten konnte. In der Firewall Livelog konnte ich schön sehen, wie die Sophos UTM fleißig damit beschäftigt war, Pakete zu filtern. Der Host selbst hat sich noch gelangweilt, der Load war unter 1. Die IPS Firewall hat ausschließlich die Regeln aktiv, die auf die Serversysteme dahinter passen. Es sind daher keine Rules aktiv, die gar nicht benötigt werden.

Sobald der Angriff allerdings gestartet war, war die IP-Adresse die geschützt werden sollte offline. Ich habe auf dem Dashboard unter Interfaces gesehen, dass 4 Gigabit auf der UTM zwar eintreffen, diese aber nur 1 Mbit weiterleitete. 

Die Frage ist daher, wenn die UTM alles erfolgreich wegfiltert, wieso ist dann die IP-Adresse dahinter dennoch offline?

Eine mögliche Bandbreitenbegrenzung im V-LAN von Seiten des Routers aus wurde entfernt, hier gab es also "no-limit" [:)]


-----------------------------------------------
Problem 2
-----------------------------------------------
Das ist das Problem, was mir eigentlich am meisten Sorge bereitet. Eine mir unbekannte Angriffsmöglichtkeit, die es schafft mit nur geringer Bandbreite das komplette Hostsystem lahmzulegen.

Neben UDP Flood bekommt der Kunde auch regelmäßig SYN Flood Angriffe, die die Firewall eigentlich recht gut in den Griff bekommt. Aber er bekommt auch einen Angriff, der mir nicht geläufig ist.

Bei diesem Angriff kann ich beobachten, dass die Bandbreite mit ca. 160 Mbit/s ausgelastet ist. Sobald aber die VM eingeschaltet wird und der Angriff versucht wird zu filtern, also die Pakete das Ziel erreichen, hat der komplette Host Anbindungsprobleme. Also das Problem wirkt sich in der Tat auf alle darauf betriebenen VMs einschließlich der Anbindung des Hosts selbst aus. Als ob die Netzwerkkarte nicht mit der Bearbeitung der Paketmenge zurecht kommen würde, was aber bei einer solchen Netzwerkkarte nur schwer vorstellbar ist. 

Über netstat -l konnte ich sehen, dass eine Vielzahl udpv6 Pakete über ein IPv6 Netz an den Server gesendet werden. Wir haben daher testweise IPv6 deaktiviert auf dem Host. Leider ohne Erfolg, die udpv6 Pakete waren zwar weg, nach Aktivierung der VM war das Problem aber beständig. Der Host selbst war aber CPU und Arbeitsspeicherseitig nicht voll ausgelastet und auch der Load war im Normalbereich.


---------------------------------------

Vielleicht ist jemand von euch schon einmal mit derartigem Problem


This thread was automatically locked due to age.
Parents
  • Zu Problem 1 konnten wir identifizieren, dass hier ein Angriff über den Port 53 auf den Server erfolgt.

    08:22:55  Default DROP  UDP 
    50.63.187.11  :  53
    → 
    84.200.19.10  :  31286

    Es werden in der Sekunde mehrere 1000 Pakete an die Firewall gesendet. Die Firewall selbst ist aber einwandfrei verfügbar. 

    da keine NAT Regel für dieses Ziel hinterlegt ist in der Firewall, blockt bereits die Firewall diese Pakete ohne sie an die IPS weiterzureichen. Als ich die NAT Regel für diese Ports hinzugefügt habe, landen die Pakete alle bei der IPS, dennoch ist die eigentliche Ziel IP nicht mehr erreichbar.

    Über die Linux Shell der Astaro kann ich sehen, dass die CPU Auslastung bei 0,4 % liegt. Auch der Load ist mit 1,12 in Ordnung. 

    Ich kann mir da nicht wirklich einen REim draus machen.


    astaro-vlan240:/ # cat /proc/sys/net/netfilter/nf_conntrack_max
    128000
    astaro-vlan240:/ #

    astaro-vlan240:/ # cat /proc/sys/net/netfilter/nf_conntrack_count
    1531
    astaro-vlan240:/ #


    Das sieht prinzipiell auch gut aus.
Reply
  • Zu Problem 1 konnten wir identifizieren, dass hier ein Angriff über den Port 53 auf den Server erfolgt.

    08:22:55  Default DROP  UDP 
    50.63.187.11  :  53
    → 
    84.200.19.10  :  31286

    Es werden in der Sekunde mehrere 1000 Pakete an die Firewall gesendet. Die Firewall selbst ist aber einwandfrei verfügbar. 

    da keine NAT Regel für dieses Ziel hinterlegt ist in der Firewall, blockt bereits die Firewall diese Pakete ohne sie an die IPS weiterzureichen. Als ich die NAT Regel für diese Ports hinzugefügt habe, landen die Pakete alle bei der IPS, dennoch ist die eigentliche Ziel IP nicht mehr erreichbar.

    Über die Linux Shell der Astaro kann ich sehen, dass die CPU Auslastung bei 0,4 % liegt. Auch der Load ist mit 1,12 in Ordnung. 

    Ich kann mir da nicht wirklich einen REim draus machen.


    astaro-vlan240:/ # cat /proc/sys/net/netfilter/nf_conntrack_max
    128000
    astaro-vlan240:/ #

    astaro-vlan240:/ # cat /proc/sys/net/netfilter/nf_conntrack_count
    1531
    astaro-vlan240:/ #


    Das sieht prinzipiell auch gut aus.
Children
No Data