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

11–20 of 149 posts

Re: SSHGuard

#11

Post by GekkePrutser »

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 crypto handshakes.

Though I have to say most of the bots these days are smart enough to quit as soon as password auth is turned off. But 10 years ago most were really dumb. Using fail2ban was more of a DDOS prevention than a security thing.

Re: SSHGuard

#12

Post by GekkePrutser »

qbasic_forever wrote: post #7
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…

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.

I use ssh as a fallback for when my VPN fails to activate somehow.

Re: SSHGuard

#13

Post by thesuperbigfrog »

qbasic_forever wrote: post #7
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…

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.

>> Or just run wireguard and ssh on top of that without all the fussy config and tooling to expose ssh to the internet.

Nice! Wireguard was not around when I was using Internet-facing SSH in a previous job.

Adding it to the recommendations.

Re: SSHGuard

#14

Post by hsbauauvhabzb »

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’d say that fail2ban is a Band-Aid too, if brute forcing passwords is an issue your problem is that you’re not using key based auth.

If someone wants to go to the trouble to break crypto, it would be cheaper to infiltrate the ssh project and implement back doors after a few years of building trust. If that’s your threat model, double wrap your protocols (WireGuard jumphost > ssh type stuff)

Re: SSHGuard

#15

Post by remram »

qbasic_forever wrote: post #7
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…

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?

Re: SSHGuard

#16

Post by hnarn »

hsbauauvhabzb wrote: post #14
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’d say that fail2ban is a Band-Aid too, if brute forcing passwords is an issue your problem is that you’re not using key based auth. If someone wants to go to the trouble to break crypto, it would be cheaper to infiltrate the ssh project and implement back doors after a few years of building trust. If that’s your threat model, double wrap your protocols (WireGuard jumphost > ssh type stuff)

As you correctly point out, password authentication should not be used for SSH to begin with, but more importantly fail2ban is not a piece of software written to stop brute force password attacks, it’s a very general tool for triggering network blocking actions based on specific patterns found in logs.

My only point being that there are some great use cases for fail2ban, and while this isn’t one of them it’s important to remember that this does not make fail2ban a misdirected or useless security initiative by default, in case anyone gets that impression from reading these comments.

Re: SSHGuard

#17

Post by fmajid »

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?

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 authentication enabled, you are only as strong as the weakest password.

Re: SSHGuard

#18

Post by vbezhenar »

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 would suggest how to do so. Because I'd like to see successful authentications in the logs and only those. So that could be a valid reason to change port, etc. But that's only because logs are lacking proper configurability.

Re: SSHGuard

#19

Post by Beltalowda »

fmajid wrote: post #17
remram wrote: 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…

> Apart from that, SSH's intrinsic security is the same, but if you have password authentication enabled, you are only as strong as the weakest password.

A number of configurations also ship with ssh root login enabled by default. For example if you setup a new Linode VPS. You need to add a user, remember to at least turn off root access and probably also password access. I get why they're doing it because it easier, but yeah ... not a huge fan of this configuration.

Re: SSHGuard

#20

Post by yakubin »

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?

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.

Post reply on HN