1On Sat, Mar 18, 2023 at 8:23 AM Carsten Andrich <carsten.andrich@xxxxxxxxxxxxx> wrote: > a publicly accessible sshd on port 22 generates a lot of log clutter > from unauthenticated connections. This is not unique to OpenSSH. Any well-known service on any publicly-accessible host will be probed incessantly. In addition to source-blocking solutions (portknocking, fail2ban, et. al.) and log filtering solutions, something that can be surprisingly effective is to simply configure sshd to listen on a TCP port other than 22. Virtually no attackers perform full port scans looking for hidden ssh daemons, because there’s so much low-hanging fruit on port 22. On my home network, I have a publicly-accessible sshd instance that is listening on a TCP port <1024 that is not port 22. For more than 10 years (until a botnet finally found it), I was the only person who ever attempted to connect to it. (In response to its discovery, I could have simply moved the sshd instance to a different port, but instead I used that as an excuse to experiment with a portknocker configuration.) In InfoSec, obfuscation has a bad rap, because it is frequently deployed in an attempt to hide a security vulnerability instead of applying remediation. But there are a few instances where obfuscation can be a valuable and appropriate tool in one’s toolbox. And reducing voluminous log noise by evading 99.999% of ankle-biting script kiddies is one of those instances. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
