it cuts down the drive-by noise by 97%. which lets you not overlook anomalies in the remaining 3%.
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.
"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.
> "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.
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.
That's because people can't agree on what is or isn't valuable.
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.
Could additional honey pot on 22 help? Run sshd on non-standard port and honey pot on 22. Then automatically ban all the hosts that would connect to it. There could be a concern for a mistake, so then ban for limited time at first or something.
Additionally having a non-standard port does help defend against 0day exploits before patches are available or before you are able to disable the port.
> 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.
Access behind VPN connection. Or deal with the logs in a better way. If SSH noise bothers you, you can either direct it to a different file, or setup a log aggregator where it's trivial to see what you want (or filter out what you don't by default)
fail2ban will cut down on log noise signficantly, while still allowing you to operate on the standard port. It also thwarts brute-force login attempts, if you're using password authentication. (Which you shouldn't, without good reason. Use public key authentication.)
You control what fail2ban does with said log data and what actually gets logged.
There are better ways than fail2ban of course but it's not the worst solution on the planet.
i think the main argument for leaving it default is [1] for any additional/new sysadmin that has to touch the system. but imo this goes both ways; i'd rather not have my house key hidden under my doormat, where every burglar can check for it in a few seconds. if i taped the key to a random tree branch (even in plain sight), it would be a much safer bet.
If you're going to insist on a security analogy involving keys and doors in the real world, a better one would be that the attacker has to search every single atom of the doormat to find the key. If you have PubKeyAuthentication enabled and PasswordAuthentication disabled, the world will end before the attacker finds your key (in expectation).
Changing SSH to a non-standard port is an inelegant solution and doesn't actually bolster security.
So standardize on a non-standard port, document it and when you do have ssh probes assume it's targeted rather than just another l33t child running du-jour crack(x).
Moving to non-standard means more sophisticated discovery
and possibly a more sophisticated attempt.
One reason is because setting it to a random high port allows non-root users to turn on the SSH server if the admin turned it off. Probably not super likely to happen, but it's possible.
That's really terrible recommendation. You should add firewall rules and allow SSH access only from trusted hosts, ideally over VPN. It's not about login attempts but about possible bug in SSH (and other network services), because it's all just software, written in C, so believe it or not, but it's there, it's not if but when.
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.
OpenSSH is solid piece of software. It hasn't had any (public) authentication bypasses that wasn't configuration related since it started to look like it looks today. Multiple skilled teams have looked at it thoroughly since. It has also been hardened with things like privsep and sandboxing.
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.
It's fallen out of favor these days, but if you're running on firewalls that can be configured for port knocking consider doing that. A non-sequential knock pattern that unlocks the remote IP for X amount of time can prevent a ton of grinding attacks.
Just use a jump server and put the rest of your servers on the private subnet for port 22 inbound. Expose your jump server to your vpn only and use 2fa on vpn.
Also cut down on the host keys (e.g. don't have an RSA/DSA/ECDSA host key if all of your clients support Ed25519 hostkeys) and key exchange algorithms (KExAlgorithms in sshd_config); almost all clients support curve25519-sha256 now, so get rid of all the DH fixed ones. Similarly ciphers; OpenSSH and PuTTY support ChaPoly, so you can get rid of aes-ctr, et al.
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.
This would be detected by SSH, as the host key wouldn't match. (The impersonator wouldn't be able to use the same host key, as they would need the private key, and that requires root privs.)
Or someone can simply own your key holding device as you sip your beverage at the local hotspot or home wifi. Simpler to
go after the secret privileged client than the server.
Do you sync your ssh keys to all the machines you login from?
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.
So, I just ssh to whatever machine I need to work on, but occasionally need to rsync or scp files to/from that server.
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?
Right, but say you have a dozen machines you login from regularly and maybe a few 100 that you login from occasionally. You want to maintain a ~/.ssh/config on all of them?
Seems like a big inconvenience for minimal extra security. Not like scanning for all open ports that have an ssh listening is hard.
If you’re already typing in the full address for the server every time, since you don’t have an ssh config file, then is it really so much more work to additionally type the port?
Yes because I will forget to type -p 5223 at some point. If you set up a non standard port against my recommendation and I get banned for trying 22, you better be on call 24/7 for free to unban me.
I do similar but I personally recommend OpenVPN on 443/tcp rather than 1194/udp. It looks like SSL traffic because that is essentially what it is. Make sure you use your own locally signed CA and certs and enforce CA trust for a successful connection - to avoid any silly MitM tricks.
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.
It's actually very easy to detect OpenVPN on port 443 because it isn't really TLS traffic. Much better to use OpenConnect with ocserv, it opportunistically uses DTLS over UDP on 443, and if it can't do that it can use normal TLS. Much harder detect and gives you the performance boost of UDP when possible.
I have the same , but also have an IP ACL on the VPN ports / protocols (only on new connections). When I do need to Connect from random remote ip , I have a port knocking rule that adds ip for 5min to acl
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
The only benefit of this is clean logs. We had auditd running and the bots blew up our SSH logs. Was so ugly that I killed SSH on all but a single entry point server, which is better security anyways. Then I finally just killed logging failed attempts. Since we use two-factor authentication with a key (you have) + password (you know) I was not very worried about this. Prob should just use something like fail2ban though eh?
Less attempts of something that has zero chance of succeeding (password login against a system that requires keys) doesn't really translate into less risk.
>Less attempts of something that has zero chance of succeeding
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.
