There's No Protection In High Ports
bsdly.blogspot.ca
bsdly.blogspot.ca
Not even that. It's like a separate two-byte password because you get to guess and confirm the port separately from the password.
Lengthening your password by N bits multiplies the number of necessary guesses by 2^N. Having a separate N bit password adds 2^N to the number of of necessary guesses. So if your real password's effective key length is more than 16 bits, using a random port effectively adds less than 1 bit of entropy.
Also, rate-limiting port scans is way harder to do than rate-limiting authentication.
No, do not run SSH on a non-default port. It's nothing but an obscurity hack, does little good and breaks a lot of workflows (routers that prioritize port 22 as interactive traffic, firewalls that explicitly allow ssh - on port 22 of course, tools that are awkward to use as soon as you need to use a different port than the _standard_ one).
I admit that I mocked people recommending that practice in the past. That's childish of course, but if the data of this submission is correct I can now add a more serious 'Please do not do that' argument to my list.
I just doubt that a change of port makes sense, I don't claim that it's a amoral or anything. You do it? Yeah, go ahead. Please don't recommend it as 'best practice' is all that I ask for, with both the argument and my condensed workflow examples listing scenarios why this might not be useful.
Yes, you could use fail2ban and ban half the internet, but that just clogs your filtering rules and makes your system waste memory and cycles. Case in point: one of my servers with ssh on port 22 had +9,000 denied IPs over less than one year. On a non-std port, ~100.
There's almost no drawback to using a non-standard port. Everything that uses ssh allow port customization (and I wouldn't trust something that doesn't).
> routers that prioritize port 22 as interactive traffic
Internet routers don't typically do any QoS (except to reduce the priority - bittorrent/etc), let alone prioritize 22. And within your own network, you have control over QoS anyway.
Also, I disagree with the OP:
>...those who have moved their main login service to a non-standard port pay less attention to their logs than the rest of us
I believe it's exactly the opposite. When you're used to carefully inspect your logs on an ongoing basis, you don't want to see it polluted by automated attacks.
Now when you use a non-std port and discover people doing port scans, you'd better pay attention...
My take: If the fail2ban solution bans 9000 IPs - why would you care? If password authentication is disabled (is it?), who cares? What's _gained_ here, except for a potentially smaller log file?
Everything that uses ssh allow port customization
(and I wouldn't trust something that doesn't).
I certainly CAN manage .ssh/config files and reduce that mental overhead a bit. But my argument is that this makes no sense. It - in my world - doesn't buy you security, but might cause mental laps and cache misses that annoy you.
So, I still fail to see a reason to do that..
- Smaller and easier to parse log files
- Less time wasted parsing log files (or creating scripts to filter out automated attacks)
- Less RAM & CPU cycles (particularly important when running low memory VMs)
I still fail to see a reason to NOT do that.
It won't increase your overall security, but it doesn't reduce it either, so why not do it? Just to save you from adding 'alias ssh=ssh -P xx' to your .profile?
Or better yet, add it to your .ssh/config file:
Host myhost
Hostname myhost.com
Port xxxx
Also you don't need to alias - .ssh/config should work more transparently here.
> You can redirect ssh failure messages to a specific log
> file, separate from all others
Or, you can spend time combing through hundreds of invalid messages, trying to separate the wheat from the chaff. Either in one or multiple separate files, it doesn't really matter.
Anyway, not trying to convince anybody here. I respect the opinion that some may prefer to leave everything as the default.
For me, I just vehemently disagree with OP's point that using a non-std port doesn't have concrete benefits and/or reduce the security. To me it's exactly the opposite. At least if you know what (and why) you're doing.
It needs to be pointed out that it is actually worse than that. Guessing a password is O(2^n) on the length of the password. Making the attacker guess a random m bit value before starting to guess passwords is O(2^m + 2^n). To put numbers behind this, a password with 32 bits of entropy has ~4 billion possible combinations, 16 bits of random port + 32 bits of password has 65536 + ~4 billion possible combinations (also known as ~4 billion), while a 34 bit password would have ~16 billion possible combinations.
One could also use port knocking. Using just a single port it would add the 16 bits of randomness making it 32 bits of extra randomness which is significant.
Another advantage of using a different port is that it's often quite easy to detect port scans against a host so an automated tool can easily just block the scanning IP. Slow scans exist but if someone is willing to take that amount of time then there's not much you can do to stop them from eventually finding your service.
I used to fume about 15 years ago. These days, I'm much more zen about this. (or trying to be zen).
Also, I welcome posts like this. I've come to understand that what was once understood by many, may not be when you add 10 or 5 years. For example, the recent HN post from dadgum.com about C's most powerful operator being 'switch'. This is well known. However, maybe there are 17 or 15 year olds who lurk HN. In order for them to learn, they should be exposed to that knowledge.
So, while we are trying to help one another, here is some advice. One really good way to run sshd securely is to use a different operating system other than Linux. This isn't because Linux is bad, it is just that certain decisions were made that will not change. People might extrapolate what I just said too far. Let me illustrate this as a conversation for entertainment.
world says: 'drudru just said don't run linux anywhere'
drudru says: 'Nope. What I'm saying is if you need high security, yet open to the world, sshd install, don't run it on Linux. Run it on an OS and config designed for security. You can still use Linux and other OSs for other things.'
world says: 'Ok, if I do that, how do I ssh to my Linux hosts?'
drudru says: 'Since your sshd host is running not on Linux and it is secure, you can use it to login to your other hosts. You should run it on a static IP address. Then you will only allow ssh in to all your other hosts from that known secure IP and host key. You can have multiple jump machine/static IPs, say 2 on different networks for redundancy.'
world says: 'I've heard OpenBSD was secure. I don't want to learn OpenBSD, FreeBSD, etc.'
drudru says: 'You should just run on Heroku or something equivalent. It will allow you to outsource the entire problem.'
world says: 'I cannot run my Hadoop,Cassandra, etc. on XYZ cloud platform.'
drudru says: 'I am pretty sure you can. There are a lot of new solutions out there if you get a moment to search.'
ALTERNATE ENDING
world asks: 'Can I run sshd on Windows securely?'
drudru says: 'You should just run on Heroku or something equivalent. It will allow you to outsource the entire problem.'
RING RING
drudru says: 'hey, good luck with that. gotta go.'
1. Configure a decent firewall, edit iptables and disable anything you aren't or don't plan to use.
2. Disable root login completely.
3. Install fail2ban just in case and set it to block IPs of failed attempts for 2 to 24 hours
4. Use key based authentication and disable SSH logins using passwords altogether.
I'd recommend going a step further on number 4 and put a strong password on your key. A lot of people believe that key based authentication in and of itself is enough but if you somehow leak your keys and there's no password on them then an attacker has just easily gained access to your machine. Now I'm guilty of not using a password with my keys because like a lot of people it feels like it defeats the purpose but you can actually set things up so that you only need to enter your password once and it won't ask you for it again for a while just like the sudo "grace period" which lets you sudo without a password after you've entered it once. I do plan to give my keys a password and stop being so lazy in the very near future.
I know the Linode library as well as a few posts that have made it to the front page here explain how to do this. Here are the links:
http://feross.org/how-to-setup-your-linode/
http://news.ycombinator.com/item?id=4618808 (Discussion of the above which has some more helpful hints)
When I switched to some other port, they stopped. Less noise in my logs, hurray! Now, if I see something weird in my logs, chances are it's important.
No. Your definition of "security through obscurity" is totally wrong, so your sentence makes zero sense.
If I say: "This server uses port-knocking, you must on three ports between 1..65535 in the correct order before you can attempt to login using SSH on an unknown port"
There is absolutely zero security through obscurity here.
Just as there's zero security through obscurity when someone says: "I've got a server with SSH on port 22 open, you need a login/password to get in". Attackers do not know the login/password but that is still certainly not "security through obscurity".
Just as attackers do not know which three-ports knocking sequence they should use to log in. All they know is that they'll first need to try to find the correct port-knocking sequence amongst the 65536 exp 3 possibilities before being able to try to find the SSH port and then try to force the login/password.
Just as using a random SSH port is certainly not "security through obscurity".
Security through obscurity is when there's a design or an implementation detail that is obscured. Like when a snake-oil vendors creates a "one-password to store them all" website and doesn't say how it's doing the storing / encryption / authentication / etc.
That is security through obscurity.
Saying: "You need to know the secret root password to login" or "You need to know the secret port-knocking sequence before the SSH port shall allow" is not, has never been and shall never be "security through obscurity".
"""
Can significantly increase bandwidth usage for interactive
sessions: It sends data in packets of 1024 bytes, and pads
smaller messages up to this length, so a 1 byte write could
be expanded to 1024 bytes if it cannot be coalesced with
adjacent bytes.
"""
-- https://code.google.com/p/spiped/source/browse/trunk/README
I wonder if there is anything like spiped that provides something similar to openvpn's tls-auth (HMAC auth) functionality, for protocols that already provide encryption.
On one server it's (supposedly) using 192m - but only 5m is resident, the rest is swapped out or unused.
On other 52m virt, but only 4m resident.
All the damn thing needs to do is keep a couple of running counters on a short buffer of IPs and run iptables when limits are met, and a periodic parse of a log file. This feels like something where 64k ought to be enough for anyone, much less 640k!
Sure, we can get by with a fifth of a gigabyte of swap space for this task. Ugh. I've spent too much of my life in debugger CPU views. Jack's quivering tower of abstractions writhes in repulsion.
There's about 200K of source code, but basically all the overhead is the python runtime.
(The memory usage of python doing nothing varied on different machines, but was always virtually identical to the usage of fail2ban.)
Also, the virt usage is mostly large memory mapped logfiles, not actual swap usage.
And for even better security point fail2ban to itself, so that multiple bans result in an even longer 1 week ban.
http://whyscream.net/wiki/index.php/Fail2ban_monitoring_Fail...
- disable passworded logins (only keys)
- ssh bastion host
- decoy ssh honeypot on port 22 (http://www.plainlystated.com/2013/02/ssh-honeypots-dataviz/)
Unless you're logging in from other people's machines a lot that is (where you would need to access your private key from a USB stick) but that's obviously not a good idea anyway.
Now give me one reason why I should actually run sshd on port 22.
* CVS over SSH
* rsync over SSH
* Commercial SSH tunnels
VPNs are a good idea in general if you are doing anything from a public access point that involves logging in.
In terms of security in depth, VPN provides another layer. If someone gets your VPN credentials, all they've done is given themselves a new endpoint, not gained access to any of your stuff.
VPN also protects web surfing, which ssh does not.
One strong layer is better than two weak ones. If you're willing to remember 20 characters, a 20 character ssh password is much safer against these brute force attacks than 10 character VPN password + 10 character ssh password.
(as for non-bruteforce attacks, if someone compromises the VPN software they now have access to your home box without needing a second attack, so it comes down to whether the VPN software is more or less likely than SSH to have bugs - and my impression is that the SSH codebase is possibly the most thoroughly audited in the world)
>VPN also protects web surfing, which ssh does not.
Non-https traffic is going to be unencrypted over the open internet anyway, so I see no harm in it being unencrypted on the cafe network. (And if you're worried about being under surveillance, routing all your traffic via your home internet connection makes that easier than using a variety of public access points).
With the commercial VPN service, you run your own server exactly the same way as before, but restrict ssh access to only your VPN endpoint IP. Now your attack surface is way way smaller. (And your ssh logs are nice and clean.)
> Non-https traffic is going to be unencrypted over the open internet anyway, so I see no harm in it being unencrypted on the cafe network.
It's just so much easier to sniff traffic on unsecured WiFi than anywhere else. Not every site you log into implements https, or implements it correctly, and there are a variety of nasty things that can be done with that.
Think of running a Wordpress blog on your own server...how many people bother to force https for that? But if someone hijacks your Wordpress admin session, they've basically got your whole server.