Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Fail2Ban vs CrowdSec

16 views
Skip to first unread message

Andreas M. Kirchwitz

unread,
Jul 8, 2023, 8:21:53 PM7/8/23
to
Hallo Sicherheitsleute!

Fail2Ban ist ein Klassiker, aber inzwischen für Ewiggestrige,
denn der neue heiße Sch*** ist CrowdSec, weil nicht jeder für
sich isoliert in seinen lokalen Logs schmort, sondern man die
lokalen Erkenntnisse mit anderen teilt und dann mit geballter
Cloud-Power gegen böse Angreifer vorgehen kann.

Fail2Ban habe ich schon nicht verstanden, wogegen es mich
schützen oder welche alltäglichen Probleme es lösen soll.

CrowdSec ist die logische Weiterentwicklung, doch wozu
eigentlich, frage ich mich, wo ich doch bereits den Sinn
des Vorgängers nicht verstanden hatte.

Welche realen Probleme lösen Fail2Ban oder CrowdSec?
Das läuft ja auf dem "angegriffenen" System. Was muss
da abgewehrt werden? Seine Dienste betreibt man hoffentlich
bereits sicher, sonst sollte man es lieber ganz sein lassen.
Angriffe durch hohe Last muss man in der Regel im Netz über
einem abwehren, da hilft nichts auf dem angegriffenen System
selbst. Generell gehört eine Inspektion des Netzwerk- oder
Datenverkehrs eine Ebene höher auf die Netzwerkgeräte und
nicht auf den Host ganz am Ende der Kette.

So meine bescheidene Meinung, die ich für die bestmögliche
halte, sonst hätte ich ja eine andere Meinung. :-)

Hat jemand vielleicht Beispiele, wo ihm Fail2Ban oder CrowdSec
in einer realen Situation den Hintern gerettet haben, weil sonst
alles zusammengebrochen wäre?

Ich möchte es gern verstehen ... Andreas

Sebastian Suchanek

unread,
Jul 9, 2023, 3:12:51 AM7/9/23
to
Thus spoke Andreas M. Kirchwitz:

> [...]
> Welche realen Probleme lösen Fail2Ban oder CrowdSec?
> Das läuft ja auf dem "angegriffenen" System. Was muss
> da abgewehrt werden?
> [...]

Ich sehe Fail2Ban als Schutz vor Brute-Force-Angriffen.
Beispielsweise meine Exim-Installationen werden täglich mit
hunderten bis tausenden Login-Versuchen bombardiert. Natürlich
sind die Passwörter der legitimen User halbwegs sicher gewählt,
aber es kann halt auch niemand garantieren, dass nicht doch 'mal
eins erraten wird. Um dieses Risiko zu minimieren, werden fremde
Hosts bei mir eben nach 5(?) fehlgeschlagenen Versuchen
geblockt.


HTH,

Sebastian

Marco Moock

unread,
Jul 9, 2023, 4:43:25 AM7/9/23
to
Am 09.07.2023 um 00:21:51 Uhr schrieb Andreas M. Kirchwitz:

> Hallo Sicherheitsleute!
>
> Fail2Ban ist ein Klassiker, aber inzwischen für Ewiggestrige,
> denn der neue heiße Sch*** ist CrowdSec, weil nicht jeder für
> sich isoliert in seinen lokalen Logs schmort, sondern man die
> lokalen Erkenntnisse mit anderen teilt und dann mit geballter
> Cloud-Power gegen böse Angreifer vorgehen kann.
>
> Fail2Ban habe ich schon nicht verstanden, wogegen es mich
> schützen oder welche alltäglichen Probleme es lösen soll.

Verhindern von Brute-Force-Attacken und Verringern der Last dadurch.
Gibt es von einer IP/einem Netz zu viele ungültige Passwörter, wird die
IP für eine gewisse Zeit komplett blockiert.

> Welche realen Probleme lösen Fail2Ban oder CrowdSec?

Massenhafte Login-Versuche auf öffentlich erreichbaren Server, die aber
für die Allgemeinheit erreichbar sein müssen.

> Das läuft ja auf dem "angegriffenen" System. Was muss
> da abgewehrt werden? Seine Dienste betreibt man hoffentlich
> bereits sicher, sonst sollte man es lieber ganz sein lassen.
> Angriffe durch hohe Last muss man in der Regel im Netz über
> einem abwehren, da hilft nichts auf dem angegriffenen System
> selbst. Generell gehört eine Inspektion des Netzwerk- oder
> Datenverkehrs eine Ebene höher auf die Netzwerkgeräte und
> nicht auf den Host ganz am Ende der Kette.

Nur funktioniert sowas nicht richtig. Wie soll z.B. eine Firewall, die
den Datenverkehr sehen kann (z.B. TLS aufgebrochen), über diesen
entscheiden?
Man kann mit sowas wie Fail2Ban ja lokal auf dem Server eine Firewall
einrichten und alles von einer IP droppen ohne ICMP admin. prohibited.
Oder daraus ne Liste erstellen, die dann sekündlich auf eine richtige
Firewall übertragen wird.

Marc Haber

unread,
Jul 9, 2023, 9:21:11 AM7/9/23
to
"Andreas M. Kirchwitz" <a...@spamfence.net> wrote:
>Fail2Ban ist ein Klassiker, aber inzwischen für Ewiggestrige,
>denn der neue heiße Sch*** ist CrowdSec, weil nicht jeder für
>sich isoliert in seinen lokalen Logs schmort, sondern man die
>lokalen Erkenntnisse mit anderen teilt und dann mit geballter
>Cloud-Power gegen böse Angreifer vorgehen kann.
>
>Fail2Ban habe ich schon nicht verstanden, wogegen es mich
>schützen oder welche alltäglichen Probleme es lösen soll.

Fail2Ban ist in erster Linie ein Schutz gegen Bruteforce-Angriffe, was
sich natürlich besonders auswirkt wenn man Muggel-Benutzer hat, die
"geheim1984" als ein gutes Passwort einstufen.

Wenn man Dinge wie logcheck einsetzt, verhindert man mit Fail2ban
zusätzlich, dass die Logcheck-Ergebnisse unbeherrschbar groß werden.

>Welche realen Probleme lösen Fail2Ban oder CrowdSec?
>Das läuft ja auf dem "angegriffenen" System. Was muss
>da abgewehrt werden? Seine Dienste betreibt man hoffentlich
>bereits sicher, sonst sollte man es lieber ganz sein lassen.

Es kommt auch vor dass man dafür bezahlt wird, dass man die Dienste
betreibt und deswegen den einen oder anderen Abstrich bei der
Sicherheit machen muss.

>Angriffe durch hohe Last muss man in der Regel im Netz über
>einem abwehren, da hilft nichts auf dem angegriffenen System
>selbst.

Ein mit dem Paketfilter abgewehrtes TCP SYN ist unter Linux sicher
effizienter als eine Verbindung anzunehmen, einen Prozess zu forken
und in diesem dann den Protokoll-Handshake bis zur Passwortprüfung,
die am besten die Credentials noch in einer Datenbank liegen hat,
laufen zu lassen.

> Generell gehört eine Inspektion des Netzwerk- oder
>Datenverkehrs eine Ebene höher auf die Netzwerkgeräte und
>nicht auf den Host ganz am Ende der Kette.

Da kann ich Dir nicht so ganz komplett zustimmen, weil der Host am
Ende der Kette mehr Informationen hat als das Netzwerkgerät.

>Hat jemand vielleicht Beispiele, wo ihm Fail2Ban oder CrowdSec
>in einer realen Situation den Hintern gerettet haben, weil sonst
>alles zusammengebrochen wäre?

Auch hier gibt es Situationen zwischen den Extremen.

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Thomas Hochstein

unread,
Jul 9, 2023, 3:00:03 PM7/9/23
to
Andreas M. Kirchwitz schrieb:

> Fail2Ban habe ich schon nicht verstanden, wogegen es mich
> schützen oder welche alltäglichen Probleme es lösen soll.

Verhinderung von Brute-Force-Angriffen und damit weniger Müll im Log, ggf.
auch keine Überlastung von Diensten.

Arno Welzel

unread,
Jul 10, 2023, 11:07:39 AM7/10/23
to
Andreas M. Kirchwitz, 2023-07-09 02:21:

> Hallo Sicherheitsleute!
>
> Fail2Ban ist ein Klassiker, aber inzwischen für Ewiggestrige,
> denn der neue heiße Sch*** ist CrowdSec, weil nicht jeder für
> sich isoliert in seinen lokalen Logs schmort, sondern man die
> lokalen Erkenntnisse mit anderen teilt und dann mit geballter
> Cloud-Power gegen böse Angreifer vorgehen kann.
>
> Fail2Ban habe ich schon nicht verstanden, wogegen es mich
> schützen oder welche alltäglichen Probleme es lösen soll.

Brute Force Angriffe - z.B. Loginversuche, die dann CPU-Zeit
beanspruchen. Fail2ban blockt das dann einfach komplett, so dass der
Angreifer gar nicht so weit kommt, einen Login zu versuchen.

[...]
> Hat jemand vielleicht Beispiele, wo ihm Fail2Ban oder CrowdSec
> in einer realen Situation den Hintern gerettet haben, weil sonst
> alles zusammengebrochen wäre?

Siehe oben.

--
Arno Welzel
https://arnowelzel.de

Marc Haber

unread,
Jul 11, 2023, 2:52:42 AM7/11/23
to
Andreas Kohlbach <a...@spamfence.net> wrote:
>On Mon, 10 Jul 2023 17:07:37 +0200, Arno Welzel wrote:
>> Brute Force Angriffe - z.B. Loginversuche, die dann CPU-Zeit
>> beanspruchen. Fail2ban blockt das dann einfach komplett, so dass der
>> Angreifer gar nicht so weit kommt, einen Login zu versuchen.
>
>CPU-Zeit ist (vor allem bei gehackten Rechnern) heute für Umme. Auch
>Netzwerk-Ressourcen: Verzögern oder Festhalten dürfte seit
>Jahren/Jahrzehnten kaum noch Erfolg haben.

Arno schreibt von den Ressourcen auf den angegriffenen Servern. Da
kommt es durchaus darauf an die durch den Angriff verursachte Last
niedrig zu halten.

Aber da hat AMK schon recht, wenn man _das_ Problem hat, möchte man
fail2ban besser dafür benutzen, eine Accessliste im vorgeschalteten
Router zu pflegen, der macht das Filtern im Zweifel in Hardware.

Marco Moock

unread,
Jul 11, 2023, 3:12:55 AM7/11/23
to
Am 10.07.2023 um 21:51:27 Uhr schrieb Andreas Kohlbach:

> On Mon, 10 Jul 2023 17:07:37 +0200, Arno Welzel wrote:
> >
> > Andreas M. Kirchwitz, 2023-07-09 02:21:
> >
> >> Hallo Sicherheitsleute!
> >>
> >> Fail2Ban ist ein Klassiker, aber inzwischen für Ewiggestrige,
> >> denn der neue heiße Sch*** ist CrowdSec, weil nicht jeder für
> >> sich isoliert in seinen lokalen Logs schmort, sondern man die
> >> lokalen Erkenntnisse mit anderen teilt und dann mit geballter
> >> Cloud-Power gegen böse Angreifer vorgehen kann.
> >>
> >> Fail2Ban habe ich schon nicht verstanden, wogegen es mich
> >> schützen oder welche alltäglichen Probleme es lösen soll.
> >
> > Brute Force Angriffe - z.B. Loginversuche, die dann CPU-Zeit
> > beanspruchen. Fail2ban blockt das dann einfach komplett, so dass der
> > Angreifer gar nicht so weit kommt, einen Login zu versuchen.
>
> CPU-Zeit ist (vor allem bei gehackten Rechnern) heute für Umme. Auch
> Netzwerk-Ressourcen: Verzögern oder Festhalten dürfte seit
> Jahren/Jahrzehnten kaum noch Erfolg haben.

Es erschwert aber die Attacken. Wenn jemand nun wirklich Brute-Force
machen will, reicht halt nicht eine IP, sondern er braucht mehrere, um
es effektiv zu machen.

F2B ist halt kein 100%-Schutz.

Andreas M. Kirchwitz

unread,
Jul 11, 2023, 5:00:19 AM7/11/23
to
Marc Haber <mh+usene...@zugschl.us> wrote:

> Fail2Ban ist in erster Linie ein Schutz gegen Bruteforce-Angriffe, was
> [...]

Erst einmal besten Dank an Dich und auch die anderen für die
netten Erklärungen. Ich hab jetzt einfach mal Deinen Artikel
genommen zum Antworten, aber es sind alle gemeint. :-)

Okay, das mit Brute-Force-Angriffen auf Passwörter kann ich
als Sorgenkind verstehen. Solche Angriffe sehe ich natürlich
ebenfalls in den Logs der Dienste, die ich als Hobby privat
für mich betreibe, und ich habe da natürlich keine dicken
Server stehen, muss also auf Ressourcen achten.

Zufall oder Absicht? Bisher haben solche Passwort-Hacker bei
mir nie erkennbare (Über-)Last-Situationen verursacht, sondern
man erkennt klare Verzögerungen auf deren Seite. Ich denke schon,
dass sie unter dem Radar bleiben wollen, obwohl die mich mühelos
mit einem einzigen Angriffs-Host in die Knie zwingen könnten,
aber schließlich wollen sie ja meine Passwörter haben, und dafür
müssen sie den Dienst am Leben lassen und mir möglichst nicht
auf den Keks gehen, sonst würden sie notfalls manuell geerdet.

> [...]
> sich natürlich besonders auswirkt wenn man Muggel-Benutzer hat, die
> "geheim1984" als ein gutes Passwort einstufen.

Ja, leider kann man das nie ganz ausschließen. Selbst scheinbar
gute Passwörter werden manchmal zu Opfern. Damit muss man am Ende
aber auch leben können. Gelegentlich werden Accounts halt gehackt.

Vielleicht ist es naiv, aber meinetwegen sollen die Hacker es halt
probieren. Wenn das Passwort hinreichend gut ist, kann es durch
wildes Probieren nicht geknackt werden - nicht solange ich lebe.

Die meisten Dienste bauen selbst kleine Verzögerungen ein beim
Password-Check, bei anderen kann man sowas mit ein paar
Handgriffen hinzufügen, und bei Diensten, die allgemein eher
wenig Verbindungen erzeugen kann man ein Ratelimit auf den Port
setzen, das ist ja von der Idee so ähnlich wie Fail2Ban, nur eben
bereits mit Hausmitteln (Kernel, iptables & Co.)

Mathematisch dürften die Password-Hacker so gut wie keine Chance
haben, oder?

> Wenn man Dinge wie logcheck einsetzt, verhindert man mit Fail2ban
> zusätzlich, dass die Logcheck-Ergebnisse unbeherrschbar groß werden.

Das kann ich verstehen, früher hab ich neugierig Logfiles gelesen,
doch heutzutage lass ich höchstens Tools darin nach Auffälligkeiten
suchen, aber von Hand gucke ich da nicht mehr rein. Insofern dürfen
die Logs ruhig "zugemüllt" werden, und um Disk Space mache ich mir
keine Sorgen, um den zu sprengen, müsste man die Dienste so massiv
angreifen, dass meine Probleme eh ganz andere wären. :-)

>> Welche realen Probleme lösen Fail2Ban oder CrowdSec?
>> Das läuft ja auf dem "angegriffenen" System. Was muss
>> da abgewehrt werden? Seine Dienste betreibt man hoffentlich
>> bereits sicher, sonst sollte man es lieber ganz sein lassen.
>
> Es kommt auch vor dass man dafür bezahlt wird, dass man die Dienste
> betreibt und deswegen den einen oder anderen Abstrich bei der
> Sicherheit machen muss.

Also im beruflichen Umfeld haben die Kunden in der Regel
(beliebig komplexe) Firewalls davor, die wollen dann bewusst
lieber keine lokalen Spielereien auf den Hosts mit den Diensten.
Ja, die Hosts wüssten manches zwar besser, aber an dieser Stelle
ist meist eine Minimierung der Komplexität erwünscht.

Vor allem CrowdSec, was man als "Nachfolger" von Fail2Ban sehen
könnte, ist ein No-Go, also sich so allgemein auf Netzwerk-Ebene
abhängig zu machen von einer "undefinierten" Community.

Bei Spamfiltern im Mailserver wird die Kröte meist geschluckt,
aber ich kenne da auch welche, die beispielsweise RBLs ablehnen,
weil die nicht selten zu freizügig und ungerechtfertigt größere
Netze sperren, um Providern einen "Denkzettel" zu verpassen,
statt nur die konkreten Spammer-Hosts zu sperren.

CrowdSec kann im Gegensatz zu Fail2Ban daher auch Filter erstellen,
bevor der Hacker bei einem selbst angekommen ist. Aber man weiß
eben auch nicht so genau, wie die "Community" tickt und ob die
Sperren umfassender sind als technisch notwendig.

>> Angriffe durch hohe Last muss man in der Regel im Netz über
>> einem abwehren, da hilft nichts auf dem angegriffenen System
>> selbst.
>
> Ein mit dem Paketfilter abgewehrtes TCP SYN ist unter Linux sicher
> effizienter als eine Verbindung anzunehmen, einen Prozess zu forken
> und in diesem dann den Protokoll-Handshake bis zur Passwortprüfung,
> die am besten die Credentials noch in einer Datenbank liegen hat,
> laufen zu lassen.

Ja, das ist richtig, doch siehe oben, der typische Hacker lässt
nach meiner persönlichen Erfahrung seine Opfer leben, hält sich
sogar spürbar zurück. Anders natürlich bei einem DoS- oder gar
DDoS-Angriff, das würden meine kleinen Privat-Dienste sowieso
nicht verkraften, wenn es jemand gezielt darauf anlegt, da würde
mir am Ende auch kein Fail2Ban, CrowdSec etc. helfen, da müsste
mein Provider ran.

Ich nehme mal an, die größeren Hoster haben ohnehin Vorrichtungen
gegen die allergröbsten Angriffe, also nicht für mich speziell
als kleinen Kunden, sondern um ihr gesamtes Business zu schützen.

Vielleicht hatte ich bisher nur Glück, dass ich bisher keinen
Kummer hatte mit Angriffen. Klar, natürlich sind meine täglichen
Logs voller Spuren diverser Angriffsversuche, aber selbst für
meine winzigen Privat-Dienste sind das lastmäßig Peanuts, und
zu (meinen) Lebzeiten sollten sie mathematisch gesehen geringe
Chancen auf Erfolg haben.

Besten Dank dennoch für die guten Erklärungen, denn jetzt sehe
ich klarer, gegen welchen Kummer mich z.B. Fail2Ban schützen
könnte, falls es mich unglücklicherweise doch mal betreffen sollte.

Wie sind eigentlich die Meinungen zu CrowdSec, also Fail2Ban
mit extra Filterlisten aus der Community bzw. "aus der Cloud",
wie man modern sagen würde? Schon Erfahrungen damit gesammelt?

Grüße, Andreas

Christian Garbs

unread,
Jul 11, 2023, 12:43:43 PM7/11/23
to
Mahlzeit!

Andreas M. Kirchwitz <a...@spamfence.net> wrote:

[fail2ban auf dem Zielhost]

> Also im beruflichen Umfeld haben die Kunden in der Regel
> (beliebig komplexe) Firewalls davor, die wollen dann bewusst
> lieber keine lokalen Spielereien auf den Hosts mit den Diensten.
> Ja, die Hosts wüssten manches zwar besser, aber an dieser Stelle
> ist meist eine Minimierung der Komplexität erwünscht.
>
> Vor allem CrowdSec, was man als "Nachfolger" von Fail2Ban sehen
> könnte, ist ein No-Go, also sich so allgemein auf Netzwerk-Ebene
> abhängig zu machen von einer "undefinierten" Community.

Ich finde es auch sinnvoll, seine Security-Infrastuktur lokal zu
betreiben, aber ist es im kommerziellen Umfeld nicht inzwischen sogar
Usus (sprich: es gibt teuer bezahlte Produkte) dafür, möglichst viel
seiner Firewall- und Virenschutzinfrastruktur in die Cloud auszulagen,
um sofort und noch vor dem Rest der Welt vor den neuesten Angriffen
geschützt zu sein?

Vor dem Hintergrund sehe ich CrowdSec (von dem ich vor Deinem Artikel
nichts gehört habe; fail2ban nutze ich sogar) daher als "Kind unserer
Zeit" und "das musste ja so kommen" ;-)

Wechseln werde ich erstmal nicht, mir reicht es, den dauernden SSH-
und IMAP-Abklopfern wenigstens ein paar kleinere Steine in den Weg zu
lesen, wenn sie nicht schnell genug die Quell-IP wechseln.

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de
Viele Menschen sehnen sich nach der Unsterblichkeit und wissen nicht,
was sie an einem Sonntagnachmittag machen sollen!

Arno Welzel

unread,
Jul 15, 2023, 8:02:19 AM7/15/23
to
Andreas Kohlbach, 2023-07-11 03:51:

> On Mon, 10 Jul 2023 17:07:37 +0200, Arno Welzel wrote:
>>
>> Andreas M. Kirchwitz, 2023-07-09 02:21:
>>
>>> Hallo Sicherheitsleute!
>>>
>>> Fail2Ban ist ein Klassiker, aber inzwischen für Ewiggestrige,
>>> denn der neue heiße Sch*** ist CrowdSec, weil nicht jeder für
>>> sich isoliert in seinen lokalen Logs schmort, sondern man die
>>> lokalen Erkenntnisse mit anderen teilt und dann mit geballter
>>> Cloud-Power gegen böse Angreifer vorgehen kann.
>>>
>>> Fail2Ban habe ich schon nicht verstanden, wogegen es mich
>>> schützen oder welche alltäglichen Probleme es lösen soll.
>>
>> Brute Force Angriffe - z.B. Loginversuche, die dann CPU-Zeit
>> beanspruchen. Fail2ban blockt das dann einfach komplett, so dass der
>> Angreifer gar nicht so weit kommt, einen Login zu versuchen.
>
> CPU-Zeit ist (vor allem bei gehackten Rechnern) heute für Umme. Auch

Nein, ist sie nicht. Server kosten echtes Geld - jeden Monat. Und
entsprechend ist die verfügbare CPU-Zeit eben nicht "für Umme" und wird
für sinnvollere Dinge benötigt, als sich mit Loginversuchen von
Angreifern zu befassen.

Und "bei gehackten Rechnern" will man ja gerade *nicht*, deswegen nutzt
man auf *Servern* fail2ban um einen erfolgreichen Hack zu vermeiden.

> Netzwerk-Ressourcen: Verzögern oder Festhalten dürfte seit
> Jahren/Jahrzehnten kaum noch Erfolg haben.

Hier schon.

Arno Welzel

unread,
Jul 15, 2023, 8:03:23 AM7/15/23
to
Marco Moock, 2023-07-11 09:12:
Auch mehrere IP-Adressen werden durch fail2ban erkannt, wenn der
Angreifer nicht nur einen einzigen Versuch pro IP-Adresse durchführt.

> F2B ist halt kein 100%-Schutz.

Das ist keine Maßnahme.

Marco Moock

unread,
Jul 15, 2023, 10:51:23 AM7/15/23
to
Am 15.07.2023 um 14:02:17 Uhr schrieb Arno Welzel:

> Andreas Kohlbach, 2023-07-11 03:51:
>
> > On Mon, 10 Jul 2023 17:07:37 +0200, Arno Welzel wrote:
> >>
> >> Andreas M. Kirchwitz, 2023-07-09 02:21:
> >>
> >>> Hallo Sicherheitsleute!
> >>>
> >>> Fail2Ban ist ein Klassiker, aber inzwischen für Ewiggestrige,
> >>> denn der neue heiße Sch*** ist CrowdSec, weil nicht jeder für
> >>> sich isoliert in seinen lokalen Logs schmort, sondern man die
> >>> lokalen Erkenntnisse mit anderen teilt und dann mit geballter
> >>> Cloud-Power gegen böse Angreifer vorgehen kann.
> >>>
> >>> Fail2Ban habe ich schon nicht verstanden, wogegen es mich
> >>> schützen oder welche alltäglichen Probleme es lösen soll.
> >>
> >> Brute Force Angriffe - z.B. Loginversuche, die dann CPU-Zeit
> >> beanspruchen. Fail2ban blockt das dann einfach komplett, so dass
> >> der Angreifer gar nicht so weit kommt, einen Login zu versuchen.
> >
> > CPU-Zeit ist (vor allem bei gehackten Rechnern) heute für Umme.
> > Auch
>
> Nein, ist sie nicht. Server kosten echtes Geld - jeden Monat. Und
> entsprechend ist die verfügbare CPU-Zeit eben nicht "für Umme" und
> wird für sinnvollere Dinge benötigt, als sich mit Loginversuchen von
> Angreifern zu befassen.

Kommt drauf an, wie stark der ausgelastet ist und wie viele
Angreifer-Anfragen reinkommen. Wenn von einer IP ständig pro Minute 10
Anfragen reinkommen, kann da heutige Hardware völlig problemlos
verarbeiten.

Arno Welzel

unread,
Jul 15, 2023, 10:57:10 AM7/15/23
to
Marco Moock, 2023-07-15 16:51:

> Am 15.07.2023 um 14:02:17 Uhr schrieb Arno Welzel:
[...]
>>> CPU-Zeit ist (vor allem bei gehackten Rechnern) heute für Umme.
>>> Auch
>>
>> Nein, ist sie nicht. Server kosten echtes Geld - jeden Monat. Und
>> entsprechend ist die verfügbare CPU-Zeit eben nicht "für Umme" und
>> wird für sinnvollere Dinge benötigt, als sich mit Loginversuchen von
>> Angreifern zu befassen.
>
> Kommt drauf an, wie stark der ausgelastet ist und wie viele
> Angreifer-Anfragen reinkommen. Wenn von einer IP ständig pro Minute 10
> Anfragen reinkommen, kann da heutige Hardware völlig problemlos
> verarbeiten.

Und wenn von 100 IP-Adressen pro Sekunde 100 Anfragen reinkommen, ist es
nicht mehr problemlos. BTDT.

Marco Moock

unread,
Jul 15, 2023, 11:06:43 AM7/15/23
to
Das scheint aber beim Andreas Kohlbach bisher nicht passiert - oder er
hat immer so flotte Rechner, dass es ihm wurscht ist.

Arno Welzel

unread,
Jul 15, 2023, 11:29:09 PM7/15/23
to
Andreas Kohlbach, 2023-07-15 23:05:

> On Sat, 15 Jul 2023 17:06:41 +0200, Marco Moock wrote:
>>
>> Am 15.07.2023 um 16:57:08 Uhr schrieb Arno Welzel:
>>
>>> Marco Moock, 2023-07-15 16:51:
>>>
>>>> Kommt drauf an, wie stark der ausgelastet ist und wie viele
>>>> Angreifer-Anfragen reinkommen. Wenn von einer IP ständig pro Minute
>>>> 10 Anfragen reinkommen, kann da heutige Hardware völlig problemlos
>>>> verarbeiten.
>>>
>>> Und wenn von 100 IP-Adressen pro Sekunde 100 Anfragen reinkommen, ist
>>> es nicht mehr problemlos. BTDT.
>>
>> Das scheint aber beim Andreas Kohlbach bisher nicht passiert - oder er
>> hat immer so flotte Rechner, dass es ihm wurscht ist.
>
> Weil ich keinen professionellen Service betreibe. Ich (und die meisten
> anderen Amateur-Server-Betreiber) werden vermutlich nie 100 Anfragen pro
> Sekunde sehen.

Es geht weniger darum, was bei Dir persönlich relevant ist, sondern um
die Frage, warum Tools wie fail2ban existieren.

Arno Welzel

unread,
Jul 15, 2023, 11:31:43 PM7/15/23
to
Andreas Kohlbach, 2023-07-15 22:58:

> On Sat, 15 Jul 2023 14:02:17 +0200, Arno Welzel wrote:
>>
>> Andreas Kohlbach, 2023-07-11 03:51:
>>
>>> On Mon, 10 Jul 2023 17:07:37 +0200, Arno Welzel wrote:
>>>>
>>>> Brute Force Angriffe - z.B. Loginversuche, die dann CPU-Zeit
>>>> beanspruchen. Fail2ban blockt das dann einfach komplett, so dass der
>>>> Angreifer gar nicht so weit kommt, einen Login zu versuchen.
>>>
>>> CPU-Zeit ist (vor allem bei gehackten Rechnern) heute für Umme. Auch
>>
>> Nein, ist sie nicht. Server kosten echtes Geld - jeden Monat. Und
>> entsprechend ist die verfügbare CPU-Zeit eben nicht "für Umme" und wird
>> für sinnvollere Dinge benötigt, als sich mit Loginversuchen von
>> Angreifern zu befassen.
>
> Dann müsste man schon einem DDoS ausgesetzt sein.

Ja, sowas kommt vor.

> Mein "Homeserver" sieht natürlich auch Versuche. Nichts aber, was beim
> Arbeiten auffällt.

Ja - und?

>> Und "bei gehackten Rechnern" will man ja gerade *nicht*, deswegen nutzt
>> man auf *Servern* fail2ban um einen erfolgreichen Hack zu vermeiden.
>
> Der gehackte Server ist der Angreifer. Darauf hat man keinen Einfluss.
>
> Ich meinte, wenn X gehackte Server für Angriffe genutzt werden, merkt
> jeder einzelne Betroffene oft nicht einmal, dass er gehackt ist.

Aber der *Server* merkt das! Und *dass* will man sich schützen!

> Man selbst als Ziel sollte in der Regel auch nichts merken (Rauschen in
> den Logs). Zumindest nicht hier.

Einen DDoS merke ich durchaus.

>>> Netzwerk-Ressourcen: Verzögern oder Festhalten dürfte seit
>>> Jahren/Jahrzehnten kaum noch Erfolg haben.
>>
>> Hier schon.
>
> Dann hast Du einen "großen" Server, der professionell Dienste anbietet?
> Ja, dann kann fileban helfen.
>
> Für Privatuser, die nebenher Server betreiben — wie ich — werden kaum
> CPU-Last spüren.

Ja und? Es ging um die Frage, wozu fail2ban benutzt wird. Das ist die
Antwort. Ob es für Dich persönlich sinnvoll ist, ist für die Frage
völlig irrelevant.

Marco Moock

unread,
Jul 16, 2023, 1:31:44 AM7/16/23
to
Am 15.07.2023 um 16:58:15 Uhr schrieb Andreas Kohlbach:

> Der gehackte Server ist der Angreifer. Darauf hat man keinen Einfluss.

Du kannst eine Abuse-Mail schreiben. Gescheite ISPs und Hoster kümmern
sich darum. So kann man zumindest die Anzahl solcher Server reduzieren.

Marc Haber

unread,
Jul 16, 2023, 2:35:08 AM7/16/23
to
Und für jeden den man so los wird, wachsen zehn nach. Das ist sinnlos.
Ignorieren, höchstens im Paketfilter blocken, und gut.

Andreas M. Kirchwitz

unread,
Jul 16, 2023, 3:19:43 AM7/16/23
to
In den Ländern, aus denen die meisten Angriffe erfolgen, interessiert
sich üblicherweise niemand für Abuse-Mail aus dem Ausland, weil denen
klar ist, dass sie rechtlich meist nicht sinnvoll zu belangen sind,
das ist vermutlich nicht selten sogar bewusst deren Geschäftsmodell.

Wie ich bereits erwähnte, zeigen Hacker ein oft auffallend defensives
Verhalten, im einfachsten Fall ganz banal deshalb, weil sie das Ziel
ja nicht lahmlegen, sondern hacken wollen. Es bringt also nichts,
das Opfer brachial zu überrennen. Bei genauerer Betrachtung wollen
sie aber auch möglichst lange unter dem Radar bleiben, und damit ist
nicht Kleinkram wie fail2ban gemeint, sondern zentrale netzwerkseitige
Überwachungssysteme, wie sie seit vielen Jahren üblich sind, um sich
oder sein Geschäft zu schützen.

Deshalb bringt Andreas Kohlbach es auf den Punkt, dass gegen den
durchschnittlichen Hacker keine besonderen Maßnahmen notwendig sind,
die paar Hackversuche auf Passwörter, Keys oder was auch immer gehen
selbst auf altersschwachen System im Rauschen unter, die verursachte
Last ist selten wahrnehmbar. Freilich nicht, weil CPU-Power billig
wäre, das ist sie keineswegs, schließlich ist das eine wesentliche
Kenngröße für die entstehenden Kosten, sondern weil die Last von den
Hackern bewusst sehr gering gehalten wird.

Etwas anderes ist das gezielte Lahmlegen von Diensten, was leider
durchaus verbreitet ist, aber dagegen hilft in der Regel kein lokaler
Schutz wie fail2ban, sondern da muss leider auf höherer Ebene
eingegriffen werden. Wenn man im voraus weiß, dass man aufgrund
seiner Dienste im Fokus bestimmter Leute steht, geht man ohnehin
besser gleich zu Anbietern, die spezialisiert sind auf sowas.

Grüße, Andreas

Andreas Kohlbach

unread,
Jul 16, 2023, 9:25:39 PM7/16/23
to
On Sun, 16 Jul 2023 07:19:41 -0000 (UTC), Andreas M. Kirchwitz wrote:
>
> Marco Moock <mo...@posteo.de> wrote:
>
>> Am 15.07.2023 um 16:58:15 Uhr schrieb Andreas Kohlbach:
>>
>>> Der gehackte Server ist der Angreifer. Darauf hat man keinen Einfluss.
>>
>> Du kannst eine Abuse-Mail schreiben. Gescheite ISPs und Hoster kümmern
>> sich darum. So kann man zumindest die Anzahl solcher Server reduzieren.
>
> In den Ländern, aus denen die meisten Angriffe erfolgen, interessiert
> sich üblicherweise niemand für Abuse-Mail aus dem Ausland, weil denen
> klar ist, dass sie rechtlich meist nicht sinnvoll zu belangen sind,
> das ist vermutlich nicht selten sogar bewusst deren Geschäftsmodell.

Wie die 218.92.0.112, die ich im anderen Postings aus den Logs zog. China
Telecom. Da werden eher ein paar Säcke Reis umfallen, bis der ISP tätig wird.
--
Andreas

Marc Haber

unread,
Jul 17, 2023, 6:42:25 AM7/17/23
to
"Andreas M. Kirchwitz" <a...@spamfence.net> wrote:
>Etwas anderes ist das gezielte Lahmlegen von Diensten, was leider
>durchaus verbreitet ist, aber dagegen hilft in der Regel kein lokaler
>Schutz wie fail2ban, sondern da muss leider auf höherer Ebene
>eingegriffen werden.

Auch hier wäre fail2ban ein guter Erstansatz, weil auf der Linux-Seite
weit verbreitet und gut integriert. Muss man nur dranfrickeln, dass
als Ersatz oder zusätzlich zur Konfiguration des lokalen Paketfilters
eine Benachrichtigung eines Managementsystems o.ä. erfolgt, damit
dieses die davor liegende Firewall entsprechend parametriert.

Könnte man automatisieren, wenn man wollte.

Ich werde fail2ban in absehbarer Zeit auf einem bestimmten System
einsetzen, weil ich hoffe, dass der stündliche Syslog-Report aus
logcheck dann wieder öfter auf eine Bildschirmseite passt.

Arno Welzel

unread,
Jul 17, 2023, 12:13:20 PM7/17/23
to
Andreas Kohlbach, 2023-07-17 03:31:
> Sollte es nicht darum gehen, *ob* man den Aufwand des Einrichtens
> betreiben soll?

Nein, die Frage war nicht, ob man fail2ban einrichten soll, sondern was
die Funktion dieses Tools ist.

> Weiter verallgemeiner ich meine Situation auf andere Linuxer, die
> vielleicht nebenher einen Server (SSH ist ja auch einer) betreiben, um
> den Rechner auch mal vom Internet aus erreichen zu können. Die werden
> kein Fail2Ban benötigen. Und auch keine hohe CPU-Last sehen.

Und darum ging es ebenfalls nicht, sondern die Frage, warum fail2ban
existiert. Wenn Du für Dich persönlich zu der Erkenntnis kommst, dass Du
das nicht brauchst, dann ändert sich dennoch gar nichts daran, wofür
fail2ban ursprünglich entwickelt wurde.

Zitat aus dem OP:

"Fail2Ban habe ich schon nicht verstanden, wogegen es mich schützen oder
welche alltäglichen Probleme es lösen soll."

Und genau diese Frage wurde geklärt. Wenn der OP keinen Server betreibt,
bei dem man von entsprechenden Angriffsversuchen ausgehen muss, dann
braucht er fail2ban nicht. Aber dennoch sollte er zumindest auf die
Frage, wozu fail2ban eigentlich da ist, eine Antwort bekommen.

Arno Welzel

unread,
Jul 17, 2023, 12:17:06 PM7/17/23
to
Andreas Kohlbach, 2023-07-17 03:23:

> On Sun, 16 Jul 2023 05:31:41 +0200, Arno Welzel wrote:
>>
>> Andreas Kohlbach, 2023-07-15 22:58:
>>
>>> Dann hast Du einen "großen" Server, der professionell Dienste anbietet?
>>> Ja, dann kann fileban helfen.
>>>
>>> Für Privatuser, die nebenher Server betreiben — wie ich — werden kaum
>>> CPU-Last spüren.
>>
>> Ja und? Es ging um die Frage, wozu fail2ban benutzt wird. Das ist die
>> Antwort. Ob es für Dich persönlich sinnvoll ist, ist für die Frage
>> völlig irrelevant.
>
> Ich verstand, wann fail2ban eingesetzt werden soll. Oder eben gar nicht.

Nein, es ging darum, was fail2ban rein technisch tut. Ob man das dann
braucht oder nicht, muss jeder selbst entscheiden.

[...]
> 2023-07-16T21:16:14.497394-04:00 ank sshd[164445]: Failed password for root from 218.92.0.112 port 24575 ssh2
> 2023-07-16T21:16:17.002860-04:00
> 2023-07-16T21:16:20.046333-04:00
> 2023-07-16T21:16:22.405715-04:00
> 2023-07-16T21:16:22.406096-04:00
> 2023-07-16T21:16:24.141155-04:00
> 2023-07-16T21:16:25.670370-04:00
> 2023-07-16T21:16:29.053934-04:00
> 2023-07-16T21:16:33.071139-04:00
>
> fail2ban o.ä. laufen nicht. Der Scammer versucht es alle paar
> Minuten. Das wird vermutlich bei anderen Privatusern ähnlich aussehen.

Ja - und wenn man keine Lust auf hunderte solche Einträge im Log hat,
hilft fail2ban sehr zuverlässig, solche Zugriffsversuche generell zu
unterbinden.

Andreas M. Kirchwitz

unread,
Jul 17, 2023, 5:09:03 PM7/17/23
to
Marc Haber <mh+usene...@zugschl.us> wrote:

>> Etwas anderes ist das gezielte Lahmlegen von Diensten, was leider
>> durchaus verbreitet ist, aber dagegen hilft in der Regel kein lokaler
>> Schutz wie fail2ban, sondern da muss leider auf höherer Ebene
>> eingegriffen werden.
>
> Auch hier wäre fail2ban ein guter Erstansatz, weil auf der Linux-Seite
> weit verbreitet und gut integriert. Muss man nur dranfrickeln, dass
> als Ersatz oder zusätzlich zur Konfiguration des lokalen Paketfilters
> eine Benachrichtigung eines Managementsystems o.ä. erfolgt, damit
> dieses die davor liegende Firewall entsprechend parametriert.

Ich habe mir fail2ban aufgrund der Diskussion noch mal angeschaut,
und da kam die Erinnerung zurück, warum ich früher gezögert hatte
beim Einsatz.

Man muss fail2ban natürlich beibringen, worauf es in den Logs
überhaupt anspringen soll. Es bringt zwar allerlei Konfigs mit,
allerdings muss man am Ende doch selbst sicherstellen, dass es
harmoniert mit den konkreten Software-Versionen, die man für
seine Dienste einsetzt. Das können manchmal besonders alte sein
(bei RHEL bis zu 10 Jahre), manchmal aber auch besonders neue
(wenn man selbst das Neuste compiliert). fail2ban läuft durch
seine Abhängigkeit von Python selbst nicht überall in jeder
beliebigen Version, da muss man also auch ein Auge drauf haben.

Das soll keine Kritik sein, so ist halt das Konzept dahinter,
und das waren damals meine Gedanken dazu. Als Admin sieht man
halt überall Kummer und Sorgen. :-)

Wie machst Du das bei Dir? Ist das viel Arbeit in der Praxis?
Oder mache ich mir bloß zu viele Gedanken?

Vielleicht ist es z.B. bei Debian ein No-Brainer, solange man
das mitgelieferte fail2ban und die mitgelieferten Dienste nutzt,
weil die perfekt harmonieren, jedoch wenn man in der RHEL-Welt
aufgewachsen ist, sehen die Dinge etwas anders aus, das meine
ich wertfrei, nimm einfach mal die bis zu 10 Jahre Laufzeit,
da muss man notgedrungen manches anders denken.

Grüße, Andreas

Marc Haber

unread,
Jul 18, 2023, 1:47:15 AM7/18/23
to
"Andreas M. Kirchwitz" <a...@spamfence.net> wrote:
>Wie machst Du das bei Dir? Ist das viel Arbeit in der Praxis?
>Oder mache ich mir bloß zu viele Gedanken?

Ich hab es ja noch nicht. Aber im Zweifel wird durch fail2ban ncihts
schlechter, so dass man es einfach mal probieren kann. Unpassende
Pattern werden in die eine Richtung (keine Sperren mehr => fällt in
der Statistik auf) oder in die andere Richtung (zu viele Sperren =>
User beschweren sich oder Monitoring wird rot) auffallen.

Python ist in Debian inzwischen ziemlich schmerzfrei.

Peter J. Holzer

unread,
Jul 18, 2023, 4:53:24 AM7/18/23
to
On 2023-07-18 05:47, Marc Haber <mh+usene...@zugschl.us> wrote:
> "Andreas M. Kirchwitz" <a...@spamfence.net> wrote:
>>Wie machst Du das bei Dir? Ist das viel Arbeit in der Praxis?
>>Oder mache ich mir bloß zu viele Gedanken?
>
> Ich hab es ja noch nicht. Aber im Zweifel wird durch fail2ban ncihts
> schlechter,

/var könnte voll werden. Fail2ban kann durchaus mal ein Gig oder so
belegen, und wenn man es gewohnt ist, kleine dedizierte VMs anzulegen,
sollte man das einplanen.

Je nachdem, wie man seine lokalen iptables-Rules verwaltet, kann einem
fail2ban auch in die Quere kommen.

hp
0 new messages