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

41–50 of 149 posts

Re: SSHGuard

#41

Post by mtlmtlmtlmtl »

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…

Have you looked into logrotate?

Re: SSHGuard

#42

Post by justusthane »

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…

This is advice from the 90s and is mostly security through obscurity, except for the last one. Modern advice: don’t use password auth.

Re: SSHGuard

#43

Post by throwaway892238 »

remram wrote: post #15
qbasic_forever wrote: post #7

Earlier quoted context omitted.

Or just run wireguard and ssh on top of that without all the fussy config and tooling to expose ssh to the internet. You could even live dangerously and just use telnet once you have wireguard going.

Is Wireguard more secure than SSH?

This is akin to asking if a bike is more reliable than a car. They are very different use cases with different implications, so it depends on what you're doing with them and how.

Wireguard is just a very simple network bridge. Whoever has the key can send anything over the network. There isn't a robust mechanism required to keep the key, to revoke it, to audit its use, to enable it to only provide access to specific applications. It doesn't have 1/20th the features SSH has, and SSH itself lacks a bunch of security features.

Bottom line is that you should only use Wireguard if you need a simple encrypted network bridge. It does not remove the need for other more complex security products.

Re: SSHGuard

#44

Post by Jorengarenar »

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…

> But it's even scarier: it's written in C.

Why would being written in C make it scarier?

Re: SSHGuard

#45

Post by ergonaught »

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 mean, yeah, these things are kind of silly. So is, "But it's even scarier: it's written in C. I guess this is from like 2010? Don't run stuff like this."

Re: SSHGuard

#46

Post by GekkePrutser »

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.

When I still ran my own server it was a pretty heavy load, like 30% or so. Much more than a minor nuisance.

But it was a SPARC server with 1 core at a few hundred MHz and no crypto acceleration. As you can tell this is a while ago :) So yeah I guess these days it's much less of an issue. But the number of possible attempts will have increased too of course.

Re: SSHGuard

#47

Post by EnigmaCurry »

akulbe wrote: post #29
antihero wrote: post #27

Earlier quoted context omitted.

I’ve always used this: https://www.sshaudit.com/hardening_guides.html If there’s something better please correct me!

I wasn't familiar with this. I find it interesting that one of the suggestions is to disable the ECDSA host key. I thought ECDSA was one of the "good" algorithms?

Its suspected from the snowden docs that this is one of the ones intentionally weakened by NIST.

Here's the long answer: https://blog.cr.yp.to/20140323-ecdsa.html

Re: SSHGuard

#48

Post by youainti »

akulbe wrote: post #29
antihero wrote: post #27

Earlier quoted context omitted.

I’ve always used this: https://www.sshaudit.com/hardening_guides.html If there’s something better please correct me!

I wasn't familiar with this. I find it interesting that one of the suggestions is to disable the ECDSA host key. I thought ECDSA was one of the "good" algorithms?

I think it is the issue where ecdsa is a NIST standard that was based on an elliptic curve provided by the NSA. As the NSA has been known to suggest poor cryptography primitives in the past, many groups recommend ed25519 (same process, different and more trusted curve generation process)

Take a look at the "concerns" section of the wiki page. https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signatu...

Re: SSHGuard

#49

Post by tptacek »

ergonaught wrote: post #45
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 mean, yeah, these things are kind of silly. So is, "But it's even scarier: it's written in C. I guess this is from like 2010? Don't run stuff like this."

Fail2ban is written in Python and managed to have a vulnerability.

Re: SSHGuard

#50

Post by upofadown »

Doesn't Dovecot now have a fairly capable brute force password attack prevention system? Is there any reason that someone would still use something like this anyway?

Couldn't find anything about Exim or Postfix integrated brute force prevention on SMTP connections...

Post reply on HN