Also...stick the SSH on a non-default port. Cuts login attempts down to near zero.
we also had a bunch of scanners probing for common php scripts on the http server (we don't run php). simply returning a 404 header and disabling logging in nginx for \.php$ uris cut down a bunch of garbage (mostly from China). additionally, using ngx_http_limit_req_module reduced the effects of numerous DoS-type scanners.
so far, this + iptables for only 80/443/ssh has been a superior solution to instaling fail2ban that continually scans bloated log files and performs constant iptables banning/unbanning foo.
clean logs are essential, not just nice to haves.
"Log noise" is a legitimate security concern all by itself. It is actually disappointing how rarely it is discussed, and how in this world of "AI everywhere" there's no great smart AI log analysers to reduce the signal:noise.
Moving the SSH port might "only" reduce noise, but that's a legitimate security goal in its own right.
For instance, if I (or my software anyway) see a bunch of sshd login attempts from some IP, and then that IP decides to try imap ... yeah, that's getting insta-blocked.
And that's hard to do if you decide to just ignore the sshd attempts.
That's because after many people learn about not using "security through obscurity" they apply the rule without thinking as if obscurity never has any benefit for anything.
SSH key-based logins are so much more secure and convenient as heck once you invest the time to learn how they work.
Putting SSH on a nonstandard port is pretty silly.
what's the alternative while still keeping ssh logs that aren't filled with thousands of login attempts from bots per day? afaik there isnt any solution that is both as simple and as effective as changing the port.
Last commit June 2012? Does it work with modern distros?
Do you really think making firewalling decisions based on unstructured attacker-controlled log data is a good idea?
Many unexpected things can happen, as a simple example SSH can generate log entries like this
Jan 30 17:37:04 server sshd[26695]: Invalid user root from 127.0.0.1 from 10.0.0.1
[1] https://en.wikipedia.org/wiki/Principle_of_least_astonishmen...
Changing SSH to a non-standard port is an inelegant solution and doesn't actually bolster security.
If your environment contains multiple ssh servers running on non-standard ports you would not notice when something out of the ordinary happens.
Something listening to an unexpected port should be something you must look into, not shrug at.
Moving to non-standard means more sophisticated discovery and possibly a more sophisticated attempt.
However, indeed. Minimized log noise is great for analyzing anomalies manually.
it would be if it was meant to be comprehensive.
Likewise for VPN stacks: https://nvd.nist.gov/vuln/detail/CVE-2017-7521
If you're not prepared to expose a service to the world, you probably should run it at all. Ad hoc, non-standard configurations add substantial complexity and maintenance burdens. Complexity is the enemy of security, and having less time to manage more complex configurations is not a good recipe.
If you really need a service, then choose the best one and move on. The rule of thumb is that if you can reach a service, you should assume anybody else can, as well. This is especially true regarding SSH. I've seen plenty of servers p0wned via SSH, but never by breaking SSH. Instead the vector was always through an SSH user's computer infected by malware.
You want secure SSH? Disable password authentication and force everybody to use smartcard authentication like a Yubikey. I do rate limit SSH access using OpenBSD PF, but only because the authentication failures fill up and pollute the logs.
This is not OpenSSL. Language alone does not make a product insecure. For practical purposes it is certainly not just a matter of when.
Contrast that with your VPN product, which probably falls over if someone looks at it funnily. Unless your product is called Wireguard, and we are ten years in the future, perhaps.
I'm not saying decrease your supported algorithms to the point where you break things you're using, but you'd be surprised at how much you can get away with not having and never notice it.
At the end of the day this means all those horrible libssh bots and worms can't even begin an SSH session with you, much less attempt any sort of exploitation or bruteforcing. It still generates an entry in your logs (key exchange algorithm mismatch or the like), but decent syslog daemons can filter out such messages by regexps, and redirect them to another debugging log file that you hardly check unless you're having an issue connecting somewhere. Metalog is an example.
It stopped my logs from getting splattered with failed attempts.
EDITED TO ADD: I wholeheartedly agree with the sentiment though.
I'm of the opinion that if an attacker gets a local account then I'm already hosed given the regularity of local privilege escalation CVE's
Or you could use the standard port, turn off passwords, and wait for the sun to burn out before someone brute forces their way in.
How do you ssh-copy-id without some allowance for passworded logins? Especially if you're doing it from such distant machines that you can't scp over a .ssh/config file.
Sure, I could have puppet push a ~/.ssh/config file everywhere, just seems more effort than it's worth. After all if a hacker wants to know if you are running ssh, it's not hard to scan all ports for ssh.
Why inconvenience yourself more than the attacker?
meh. Just means typing in the port in putty. Pick an easy port - 60k. I can live with that.
Seems like a big inconvenience for minimal extra security. Not like scanning for all open ports that have an ssh listening is hard.
There is a reasonable argument against using tcp for the tunnel instead of udp due to what can happen to latency when you have a tcp inside tcp stream when one or the other or both are dealing with retransmits (bear in mind that tcp has some guarantees about delivery, whereas udp does not).
In theory you can get an exponential stand off instead of linear due to tcp (say RDP or http) in tcp (openvpn). In practice I find that it does not generally matter these days and I can generally stream BBC iPlayer when abroad with minimal fuss over OpenVPN.
https://www.cox.com/residential/support/internet-ports-block...
I actually have the port knock action on a blank website w a unusual subdomain. So we need i it I pull up website and can then vpn in temporaryly
Except no. Less attempts translate directly into less risk.
All attempts have a >zero chance of succeeding. Honestly...struggling to see how this concept is even remotely contentious or how someone could credibly argue against it.
If the number of brute force attempts drops substantially then the chances of success drop too. This is true for a high security setup and a low security setup. In both cases there is going to be a proportionate drop.