Alternatief voor Fail2Ban ?

[Doktor Avalanche]

Beste,

Ik gebruik fail2ban op een Oracle Free Tier server om ssh login pogingen te blokkeren.
De bantime stond op 180 dagen bij mij ,wat resulteerde in > 10000 entries in de firewall.
Ik merkte een heel trage netwerk connectie naar die server (150kb/sec), van het moment ik fail2ban afzet gaat ie terug op volle snelheid.
SSH toegang is enkel via private key mogelijk op deze server. Dus op zich doen die login pogingen er niet toe. Maar op zich moeten ze niet proberen he
Gebruiken jullie fail2ban nog (of iets anders)?
Hoe beveiligen julllie je server verder nog?

Alvast bedankt
Wim

[CCatalyst]

SSH toegang is enkel via private key mogelijk op deze server.

De authenticatie is met de public keys mag ik hopen. Maar nee, als er geen authenticatie via paswoord is, dan is Fail2Ban niet nodig en mag je het gerust afzetten. Dat is de configuratie die ik hanteer: pubkey online, sshd hardened volgens de gebruikelijke richtlijnen, en geen Fail2Ban oid.

Je kan eventueel nog via firewall toegang beperken tot bepaalde IP's.

[liber!]

De bantime stond op 180 dagen bij mij ,wat resulteerde in > 10000 entries in de firewall.
Ik merkte een heel trage netwerk connectie naar die server (150kb/sec), van het moment ik fail2ban afzet gaat ie terug op volle snelheid.

Je kan de fail2ban config aanpassen zodat je minder bans genereerd en zo het aantal iptables regels wat beperkt. De performance issue komt van de vele iptable regels.


Ik gebruik fail2ban, ook voor enkele nginx sites, een layered defense (in combinatie met ssh keys, etc) is altijd nuttig.

[DarkV]

Waarom zo'n hoge ban time... als je die op 7 dagen zou zetten is dat toch meer dan voldoende om iemand af te remmen ?

Maar public keys lijkt me inderdaad een betere oplossing.

[Splitter]

sshd config optimaliseren, pubkeys gebruiken en dus zeker zorgen dat er geen password auth toegelaten is, en fail2ban met een bantime van 7 dagen.
waarom zou je fail2ban weghalen ipv gewoon correct configureren?

een bantime van 180 dagen, dat is een halfjaar... de meeste pogingen zijn niet zo hardnekkig hoor (al kan het zijn dat ze na een halfjaar opnieuw proberen natuurlijk, maar een halfjaar aan een stuk...)
als je de eerste ban op 7 dagen zet en dan recidive op 30 bv ben je al meer dan gesteld genoeg met fail2ban.

[devilkin]

Als je perse fail2ban wilt blijven gebruiken kan je er ook voor opteren om de bantime progressief te laten verhogen bij repeat offenders
https://visei.com/2020/05/incremental-b ... -fail2ban/

Maar als je ssh key authentication gebruikt maakt het allemaal al veel minder uit. Je kan als je perse wilt nog je ssh enkel toelaten vanuit een VPN tunnel.

[Splitter]

het maakt minder uit, maar het is zeker nog steeds niet nutteloos.
bv bij mij staat f2b over het algemeen ingesteld: als ze een dienst proberen te bruteforcen, blokkeer alle diensten voor dat IP

het is nu ook niet zo dat f2b echt veel overhead of onderhoud nodig heeft (als in eigenlijk totaal niks), dus het is een eenvoudige stap om net dat ietsje meer security te hebben.

zoals hierboven ook aangehaald: het probleem komt eigenlijk niet van fail2ban, maar van het feit dat je zoveel regels in je iptables hebt, dat het even duurt alvorens die allemaal gecontroleerd zijn voor elk pakket.
(en dat los je op door de bantime te verminderen naar bv een week in eerste instantie)

[Doktor Avalanche]

Bedankt allen voor de tips,
Ik heb de bantime nu op 1 dag gezet (een uur geleden), op dat uur zijn er nu al 100 bijgekomen (waarschijnlijk een groot deel van die net unbanned zijn en opnieuw proberen)
Hou het nog wel even in het oog.

Merci!

[CCatalyst]

waarom zou je fail2ban weghalen ipv gewoon correct configureren?

Omdat fail2ban geen meerwaarde biedt als je geen paswoorden toestaat. Behalve misschien uw logfiles verkleinen, maar dat mag op zich niet de bedoeling zijn (wel uw logfiles beter managen).

Als een beveiligingsmaatregel geen meerwaarde biedt - zeker als het berust op extra software - dan haal je het beter weg. De software kan immers zelf de attack surface weer vergroten, waardoor je netto dus een groter risico loopt door fail2ban wel te gebruiken (als je geen paswoorden toestaat natuurlijk).

Fail2ban dateert van 2004, security practices waren toen volledig anders, zo zag Userbase eruit toen de eerste versie van fail2ban uitkwam - @meon had net het artikel "Belgacom begint met VDSL" gepubliceerd. In die tijd had fail2ban absoluut een nut. Nu, 20 jaar later, is er op beveiligingsvlak veel verbeterd. Dat het vandaag voor iedereen haalbaar is om een sshd te runnen zonder dat fail2ban nog een meerwaarde biedt is een positieve zaak, en bewijst dat fail2ban geslaagd is in haar oorspronkelijke missie: sshd beter beveiligen.

[Splitter]

quasi al die CVE"s zijn ofwel "er kan een IP teveel geblokkeerd worden" (niet zo erg) of "er zit een fout in die door een externe applicatie mogelijk gemaakt werd (ok ok, f2b zou ook alles moeten checken & escapen).... maar echte "attack surface" is er nu ook niet dadelijk door f2b.

dat f2b origineel 20j geleden begonnen is, wil gewoon zeggen dat het ook na 2 decennia nog steeds nut heeft (en actief onderhouden is).
onthou dat het internet nog voor grote delen draait op apache (origineel 1995) en postfix (origineel 1998), terwijl openssh (meest gebruikte iirc) van 99 is...
de ouderdom wil dus absoluut niets zeggen over het nut.

buiten crowdsec (dat vrij nieuw is, en mogelijks onbetrouwbaar indien er een issue is met de agent of de dns) heb je voor zover ik weet géén alternatief om eventuele bruteforcers tegen te houden (en dat over zowat elk type applicatie dat logfiles kan maken)

het zou idd niet de enige security mogen zijn, maar het is m.i. nog steeds een nuttige add-on, hoewel misschien steeds minder en minder voor ssh
(gezien je passwords kan uitzetten, alles met keys kan doen, en rate limit ook in de sshd config kan steken)

maar ik vermoed dat het geen pure jump-server zal zijn van OP, en er toch op zijn minst 1 andere service op draait die exposed is,
en dan kan f2b zeker nog zijn meerwaarde bieden dus

edit:

ik moet trouwens wél zeggen dat het lijkt alsof je bij OCI meer aanvallen krijgt dan bij bv leaseweb, want op mijn OCI machines heb ik ook wel altijd meer ip's in de banlist dan bij leaseweb.

[J-J]

Misschien geen direct antwoord op de vraag over fail2ban, maar ik maak gebruik van ”tailscale-ssh” om mijn OCI te bereiken.
Zo hoef ik geen poorten open te zetten.

[silentkiller]

Even de knuppel in het hoenderhok gooien ( ):
Kan je de poort niet wijzigen naar iets anders dan 22?

Niet dat ik security through obscurity wil promoten, verre van, maar als je op een andere poort je security op orde hebt, heb je al een pak minder 'bans'