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