4 ms·

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 lo

by lima 10y ago

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)...

vidarh 10y ago
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)
- ultramancool 10y ago
  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.
  - vidarh 10y ago
    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.
therealmarv 10y ago
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-iptables/ https://www.jimmycuadra.com/posts/securing-coreos-with-iptab... IP tables rule to reduce ssh attack spam: http://serverfault.com/a/217066 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).
ams6110 10y ago
fail2ban can protect other services besides ssh.
xorcist 10y ago
The purpose is also to be able to keep a sane amount of logging.
dbalan 10y ago
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.

by lima 10y ago

vidarh 10y ago

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)

ultramancool 10y ago
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.
- vidarh 10y ago
  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.

therealmarv 10y ago

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-iptables/ https://www.jimmycuadra.com/posts/securing-coreos-with-iptab... IP tables rule to reduce ssh attack spam: http://serverfault.com/a/217066 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).

ams6110 10y ago

fail2ban can protect other services besides ssh.

xorcist 10y ago

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

dbalan 10y ago

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.