then you do not open it to Internet. Otherwise you patch aggressively, you use ssh keys and not passwords and you move it to some random port to hide it a bit (it actually helps)
> logspam
you can filter this out in your log management tool
> CPU burn
if this is your concern, then you have a hep of issues you need to address. I have never seen a CPU perf hit because of such behaviour (there are cases where it happens, butthis is due to a vulnerability of the service)
> network traffic
the packet is here already, there is nothing to reduce
Moving ssh off of port 22 makes it a pain in the ass to work with. Ports are standardized for a reason.
Authentication attempts are a useful security signal; I don't want to filter them out. I want hosts running dictionary attacks to not be able to connect to my services in the first place. If you are running an SSH bot, then I don't want you on my website or anything else.
> Moving ssh off of port 22 makes it a pain in the ass to work with. Ports are standardized for a reason.
yes, they were standardized in the ol' good times :) If you have a limited amount of people/services connecting then it is manageable. But of course YMMV.
> Authentication attempts are a useful security signal; I don't want to filter them out. I want hosts running dictionary attacks to not be able to connect to my services in the first place. If you are running an SSH bot, then I don't want you on my website or anything else.
enumeration and brute force on SSH fail by design when using keys.
As for other services I do not see how this helps - you will block random IPs hoping that a vulnerable site is not taken over if they happen to get back. It is not common (at least in my monitoring of several honeypots in various locations) to have the same IP being particularly visible. Sure they are back sometimes but this is quite exceptional.
Anyway - it is not worth the hassle, better have proper hardening.
> yes, they were standardized in the ol' good times :) If you have a limited amount of people/services connecting then it is manageable. But of course YMMV.
Agreed. I've never found it difficult to manage this. I already tend to configure SSH hosts in my ~/.ssh/config file anyway so that I don't have to remember every IP and port combination for every host I have access to when I want to use SSH (or something that relies on the SSH protocol like rsync or scp).
then you do not open it to Internet. Otherwise you patch aggressively, you use ssh keys and not passwords and you move it to some random port to hide it a bit (it actually helps)
> logspam
you can filter this out in your log management tool
> CPU burn
if this is your concern, then you have a hep of issues you need to address. I have never seen a CPU perf hit because of such behaviour (there are cases where it happens, butthis is due to a vulnerability of the service)
> network traffic
the packet is here already, there is nothing to reduce