Hacker News Reader

Comment by lima | Hacker News Reader

There's no point in using fail2ban if you use public key authentication. It's a kludge which helps against brute force attacks, which are limited to password login.

Since CoreOS enforces public key authentication, and the SSH server is the only external attack surface, they're doing just fine. Security is definitely a top priority for CoreOS, and they're doing a great job at it - image signing, Docker container signing, ASLR binaries, a clean build system (based on Gentoo)...

View on HN

After rethinking... I also tend to agree. Actually I never use password login, maybe it felt safer without brute-force logging of ssh logins and I also think that a rate limit would not hurt, especially when there is a SSH security issue like here ;)

Answering my own question (it was a longer time ago I used CoreOS) here two interesting links:

Securing CoreOS with iptables rules (Firewall like): https://www.jimmycuadra.com/posts/securing-coreos-with-iptab...

IP tables rule to reduce ssh attack spam: http://serverfault.com/a/217066

Maybe this advices should be integrated into CoreOS official docs? Something like "How to harden CoreOS servers". When I first looked into CoreOS I wanted to use familiar tools like fail2ban or ufw to run there (which is not possible, at least not easy). I'm no iptables expert (who is? I think it's not a trivial to use program) and this lack of admin tools made me think it's not good to secure. It's for sure more complicated than in Ubuntu (from an admin perspective).

I tend to agree. One reason to use something like it, though, is that it clogs up logs. But I'd tend to want to tie it down with iptables and limited IP ranges and/or just move ssh to another port (the latter as a quick and dirty way to avoid the steady annoying log nonsense if you for whatever reason can't limit ip ranges, not because I have any illusions it does much for security)

When filtering your logs, filter for only successful attempts. You really don't care how many people failed to login on a server with only pubkey enabled. It's the ones who succeeded you want to know about.

Exactly, but it's nice to be able to follow your logs without all that clutter. Though with journald I mostly look at logs on a per-unit basis anyway (or via e.g. an ELK setup), so it's a slight nuisance rather than something essential.

As another used pointed out, fail2ban is a generic tool, I don't necessarily agree with the method its implemented though there is a recent module in iptables that should be enough for most services.

Also, about SSH - it is still better to block the bad actors before you process the request. I've seen occurances where the network was saturated bots trying to brute force.

The purpose is also to be able to keep a sane amount of logging.

fail2ban can protect other services besides ssh.

Reply on news.ycombinator.com