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

111–120 of 149 posts

Re: SSHGuard

#111

Post by pferde »

BoardsOfCanada wrote: post #99
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

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

FWIW, your guess is incorrect. From sshd_config(5): "For each keyword, the first obtained value will be used."

Still, if you cannot explain how that second line got in there, it is probably prudent to reinstall (perhaps even reflash BIOS).

Re: SSHGuard

#112

Post by pferde »

antihero wrote: post #27
akulbe wrote: post #21

Earlier quoted context omitted.

Hi Tom - I don't know if you've already written about this elsewhere, but what would be some sane defaults for SSH? Do you think using key-based auth and disabling password authentication is enough ? or are there other things you would recommend? OT - nice Fibonacci in your profile :D

I’ve always used this: https://www.sshaudit.com/hardening_guides.html If there’s something better please correct me!

Wow, that's terrible. Imperative instead of declarative, and does not explain the reasons. Perfect for cargo-culting your way to disaster.

Re: SSHGuard

#113

Post by Klasiaster »

Would be nice to have this as eBPF cgroup socket filter, attachable to the systemd service (or OpenSSH could load it itself). Then it's not needed to parse the text logs anymore.

Re: SSHGuard

#114

Post by vinay_ys »

In 2022, I can't think of good reasons to run a Internet-facing ssh server. Wireguard should be your only Internet facing protocol for any private access. Once you establish a Wireguard tunnel, you can ssh to that machine if you like.

And, please don't use passwords, instead use certificates. You can easily have system to create and use a short-term valid login certificates. Also, don't forget to authenticate your hosts to users with host certificates.

All of the above is needed even if it is behind wireguard. That's defense in depth. Ensure there is no shared-fate between the two authentication systems.

Also, consider multi-factor personal authentication – biometric+external auth (FIDO2 device with fingerprint auth) and device-auth (device-secure-enclave bound certificates) where device is unlocked by a password/pin from your memory.

If you do these, you don't need silly hacks like SSHGuard.

Re: SSHGuard

#115

Post by intelVISA »

cookiengineer wrote: post #71
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 mech…

> write my own guard tools.

if (notMe)

    panic();
Though I agree, security is a mindset not a tool you can simply download or run.

Re: SSHGuard

#116

Post by ozim »

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…

I want that for servers I manage.

Re: SSHGuard

#117

Post by Beltalowda »

fmajid wrote: post #106
Beltalowda wrote: post #19

Earlier quoted context omitted.

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

Never used Linode. Most of the services I am familiar with will let you upload your SSH public key that is auto provisioned for root authorized_keys by cloud-init. Using SSH certificates would be even better but I don’t know of any cloud that support them.

Yup, Linode does that too, but unless they changed things it still ships with root login + password auth enabled by default.

Re: SSHGuard

#118

Post by ratorx »

vinay_ys wrote: post #114

In 2022, I can't think of good reasons to run a Internet-facing ssh server. Wireguard should be your only Internet facing protocol for any private access. Once you establish a Wireguard tunnel, you can ssh to that machine if you like. And, please don't use passwords, instead use certificates. You can easily have system to create and use a short-term valid login certificates. Also, don't forget to authenticate your ho…

SSH certificates don’t have an equivalent in Wireguard. They are a much more scalable way of provisioning authentication.

Defense-in-depth is a good idea, but has its limits. I don’t think there’s too much value to layering SSH over Wireguard.

Agreed on SSHGuard type things not being necessary (for authentication protocol). SSH is not special. People can attempt to bruteforce Wireguard too. In fact, the only difference seems to be SSH making the logs (more easily) accessible.

The main downside to SSH is that it allows in default configuration to use insecure passwords for authentication (but this can be disabled). Wireguard is strictly better since passwords are never an option.

Protocol negotiation is another downside, but I think it’s a smaller one. The SSH devs are fairly good about removing insecure schemes from the defaults.

Re: SSHGuard

#119

Post by amelius »

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…

Security always works in layers, it should never be just one line of defense ...

Even obscurity has its place (e.g. using a different SSH port)

Re: SSHGuard

#120

Post by amelius »

vinay_ys wrote: post #114

In 2022, I can't think of good reasons to run a Internet-facing ssh server. Wireguard should be your only Internet facing protocol for any private access. Once you establish a Wireguard tunnel, you can ssh to that machine if you like. And, please don't use passwords, instead use certificates. You can easily have system to create and use a short-term valid login certificates. Also, don't forget to authenticate your ho…

What setup would you recommend for systems that at some point are owned by a customer (but which you might still need to login to frequently; and you might need to access private repositories from)?
Post reply on HN