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

91–100 of 149 posts

Re: SSHGuard

#91

Post by theteapot »

traceroute66 wrote: post #88
theteapot wrote: post #70

Earlier quoted context omitted.

> 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 t…

> Rate limiting You don't need fail2ban to rate-limit SSH. RFTM ... MaxStartups, PerSourceMaxStartups, PerSourceNetBlockSize. > trying to brute force AuthenticationMethods publickey PasswordAuthentication no ChallengeResponseAuthentication no PermitRootLogin no

> (not just SSH) ...

We know about the SSH daemon config. You still get all sorts of probing that isn't a brute force on SSH.

Re: SSHGuard

#92

Post by maltris »

tptacek wrote: post #80
UI_at_80x24 wrote: post #79

Earlier quoted context omitted.

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?

I dont see anything wrong in collecting and blocking them for some time, not infinitely of course. Blocking at the firewall effectively means blocking further communication and requests that cost you bandwidth and computing time. Why not save that for the legitimate visitors?

Re: SSHGuard

#93

Post by nix23 »

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…

>These tools are popular, but I think they're kind of silly.

Really? And how do you block someone who slowly try's (every 2-4 minutes) to bruteforce your smtp? Yes your openSSH has some slowdown mechanisms builtin, but your Imap-Server? Smtp-Server? Your openTTD-Server? However i think using the logs is the wrong approach hence my use of blacklistd* whenever possible.

* https://www.freebsd.org/cgi/man.cgi?query=blacklistd&sektion...

* https://man.netbsd.org/NetBSD-7.0/blacklistd.8

Re: SSHGuard

#94

Post by tlamponi »

traceroute66 wrote: post #88
theteapot wrote: post #70

Earlier quoted context omitted.

> 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 t…

> Rate limiting You don't need fail2ban to rate-limit SSH. RFTM ... MaxStartups, PerSourceMaxStartups, PerSourceNetBlockSize. > trying to brute force AuthenticationMethods publickey PasswordAuthentication no ChallengeResponseAuthentication no PermitRootLogin no

Not disagreeing in general and disallowing password login for root is IMO really a no-brainer.

But, it's nonetheless a fact that a (temporary) nft drop rule in the kernel is much more effective than traffic hitting a user space daemon like SSH.

Some NICs even allow offloading that (e.g., in form of a bpf program) to the card itself, so that such traffic won't ever hit the system (CPU) at all.

So yes, SSH can be made secure and rate-limited without anything else, but that won't be the most efficient solution; now fail2ban/sshguard/... ain't no free lunch either, so one needs to weight the added (IMO small, but still) complexity against benefits in a specific use case.

Re: SSHGuard

#95

Post by swinglock »

maltris wrote: post #92
tptacek wrote: post #80

Earlier quoted context omitted.

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?

I dont see anything wrong in collecting and blocking them for some time, not infinitely of course. Blocking at the firewall effectively means blocking further communication and requests that cost you bandwidth and computing time. Why not save that for the legitimate visitors?

Because you block legitimate visitors. After we ran out of IPv4 space and started to use CGNAT instead of IPv6, the internet has become a bastardized version of itself.

Re: SSHGuard

#96

Post by nix23 »

theteapot wrote: post #91
traceroute66 wrote: post #88

Earlier quoted context omitted.

> Rate limiting You don't need fail2ban to rate-limit SSH. RFTM ... MaxStartups, PerSourceMaxStartups, PerSourceNetBlockSize. > trying to brute force AuthenticationMethods publickey PasswordAuthentication no ChallengeResponseAuthentication no PermitRootLogin no

> (not just SSH) ... We know about the SSH daemon config. You still get all sorts of probing that isn't a brute force on SSH.

Exactly, fail2ban/blacklistd is for software who lacks certain function ssh has for example sendmail, asterisk etc:

https://github.com/fail2ban/fail2ban/tree/master/config/filt...

Re: SSHGuard

#97

Post by unixhero »

Is this better than fail2ban?

I use crowdsec also nowadays, but I don't trust it like I trust fail2ban. Due to opaque answers from the engine on how it has protected my hosts. Considering going all the way Back to fail2ban again.

Re: SSHGuard

#98

Post by 0___0 »

schipplock wrote: post #90
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. I don't want to defend this tool, but OpenSSH is written in C as well :).

Two Cs don't make it Rust

Re: SSHGuard

#99

Post by BoardsOfCanada »

traceroute66 wrote: post #88
theteapot wrote: post #70

Earlier quoted context omitted.

> 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 t…

> Rate limiting You don't need fail2ban to rate-limit SSH. RFTM ... MaxStartups, PerSourceMaxStartups, PerSourceNetBlockSize. > trying to brute force AuthenticationMethods publickey PasswordAuthentication no ChallengeResponseAuthentication no PermitRootLogin no

Just to double check my sshd settings I logged in to a server I have, and while it had "PasswordAuthentication no" set in the normal place in the config file, there was a line added to the very end of it "PasswordAuthentication yes", which I guess overrides the previous one.

The server is reinstalling the OS right now...

Re: SSHGuard

#100

Post by mekster »

perlgeek wrote: post #87
mekster wrote: post #76

Earlier quoted context omitted.

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.

If your private SSH key is leaked, you can expect the attacker to come up in with a single successful login attempt, sshguard, fail2ban etc. won't help. The only help against that scenario is a true multi factor setup, or maybe a hardware-based security token that needs a second factor (fingerprint or PIN) to unlock.

How's that so? The attacker has no knowledge of the user name of the key, unless that is also leaked, then only white listed IP may help.
Post reply on HN