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

71–80 of 149 posts

Re: SSHGuard

#71

Post by cookiengineer »

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…

Remember when fail2ban had an RCE to execute things on a server via root user and it was as simple as parsing an email string because it was executing the mail binary on the other end? [1]

That's pretty much the reason why I started to write my own guard tools.

I don't need people from China or Russia logging in to my server. I don't understand why tools like this are never built in an ASN aware manner, blocking mechanisms would be so much easier.

[1] https://research.securitum.com/fail2ban-remote-code-executio...

Re: SSHGuard

#72

Post by smackeyacky »

thesuperbigfrog wrote: post #13
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.

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

Tailscale is a good solution. I have no ports open on my internet facing router at all any more. Tailscale has proved to be as reliable as the servers themselves. I like it so much I use it to access my AWS machines as well, by running it as an exit node up there.

Re: SSHGuard

#73

Post by mekster »

justusthane wrote: post #42
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.

Dismissing security through obscurity as pointless is an advice from the 90s.

Basically security comes with layers of obscurity. Even key based auth is a random string that no one is meant to guess.

If you have more obscurity, the less chance one reaches to the actual attack surface.

If an attacker gains a key, without fail2ban etc, he may try bunch of user names against the key file consecutively but if a login attempt is limited to 3 times every 5 minutes, see it's better than nothing.

Re: SSHGuard

#74

Post by Jorengarenar »

mattarm wrote: post #61
Jorengarenar wrote: post #44

Earlier quoted context omitted.

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

The question wasn't about common mistakes C programmers make

Re: SSHGuard

#75

Post by Jorengarenar »

tptacek wrote: post #49
ergonaught wrote: post #45

Earlier quoted context omitted.

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.

Since when being written in Python automatically makes a program less vulnerability prone than usual?

Re: SSHGuard

#76

Post by mekster »

nullc wrote: post #24

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

I'd expect a (ex?) crypto developer to think security from another perspective, but what if the key is leaked?

It's time another prevention system may save your day.

Re: SSHGuard

#77

Post by rurban »

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."

It's mostly shell scripts, with a few C handlers. Very minimal.

Re: SSHGuard

#78

Post by tptacek »

Jorengarenar wrote: post #75
tptacek wrote: post #49

Earlier quoted context omitted.

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

Since when being written in Python automatically makes a program less vulnerability prone than usual?

It depends I guess on where you start the count; some people would say Elias' "Smashing The Stack", I'd say Lopatic's HP-UX exploit, some people would go all the way back to RTM's worm.

Re: SSHGuard

#79

Post by UI_at_80x24 »

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 _WANT_ to harvest IP's of PC's trying to SSH into any of my servers. I want them because then I can block ALL traffic coming from their IP's.

At my last gig, I had thousands of domains and hundreds of servers running on every major (and a shitload of minor) service provider. I custom scripted all these servers to compile all the IP's that attempted a connection, send those lists back to HQ, and then distribute back to each node a block-list table that I could dynamically apply to each edge device. One compromised computer even trying to login was completely blocked from 5000+ domains within 15 minutes.

I'm not worried about my ssh login being brute-forced, but if your computer is compromised I want nothing to do with you.

Re: SSHGuard

#80

Post by tptacek »

UI_at_80x24 wrote: post #79
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 _WANT_ to harvest IP's of PC's trying to SSH into any of my servers. I want them because then I can block ALL traffic coming from their IP's. At my last gig, I had thousands of domains and hundreds of servers running on every major (and a shitload of minor) service provider. I custom scripted all these servers to compile all the IP's that attempted a connection, send those lists back to HQ, and then distribute back…

There is a whole Internet worth of random IPv4 addresses being variously used to variously attack various computers. Your blocklist doesn't even approximate it. What's the point of trying to track and block 0.000000001% of the machines that might be used to attack you?
Post reply on HN