DDos/Dos Angreifer IP loggen

[seirex1234]

Hallo,

in den letzten Tagen habe ich 2 DDOS/Dos Angriffe bekommen. Gibt es eine Möglichkeit, dass wenn ein DDos/Dos ankommt, dass die Angreifer IP automatisch in einen Log eingetragen wird? Z.B wenn eine IP vielfache Verbindungen mit dem Server aufbaut und ihn mit Pings floodet? Ich weiß wie ich die aktuellen Verbindungen anzeigen lasse, jedoch nicht wie ich dies alles in einen Log schreiben lassen kann um den Angriff im nachhinein zu untersuchen. Hat jemand eine Idee wie das klappen könnte?

Wünsche noch einen angenehmen Sonntag

[mat6937]

Z.B wenn eine IP vielfache Verbindungen mit dem Server aufbaut ...

Kannst Du mit dem Dienst (Software?) über den die vielfachen Verbindungen hergestellt werden, nicht auch eine Log-Datei konfigurieren bzw. benutzen?

EDIT:

Siehe auch: https://forum.ubuntuusers.de/topic/ddos ... st-9059748

[DeletedUserReAsG]

Wenn das nicht gehen sollte, warum auch immer, könnte man entsprechende Regeln via iptables anlegen.

[seirex1234]

Z.B wenn eine IP vielfache Verbindungen mit dem Server aufbaut ...

Kannst Du mit dem Dienst (Software?) über den die vielfachen Verbindungen hergestellt werden, nicht auch eine Log-Datei konfigurieren bzw. benutzen?

EDIT:

Siehe auch: https://forum.ubuntuusers.de/topic/ddos ... st-9059748

Also ich benutze den hier:
netstat -anp |grep ‚tcp\|udp‘ | awk ‚{print $5}‘ | cut -d: -f1 | sort | uniq -c | sort –n

Dort kann ich nur aktuelle Verbindungen anzeigen und nichts im nachhinein feststellen oder in einen log schreiben lassen

Wenn das nicht gehen sollte, warum auch immer, könnte man entsprechende Regeln via iptables anlegen.

Wie könnte denn sowas aussehen, dass IPs geloggt werden die beispielsweise mehr als 10 verbindungen zum server aufbauen? Oder eine Bestimmte Anzahl an Pakete senden

[eggy]

netstat -anp |grep ‚tcp\|udp‘ | awk ‚{print $5}‘ | cut -d: -f1 | sort | uniq -c | sort –n

Wozu soll das tcp/udp greppen gut sein, wenn Du Pings als Ursache vermutest ?

[Huck Fin]

Fail2ban sollte das können...

[schwedenmann]

Hallo


per netstat kann man das afaik in einlog schreiben und das auswerten

https://www.linuxquestions.org/question ... og-749396/


mfg
schwedenmann

Alternativ kannst du ja so was wie monitorix, oder dergleichen installieren, die schreiben ja auch logs, bzw. legen die entsprechenden Daten in einer rrdb an, die kann mann ja auch wiederum auswerten sollen können dürfte

PPs
da du nicht schreibst, um was für einen Rechner es sich handelt.(wenn da apache2 oder nginx drauf ist, hast du doch auswertbare logs.)

[eggy]

@schwedenmann: Wenn es sowas wie synflooding ist, kommen die Anfragen garnicht erst bis zum Webserver nach oben, sondern es legt den Server bereits weiter unten im Protokollstack beim Aushandeln der TCP Verbindung lahm. Daher machts schon Sinn, erstmal weiter unten (tcpdump/iptables logging) nachzusehn, was da wirklich passiert.

[TomL]

Daher machts schon Sinn, erstmal weiter unten (tcpdump/iptables logging) nachzusehn, was da wirklich passiert.

Genau so sehe ich das auch... die Pakete sollen erst gar nicht bis zum Service durchkommen. Bei mir sieht das via nftables geloggt so aus:
40671

[mat6937]

da du nicht schreibst, um was für einen Rechner es sich handelt.(wenn da apache2 oder nginx drauf ist, hast du doch auswertbare logs.)

BTW: Beim TE geht es um UDP Flooding auf einen Teamspeak-Server.

[seirex1234]

da du nicht schreibst, um was für einen Rechner es sich handelt.(wenn da apache2 oder nginx drauf ist, hast du doch auswertbare logs.)

Es handelt sich um einen Debian 8 Server.

Auf diesem Server ist nur Teamspeak installiert.

[TomL]

BTW: Beim TE geht es um UDP Flooding auf einen Teamspeak-Server.

Gibts denn da Möglichkeiten... ?... ich kenne keine... ich würde das auch nicht protokollieren wollen. Dabei würde ich befürchten,dass ich das System allein mit Journaleinträgen und ICMP-Antworten völlig lahmlegen würde. UPD ist verbindungslos und zustandslos, also gibts auch kein Conntrack... da kommen auf beliebigen Ports wie aus ner Gieskanne UDP-Pakete rein, denen es egal ist, ob sie ankommen oder nicht, ob sie fehlerfrei oder fehlerhaft sind, ob sie angenommen werden oder nicht.

Ich würde an der Stelle via Paketfilter alle UDP-Pakete mit „zufälligen“ Ports ohne ICMP-Rückantwort einfach verwerfen und die Drop-Rate einfach mal ne Zeit beobachten oder sogar stündlich via Cron abfragen und in eine Tabelle packen. Um dann mal zu den ermittelten Spitzenzeiten -sofern sich das wiederholt oder vorhersagbar ist- direkt auf den Traffic zu schauen. Die Pakete mit passendem Port muss man eh durchlassen, das könnten ja reguläre Verbindungsversuche oder Datenpakete sein.

[mat6937]

Die Pakete mit passendem Port muss man eh durchlassen, das könnten ja reguläre Verbindungsversuche oder Datenpakete sein.

Naja, das Problem wird hier sein, dass das UDP Flooding hier nur auf den passenden UDP-Port des TS geht.

[TomL]

Und wie will man da zwischen erwünschten und unerwünschten IP-Source-Adressen differenzieren? Meiner Meinung nach geht das mit UDP nicht. Weisst Du, wie die Lösung aussieht?

[mat6937]

Weisst Du, wie die Lösung aussieht?

Nein. Deshalb habe ich ja auch geschrieben, dass das hier ein Problem sein wird.

[mat6937]

Weisst Du, wie die Lösung aussieht?

Nein. Deshalb habe ich ja auch geschrieben, dass das hier ein Problem sein wird.

EDIT:

OK, ich wusste schon eine Lösung. Den Teamspeak-Server nicht benutzen. Es gibt gleichwertige VoIP-Server, bei denen man die Ports selber konfigurieren kann und nicht gezwungen ist die Standard-Ports (die jeder kennt) zu benutzen.

[DeletedUserReAsG]

Soweit mir bekannt, kann man bei TS durchaus die Ports bestimmen. Zumindest haben einige von mir manchmal benutzte Server unterschiedliche Ports.

Was meinen Vorschlag zu iptables betrifft: Für die Auswertung und angedachte Reaktion wird man sich dann noch ’n Script schreiben müssen. Wer so Server betreibt, sollte das aber problemlos hinbekommen.

[mat6937]

Soweit mir bekannt, kann man bei TS durchaus die Ports bestimmen.

Das wäre dann m. E. eine mögliche Lösung (... wenn es nicht (zu) viele Benutzer sind und der "Angreifer" nicht aus dem Kreis der berechtigten bzw. informierten Benutzer kommt).