Live data from Hacker News

SSHGuard

sshguard.net

21–30 of 149 posts

Re: SSHGuard

#21
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…

Hi Tom - I don't know if you've already written about this elsewhere, but what would be some sane defaults for SSH?

Do you think using key-based auth and disabling password authentication is enough? or are there other things you would recommend?

OT - nice Fibonacci in your profile :D

Re: SSHGuard

#22
post #15

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?

It runs over UDP and doesn't respond to anything until it sees a valid key sent to it, so right there it totally removes any need for stuff like port knocking. There's no way to use passwords or low security keys so there's less brute force chance. It's basically the same as going through all those machinations to make ssh secure publically (high quality key auth only, nonstandard port, port knocking, etc) but ready to go out of the box.

Re: SSHGuard

#23
post #20
post #15

Earlier quoted context omitted.

Is Wireguard more secure than SSH?

It has orders of magnitude less code (which has been reviewed by many people), its configuration is a lot simpler, and it doesn’t allow password authentication, so… probably yes? Edit: deleted false information about TLS.

SSH doesn't rely on TLS and I'm sure its transport isn't a lot of code.

Re: SSHGuard

#24
If you disable password auth completely (you're using key auth... right???) most of the password bruteforcers will just go away.

Re: SSHGuard

#25
post #17
post #15

Earlier quoted context omitted.

Is Wireguard more secure than SSH?

It's not TCP based so you can't port scan it like SSH, and it will only respond on successful authentication, so a failed attempt is undistinguishable from it not being there. It is also fairly easy to DoS SSH by having too many connections in the authentication state leaving no slots open, which SSHGuard is useful to counter. Apart from that, SSH's intrinsic security is the same, but if you have password authenticat…

That sound like big advantages indeed, thanks.

Re: SSHGuard

#26
post #23
post #20

Earlier quoted context omitted.

It has orders of magnitude less code (which has been reviewed by many people), its configuration is a lot simpler, and it doesn’t allow password authentication, so… probably yes? Edit: deleted false information about TLS.

SSH doesn't rely on TLS and I'm sure its transport isn't a lot of code.

My bad. I was fooled by it using OpenSSL/LibreSSL.

Re: SSHGuard

#27
post #21
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…

Hi Tom - I don't know if you've already written about this elsewhere, but what would be some sane defaults for SSH? Do you think using key-based auth and disabling password authentication is enough ? or are there other things you would recommend? OT - nice Fibonacci in your profile :D

I’ve always used this: https://www.sshaudit.com/hardening_guides.html

If there’s something better please correct me!

Re: SSHGuard

#28

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…

The issue with fail2ban is that it's an extremely heavy python application. It takes up a boatload of resources! SSHGuard however is much lighter and even less to configure manually.

From quickly skimming the docs, Fail2Ban can do a few other things like execute a script for the action. I have it doing an API call to block the offending IP on OPNSense firewall.

Re: SSHGuard

#29
post #21

Earlier quoted context omitted.

Hi Tom - I don't know if you've already written about this elsewhere, but what would be some sane defaults for SSH? Do you think using key-based auth and disabling password authentication is enough ? or are there other things you would recommend? OT - nice Fibonacci in your profile :D

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?

Re: SSHGuard

#30
post #24

If you disable password auth completely (you're using key auth... right???) most of the password bruteforcers will just go away.

I just move it off port 22 first. That alone makes it go from hundreds of attempts per day to zero.
Post reply on HN