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

141–149 of 149 posts

Re: SSHGuard

#141

Post by ratorx »

vinay_ys wrote: post #140
ratorx wrote: post #137

Earlier quoted context omitted.

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.

Sure, defense in depth is great, but there needs to be an argument about the tradeoff. Otherwise as I said, everyone should run OpenSSH over Wireguard over IPSec over OpenVPN, because then you need to exploit all of them to do an exploit and that is harder to do than exploiting any smaller subset.

Why is the tradeoff of adding Wireguard worth it? Sure it’s extra security, but is it really worthy managing multiple keys, not-as-ubiquitous protocol, less flexible administration and no CA? I don’t think there is a correct answer (it depends on the threat model), but your original comment made it seem like there was no tradeoff and there was an obvious correct answer.

Re: SSHGuard

#142

Post by nullc »

mekster wrote: post #76
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.

FWIW, you can make your SSH itself key-auth only and then setup whatever second factor you like via pam. (including fancy stuff if you like, n of m yubikeys ...)

Re: SSHGuard

#143

Post by unixhero »

klausagnoletti wrote: post #134
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 :-)

Hi

The main issue is that on my hosts where fail2ban are running, I see week on week activity and banned hosts.

When I look into cscli decisions or cscli metrics, it gives me the indication that nothing is happening which I don't believe is true. Maybe it is doing the work it promises, but I can't easily see it.

This could be a false negative, and that there genuinely is less malicious connection attempts. The busy fail2ban are bastion hosts on AWS, while the others are hosted on DigitalOcean. For me as a user though, I wish there was a way to see historically blocked hosts. The last time I looked half a year ago, this was not available in CrowdSec.

Re: SSHGuard

#144

Post by klausagnoletti »

unixhero wrote: post #143
klausagnoletti wrote: post #134

Earlier quoted context omitted.

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 :-)

Hi The main issue is that on my hosts where fail2ban are running, I see week on week activity and banned hosts. When I look into cscli decisions or cscli metrics, it gives me the indication that nothing is happening which I don't believe is true. Maybe it is doing the work it promises, but I can't easily see it. This could be a false negative, and that there genuinely is less malicious connection attempts. The busy f…

Hey and thanks for your reply. This is done easily in the cscli with the 'decisions' command: https://doc.crowdsec.net/docs/next/cscli/cscli_decisions. 'sudo cscli decisions list' lists all local decisions as you request :-). If you want to look into a decision, 'explain' is your friend: https://doc.crowdsec.net/docs/next/cscli/cscli_explain or simply look in /var/log/crowdsec.log (on Linux). I hope this answers your question. If not, you're welcome to ask again or join our Discord at https://discord.gg/crowdsec (which is by far the best way to get help fast).

Re: SSHGuard

#145

Post by antihero »

amelius wrote: post #123
pferde wrote: post #112

Earlier quoted context omitted.

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

Also, why isn't hardened ssh the default? Is this breaking too many things for the user?

Compatibility basically.

Re: SSHGuard

#146

Post by antihero »

pferde wrote: post #112
antihero wrote: post #27

Earlier quoted context omitted.

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.

Would you recommend a better guide? Is the config suggested by it bad? Not everyone has the skill/time to deeply understand everything immediately, and having a saner starting point is a good thing.

Re: SSHGuard

#147

Post by IcePic »

ratorx wrote: post #141
vinay_ys wrote: post #140

Earlier quoted context omitted.

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.

Sure, defense in depth is great, but there needs to be an argument about the tradeoff. Otherwise as I said, everyone should run OpenSSH over Wireguard over IPSec over OpenVPN, because then you need to exploit all of them to do an exploit and that is harder to do than exploiting any smaller subset. Why is the tradeoff of adding Wireguard worth it? Sure it’s extra security, but is it really worthy managing multiple key…

Since wireguard is not visible from the outside, you have immediately fixed everything related to ssh logs clogging up with failed attempts.

Re: SSHGuard

#148

Post by fmajid »

Beltalowda wrote: post #117
fmajid wrote: post #106

Earlier quoted context omitted.

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.

I agree, neither is a sensible default.

Re: SSHGuard

#149

Post by fmajid »

yakubin wrote: post #68
noAnswer wrote: post #66

Earlier quoted context omitted.

What I find funny though is that every implementation not involving Donenfeld has "drama" (Free- and NetBSD). The small code still leave a lot of room for failure.

That’s why I mentioned reviewed code. The original FreeBSD code which sparked the drama wasn’t reviewed. And honestly some of the issues that were there are not something preventable by limiting oneself to even 50 LOC. I don’t want to speculate how they came to be though. It’s really baffling.

It was reviewed, with prejudice. Netgate (company behind pfSense) asked Donenfeld "by the way, we are merging this into FreeBSD next week, would you mind having a look?". Donenfeld dropped whatever he was doing (the short notice period: not cool at all), looked at the code, was horrified by what he saw, and blew the whistle. Instead of being grateful, the team at Netgate/pfSense started being snitty. Colin Perceval (Chief Security Officer for FreeBSD) decided to just yank it, but the clear influence Netgate has over the FreeBSD project is not a good look.

Here's a good summary:

https://arstechnica.com/gadgets/2021/03/buffer-overruns-lice...

Contrast this with how easily and well Wireguard was integrated into OpenBSD.

Post reply on HN