EDIT: What happens to HN? It's my second post that get downvoted for no reason in this thread. This whole post is mostly question asking for clarification, how can they deserve to be downvoted?
> So when you have SSH listening on some uncommon port and see hits in your logs you have a reasonable assurance the attacker isn't some script kiddy spamming the "attack" button on some stupid app.
Do you remove a vulnerability by doing this? Whatever you are afraid that the script kiddy may do, still can happen, thus it is security by obscurity.
> You also have reasonable assurance blocking that host/network with fail2ban or equivalent will actually be effective.
Can you explain that to me? How is it less effective to block a script kiddy or not? Block him... that's it...
> You can also set way more strict fail2ban rules since you're far less likely to ever lock out authorized traffic.
Wait, what? How will it make less likely to block authorized traffic? As long as that traffic act like authorized traffic, it should still be authorized, isn't it? You would blanked ban traffic that doesn't try too many username/password?
The argument is that moving ports act on the probability of the attack, not the possibility of the attack.
Reducing the probability of the attack attemp is good in itself and reduces the noise and thus allows easier detection of worse attackers in server logs.
Hell I'm not arguing security by obscurity doesn't have an effect. I do believe it does hide security vulnerabilities that can be attacked, but it's still security by obscurity.
>thus allows easier detection of worse attackers in server logs
I would be amazed if you could show me a single instance where people would see an attacker in server logs and act on it... quickly enough too that it's effective.
I'm pretty sure that it's extremely rare that anyone will look at logs, even small one, to catch theses kinds of situation. If that's really what you suggest as being an effective way to protect yourself, than that's what you should mentions that it's required to do to become effective.
Fail2ban will act noise or not... which was my point in my comment.
So first, moving the SSH port to something non-standard is not the only step in securing a machine. It's a filter.
On my little jump server at home I used to get tens to hundreds of login attempts per hour. The server only allows for pubkey authentication and my fail2ban rules were strict (block after a single failed login) so the probing never went anywhere. Unfortunately the block lists got huge if I set the block time to a meaningfully long period. It also kept my server at a constant low utilization.
I then started forwarding a non-standard port (that didn't end in 22) and the number of attempted logins dropped to a dozen in a week. I could set my f2b rules to expire after days and not see any performance impact from a big iptables blocklist. My server's baseline load also dropped since it wasn't dealing with constant noise. I could also set up alerts on failed login attempts since I wasn't getting inundated with noise.
I started with a secure setup and increased security by changing the SSH port. Less noise means I can actually see when things happen. It's an outlier event when I get a failed login on my server.
Why would you let the rule be shorter when the attack are more targeted? Doesn't make sense to me to lower it.
> not see any performance impact from a big iptables blocklist.
Wouldn't it be a pretty marginal performance impact? Let say you do get a performance impact significant, then the goal isn't security, it's performance. That's a new thing, performance by obscurity!
> I could also set up alerts on failed login attempts since I wasn't getting inundated with noise.
So you are looking for failed login attempts more now? I have an hard time believing this, but as I said in my previous message, if that was what made it more secure, it's a pretty important step to add, as I would ignore them whether it's 1000 an hour or 10 a week.
I'm curious, what would you even do if you were to see a failed attempt? At what point will you act and how would you act? Anything I can think of is meaningless.
Most distros have f2b's bantime and findtime set to ten minutes by default and a maxretry of 5. Those settings cover the script kiddies/bulk scans. Because of the short timeout your iptables block list isn't going to get too full for too long.
I set my bantime and findtime to much longer durations and maxretries to be 2. This means my iptables block list is long for long periods and f2b has to do more work looking through the SSH logs when dealing with the noise of listening on port 22. Both have non-zero effect on my little Atom powered jump server.
Cutting down the noise let me set even stricter f2b rules with far fewer resources being used on my server.
As for "doing something", there's not much to do for a failed SSH login attempt. I do send myself notification emails but those are just a small section of a larger status email. If I were to see a lot of login attempts on my random high port I'd likely take down external access to my server or set up VPN access to my home network.
My goal is to avoid background noise and get on a "not worth it don't bother" list.
> So when you have SSH listening on some uncommon port and see hits in your logs you have a reasonable assurance the attacker isn't some script kiddy spamming the "attack" button on some stupid app.
Do you remove a vulnerability by doing this? Whatever you are afraid that the script kiddy may do, still can happen, thus it is security by obscurity.
> You also have reasonable assurance blocking that host/network with fail2ban or equivalent will actually be effective.
Can you explain that to me? How is it less effective to block a script kiddy or not? Block him... that's it...
> You can also set way more strict fail2ban rules since you're far less likely to ever lock out authorized traffic.
Wait, what? How will it make less likely to block authorized traffic? As long as that traffic act like authorized traffic, it should still be authorized, isn't it? You would blanked ban traffic that doesn't try too many username/password?