[erledigt] Massive Attacken von multiplen IP-Adressen

[TomL]

Moin

Jetzt gerade werfe ich mal eben in der Werbung ein Blick auf mein tägliches Log und bin erst mal geschockt. Offensichtlich hats gestern eine heftige Attacke auf meinen Server gegeben, wie ich sie vorher noch nie gesehen habe. Ich vermute mal, dass ich noch nicht mal alles sehe, weil das größen-orientierte Log-Rotate vermutlich nen Teil schon wieder gelöscht hat. Aber was ich gesehen hab, hat mich echt geschockt. Nicht eine IP, die es etliche Male versucht hat, sondern etliche IPs abgestimmt auf die gleiche Zeit... fast wie eine konzertierte Aktion.

Das ist das Log: 40814

An den letzten 2 Paketen sehe ich, dass die Attacken nicht bis zum eigentlichen Service durchgekommen sind, zumindest ist in dessen Logs nix ungewöhnliches zu sehen. Der Paketfilter hat das also vorher erfolgreich abgefangen. Aber ein solches Ausmaß ist echt heftig.

Kann jemand irgendwas dazu sagen...?... wie man damit umgeht...?... oder so einen Vorfall interpretiert? Ich würde jetzt sagen, meine Filter-Maßnahmen waren erst mal erfolgreich, der Server läuft wie gehabt weiter. Aber unsicher lässt es einen doch zurück... diese Dimension war völlig unerwartet und neu für mich

Nachtrag: Das obige Log war von heute morgen 00:01 Uhr und betrachtet den gestrigen Tag. Jetzt gerade -mit Blick auf heute- sehe ich, die Attacken liefen weiter, bis heute abend um 19:40 Uhr, mit gleicher Heftigkeit und in gleicher Größenordnung

[schorsch_76]

Hallo TomL,
Ich habe deshalb meine Blockzeit auf 1 Woche ausgedehnt mit drop anstatt Block in der Firewall/fail2ban. So lass ich den Angreifer in lange Timeouts rein laufen anstatt ihm Info zu geben. Mehr als Sicherheitsupdates und mehr oder weniger sichere Konfiguration kann man fast nicht machen. Evtl Cloudfront oder so... Aber das ist dann nicht mehr Hobby Bereich
Gruß Georg

[mludwig]

Seltsam finde ich, dass bei oberflächlicher Prüfung der IPs/Netze mit whois ein großer Teil von der gleichen AS aus den Niederlanden zu kommen scheint. Hast du irgendwelche Holländer geärgert?

Fast alles aus AS50673 Serverius

[TomL]

Moin

Hast du irgendwelche Holländer geärgert? Fast alles aus AS50673 Serverius

Serverius....?... das hatte ich noch gar geprüft.... war viel zu geschockt.... aber interessant isses schon, dass das von einer Stelle kommt. Und nein, ich habe natürlich keine Holländer geärgert. Ich vermute mal, entweder haben die MyFritz gehackt, weil die von dort vergebene DynDNS ja kaum lesbar und noch schlechter zu merken ist, oder meine öffentliche IPv4 wurde zufällig getroffen.... anzumerken ist, die wird ja momentan noch einmal täglich zwangsgetrennt.

Seit gestern abend 19:40 Uhr ist Ruhe... alles wieder wie immer. Anhand meiner Logs kann ich jetzt rückwirkend eine Mindestlaufzeit der Attacken vom 11.08.19, 14:50 bis 12.08.19, 19:40 erkennen. Ich muss aber davon ausgehen, dass das Log-Rotate schon Sätze entfernt hat. Aber Fakt ist, die Attacke lief durchgehend mindestens 29 Stunden .

Ich habe deshalb meine Blockzeit auf 1 Woche ausgedehnt mit drop anstatt Block in der Firewall/fail2ban.

Fail2ban habe ich mir mal angesehen und speziell für meine Bedürfnisse als ungeeignet verworfen. Mir war das zu träge, weil damit erst im Anschluß der beim Service ankommende Failed-Traffice analysiert wird und dann darauf reagiert wird. Ich packe solche Pakete schon an, bervor sie beim Service ankommen und entsorge sie sofort. Das ist aber eine speziale Lösung und nicht pauschal anwendbar. Hier werden solche Pakete auch gedropt, und zwar rigoros, mit einer Sperrzeit der IP von 1 Stunde. Aber weil die IPs ja durchweg reingekommen sind, waren sie quasi durchgängig gesperrt.

Am meisten würde mich hier interessieren, ob meine öffentliche IP vielleicht doch nur ein Zufallstreffer war.... was ich ja eigentlich gerne glauben möchte.....

[mat6937]

Ich vermute mal, entweder haben die MyFritz gehackt, weil die von dort vergebene DynDNS ja kaum lesbar und noch schlechter zu merken ist, oder meine öffentliche IPv4 wurde zufällig getroffen.... anzumerken ist, die wird ja momentan noch einmal täglich zwangsgetrennt.

... Aber Fakt ist, die Attacke lief durchgehend mindestens 29 Stunden .
[....
Am meisten würde mich hier interessieren, ob meine öffentliche IP vielleicht doch nur ein Zufallstreffer war.... was ich ja eigentlich gerne glauben möchte.....

Wenn es 29 Stunden waren, dann müssen es ja 2 deiner öffentliche IP-Adressen gewesen sein.

Oder war es doch der DynDNS deines MyFritz-Accounts, ... denn MyFritz ist ja mehr als nur ein DynDNS-Service.
Seit wann hast Du diesen MyFritz-Account? ... schon vor 2014 (... das Jahr des Massenhack von AVM-FritzBoxen) oder nach 2014?

[TomL]

Wenn es 29 Stunden waren, dann müssen es ja 2 deiner öffentliche IP-Adressen gewesen sein.

Ja, richtig, so war es auch ... hab es gerade geprüft. Danke für den Tip, auf diesen Zeitpunkt zu gucken bin ich selber erst mal gar nicht gekommen. Ich hatte mich wohl mehr mit der Motivation des Angriffs und den Konsequenzen beschäftigt. Zum Zeitpunkt der Trennung reisst der Angriff tatsächlich ab, und geht dann etwa ne viertelstunde später mit einer IP weiter. Kurz darauf sind es dann wieder etliche unterschiedliche IPs.

Oder war es doch der DynDNS deines MyFritz-Accounts, ... denn MyFritz ist ja mehr als nur ein DynDNS-Service. Seit wann hast Du diesen MyFritz-Account? ... schon vor 2014

Also jetzt, nach Deinem Hinweis nehme ich auch an, dass meine DynDNS-Adresse des MyFritz-Kontos das Ziel war. Spätestens mit der Zwangstrennung hätte das ja beendet sein müssen... wars aber nicht...
Wie lange habe ich den Account...?...*hmmm* ... seit wann hat NoIp die Free-Accounts auf 30 Tage limitiert.... etwa so lange. Ich werde das jetzt ein paar Tage beobachten und wenns wieder passiert, lösch ich den DynDNS und richte ihn mit neuer Adresse neu ein.

[wanne]

Ich habe deshalb meine Blockzeit auf 1 Woche ausgedehnt mit drop anstatt Block in der Firewall/fail2ban. So lass ich den Angreifer in lange Timeouts rein laufen anstatt ihm Info zu geben.

Das machst du genau so lange bis du mal ne echte ddos abbekommst. Ein nginx (oder sonst die meisten services) können um Größenordnungen mehr Verbindungen/s ab als ein iptables mit tausenden von ail2ban regeln. IMHO ist das die häufigste Art und weise wie Leute wegen CPU-Last down gehen.
Meine Fette empfehlung: Wenn du nicht mit schlechten passwörtern rechnest lass die finger von fail2ban.

[irgendwas]

Mit einer ipfire vor dem Webserver (oder mit nginx selbst) kann man doch die Anzahl der Verbindungen pro IP-Adresse begrenzen.

[mat6937]

... kann man doch die Anzahl der Verbindungen pro IP-Adresse begrenzen.

Warum sollte man die Anzahl der Verbindungen begrenzen?, ... wenn doch der richtig konfigurierte Dienst/service mit einem (echten) DDOS besser "umgehen" kann als der Paketfilter (oder gleichwertig).

[irgendwas]

Ich habs im Eifer des Gefechts etwas unglücklich formuliert.

Es hätte mal eine Frage werden sollen, die du aber damit beantwortet hast

[novalix]

Ich habe deshalb meine Blockzeit auf 1 Woche ausgedehnt mit drop anstatt Block in der Firewall/fail2ban. So lass ich den Angreifer in lange Timeouts rein laufen anstatt ihm Info zu geben.

Das machst du genau so lange bis du mal ne echte ddos abbekommst. Ein nginx (oder sonst die meisten services) können um Größenordnungen mehr Verbindungen/s ab als ein iptables mit tausenden von ail2ban regeln. IMHO ist das die häufigste Art und weise wie Leute wegen CPU-Last down gehen.
Meine Fette empfehlung: Wenn du nicht mit schlechten passwörtern rechnest lass die finger von fail2ban.

Sorry can not resist:
Was sind "die meisten services"?
Hast Du da auch belastbare Zahlen?

Was sicherlich richtig ist: fail2ban ist in seiner neuen Architektur viel "fetter" (speicherhungriger) geworden und bei einem "echten ddos" sowieso eher ein Klotz am Bein. Es wird relativ aufwändig geprüft und geprüft, aber nichts gesperrt.

Reines Netfilter (z.B. mit recent modul) wäre da schon deutlich leichtgewichtiger, würde aber bei vollständiger distribution genauso ins Leere laufen und letztlich nur überflüssige zusätzliche Last erzeugen.

Nichtsdestotrotz ist ein wirklicher ddos dann doch eher selten. Die meiste Zeit (oder sogar immer) leisten solche Methoden (fail2ban, recent) genau die gewünschte und wichtige Arbeit der Abwehr von Angriffsversuchen.

Für ein dezidiertes DDOS-Szenario sollte man - so lange man auf sich allein gestellt ist - ein sinnvolles Monitoring einrichten, um das Event zu entdecken und die services vom Netz nehmen, bevor sie von sich aus in die Knie gehen.
Da wäre ein laufender fail2ban sicherlich ein erster Kandidat.

@TomL
Soweit ich das korrekt erinnere, sind bei Dir sowieso keine daemons von außen zu erreichen. Du könntest einfach das Logging des Netzfilters unterbinden. Das minimiert noch mal zusätzlich den Rechenaufwand und verheimlicht einem die unangenehmen Informationen.
Im Ernst: Ich vermute, dass es sich bei dieser Sache um keinen gezielten Angriff auf Deinen Server, sondern um ein schon etwas aufwändigeren Versuch, *irgendein* Opfer in dem Dyndns-Namensraum aufzuspüren, handelt.

[TomL]

Warum sollte man die Anzahl der Verbindungen begrenzen?, ... wenn doch der richtig konfigurierte Dienst/service mit einem (echten) DDOS besser "umgehen" kann als der Paketfilter (oder gleichwertig).

So richtig bin ich mit der Aussage auch noch nicht fertig, dass nginx besser mit einem DDOS umgehen kann, als ein Paketfilter... direkt oder via fail2ban. Was tut denn Nginx...?... es begrenzt die Request-Rate und die Anzahl der Connects und verwirft "failed" Anfragen. Ich rede jetzt hier ausdrücklich nicht von Passwörtern, sondern das, was auf Paketebene stattfindet. Ein Paketfilter (resp. fail2ban) macht doch da aber nix anderes... nur halt eben früher, er limitiert die Request-Rate, die Anzahl der Connects und drop'd "failed" Pakete. Warum soll das schlechter sein? Wie kann man das verständlich erklären, dass das schlechter ist? An fail2toban habe ich nur die Kritik, dass es mir zu träge ist und nur nachgeschaltet erst nach etlichen Prüfungen reagiert. Bis dahin könnte ein Daemon schon angeschossen sein.

Soweit ich das korrekt erinnere, sind bei Dir sowieso keine daemons von außen zu erreichen.

Doch natürlich, ansonsten wärs ja Blödsinn, einen Port im Router zu öffnen und auf den Server weiterzuleiten. Bei mir isses ein auf dem TCP-Stack lauschender VPN-Daemon.... den ich natürlich auch benötige.

Das Ablauf ist bei mir allerdings so, dass verdächtige TCP-Pakete gar nicht erst bis zum Daemon durchkommen, also bis zur tatsächlich verarbeitenden Programmebene. Zunächst mal ist es hier so, das jedes fremde TCP-Paket tatsächlich auch auf dem NIC meines Server ankommt. Gestern eben waren's diese zigtausend. Das heisst, ein neuer Request passiert zunächst auch mal ganz ungehindert meinen Paketfilter auf dem System, was natürlich ja auch so gewollt ist. Aber es verreckt dann in der HMAC-Firewall, wenn es auf dem TLS-Channel als ungültig erkannt wird, und bevor es die 'Arbeitsebene' des laufenden Daemons erreicht wird es schon verworfen. Und nun bei jedem weiteren attackierenden Folgepaket mit der gleichen SADDR greift jetzt der Paketfilter via "recent" zu... das bedeutet, die weiteren Pakete erreichen noch nicht mal mehr die HMAC-Firewall, ganz zu schweigen vom eigentlichen Prozess meines Daemons.

Du könntest einfach das Logging des Netzfilters unterbinden. Das minimiert noch mal zusätzlich den Rechenaufwand und verheimlicht einem die unangenehmen Informationen.

Ja, das wäre vermutlich eine passende Lösung. Allerdings muss ich zugeben, dass die in der Vergangenheit geloggten Attacken eher auch eine beruhigende Wirkung hatten... "siehe da, der Paketfilter ist aktiv und werkelt fleissig vor sich hin". Ohne diese Logs müsste ich ja dann einen umgekehrten Schluss ziehen, und zwar ist alles OK, solange der Daemon selber nix berichtet. *hmmm*. Aber dann immer ohne zu wissen, ob einfach nix vorgefallen ist oder ob der Filter dafür verantwortlich ist.

Im Ernst: Ich vermute, dass es sich bei dieser Sache um keinen gezielten Angriff auf Deinen Server, sondern um ein schon etwas aufwändigeren Versuch, *irgendein* Opfer in dem Dyndns-Namensraum aufzuspüren, handelt.

Ich will das auch glauben.... das scheint mir auch die wahrscheinlichste Ursache zu sein. Ich werds jetzt einfach mal die nächsten Tage beobachten.

[mat6937]

Warum sollte man die Anzahl der Verbindungen begrenzen?, ... wenn doch der richtig konfigurierte Dienst/service mit einem (echten) DDOS besser "umgehen" kann als der Paketfilter (oder gleichwertig).

So richtig bin ich mit der Aussage auch noch nicht fertig, dass nginx besser mit einem DDOS umgehen kann, als ein Paketfilter... direkt oder via fail2ban. Was tut denn Nginx...?... es begrenzt die Request-Rate und die Anzahl der Connects und verwirft "failed" Anfragen. Ich rede jetzt hier ausdrücklich nicht von Passwörtern, sondern das, was auf Paketebene stattfindet. Ein Paketfilter (resp. fail2ban) macht doch da aber nix anderes...

OK, wenn nur die Anzahl der Connects limitiert wird, betr. das ja auch die zulässigen Verbindungsversuche.

Aber in deinem konkreten Fall, z. B. OpenVPN. Du benutzt doch auch "HMAC packet authentication" mit tls-crypt (bzw. mit tls-auth), oder?

[TomL]

Aber in deinem konkreten Fall, z. B. OpenVPN. Du benutzt doch auch "HMAC packet authentication" mit tls-crypt (bzw. mit tls-auth), oder?

Ja, richtig, ich denke, dass mein Server ziemlich gut gehärtet ist, da ist jedenfalls nix durchgekommen. Mich hat aber die hinter der Attacke stehende Motivation echt beunruhigt und die Frage in den Raum gestellt "zufällig oder gezielt?". Und natürlich möchte ich gerne glauben, dass meine IPs zufällige Opfer waren ... aber wer betreibt das denn dann 29 Stunden lang, bei einem unbekannten Ziel und sogar weiter nach einem IP-wechsel? Damit hab ich ein Problem. Aber novalix' Sichtweise relativiert das wieder einigermaßen.

[mat6937]

... ich denke, dass mein Server ziemlich gut gehärtet ist, ...

Ja, der Server ist gut gehärtet, ... aber es stellt sich die Frage, was ist Ressourcen schonender im Falle eines (Dauer-)Angriffs, die HMAC-Firewall oder der Paketfilter?

[TomL]

Ja, der Server ist gut gehärtet, ... aber es stellt sich die Frage, was ist Ressourcen schonender im Falle eines (Dauer-)Angriffs, die HMAC-Firewall oder der Paketfilter?

Tja, die Frage überfordert mich. So rein laienhaft würde ich vermuten, weil die HMAC-FW schon ein dem Paketfilter nachgeschalteter Prozess ist, ist es hier eben ein weiterer, zusätzlicher Verarbeitungsschritt, und das (im Gegensatz zu den Netfilter-Modulen) sogar außerhalb des Kernels und darüber hinaus imho auch auf einem höheren Layer. Außerdem verewigen sich die HMAC-Failed's ja auch im LOG, nur halt im VPN-Log, das heisst, statt journald im Log des Daemons... also auch nicht wirklich eine Verbesserung.

Im Grundegenommen liegen also die Conntrack-Module auf der einen Waage-Seite, und die Daemon-eigenen Prozesse auf der anderen... was wiegt hinsichtlich CPU-Last mehr? Aber ich kann (und will) ja nicht grundsätzlich aufs Traffic-Tracking verzichten, ich halte das für wertvoll... und so groß sind die Recent-Tabellen selbst durch die Attacke nicht geworden... es waren ja nicht tausende von SADDR, sondern nur 1000e von Zugriffen einer eher kleineren Anzahl von SADDR.

Ich würde jetzt sagen, wenn ich auf das Logging des Paketfilters verzichten würde, wäre der Paketfilter imho die performanteste Verarbeitung... aber diese Entscheidung an einem einzigen Vorfall in etlichen Jahren festzumachen, wäre m.M.n. auch ein wenig unüberlegter Aktionismus. Außerdem, was mir auch wichtig ist/war, ich verwende das Journald-Logging eben auch als faktisches Positiv-Fazit beim täglichen Kontrollüberblick. Darauf müsste ich dann verzichten... und ich glaube, das würde mir weniger gut gefallen.

[mat6937]

Darüber hinaus verewigen sich die HMAC-Failed's ja auch im LOG, nur halt im VPN-Log, das heisst, statt journald im Log des Daemons... also auch nicht wirklich eine Verbesserung.

Das Loggen sollte nicht das Problem sein, denn man könnte VPN so konfigurieren, dass nicht geloggt wird und journald könnte man deaktivieren.

[TomL]

Das halte ich überhaupt nicht für eine gute Idee. Das Logging ist ja (zumindest für mich) ein wesentlicher Bestandteil meiner Maßnahmen zur Sicherstellung der lokalen Netzhygiene. Das abzuschalten halte ich sogar für grob fahrlässig, egal obs der Daemon ist oder journald. Außerdem, der Paketfilter loggt ja nicht automatisch nach journald, ich habe das ja für diese Recent-Kandidation ausdrücklich so eingestellt. Generelles Abschalten schließe ich jedenfalls aus

Hast Du das bei Dir alles deaktiviert?

[mat6937]

Das halte ich überhaupt nicht für eine gute Idee.

OK, ich hätte noch ergänzen sollen, dass man das temporär machen kann, d. h. nur für die Zeitdauer von Performance-Tests.

Hast Du das bei Dir alles deaktiviert?

Ich habe das alles deaktiviert (... nach einer Testphase), aber ich benutze UDP und einen anderen Port als 1194.

[TomL]

...aber ich benutze UDP und einen anderen Port als 1194.

Das ist hier nicht anders. Hier läuft der Daemon lediglich 2 mal, eben als Fallback auch für TCP. Auf dem UDP-Port passiert so gut wie gar nichts....

[TomL]

Moin@all

Die Angriffe gingen bis gestern abend ca. 22:00 Uhr unvermindert heftig weiter . Ich habe dann zunächst meinen MyFritz-DynDNS-Account deaktiviert und den DSL-Router neu gestartet. Danach war erst mal Ruhe. In der Nacht hats dann nur wieder die ganz normalen quasi obligatorischen Zufalls-Treffer-Attacken gegeben. Heute morgen habe ich den alten DNS-Account komplett stillgelegt und einen neuen eingerichtet... jetzt muss ich mal abwarten, wie es in den nächsten Tagen weitergeht.

Es sieht also tatsächlich so aus, als wäre meine MF-DynDNS-Adresse das Opfer gewesen und als wäre diese Adresse gottweisswohin verteilt worden . Die über viele Stunden ankommenden TCP-Syn-Flag-Pakete kamen zu zig-tausenden zuletzt aus der ganzen Welt, Russland, Amerika, China, Korea. Ich verstehe nur eines an der ganzen Sache nicht ... mir ist schon klar, dass da nicht irgendwelche Typen hundertausende Male meine Adresse auswählen und auf die Entertaste drücken, das tut 'nen stumpfsinniger Bot. Ich kapiere nur nicht, wieso tut der das über viele Stunden lang immer wieder neu, obwohl aus meinem Netz keine Antwort kommt, weil die Pakete verworfen wurden. Selbst ein Bot muss doch irgendwann merken, wenn die Leitung tot ist. Oder denken die, wahrscheinlich ist um 9:00 Uhr Schichtbeginn und ein Thebentimer öffnet mit der Begrüßung "Hereinspaziert" die Türen in mein Netz und die warten einfach darauf?

Hat vielleicht jemand eine Erklärung, warum das bei diesen Attacken so abläuft.... um das ein wenig besser zu verstehen?

[mat6937]

Ich kapiere nur nicht, wieso tut der das über viele Stunden lang immer wieder neu, obwohl aus meinem Netz keine Antwort kommt, weil die Pakete verworfen wurden. Selbst ein Bot muss doch irgendwann merken, wenn die Leitung tot ist.
...
Oder denken die, wahrscheinlich ist um 9:00 Uhr Schichtbeginn und ein Thebentimer öffnet mit der Begrüßung "Hereinspaziert" die Türen in mein Netz und die warten einfach darauf?

Ich denke, dass deine Art der Absicherung, unter den MF-Account-Inhabern die Ausnahme ist.
Bei den meisten wird dann doch irgendwann eine Antwort kommen und deshalb diese beharrlichen Scans.
Evtl. mal temporär (einige Monate) auf den MF-Account verzichten und in diesem Zeitraum einen anderen ddns-Provider nutzen.

[wanne]

Ich kapiere nur nicht, wieso tut der das über viele Stunden lang immer wieder neu, obwohl aus meinem Netz keine Antwort kommt, weil die Pakete verworfen wurden.

Weil die halt – im Gegensatz zu den üblichen Firewalladmins – verstehen wie man Effizente Software schreibt: Was dir weh tut ist state zu behalten. Alles was sich ansatzweise wie Statistik anhört ist ganz sicher teuer.
Das Botnetz wird wohl nicht nur gegen dich Angriffe fahren und deswegen gehen die Sparsam mit ihren Ressourcen um. So ein Syn raus senden kostet gar nichts. Sich jedes Sysn zu merken und dann zu schauen, ob da eine Anzwort drauf kommt ist um Größenordnungen teurer. Deswegen feuer die halt ohne auf Rückmeldung zu warten oder zu reagieren.
Viele sogar noch mit falscher Source-IP. Da kommt dann by desighn nichts durch.

Was sicherlich richtig ist: fail2ban ist in seiner neuen Architektur viel "fetter" (speicherhungriger) geworden und bei einem "echten ddos" sowieso eher ein Klotz am Bein. Es wird relativ aufwändig geprüft und geprüft, aber nichts gesperrt.

Reines Netfilter (z.B. mit recent modul) wäre da schon deutlich leichtgewichtiger, würde aber bei vollständiger distribution genauso ins Leere laufen und letztlich nur überflüssige zusätzliche Last erzeugen.

Ich bezog mich explizit auf fail2ban.
Wenn du wirklich die nur wie mit dem recent Modul die Requests begrenzt hat TomL schon recht:

es begrenzt die Request-Rate und die Anzahl der Connects und verwirft "failed" Anfragen.

Das Problem ist das fail2ban "failed" Anfragen nicht nur einfach verwirft sondern sich merkt. – Und das auch noch auf extrem ineffiziente Art und Weise. Während der Rest der Welt Enormen Einsatz in immer Effizentere Hash- und Zählalgorithem steckt logt fail2ban und muss dass dann auch noch dauernd parsen. Je anfragen desto mehr Einträge, für 100 Requests musst du schon 5000 Zeilen aufändig parsen während man im nginx optimiert ob man jetzt mit schneller ist, wenn man 100 mal ein 2 oder 4 Byte Value anfassen muss...

[TomL]

Ein wenig ärgere ich mich, dass ich nicht mehr alle Daten habe... ich konnte mir also nur noch das ansehen, was ich zwischendurch mal gesichert habe. Anhand meiner Daten konnte ich in dem kurzen Zeitraum über (mindestens) 1400 IP-Adressen auf meinem Server als Gast begrüßen ... die natürlich allesamt umgehend rausgeworfen wurden.

Die Tabelle, aufsteigend sortiert nach Häufigkeit der Versuche.... leider ist das nur ein kleines Zeitfenster.... aber interessant isses schon....:
40822

Die Spitzenreiter seit gestern abend 18:00 Uhr ...

Code: Alles auswählen

    102 SRC=66.11.117.226
    160 SRC=66.11.117.120
    270 SRC=154.223.181.180
    692 SRC=31.14.234.216
    804 SRC=192.250.197.244
   1234 SRC=192.250.197.246

Sich jedes Sysn zu merken und dann zu schauen, ob da eine Anzwort drauf kommt ist um Größenordnungen teurer. Deswegen feuer die halt ohne auf Rückmeldung zu warten oder zu reagieren.

Was ist denn dann überhaupt der Sinn der Aktion, wenn die einfach nur feuern, ohne zu gucken, ob die was getroffen haben? Was passiert denn mit Zufallsteffern, von denen die ja dann gar nix mitkriegen?

Das Problem ist das fail2ban "failed" Anfragen nicht nur einfach verwirft sondern sich merkt. – Und das auch noch auf extrem ineffiziente Art und Weise.

Fail2ban verwirft ja nach meinem Verständnis gar nicht, das erstellt bloß ne Regel im Paketfilter und pflegt dafür ne eigene Recentlist. Das ist genau das, was auch mir nicht passt. Das Programm muss sich alles merken, damits nach Ablauf des jeweiligen Element-Timeouts wieder weiß, an welcher Stelle welcher Eintrag im Pakektfilter entfernt werden muss. Das ist ein absolut krasser Verwaltungsoverhead .... ...und alles deutlich weniger effizient, als das der Kernel selber tut.

[mat6937]

Was ist denn dann überhaupt der Sinn der Aktion, wenn die einfach nur feuern, ...

Der Sinn der Aktion ist, den Dienst der auf dem Port 443 lauscht zu überlasten, damit dieser nicht mehr genutzt werden kann bzw. nicht mehr erreichbar ist.
Das ist kein Angriff um in dein System einzudringen.