As I'm sure someone else on this thread has observed, this is a silly example, because the SSH example forgets the denominator, which would show that even with 18,000 attack requests, the probability of a compromise on a properly configured system is nonexistent --- and if your system isn't configured properly, SSH becomes an example of obscurity layered on "instead of" proper security.
Do you think there's any benefit in reduced log noise making a serious attacker more obvious to SoC analysts?
I.e. if I run SSH on 24956/TCP and start seeing attacks, it's a fair bet this is targeted (someone has taken the time to do 65K port scans, not common for untargeted attackers), so it's a stronger signal for the blue team to look at that activity more closely than the noise on 22/TCP.
It’s worth noting that running sshd above port 1024 on most systems adds the risk that non-root users can bind their own process to its port if they can crash it or wait for it to crash, and if you break into the ephemeral range, you’re risking non malicious conflicts as well.
There are a number of controls available for pretty much every threat model, so I’m not sure what you’re claiming about my point that using an non-privileged port adds risk to the system that would need to be accepted or dealt with.
So to elaborate. Many Internet facing systems are application servers (e.g. web servers). They typically have very few local users, administrative/Ops staff are the primary users.
At that point an attack requiring the ability to execute arbitary code on the host as a local user is possibly less relavant as, if an attacker is in that position, they likely have a number of other options to further their goals.
The reason I made the comment about alternate controls, is that the original discussion and point I was making revolved around Internet focused attackers, rather than local attackers, so it's not too surprising that I didn't try to cover that case :) No sinister intent, honest!
Heck however if we want to then lets theorize that I can just use some form of firewall to port forward the high port that's presented externally to 22/TCP internally to get the best of both worlds, both a less visible external service and an internal port that requires root to bind.
Gotcha. All valid points, and I’m a big fan of firewall-based port rerouting like you describe.
I agree that an attacker who gets code exec on an app server is in a pretty fun spot already, and has a lot of different paths to escalate/persist/etc that don’t involve misuse of your ssh daemons port.
I hear you on this, but how do you feel about programs such as fail2ban. Even if breakable via 18K requests, if the ssh host has fail2ban installed, the attacker will never get off those 18K requests (unless, and this is a big unless he/she controls 100s of unique IP addresses).
Fail2ban is ineffective against distributed brute force -- if someone has a 100k strong botnet, they can try 100k user/pass guesses, and fail2ban won't lift a finger.
But stepping back a bit, in the case where you're using keys for auth and have passwords disabled, fail2ban adds nothing.
true, but it's a simple tweak to fail2ban to treat failed login attempts (irrespective of IP address) similar to how it treats failed logins linked to a particular IP address. Of course, the exponential back off would have to be much slower to avoid making the server very susceptible to DDOS attacks.
All that being said, yes, ssh keys are the gold standard, but I don't find them to be very portable.
Not the parent commenter, but could you explain why? AT my work we're setting up a large deployment and I'm planning on configuring fail2ban on all our instances. Is there any downside to doing so that I'm missing?
There’s no downside that I know of, but if you’re using keys there’s no upside, and if you’re not exclusively using keys there’s a huge downside to that.
The major downside of fail2ban is actually that it punishes you for using keys. If you have different keys for different machines and haven't configured your SSH client to pair them up you might attempt to login several times with the wrong key before getting in. You won't even notice this normally but fail2ban will trigger and ban you from the machine.
