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

121–130 of 149 posts

Re: SSHGuard

#121

Post by themoonisachees »

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 don't think anybody with a sane config need fail2ban or similar. But as a sysadmin who works for clients who don't understand such concepts, sometimes it's easier going "okay, we will install it on your systems for $x" than explaining why it's useless. It's a business politics tool.

Re: SSHGuard

#122

Post by amelius »

GekkePrutser wrote: post #11
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…

> 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. Well, even when accepting only certificates some brute force bots are dumb enough to keep trying to connect to try passwords, and this can give a lot of unnecessary CPU load due to all the initial connection cr…

On the other hand, shouldn't we be stealing resources from bots, even if it costs us resources too?

Re: SSHGuard

#123

Post by amelius »

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.

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

Re: SSHGuard

#124

Post by GekkePrutser »

amelius wrote: post #122
GekkePrutser wrote: post #11

Earlier quoted context omitted.

> 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. Well, even when accepting only certificates some brute force bots are dumb enough to keep trying to connect to try passwords, and this can give a lot of unnecessary CPU load due to all the initial connection cr…

On the other hand, shouldn't we be stealing resources from bots, even if it costs us resources too?

No. Let them bother someone else :P

Re: SSHGuard

#125

Post by GekkePrutser »

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.

This is really useful, thanks!

Re: SSHGuard

#126

Post by hun3 »

ratorx wrote: post #118
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 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?

Re: SSHGuard

#127

Post by throwawaaarrgh »

sjellis wrote: post #84

PSA: If you are using AWS, you should be using Session Manager for remote access to your EC2 instances if possible - it is free and trivial to enable. Azure offers Azure Bastion, which is exactly what it says. Both of these can keep hostile SSH connections completely away from your servers, and also help to aggregate access logs.

iirc you cannot handle multiple separate user accounts with limited privileges on a server with AWS SSM SM, has that changed?

Re: SSHGuard

#128

Post by nubinetwork »

swinglock wrote: post #95
maltris wrote: post #92

Earlier quoted context omitted.

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.

If carriers/ISPs monitored their networks better (or acted on abuse@ emails), their IPs wouldn't wind up on blocklists (either temporarily or permanently).

edit: That isn't to say they should be logging every packet... But if I work for XYZ Hosting Company and spin up a new VM, hand you the IP, and you turn the IP into a mini-shodan scanner... Is the hosting company at least a little responsible for what happens next?

Re: SSHGuard

#129

Post by funstuff007 »

einichi wrote: post #83
funstuff007 wrote: post #62

I get keys are better than passwords, but how do you enforce key rotation for non-technical users when they can barely manage to changer their passwords? I much prefer 2FA than keys for non-technical users.

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

Re: SSHGuard

#130

Post by egberts1 »

akulbe wrote: post #21
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…

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

while it is not the best, I do regularly code audit OpenSSH.

For sane default, you can generate your working but sane ssh_config and sshd_config based on my inner code knowledge and network security and as an IDS/IPS architect.

Each and every known OpenSSL (v8.4; v9.0 is underway) settings in the config files have annotations and details and many have additional links detailing why. I also note where each and every config settings are found in the source code by nesting, what protocol state, control state, authentication stage, and lockings (makes code review so much easier for me) also in its comment section of each config setting.

Even has a bash script to let you create these config files (defaults to your subdirectory for pretesting, but can also as an option update /etc/ssh, which I confidently do) into something that would pass an SSH audit for ssh-audit (I’m a contributor), CISecurity and often better.

Also these scripts generates a script containing proper file permission settings based on top generic Linux File System variants (basic variants like APT, pacman, Portage, DNF/RPM) ).

I also offer SSH bastion setup (adjacent to my URL given below) as well.

I also enjoy using certificate-by-user as an authentication mechanism for maximum ease of sysadmin use when it comes to emergency mass-blocking or occasional employee departures.

https://github.com/egberts/easy-admin/tree/b74765baa450593be...

Post reply on HN