Hacker News Reader

Comment by teilo | Hacker News Reader

I gave up obscuring years ago, and just use fail2ban.

Now that botnets are brute forcing from thousands of unique ips, fail2ban doesn’t offer much on my servers anymore. I‘ve stopped installing it.

If the attackers are using botnets to distribute the load across IPs, then perhaps we need to distribute the detection across IPs: https://www.abuseipdb.com/fail2ban.html

I used to manage VoIP systems and VoIPBL[0] was amazing.

"VoIPBL is a distributed VoIP blacklist that is aimed to protects against VoIP Fraud and minimizing abuse for network that have publicly accessible PBX's"

It's very similar to what you linked but is targeted to catching VoIP abuse.

[0] https://voipbl.org/

Just curious, what problems does fail2ban suffer with thousands of unique ips? (A crowded iptables I guess...)

I still use it with a super oppressive jail time and few retries, with a few whitelisted IPs and it seems to work ok.

I think the concern is a botnet with n IPs is that fail2ban tracks individual IPs, so if you have any kind of grace period before bannination, they get a linear speedup of n, and if there's an expiration period, get to try n times harder than a single bored script kiddie.

Worse, from an economic perspective, theres enough hosts listening on port 22 that a bot can try instead while they wait for timeouts, so you're not really imposing a cost on them. If you view running a botnet as a form of multi-armed bandit problem, the best you can really do is limit the economic value by slowing them down a tad versus their many, many other options.

F2B support subnets: https://github.com/fail2ban/fail2ban/issues/2261

I think they're saying it doesn't stop brute force attacks because the botnet will just try with another IP.

My logs still show repeated attempts by the same IP. Lots of 1 and 2 tries, but multiple IP's with hundreds or dozens.

Keep forgetting to enable fail2ban.

Fail2Ban is fantastic tool.

But as soon as you found that "PermitRootLogin" can be set with no then all brute forces become useless since they can't match combination of user/password.

fail2ban has other uses: it prevents non-root user error (oops, one of your contractors reused a password…), it significantly reduces log noise, and it protects against any future exploit which doesn’t always work on the first 3 tries.

I know...

But for mine usage it increase memory usage. I'm using it on OrangePi Zero with 256MB RAM.

Port 22 is opened for world so anyone can join. Device have 2 users - root and jacob. I make a change and disable root login from WAN. Now can login from root from LAN. Since noone knows that "jacob" exists i'm saved.

Not necessarily, plenty of people have common / guessable user accounts. For example every one of my servers in the cloud has an account called "user". (All my servers are also key-only authentication, obviously.)

If you use non-standart usernames then you're saved!

Dito, a combination of forbidden root login, an obscure username, fail2ban and disabled password authentication worked well for me for the last 10 years. It's also quite simple to set up. The important part is to double and triple-check each step so that you don't lock yourself out (which has happened to me multiple times in the past, of course).

You don't need fail2ban if you've disabled password authentication. fail2ban exists to prevent password bruteforcing attempts.

True, but I still prefer to completely block IPs who tried to log in via SSH and failed multiple times.

Sure, but enforcing best practices at all times can be tedious and unnecessary sometimes.

You may have summoned tptacek with that.

(He would argue to turn off passwords and use keys only)

IMO fail2ban is still useful just to cut down on the noise.

Yeah, I still support servers that have (strong) passwords without keys. I use fail2ban on them.

I use source tracking rules on pf protecting my servers and firewall itself:

https://www.openbsd.org/faq/pf/filter.html#stateopts

Reply on news.ycombinator.com