Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SSHGuard

sshguard.net

Post reply on HN
Print view View original

31–40 of 149 posts

Re: SSHGuard

#31

Post by akerl_ »

GekkePrutser wrote: post #11
tptacek wrote: post #3

In a sane configuration, the only thing a tool like this should be doing for you is keeping your logs clear. If you're deploying something to mitigate the risk of brute-force attacks on your server, the problem is that it's possible to brute-force your server, not that you don't have an autoblocking system enabled. These tools are popular, but I think they're kind of silly. Later I read some comments below, which com…

> If you're deploying something to mitigate the risk of brute-force attacks on your server, the problem is that it's possible to brute-force your server, not that you don't have an autoblocking system enabled. Well, even when accepting only certificates some brute force bots are dumb enough to keep trying to connect to try passwords, and this can give a lot of unnecessary CPU load due to all the initial connection cr…

It seems improbable that the baseline load of a couple concurrent SSH attempts is higher than the load of running an extra Python daemon that's constantly checking your log files.

Re: SSHGuard

#32

Post by Wobble4978 »

tptacek wrote: post #3

In a sane configuration, the only thing a tool like this should be doing for you is keeping your logs clear. If you're deploying something to mitigate the risk of brute-force attacks on your server, the problem is that it's possible to brute-force your server, not that you don't have an autoblocking system enabled. These tools are popular, but I think they're kind of silly. Later I read some comments below, which com…

I have it installed, but I'm not sure I understand why its as you say.

Why are you scared of C? Also, should I remove sshguard? I dont want my server going down.

Btw, it has been updated after 2010. Are you talking about 2010 release ?

Re: SSHGuard

#33

Post by tyingq »

I would probably use something like pam_tally or pam_shield, since it's taking counts directly from the login flow and not via log files.

Mentioned in other comments, protecting from brute force isn't really the big benefit. The benefit is reducing noise in logs so that you can see more serious activity.

Re: SSHGuard

#34

Post by loeg »

michaelmrose wrote: post #8
tptacek wrote: post #3

In a sane configuration, the only thing a tool like this should be doing for you is keeping your logs clear. If you're deploying something to mitigate the risk of brute-force attacks on your server, the problem is that it's possible to brute-force your server, not that you don't have an autoblocking system enabled. These tools are popular, but I think they're kind of silly. Later I read some comments below, which com…

Doesn't it make sense to do both given that the cost of additional mitigation is trivial?

No, and to elaborate, fail2ban has had an RCE vuln in recent memory. These things add attack surface, which is the opposite of what you want.

Re: SSHGuard

#35

Post by bobleeswagger »

thesuperbigfrog wrote: post #2

Similar tool: fail2ban: https://www.fail2ban.org/wiki/index.php/Main_Page Tools like these are essential if you have Internet-facing SSH services. If you do not need Internet-facing SSH, do not enable it. It can be an attack vector and there are hundreds of bots that will try to brute-force access within minutes of opening Internet-facing SSH daemon. Best practices for Internet-facing SSH: - run on non-standard port…

Crowdsec seems to be the modern Fail2Ban replacement, it works quite well and has led to some useful insights.

Re: SSHGuard

#36

Post by loeg »

akerl_ wrote: post #31
GekkePrutser wrote: post #11

Earlier quoted context omitted.

> If you're deploying something to mitigate the risk of brute-force attacks on your server, the problem is that it's possible to brute-force your server, not that you don't have an autoblocking system enabled. Well, even when accepting only certificates some brute force bots are dumb enough to keep trying to connect to try passwords, and this can give a lot of unnecessary CPU load due to all the initial connection cr…

It seems improbable that the baseline load of a couple concurrent SSH attempts is higher than the load of running an extra Python daemon that's constantly checking your log files.

sshguard is C, and the log file for sshd won't have very much output if there are only a couple concurrent SSH attempts. Don't use this, but not because of concerns about performance overhead.

Re: SSHGuard

#37

Post by throwaway892238 »

One to two lines of iptables limits connection attempts, making a brute force attack take thousands of years. No logging, no monitoring, no extra software.

If you only use SSH keys, no brute force attack will work anyway.

https://www.systutorials.com/how-to-use-iptables-to-limit-ra... https://making.pusher.com/per-ip-rate-limiting-with-iptables... https://stackoverflow.com/questions/18616246/iptables-limit-... https://blog.oshim.net/2009/06/iptables-to-rate-limit-incomi... https://stackoverflow.com/questions/47775809/iptables-rate-l... http://blog.serverbuddies.com/using-iptables-to-rate-limit-i...

Re: SSHGuard

#38

Post by akerl_ »

loeg wrote: post #36
akerl_ wrote: post #31

Earlier quoted context omitted.

It seems improbable that the baseline load of a couple concurrent SSH attempts is higher than the load of running an extra Python daemon that's constantly checking your log files.

sshguard is C, and the log file for sshd won't have very much output if there are only a couple concurrent SSH attempts. Don't use this, but not because of concerns about performance overhead.

From the comment I replied to:

> Using fail2ban was more of a DDOS prevention than a security thing.

Re: SSHGuard

#39

Post by josephcsible »

throwaway892238 wrote: post #37

One to two lines of iptables limits connection attempts, making a brute force attack take thousands of years. No logging, no monitoring, no extra software. If you only use SSH keys, no brute force attack will work anyway. https://www.systutorials.com/how-to-use-iptables-to-limit-ra... https://making.pusher.com/per-ip-rate-limiting-with-iptables... https://stackoverflow.com/questions/18616246/iptables-limit-... https:…

The iptables methods all have the flaw that multiple sequential short-lived successful connections will trigger a ban too.

Limiting Internet-facing SSH connections to key-only is definitely a good idea, though.

Re: SSHGuard

#40

Post by n4bz0r »

vbezhenar wrote: post #18
tptacek wrote: post #3

In a sane configuration, the only thing a tool like this should be doing for you is keeping your logs clear. If you're deploying something to mitigate the risk of brute-force attacks on your server, the problem is that it's possible to brute-force your server, not that you don't have an autoblocking system enabled. These tools are popular, but I think they're kind of silly. Later I read some comments below, which com…

I agree. I never understood why people use all this stuff. If you use strong enough passwords, it's impossible to be brute-forced, simple as that. If you can't control people on your servers and afraid of weak passwords, just disable password authentication and that's about it. Now the issue of logs is real. I tried to configure debian to remove noise from the logs and I couldn't. May be someone with more knowledge w…

> I tried to configure debian to remove noise from the logs and I couldn't.

Not very elegant (as in, not with built-in tools), but using Logstash would be one way of achieving that. There probably is a better (simpler) way, though.

https://www.elastic.co/guide/en/logstash/current/pipeline.ht...

Edit: After some research, rsyslog seems like a more appropriate candidate. But the docs don't seem too novice-friendly and the configuration is quite obscure. Tradeoffs.

https://en.m.wikipedia.org/wiki/Rsyslog

Post reply on HN