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

51–60 of 149 posts

Re: SSHGuard

#51

Post by froggit »

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.

> You could even live dangerously and just use telnet once you have wireguard going.

Using telnet makes me feel a little dirty and a lot alive. Using it over wireguard seems like taking a 60s muscle car and adding brakes that actually work before a track day; probably not a bad idea.

Re: SSHGuard

#52

Post by tptacek »

EnigmaCurry wrote: post #47
akulbe wrote: post #29

Earlier quoted context omitted.

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?

Its suspected from the snowden docs that this is one of the ones intentionally weakened by NIST. Here's the long answer: https://blog.cr.yp.to/20140323-ecdsa.html

Nobody serious thinks the P-curves, which is what we're talking about, were weakened by NIST. I don't think anybody at all thinks the DSA algorithm was "intentionally weakened", but lots of people, reasonably, believe it was incompetently designed.

Ed2519 has the virtue of both a better curve and a better signing algorithm, which is why it's used in preference to ECDSA. If you're using 25519, don't bother keeping the rest of the algorithms enabled.

I think these hardening guides are mostly pretty silly too, for whatever that's worth. The important thing is making sure nobody can log into anything with a password. The rest is just liturgical.

Re: SSHGuard

#53

Post by loeg »

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…

Possibly the best tool in this space is blacklistd / blocklistd, which just exposes some reporting APIs and hooks them directly in sshd, rather than trying to parse failed logins out of logs. That said, meh.

https://github.com/zoulasc/blocklist

Re: SSHGuard

#54

Post by ptcrash »

Is this a new iteration in fail2ban? I gave it a cursory look and I couldn’t find any new features that make it a better tool than its predecessor

Re: SSHGuard

#55

Post by froggit »

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. They are very different use cases with different implications, so it depends on what you're doing with them and how.

Cars and bikes are both fine for point to point travel. They'll each give you a vastly different experience though. It"s prolly better to stick with what you know how to use, in my opinion. You're likely gonna have a bad day if you crash and die.

Re: SSHGuard

#56

Post by akerl_ »

GekkePrutser wrote: post #46
akerl_ wrote: post #31

Earlier quoted context omitted.

It seems improbable that the baseline load of a couple concurrent SSH attempts is higher than the load of running an extra Python daemon that's constantly checking your log files.

When I still ran my own server it was a pretty heavy load, like 30% or so. Much more than a minor nuisance. But it was a SPARC server with 1 core at a few hundred MHz and no crypto acceleration. As you can tell this is a while ago :) So yeah I guess these days it's much less of an issue. But the number of possible attempts will have increased too of course.

I figured I might as well go pull up some numbers from my personal systems. I've got 3 internet-facing VMs that expose SSH to the world.

For the past 30 days, I've seen a combined total of 86k SSH attempts. I've not bothered to filter out my own legitimate sessions, given that they're in the ballpark of ~3 connections a day tops.

Total load on each of these systems has stayed below 0.5, and that's including the other actual work the servers do. I don't have a great way to pull out sshd specifically, but it's safe to say that these servers haven't had their operations affected at all by the nefarious attempts.

For what it's worth, the one thing I'm doing that could potentially impact the resource consumption is hardcoding cipher/keyexchange/MAC selections. Given that I control 100% of the legitimate clients for these SSH daemons, I've hardcoded the settings as follows:

Ciphers chacha20-poly1305@openssh.com

KexAlgorithms curve25519-sha256@libssh.org

MACs hmac-sha2-512-etm@openssh.com

HostKey /etc/ssh/ssh_host_ed25519_key

Over 95% of the spam connection attempts get dropped before my server ever does any crypto, because the connecting system doesn't support that KeyExchange choice.

Re: SSHGuard

#57

Post by deathanatos »

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 primarily use it for logs.

However, I've worked at a lot of startups, and no matter how much you try to discipline people, someone thinks their circumstance is special (and it somehow requires a password-based login), or someone is just lazy and sets a password for unfathomable reasons. So, for those people, I run fail2ban to allow it to act as a rate-limiter. But tptacek is right, in any sane situation, you don't really need it. But sometimes the situation isn't sane.

> just disable password authentication and that's about it.

a.) for what ever reason, I've had third-parties insist on passwords. (In healthcare¹, too. Ugh.) b.) For quite a while, Azure's "AADLogin" used keyboard-interactive, which meant that you couldn't disable it. Thankfully, that got fixed in a recent version.

¹In addition to fail2ban, we also did firewalls at the cloud level. The password was a good (secure) one, but I'd sleep easier with a key-based login.

Re: SSHGuard

#58

Post by deathanatos »

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

Possibly the best tool in this space is blacklistd / blocklistd, which just exposes some reporting APIs and hooks them directly in sshd, rather than trying to parse failed logins out of logs. That said, meh. https://github.com/zoulasc/blocklist

Edit: Yeah, there's no race condition; the client sends the offending socket to blocklistd over the blocklistd socket.

(Originally…)

I'm a bit curious; it also seems to imply that it logs the fd number, and then blocklistd queries the kernel to obtain the remote's address. That seems like a race condition:

  1. blocklist call is made
  2. daemon closes the socket (connection has failed, after all)
  3. next client connects
  4. lookup is made by blocklistd, and the wrong peer is potentially incriminated
(Actually, perhaps it's sending the fd over the socket. I forget you can do that, and the README is hard for me to follow. The "like syslog" also implied that it's logging over syslog to me, but that's not what the code does.)

Re: SSHGuard

#59

Post by jcrawfordor »

deathanatos wrote: post #57
vbezhenar wrote: post #18

Earlier quoted context omitted.

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 primarily use it for logs. However, I've worked at a lot of startups, and no matter how much you try to discipline people, someone thinks their circumstance is special (and it somehow requires a password-based login), or someone is just lazy and sets a password for unfathomable reasons. So, for those people, I run fail2ban to allow it to act as a rate-limiter. But tptacek is right, in any sane situation, you don't…

Big issue in healthcare is a lot of legacy integration brokers that had SFTP bolted on post-release using the existing UX and config framework for FTP, which had historically been the dominant protocol in healthcare. Depending on the broker sometimes key auth isn't supported at all, it is supported but has to be configured in a strange way that's different from the normal SFTP/FTP config, or it's supported just fine but the company has business processes like paperwork for their integration subcontractor that still assume FTP is used (this latter one does unfortunately come up...).

You'll see the same thing in financial software for basically the same reasons.

Re: SSHGuard

#60

Post by hsbauauvhabzb »

hnarn wrote: post #16
hsbauauvhabzb wrote: post #14

Earlier quoted context omitted.

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

It doesnt stop determined attackers who have access to a botnet, but it does stop low sophistication attacks.

If brute forcing anything is a concern then addressing that concern should come first, focusing effort on fail2ban is a cost that is probably better spent elsewhere.

Post reply on HN