UDP Attacken abschwächen?

[Sky]

Hallo zusammen,

Könnt ihr mir ein paar Tipps und Tricks zu dem oben genannten Thema geben? :D
Ich erkläre erstmal die Situation:

Also ich habe einen Rootserver, Debian Wheezy und dadrauf laufen folgende Sachen:
Webserver (Apache2), Postfix, DNS, natürlich auch SSH und weitere UDP abhängige Gameserver, sowie TeamSpeak.

TCP Flooding kann man ja mit IPTables gut in den Griff bekommen, aber mit UDP ist es ja bisschen schwieriger, zumal man die Absenderandresse fälschen kann.

Zum Start eines Events auf unserem Gameserver kam es zu einem Angriff:

Ausschnitt aus kern.log:

Code: Select all

Debian-70-wheezy-64-minimal kernel: [1626833.926919] UDP: bad checksum. From 89.23.0.1:53 to meineServerIP:9053 ulen 1742
Debian-70-wheezy-64-minimal kernel: [1626836.174056] UDP: bad checksum. From 67.132.126.211:161 to meineServerIP:80 ulen 9143
Debian-70-wheezy-64-minimal kernel: [1626882.511641] UDP: bad checksum. From 66.118.177.58:53 to meineServerIP:60877 ulen 1034
Debian-70-wheezy-64-minimal kernel: [1626882.826109] UDP: bad checksum. From 66.118.177.59:53 to meineServerIP:6507 ulen 1034
Debian-70-wheezy-64-minimal kernel: [1626885.620166] UDP: bad checksum. From 216.152.134.32:53 to meineServerIP:31971 ulen 676
Debian-70-wheezy-64-minimal kernel: [1626898.007476] UDP: bad checksum. From 77.243.225.15:53 to meineServerIP:41973 ulen 876
Debian-70-wheezy-64-minimal kernel: [1626903.783216] UDP: short packet: From 69.194.135.155:161 56743/14800 to meineServerIP:80
Debian-70-wheezy-64-minimal kernel: [1626922.111356] UDP: bad checksum. From 91.121.64.109:53 to meineServerIP:5196 ulen 1034
Debian-70-wheezy-64-minimal kernel: [1626937.197895] UDP: bad checksum. From 46.20.114.141:53 to meineServerIP:63008 ulen 69
Debian-70-wheezy-64-minimal kernel: [1626940.538672] UDP: bad checksum. From 80.15.178.88:53 to meineServerIP:12326 ulen 876
Debian-70-wheezy-64-minimal kernel: [1626943.429349] UDP: bad checksum. From 46.20.114.141:53 to meineServerIP:33137 ulen 69
Debian-70-wheezy-64-minimal kernel: [1626950.610672] UDP: bad checksum. From 216.152.134.32:53 to meineServerIP:37531 ulen 676
Debian-70-wheezy-64-minimal kernel: [1626969.005438] UDP: short packet: From 69.194.135.147:161 56586/11840 to meineServerIP:80
Debian-70-wheezy-64-minimal kernel: [1626987.331164] UDP: bad checksum. From 91.121.54.159:53 to meineServerIP:12828 ulen 69
Debian-70-wheezy-64-minimal kernel: [1626991.874300] UDP: bad checksum. From 89.23.0.1:53 to meineServerIP:7933 ulen 1742
Debian-70-wheezy-64-minimal kernel: [1627006.902770] UDP: bad checksum. From 216.152.134.32:53 to meineServerIP:31225 ulen 676
Debian-70-wheezy-64-minimal kernel: [1627016.811600] UDP: bad checksum. From 38.105.171.10:161 to meineServerIP:80 ulen 8194
Debian-70-wheezy-64-minimal kernel: [1627023.266459] UDP: bad checksum. From 91.121.54.159:53 to meineServerIP:52408 ulen 69
Debian-70-wheezy-64-minimal kernel: [1627031.014871] UDP: bad checksum. From 216.152.134.32:53 to meineServerIP:27031 ulen 676
Debian-70-wheezy-64-minimal kernel: [1627044.830407] UDP: bad checksum. From 216.152.134.32:53 to meineServerIP:31119 ulen 676
Debian-70-wheezy-64-minimal kernel: [1627048.843281] UDP: bad checksum. From 216.152.134.32:53 to meineServerIP:42480 ulen 676
Debian-70-wheezy-64-minimal kernel: [1627048.963363] UDP: short packet: From 69.194.135.147:161 56592/11840 to meineServerIP:80
Debian-70-wheezy-64-minimal kernel: [1627076.532336] UDP: bad checksum. From 91.204.139.6:53 to meineServerIP:19510 ulen 1742
Debian-70-wheezy-64-minimal kernel: [1627082.728121] UDP: bad checksum. From 66.118.177.59:53 to meineServerIP:34457 ulen 1034
Debian-70-wheezy-64-minimal kernel: [1627085.990073] UDP: bad checksum. From 38.105.171.10:161 to meineServerIP:80 ulen 8194
Debian-70-wheezy-64-minimal kernel: [1627125.349671] UDP: short packet: From 69.194.135.147:161 56592/11840 to meineServerIP:80
Debian-70-wheezy-64-minimal kernel: [1627126.774493] UDP: bad checksum. From 122.194.239.36:161 to meineServerIP:80 ulen 8128
Debian-70-wheezy-64-minimal kernel: [1627130.291361] UDP: bad checksum. From 46.32.64.1:53 to meineServerIP:60520 ulen 2139
Debian-70-wheezy-64-minimal kernel: [1627151.605975] UDP: bad checksum. From 91.121.64.109:53 to meineServerIP:3604 ulen 1034
Debian-70-wheezy-64-minimal kernel: [1627155.695407] UDP: bad checksum. From 80.15.178.88:53 to meineServerIP:10665 ulen 876
Debian-70-wheezy-64-minimal kernel: [1627173.209033] UDP: bad checksum. From 66.111.12.182:53 to meineServerIP:19198 ulen 1742

Da es möglich ist die Absenderadresse bei UDP Paketen zu fälschen, vermute ich, dass es sich um einen DoS Angriff handelt und weniger um einen DDoS. Die UDP Pakete waren alle 1500 bytes groß (habe ich durch die Anwendung IPTraf erfahren).
Jedoch war der Server stundenlang nicht erreichbar. Die Leitung war nur zu etwa 50 MBit/s von 200 MBit/s ausgelastet (IPTraf und nachträgliche Rechnungen anhand von Trafficgrafiken).

Bei einem Serverangriff wird doch immer etwas überlastet, doch was ist es hier nur? Die Leitung jedenfalls nicht, bei der Hardware bin ich mir nicht sicher, denn ich habe 32 GB Ram und bei normalem Betrieb wird nichtmals ein GB verbraucht.
Und wie kann man diese Angriffe abwehren oder schwächen? Mir ist schon klar, dass man sich nicht vor alles schützen, aber gegen Scriptkinder, die einem ein kleines Turnier versauen wollen, muss es doch was geben, oder nicht?

Ich freu mich schon auf eure Ratschläge.

:)

[Joe User]

Am Einfachsten wäre es wohl, alle Pakete mit "bad checksum" an einer vorgelagerten dedizierten Firewall zu verwerfen.
Auf dem eigentlichen Server kannst Du Dich nicht wehren, da die Pakete immer durch den Kernel (Netzwerk-Stack) verarbeitet werden müssen und ihn irgendwann schlicht überlasten. Durch diverse sysctl-Tunings lässt sich das Abschmieren zwar etwas hinauszögern, aber letztendlich nicht verhindern.

Wenn derzeit allerdings "nur" die Gameserver abschmieren, dann kannst Du die Pakete mit "bad checksum" auch auf Deinem Server mittels Netfilter/IPTables verwerfen (siehe Netfilter-Doku), so dass sie nicht mehr zu den Gameservern durchgereicht werden.
ABER: Wenn $Angreifer seine Bandbreite vergrössert, dann hilft Dir das nicht wirklich.

Und noch ein Hinweis: "bad checksum" wird auch gerne von Netzwerkchips verursacht, die sich nicht genau genug an die Spezifikationen halten. Das heisst, wenn Deine Clients oder Dein Server solch einen fehlerhaften Netzwerkchip verwenden, könnte das Verwerfen dieser Pakete zu unerwünschten Nebenwirkungen führen.


Hilft Dir nicht wirklich, daher "nur" zur Info.

[Sky]

Ja, ausgefallen sind leider nicht nur die Games, sondern auch alle anderen Dienste...
Ein Merkmal von diesem Angriff war, dass die UDP Pakete alle über 1500 bytes groß waren.
Gibt es eine Möglichkeit diese zu Filtern und zu verwerfen? Wenn ja, wäre das überhaupt sinnvoll, bzw. würde das einenpositiven Effekt erzielen?
Ich möchte mich ja nicht gegen alles schützen. Jedoch handelt es sich um ein richtig billiges Spiel, wo wir einfach ein kleines Event veranstalten und da ist einfach ein kleiner Spielverderber dabei. Irgentwie muss es doch einen Weg geben den Server lokal zu schützen... Es gibt sich doch nicht jeder von Scriptkiddies geschlagen.

[Joe User]

Es werden in Deinem Logauszug hauptsächlich Pakete von DNS-Servern (Quell-Port 53) an Deinen Server geschickt. Den Ziel-Ports nach, sind das Antworten auf Deine DNS-Anfragen (Hostname/Reverse-Lookups) und diese möchtest Du auf keinen Fall verwerfen.

Du kannst Deinen DNS-Server (Bind?) entweder deinstallieren (wenn nicht benötigt), oder ihn nur als lokalen Resolver nutzen (nur an 127.0.0.1 binden). In beiden Fällen musst Du die DNS-Zonen für Deine Domains allerdings extern bei Deinem Domainprovider verwalten. Damit fällt schonmal etwas UDP-Traffik weg.


Benötigst Du das Monitoring des Webservers per SNMP (Quell-Port 161) wirklich?


Kann man bei den Gameservern die Hostname/Reverse-Lookups (de)aktivieren? Falls ja, dann bitte deaktivieren.
Beim Webserver lassen sich die Hostname/Reverse-Lookups ebenfalls deaktivieren, allerdings findet man in den Logs dann nur noch IP-Adressen, was nicht immer gewünscht ist.
Beim Mailserver werden die Hostname/Reverse-Lookups benötigt, dort bitte nicht deaktivieren.


Richtig wehren kann man sich dagegen nur mit einer echten Firewall die vor dem zu schützenden System steht.


Wenn Du Dir zu 100% sicher bist, dass Du nie UDP-Pakete >1500 Bytes benötigst, dann kannst Du diese verwerfen:

Code: Select all

iptables ..... -p udp -m length --length 1501 -j ACCEPT

Du solltest die verworfenen Pakete aber loggen und regelmässig prüfen ob wirklich nur unerwünschte Pakete verworfen wurden.

[Sky]

Sorry, der Ausschnitt aus der Log war viel zu spät, wo der Angriff schon sehr schwach war.
Hier noch ein Ausschnitt:

Code: Select all

Debian-70-wheezy-64-minimal kernel: [1626626.439242] UDP: bad checksum. From 216.152.134.32:53 to ***:47512 ulen 676
Debian-70-wheezy-64-minimal kernel: [1626647.862557] UDP: short packet: From 69.194.135.147:161 56592/11840 to ***:80
Debian-70-wheezy-64-minimal kernel: [1626658.995381] UDP: short packet: From 163.25.122.249:161 52931/11840 to ***:80
Debian-70-wheezy-64-minimal kernel: [1626668.298112] UDP: bad checksum. From 91.121.54.159:53 to ***:64537 ulen 69
Debian-70-wheezy-64-minimal kernel: [1626671.273860] UDP: bad checksum. From 46.20.114.141:53 to ***:46580 ulen 69
Debian-70-wheezy-64-minimal kernel: [1626677.336612] UDP: bad checksum. From 216.152.134.32:53 to ***:41526 ulen 676
Debian-70-wheezy-64-minimal kernel: [1626677.353593] UDP: bad checksum. From 216.152.134.32:53 to ***:26946 ulen 676
Debian-70-wheezy-64-minimal kernel: [1626685.053122] UDP: short packet: From 163.25.122.249:161 52883/11840 to ***:80
Debian-70-wheezy-64-minimal kernel: [1626709.896991] UDP: bad checksum. From 216.152.134.32:53 to ***:25770 ulen 676
Debian-70-wheezy-64-minimal kernel: [1626716.515859] UDP: bad checksum. From 46.20.114.141:53 to ***:44017 ulen 69
Debian-70-wheezy-64-minimal kernel: [1626767.487402] UDP: short packet: From 120.104.212.116:161 58944/13320 to ***:80
Debian-70-wheezy-64-minimal kernel: [1626819.988692] UDP: bad checksum. From 91.121.54.159:53 to ***:63481 ulen 69
Debian-70-wheezy-64-minimal kernel: [1626833.926919] UDP: bad checksum. From 89.23.0.1:53 to ***:9053 ulen 1742
Debian-70-wheezy-64-minimal kernel: [1626836.174056] UDP: bad checksum. From 67.132.126.211:161 to ***:80 ulen 9143
Debian-70-wheezy-64-minimal kernel: [1626882.511641] UDP: bad checksum. From 66.118.177.58:53 to ***:60877 ulen 1034
Debian-70-wheezy-64-minimal kernel: [1626882.826109] UDP: bad checksum. From 66.118.177.59:53 to ***:6507 ulen 1034
Debian-70-wheezy-64-minimal kernel: [1626885.620166] UDP: bad checksum. From 216.152.134.32:53 to ***:31971 ulen 676
Debian-70-wheezy-64-minimal kernel: [1626898.007476] UDP: bad checksum. From 77.243.225.15:53 to ***:41973 ulen 876
Debian-70-wheezy-64-minimal kernel: [1626903.783216] UDP: short packet: From 69.194.135.155:161 56743/14800 to ***:80
Debian-70-wheezy-64-minimal kernel: [1626922.111356] UDP: bad checksum. From 91.121.64.109:53 to ***:5196 ulen 1034
Debian-70-wheezy-64-minimal kernel: [1626937.197895] UDP: bad checksum. From 46.20.114.141:53 to ***:63008 ulen 69
Debian-70-wheezy-64-minimal kernel: [1626940.538672] UDP: bad checksum. From 80.15.178.88:53 to ***:12326 ulen 876
Debian-70-wheezy-64-minimal kernel: [1626943.429349] UDP: bad checksum. From 46.20.114.141:53 to ***:33137 ulen 69
Debian-70-wheezy-64-minimal kernel: [1626950.610672] UDP: bad checksum. From 216.152.134.32:53 to ***:37531 ulen 676
Debian-70-wheezy-64-minimal kernel: [1626969.005438] UDP: short packet: From 69.194.135.147:161 56586/11840 to ***:80
Debian-70-wheezy-64-minimal kernel: [1626987.331164] UDP: bad checksum. From 91.121.54.159:53 to ***:12828 ulen 69
Debian-70-wheezy-64-minimal kernel: [1626991.874300] UDP: bad checksum. From 89.23.0.1:53 to ***:7933 ulen 1742
Debian-70-wheezy-64-minimal kernel: [1627006.902770] UDP: bad checksum. From 216.152.134.32:53 to ***:31225 ulen 676
Debian-70-wheezy-64-minimal kernel: [1627016.811600] UDP: bad checksum. From 38.105.171.10:161 to ***:80 ulen 8194
Debian-70-wheezy-64-minimal kernel: [1627023.266459] UDP: bad checksum. From 91.121.54.159:53 to ***:52408 ulen 69
Debian-70-wheezy-64-minimal kernel: [1627031.014871] UDP: bad checksum. From 216.152.134.32:53 to ***:27031 ulen 676

Man könnte auch noch alle unbenutzten UDP Ports dicht machen, aber dann hat man mir gesagt, dass es Probleme mit der DNS geben könnte...

[Joe User]

Auch im zweiten Logauszug sind nur DNS (From w.x.y.z:53) und SNMP (From w.x.y.z:161) Pakete zu sehen.

Bist Du Dir sicher, dass Du per UDP attackiert wirst? Wie genau hast Du es festgestellt?


Vielleicht liegt das Problem auch ganz woanders und Du hast es nur noch nicht gefunden.
Wie genau äussert sich Dein Problem? Tritt es zu bestimmten Zeiten oder zufällig auf?
Sind andere Logfiles komplett unauffällig? Nutzt Du Plesk oder Ähnliches?



BTW: Da die bad checksums bei so vielen verschiedenen Verbindungen auftreten, ist vermutlich Dein Netzwerkchip buggy und daher solltest Du das "Checksum Offloading" (oft TCO abgekürzt) im Kernel (Netzwerk-Konfiguration) deaktivieren.

[Sky]

Der Server läuft einwandfrei.

Das Problem trat bisjetzt nur 2 mal auf:
Wir hatten in einem Forum 2 Termine für 2 Turniere veröffentlicht und beide male fing der Server punkt 19 Uhr (Turnierstart) zu laggen und anschließen haben alle Teilnehmer die Verbindung verloren. Weder Gameserver und TeamSpeak, noch die Website waren erreichbar.
Ich hatte beim 2. mal IPTraf laufen und dort stand, dass 1500 bytes große UDP Fragmente von verschiedenen IPs auf an alle möglichen Ports im Server eintrafen.
Bei normalbetrieb sind die Pakete unterschiedlich von ca 30-200 bytes groß. Einmal habe ich einen knapp 1000 bytes großen Paket erwischt, aber das war auch nur einer zwischen den ganzen kleinen Paketen...

[ddm3ve]

Schau mal hier oder alternativ das Buch Linux Firewalls von Spenneberg.
https://www.frozentux.net/iptables-tuto ... orial.html

[Sky]

Danke...
Also es sind große UDP Pakete angekommen und der Server ist ausgefallen. Was genau passiert ist, bin ich mir nicht sicher...Was ich weichs ist, dass die Anbindung nicht verstopft war. Wenn es an der Hardware gelegen hat, dann hätte ich nicht gedacht, dass man 32 GB Ram so schnell auslasten kann.
Gibt es keine Möglichkeit UDP Pakete von einem böswilligem User zu stoppen?

[Joe User]

Mit dem RAM hat es weniger zu tun. Wenn der Kernel beziehungsweise sein Netzwerkstack überlastet ist, dann ist halt Feierabend.
BTW: In Linux-3.9 wurde der Netzwerkstack etwas optimiert, was Dir ein wenig helfen könnte. https://lwn.net/Articles/542629/

Stoppen kannst Du beziehungsweise Dein Provider soetwas nur auf einem echten Firewallsystem vor Deinem Server.
Da solche Firewalls sehr teuer sind, werden sie bei Mietservern nur selten als buchbare Option angeboten und wenn, dann kann man durchaus mit (weit) über 100EUR/Monat allein für die Firewall rechnen. Solche Firewalls sind nicht mit den Spielzeugen, wo man nur Ports öffnen/schliessen kann, wie sie manche Provider teilweise kostenlos anbieten zu vergleichen.


Hast Du die fraglichen UDP-Pakete mal mit tcpdump mitgeschnitten und angesehen was in den Paketen steht?

[Sky]

Ne.
ok was würdet ihr mir am meisten emphehlen? Eine Firewall vor dem Server kommt nur notfalls in Frage.
Wann der nächte Angriff ist, ist unbekannt, aber anscheinend hat derjenige es nur auf das Event abgesehen...

[Joe User]

Zunächst ein Update des Kernel auf 3.11 und beim nächsten Event tcpdump die Pakete samt Inhalt mitloggen lassen. Letzteres wäre mit einem Fake-Event machbar, damit man bis zum nächsten echten Event vielleicht schon erste Gegenmassnahmen ergreifen oder planen kann.
Kernel-Updates sind je nach Distribution und Hardware manchmal tricky, daher empfiehlt sich hier ein Testsystem (eine VirtualBox @Home kann bereits reichen).

http://www.markhneedham.com/blog/2012/0 ... p-packets/
http://www.thegeekstuff.com/2010/08/tcp ... -examples/
http://linux.die.net/man/8/tcpdump

Mitloggen könntest Du zum Beispiel so:

Code: Select all

tcpdump -vv -XX -K -nn -p -w /root/udplog.pcap -i eth0 udp

Das Log kann relativ gross werden, daher solltest Du einen Pfad mit genug Platz wählen.

[Sky]

Mal angenommen, ich hätte es geschafft den Kernel zu upgraden...könnten dann hinterher irgentwie Unkompatibilitäten entstehen? Z.B. dass ich ein Dienst auf einer anderen Version auch installiert werden muss, oder irgentwelche Libraries etc. ?

[Joe User]

Nein, der Kernel ist zur Runtime unabhängig von anderer Software.