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

131–140 of 149 posts

Re: SSHGuard

#131

Post by vinay_ys »

amelius wrote: post #120
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)?

I would strongly urge such customers to put all such access behind a dedicated gateway via Wireguard.

Re: SSHGuard

#132

Post by xmodem »

funstuff007 wrote: post #129
einichi wrote: post #83

Earlier quoted context omitted.

For keys used in authentication, I feel like rotation largely just protects against keys being leaked. If you can enforce keys to exist only on a secure element then to me I feel like rotation is no longer needed in this particular scenario. With the exception of the key strength no longer being enough or something similar. Perhaps I'm overlooking something?

> exist only on a secure element Do non-technical users know how to operate a secure element? Is that an encrypted home drive on a laptop protected by a weak password? I appreciate your input, but I still think 2FA is the most secure and usable method for non-technical people. Of course, no SMS (at least outside the US).

There are a lot of commercial solutions out there, but for those of us with macs and without control of our org's IT spend, there's Secretive [1], although it lacks a way to prove that a key is hardware backed.

https://github.com/maxgoedjen/secretive

Re: SSHGuard

#133

Post by akerl_ »

5e92cb50239222b wrote: post #105
akerl_ wrote: post #56

Earlier quoted context omitted.

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…

> I don't have a great way to pull out sshd specifically If it's using systemd, try systemctl status sshd If CPU accounting is turned on, you'll see how much CPU time was used by sshd, plus when it was last restarted, which at least gives you something to work with. If not, you can enable it with: systemctl edit sshd then adding: [Service] CPUAccounting=yes and restarting the daemon.

TIL! Thanks for sharing

Re: SSHGuard

#134

Post by klausagnoletti »

unixhero wrote: post #97

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.

Hey, head of community at CrowdSec here. Could you elaborate on your situation and the 'opaque' replies from the agent you're receiving in a mail to klaus at crowdsec dot net? Very interested in understanding your issues and hopefully help you to build trust :-)

Re: SSHGuard

#135

Post by klausagnoletti »

upofadown wrote: post #50

Doesn't Dovecot now have a fairly capable brute force password attack prevention system? Is there any reason that someone would still use something like this anyway? Couldn't find anything about Exim or Postfix integrated brute force prevention on SMTP connections...

https://hub.crowdsec.net/author/crowdsecurity/collections/do...

Re: SSHGuard

#136

Post by exabrial »

I fixed ssh knocking with having wireguard VPN in front of all of our servers. We still require authentication and all inbound connections (even from the VPN ) are untrusted.

This completely silenced our logs.

Re: SSHGuard

#137

Post by ratorx »

hun3 wrote: post #126
ratorx wrote: post #118

Earlier quoted context omitted.

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

> I don’t think there’s too much value to layering SSH over Wireguard. Future in-the-wild vulnerabilities in the SSH protocol layer?

Sure, but there might be Wireguard vulnerabilities as well. Why not layer SSH over Wireguard over IPSec over OpenVPN just to be safe?

I think that layering may be useful given a certain threat model, but you shouldn’t just layer protocols without actually considering the probability of vulnerability and considering the other tradeoffs you are making. Otherwise the only correct answer would be to layer SSH over every independent VPN protocol.

Considering the security track record of SSH, I don’t see the value to layering, when on the other side, you now need to manage multiple keys and an entirely separate protocol that isn’t as ubiquitous (yet). The time spent doing this might be better spent building robust and testable auto-update infrastructure or architecting the applications on the server to reduce the risk of contagion given an RCE vulnerability.

Re: SSHGuard

#138

Post by loeg »

5e92cb50239222b wrote: post #105
akerl_ wrote: post #56

Earlier quoted context omitted.

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…

> I don't have a great way to pull out sshd specifically If it's using systemd, try systemctl status sshd If CPU accounting is turned on, you'll see how much CPU time was used by sshd, plus when it was last restarted, which at least gives you something to work with. If not, you can enable it with: systemctl edit sshd then adding: [Service] CPUAccounting=yes and restarting the daemon.

TIL about systemctl edit, thanks. Note to others: if you want to override an existing setting, rather than just add new settings, you'll need to use 'systemctl edit --full'.

Re: SSHGuard

#139

Post by nullc »

mekster wrote: post #100
perlgeek wrote: post #87

Earlier quoted context omitted.

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.

hope you don't use github (which discloses all users keys, attached to their usernames there), and/or the same username in multiple places.

SSH also leaks the keys it'll accept, it doesn't use a zero knowledge proof to first determine if the client and the server have mutually acceptable keys.

Re: SSHGuard

#140

Post by vinay_ys »

ratorx wrote: post #137
hun3 wrote: post #126

Earlier quoted context omitted.

> I don’t think there’s too much value to layering SSH over Wireguard. Future in-the-wild vulnerabilities in the SSH protocol layer?

Sure, but there might be Wireguard vulnerabilities as well. Why not layer SSH over Wireguard over IPSec over OpenVPN just to be safe? I think that layering may be useful given a certain threat model, but you shouldn’t just layer protocols without actually considering the probability of vulnerability and considering the other tradeoffs you are making. Otherwise the only correct answer would be to layer SSH over every…

Defense in depth works on the principle that you will have to find vulnerabilities in multiple heterogeneous and independent systems before you get to the prize.

Reason to put wireguard as the first line of defense before ssh is because of wireguard's simplicity and robustness vs the track record of ssh implementations.

Post reply on HN