| This is an interesting read, but it's worth digging down into the particulars. In particular: > Is adding obscurity the best use of my resources given the controls I have in place, or would I be better off adding a different (non-obscurity-based) control? Is a really important question to ask. In this case, I'd argue that port-knocking, SPA, and changing the port are not cost-effective. Obscurity is not free. There are additional costs and risks to consider: * Has the port-knocking or SPA software been well tested or audited?
* What if my pentester mistakenly believes that there is no OpenSSH service, and so doesn't check it?
* Is it worth re-configuring all of my SSH clients? What if I have to go through change control?
* Is it worth re-configuring any vuln. scanners I deploy?
* Do my clients support port-knocking or SPA?
I could spend an hour setting up port-knocking, SPA, or rolling out a port change. Could I do something more useful with my time? Perhaps better testing my application? Finishing that pressing code review? Buying and using a vulnerability scanner? Reaching out to a pentest company? Setting up an IDS?All of the above will probably have a better cost-benefit ratio than port-knocking, SPA, or changing the default port. It is almost always more cost-effective to just use Mozilla's OpenSSH guide[1], keep up with security patches, and direct your attention to the weaker components of your stack. References: [1] : https://wiki.mozilla.org/Security/Guidelines/OpenSSH Security/Guidelines/OpenSSH, Mozilla |
Changing ports is very effective, at least at reducing noise. This is especially true when setting up a new service with no preexisting clients. Default port 22 is an ocean of noise and constant password attempts, no reason to fill up my log servers with millions and millions of attempts per year.