[HN Gopher] Fail2Ban
___________________________________________________________________
Fail2Ban
Author : redbell
Score : 80 points
Date : 2023-10-06 19:26 UTC (3 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| rakkhi wrote:
| Don't ban hosts or any service account automatically. Use
| conditional accesss, mga for hosts with credentials + IP or
| client cert. Auto raise a snow ticket for the support team and an
| alert in your SIEM for your Soc. If you want more detail I'll put
| my blog in my profile.
| kevingadd wrote:
| Be careful not to ban yourself :) had to use linode emergency
| shell once after misconfigured fail2ban blocked my ip
| eco wrote:
| That's just a rite of passage we must all do.
| akerl_ wrote:
| The pro tip is to just not use it for SSH
| PUSH_AX wrote:
| To expand on this, don't use it because a good approach is to
| disable password authentication on SSH and use keys instead.
|
| If for some reason you still needed password auth enabled I'd
| be inclined to still use f2b.
| ljm wrote:
| Every time I spin up a box by hand (which isn't often),
| I'll set up a sudo user with my SSH key, then drop out of
| the root shell and log back in as the new user. Only then
| will I disable root login and password auth over SSH and
| start setting up fail2ban and the like.
|
| If I lose access by, say, switching to a new computer and
| losing my SSH key, then I'm more or less dead in the water.
| But it's a small price to pay and 1password supports SSH
| keys first-class now.
| seanp2k2 wrote:
| at that point, why not just do FIDO2 with a YubiKey or
| something? eg https://www.ajfriesen.com/yubikey-ssh-key/
| as long as you don't lose the YubiKey or the backup
| YubiKeys you're good.
| elesiuta wrote:
| I require both key and password to login, and have fail2ban
| rate limit password attempts.
|
| This gives sufficient notice to fix things if a key were to
| become compromised.
| Schnitz wrote:
| I use it with ssh and password auth disabled, is there a
| reason not to? Might be overkill but the host is in my home
| so physical access if I ever get locked out is not an
| issue.
| elesiuta wrote:
| I think this is still reasonable, attackers may have a
| database of leaked keys (e.g. if you ever accidentally
| commited to GitHub, or ever ran a malicious script which
| uploaded it), which they then try on random servers.
| chrismarlow9 wrote:
| Also be careful that you've used CSRF and other origin
| protections. Otherwise competition can DoS your legit users by
| rapidly cross posting via js from their own site. Not likely in
| enterprise world but could happen in less than ethical
| industries.
| RadixDLT wrote:
| you can probably use a vpn to log back in
| miohtama wrote:
| The first thing you need to do on any new Linux server
| installation:
|
| sudo apt install fail2ban # Choose your flavour
|
| And you get rid of most pesky SSH knocking traffic and credential
| stuffing attacks.
| seanp2k2 wrote:
| Changing the port to anything other than 22 does this as well.
| zimpenfish wrote:
| Changing the port reduces the traffic, yep, but definitely
| doesn't get rid of it - all my servers use non-standard ports
| for ssh and there's still ~10 login attempts a minute.
| dpcx wrote:
| I wrote about using fail2ban with postfix[0] almost 15 years ago
| for blocking IPs that were sending to unknown email addresses on
| my server. It was a godsend for blocking tons of spam back then.
|
| [0]: https://www.dp.cx/blog/postfix---fail2ban---win.html
| jsisto wrote:
| Shoutout to my favorite docker image that leverages fail2ban
| https://github.com/linuxserver/docker-swag
| gv83 wrote:
| The best friend of the small business LAMP specialized dev! Those
| mass scanners really love wordpress
| throitallaway wrote:
| Why was this posted? It's a great project that's widely known and
| pretty much ancient in terms of OSS projects.
| mullingitover wrote:
| I would guess the subtext here is related to the 23andme
| breach.
|
| The problem with fail2ban is that an attacker who has a botnet
| of significant size at their disposal won't even be slowed
| down. Not saying it's worthless, but it's not a silver bullet.
| seanp2k2 wrote:
| Not saying fail2ban is in any way state-of-the-art security
| or even best-practice at this point, but if they're burning
| an IP after a few bad attempts, that's going to be more
| effective than letting them try tens of thousands per IP, no?
| Security in layers of course, so even a few [dozen, hundred]
| failed SSH attempts should probably raise an alarm or put
| things into an elevated security mode automatically...but
| also don't leave SSH open to the public, especially not on
| :22.
| mullingitover wrote:
| > but also don't leave SSH open to the public, especially
| not on :22
|
| 100%. These days, at least if you're working out of a cloud
| provider, there's no excuse for exposing SSH to the world
| on any port. AWS/GCP/Azure all have different tools to
| allow you to run bastion-type services without internet-
| facing SSH.
| wds wrote:
| I like occasional discussions on these things. People sharing
| tips, experiences, pitfalls, etc. It gets everyone in one place
| at around the same time to do it, like a small digital
| convention.
| TheCoreh wrote:
| A lot of people might not know about it yet, and genuinely find
| it useful
|
| https://xkcd.com/1053/
| [deleted]
| SlavikCA wrote:
| I really wanted fail2ban for my windows RDP. I'm using non-
| standard RDP port and still getting 10,000+ brute-forcing
| requests per day.
|
| Found this alternative:
|
| https://github.com/DigitalRuby/IPBan
| jpc0 wrote:
| In the world of amazing fast vpn solutions why is your RDP port
| open to the internet?
| ozim wrote:
| In security circles RDP is called "ransomware deployment
| protocol" - basically one should never expose it to the
| internet.
|
| Make yourself a vpn box or some Linux with ssh and do port
| forwarding and allow RDP from that Linux host. OpenVpn or ssh
| are much better to be exposed to the internet.
| Phil_Latio wrote:
| What port do you use? Obviously you have to use one which is
| not common and not in the list of scanned ports of services
| like shodan or censys.
| SlavikCA wrote:
| I have RDP on port 8443.
|
| On another host I tried port 443, hoping to disguise it to
| appear like SSL. No any difference.
|
| Also, there are services, which already publishing all my
| (and yours) open ports. Here is the report for my IP:
|
| https://search.censys.io/hosts/104.63.172.143 (It's public
| anyway)
| lionkor wrote:
| 8443 is very common, id use something like 46434
| mobilio wrote:
| Both are useful:
|
| https://github.com/EvanAnderson/ts_block
|
| https://github.com/Zeziroth/Cancer2Ban
| EvanAnderson wrote:
| I made ts_block. It solved a particular problem I had at a
| particular time. Nobody should be doing RDP across the
| Internet w/o a VPN but, apparently, people still do it.
|
| Shockingly it still works fine on Server 2022.
| chunk_waffle wrote:
| For SSH I prefer blocklistd[0], which sadly is only available on
| FreeBSD and NetBSD AFAIK, it's a much simpler approach though
| requires a small patch to any daemons that want support.
|
| [0] https://youtu.be/fuuf8G28mjs?si=UhuRVndacryMim_a
| keep_reading wrote:
| I came to mention this. I was impressed when it was announced
| and disheartened to see it ignored
| dboreham wrote:
| Probably needs a date, since this tool is extremely old?
| JAlexoid wrote:
| I personally would rather recommend a whitelisting functionality,
| using a trusted third party.
|
| I wonder if SSO services can provide IPs of successfully
| authenticated against their services users.
| seanp2k2 wrote:
| Jump hosts are a well-tested and widely-deployed pattern
| already that basically do the same thing without the downside
| of lockout problems from connecting from somewhere new.
| IronWolve wrote:
| Works great, been using it for a long time to stop bots crawling
| sites. Also on hosts with open ports, like ssh that you cant
| whitelist.
| qwertox wrote:
| Can this be a dynamic whitelist or is there an API to
| whitelist/de-whitelist specific IPs?
| davesmylie wrote:
| It's a dynamic blacklist. Any abusive IPs get banned for x
| minutes.
|
| You can white list specific IPs though
| pandog wrote:
| fail2ban is a real pet peeve of mine because anyone security
| conscious enough to deploy this will have likely already
| mitigated any actual security risks this could help with either
| by using a strong password or public key authentication.
|
| That leaves noise in the logs - which sure, it's nice to reduce,
| but using an alternative port can help here.
|
| I may sound like a spoilsport - but the fact that there have been
| a number of security vulnerabilities
| (https://www.cvedetails.com/vulnerability-list/vendor_id-5567...)
| in this project, make it worse than security theatre, it actually
| increases risk whilst not at all reducing it.
| noirscape wrote:
| [delayed]
| tptacek wrote:
| Yes. At this point, fail2ban has become almost a shibboleth for
| people following security checklists as opposed to reasoning
| about a coherent threat model. This is a perennial topic on HN,
| and almost always devolves to some appeal to grooming logs,
| because of all the authentication errors fail2ban is presumably
| preventing.
|
| Don't use fail2ban. (Don't use passwords, either!)
|
| https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
| callwhendone wrote:
| I am one of the people to whom you refer. I read about
| fail2ban in a "Linux Server Bible" e-book around 2010 and
| have used it on all of my servers since, even though I am
| careful with my keys and use password-less login.
| ozim wrote:
| Grooming logs from attempts seems like shibboleth on its own
| that is indicating junior level or "security enthusiast".
|
| Anyone who manages servers professionally does not read logs
| anymore and does not care about obvious things like people
| brute-forcing.
|
| Reading ssh logs on your single VPS is security LARPING.
| Discussing faill2ban as well :)
| meepmorp wrote:
| I use fail2ban because I take break in attempts personally,
| especially when it's some script trying default logins one
| after another. It's insulting.
| quesera wrote:
| > _It 's insulting_
|
| Brute force / credential stuffing attacks against ssh are
| the mosquitos of the Internet.
|
| Ubiquitous, annoying, and persistent. But nothing personal.
| gnfargbl wrote:
| You have that exactly backwards: if someone is hitting you
| with a password bruteforce from a single IP address (which
| is the only threat that fail2ban mitigates) then it is
| assuredly _nothing personal at all_.
|
| A personal insult, if you are ever unfortunate enough to
| receive one, will be much more stealthy and neither
| fail2ban nor any other magical rock will protect you
| against it.
| throw0101c wrote:
| > _That leaves noise in the logs - which sure, it 's nice to
| reduce, but using an alternative port can help here._
|
| No, it cannot. As a sysadmin I do not want to get into user
| training about telling people about alternative ports and
| tweaking their CLI habits and any scripts that they have.
|
| If you want to further cut down on the log noise get an IPv6
| address (and drop IPv4)--good luck to anyone trying to scan a
| /64 for open ports.
| devwastaken wrote:
| You can scan ipv6 because the addresses aren't arbitrary.
| Blocks have to be purchased and then ranges within routed.
| [deleted]
| callalex wrote:
| Doesn't it help to mitigate DoS type attacks by reducing the
| amount of CPU that a bad actor can burn?
| discreditable wrote:
| You can do it with ufw limit too
| pluc wrote:
| You can also literally have anything pipe rules into it.
| Want WordPress auth to result in fail2ban-enforced bans?
| You can do that. Want cheap rate limiting? You can do that
| too
| pandog wrote:
| If someone is performing a denial of service attack from one
| I.P. address then this will help.
|
| To tptacek's point, you've got to ask yourself is a denial of
| service attack in your threat model?
|
| The reality is most folk set up fail2ban after seeing auth
| failures in their logs, not service degradation.
|
| If you're considering a denial of service attack in your
| threat model, then I'd probably also consider a DDoS attack
| and there are likely more effective solutions here (a
| firewall or CDN).
|
| And don't forget you're using some of those precious CPU
| cycles to parse the auth logs, with python no less :-)
| koito17 wrote:
| Yup. I see many resources for self-hosting recommend fail2ban
| for e.g. SSH. But I always disable password-based SSH logins on
| all of my computers. The one niche use case I can see for
| fail2ban is possibly reducing the amount of hits to /wp-
| login.php and /cgi-bin in your web server (or reverse proxy's)
| access logs.
| jtriangle wrote:
| "Don't use fail2ban because you don't need it if you do XYZ"
|
| I'm not so sure that's a good reason to be honest. And if
| you're worried about CVE's, well, you'll be using handwritten,
| hand delivered notes before long. Keep your systems patched,
| keep them tidy, none of this is likely to affect you, fail2ban
| or not.
| pandog wrote:
| To put it another way - there is no security risk that
| fail2ban helps with that can't be resolved in another,
| better, more robust and less risky way.
| zimpenfish wrote:
| But it also helps in reducing the load on your servers
| when, e.g., instead of 300+ login attempts per minute on
| your mail ports, you get 20 because the IP gets banned for
| a day after 2 failures. Or, instead of nginx spending 90%
| of its time sending out 404s for the various PHP and MySQL
| holes I do not have installed, it can spend 10% of its time
| instead.
|
| Particularly on my small server, fail2ban is the difference
| between "usable" and "on the edge of falling over".
| dang wrote:
| Related. Others?
|
| _Brute.Fail: Watch brute force attacks fail in real time_ -
| https://news.ycombinator.com/item?id=36169954 - June 2023 (259
| comments)
|
| _Ask HN: How to protect against endless SSH login attempts to my
| server?_ - https://news.ycombinator.com/item?id=34077205 - Dec
| 2022 (27 comments)
___________________________________________________________________
(page generated 2023-10-06 23:00 UTC)