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

61–70 of 149 posts

Re: SSHGuard

#61

Post by mattarm »

Jorengarenar wrote: post #44
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?

Two terms: undefined behavior and memory safety. Try searching the web for those terms.

Re: SSHGuard

#62

Post by funstuff007 »

I get keys are better than passwords, but how do you enforce key rotation for non-technical users when they can barely manage to changer their passwords? I much prefer 2FA than keys for non-technical users.

Re: SSHGuard

#63

Post by remram »

throwaway892238 wrote: post #43
remram wrote: post #15

Earlier quoted context omitted.

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…

> This is akin to asking if a bike is more reliable than a car.

It's really not. It's a technical question with many technical answers, thankfully they were provided by other commenters before you posted this.

If anything, it's similar to asking if a bike is faster than a car, to which you would reply than a bike might be faster in traffic because of small size but slower over long distances because of propulsion. It is possible to compare apples and oranges over specific axes.

Re: SSHGuard

#64

Post by funstuff007 »

GekkePrutser wrote: post #12
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.

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

True, true, true. You cannot rely on the VPN always working.

Re: SSHGuard

#66

Post by noAnswer »

yakubin wrote: post #20
remram wrote: 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.

What I find funny though is that every implementation not involving Donenfeld has "drama" (Free- and NetBSD). The small code still leave a lot of room for failure.

Re: SSHGuard

#67

Post by b112 »

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…

apt-get install logcheck

Re: SSHGuard

#68

Post by yakubin »

noAnswer wrote: post #66
yakubin wrote: 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.

What I find funny though is that every implementation not involving Donenfeld has "drama" (Free- and NetBSD). The small code still leave a lot of room for failure.

That’s why I mentioned reviewed code. The original FreeBSD code which sparked the drama wasn’t reviewed.

And honestly some of the issues that were there are not something preventable by limiting oneself to even 50 LOC. I don’t want to speculate how they came to be though. It’s really baffling.

Re: SSHGuard

#69

Post by LanternLight83 »

puffoflogic wrote: post #65

Why do documentation links from sshguard.net redirect to wayback machine versions of sshguard.net? That is sketchy as all heck.

I'm not sure about the actual situation, but I have an option in my cloudflare dashboard to automatically save my site to the way back machine and fall back to that if the origin is ever down, so that's a totally plausible explanation

Re: SSHGuard

#70

Post by theteapot »

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 never understood why people use all this stuff ... Now the issue of logs is real. I tried to configure debian to remove noise from the logs and I couldn't.

Sounds like you understand at least one reason people use stuff like this (including, most prominently, fail2ban). Rate limiting and banning IPs trying to brute force and/or probe open ports (not just SSH) goes a long way to cleaning up your logs, your real time state, as well as other things, like frustrating the attacker, not wasting connections on them.

Having said that, this particular tool looks a bit shit ...

Post reply on HN