New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Not really. Password authentication attempts take up CPU, but if you only accept keypair authentication, the client will simply give up straight away (as the authentication method handshake fails, due to no matching authentication mechanisms being available). CPU use will be negligible.
Huh, what are you talking about?
You're missing the point. If you have password authentication disabled, an attacker can bruteforce all they want for eternity, they're not going to get in. The keyspace is simply too big.
Bonus: I had to clean up somebody's VM a few months ago. Weak password, password authentication enabled, SSH running on non-standard port. Got owned within 4 hours of first boot.
So yes, it is pointless, and it is security through obscurity.
Or the developers could have realized the above, and decided not to bother. Completely valid choice.
See above. Four hours.
Then your "sudo account" is still effectively root. Not going to help unless you have a highly unusual username, in which case your username really just becomes part of the password. Might as well just set up keypair authentication.
I really wish people would stop brainlessly repeating this "run SSH on a non-standard port" nonsense, and made an effort to actually understand both how SSH works as a protocol, and security in general.
I agree that changing port should only be the nth step in the ssh hardening checklist.
I still stand by my 'breathing room' argument against zero-days for non-default ports.
Analogy: No tank commander wants to be sans camouflage, at the precise moment when the enemy deploys a one-shot kill LASER in the sky above. Now try imagining ~100 ms reload time for such a thing.
I completely agree with @joepie91's answers. Why using fail2ban and non standard port while disabling password authentication is much better?
Even dumb bots are clever enough to not try bruteforcing what can't be bruteforced (keypair authentication).
Very poor analogy. The "protection" from using a non-standard port isn't even close to that of in-the-field camouflage, and the degree of automatability much higher. They only need to enumerate 65535 ports on an IP prior to the bruteforce, and you're done.
Sorry, but the idea that a non-standard port somehow provides any kind of protection is utter feel-good bull. There's simply no merit to it whatsoever, much like basically every other "security through obscurity" tactic. It's security theater.
If you're already in your attacker's crosshair, then yes, you will fall in minutes with a zeroday+port enum(think state actor level threats).
But for the rest : the 'spray n pray' attackers, enumerating all ports on every host on Internet is not something they optimize for, in the event of a zero-day discovery.
'Defense in depth' works the same way, real world or virtual.
Addendum : I never described my exact layers,nor will I ever.
One of the reasons why I love my Leaseweb VPS (and other providers like Dediserve, RunAbove?, etc) is they have a firewall in their online panel so I just block off port 22 except for my IP and then the bruteforce attempts never reach my server.
Otherwise I just disable passwords and only allow login via ssh keys.
Nice theory, and as I said before, completely falls flat on its face in practice.
Four hours.
The key here is the WEAK password used, the box wasn't owned in 4 hours of first boot because of the port change.
It was owned despite the port change. That was the whole point.
All I'm saying is that with a weak password, what would you expect?
I once had a server with a port change and 16 char password brute forced within 18 hours.
It's obvious that changing port does NOT make your system any more secure, but it will usually make it slower to get the server hacked. But it will end up being hacked nonetheless with a weak password.
Not all passwords are equal. Care to post it here?
change default ssh port, generate a long password with uppercase & lowercase characters etc, install denyhosts. this is good enough in general, in all those years i never had my server's security breached. generally bruteforcing bots only attempt to connect to the default service ports and then afterwards skip to the next target after having scanned the default ports it is interested in - they will most of the time not scan ALL ports because that could cause their IP to be firewalled or takes up too much time, its usually fruitless for them to do so.
thisismypassword (16 chars)
Fake SSH daemons running on 50 different ports. :P
Dunno how well it'd work in practice, but in theory the bot will only have a 1 in 50 chance of brute forcing the correct daemon. Just a little thought I came up with just now.
All this crazy talk about passwords. Disable them, use keys and stick with port 22.
I would rather let you come to my front door and see how secure it is so you know to go away and not come back than encourage you to keep coming back or think I am hiding on another port.
Now this is the first time I've read something that actually makes sense about not changing ports. Some hackers may discard the target altogether when they see they cannot login with passwords.
Unhacked so far by disabling root login
It's fairly simple logic. A bot or individual wants to know quickly if there is a chance they can get into your server with minimal effort. If you straight up tell them no then they give up much quicker.
Most bots will have a go then move on, but some bots/individuals will take some additional time. If you are not on standard port 22 it's a fair assumption your password could still be quite weak but the owner thinks he is safe because you won't look for SSH on port 2200 or 2255 which appear to be the most common alternatives.
I still think it's equal parts laziness and lack of knowledge as to why people do not just disable passwords and use keys.
What if you need to log into your box from elsewhere? Or you lose the keys?
That's something you need to work out. If you see good security as an inconvenience then use passwords.
I have never lost a key in all these years and never been prevented from accessing my boxes from a new location if I really needed to.
There are always ways to solve that. Many of them. Publishing them here would defeat the point of this - we'd be giving attackers another way to enter our boxes.
But having a backup of the key, a backup key (yes, they're different) properly secured
andor an alternative to enter the system (rescue console would do) you're covered.Then you take your keys with you, protected by a strong password, on some kind of portable media.
Then you're going to have fun with the backdoors offered by your provider. My hardware (along with my SSH keys) was seized by police a while ago, and I still have access to my systems.
If sharing those details puts your system at risk, you should close off those avenues right now, because they're security holes. See also here.
If you acknowledge that, then...
at the same time? So no KVMoverIP, no IPMI, no rescue console for OVZ/KVM... you'd have the server at home, or better yet in a bank vault. No... it would go through the bank network, way too risky.
Every online system is a security risk. Every system is prone to 0days, exploits and other vulns. I code PHP myself, audit the code myself, and still for a banking system I would use a 3rd party WAF.
Everyone makes mistakes. Always.
I do not think hiding a system is the way to protect. But you can always reduce the attack surface.
If that's right (and you apply the same rules to your setup) - why do you use a firewall?
Why do you close / open ports? You have nothing to hide, right? Heck, why not leave a normal user account "tom" open with no password? You have made your homework, right? Why should you care if an attacker tries to escalate privileges from a normal account?
Also, I do not want this thread to become the 101 or a extensive list for those with nefarious intentions.
Those who want that already have more than enough resources to "learn".
Nowhere did I say that. Read the linked page again - there should simply be this same requirement of a secret key but (assumed-)known methodology. Kerckhoff's Principle doesn't exclude having two means of access.
You don't do that through "hiding".
This doesn't have anything to do with "hiding". These are technical measures, and being aware of how they function does not change their state.
Because now you have key-less entry?
If this is a concern for you, then your security is already broken.
I really think you need to re-read the page on Kerckhoff's Principle, and understand what it really means (the only secret thing should be the key). The jumps of logic in your replies above have absolutely nothing to do with it.
I'm sure they didn't guess 'gibster', so you're logging in as root, you're just playing with fire with root login enabled.
There's always one last 'key' that needs to exist only in your head.
It could also be a sequence of ordinarily rare events that need to happen in a secret order.
No, it can't be, because humans suck at entropy. This is the same reason as why you need to memorize randomly generated passwords or passphrases, and not try to figure out your own 'complex' password. Humans can't intuitively understand what is 'complex' to a computer.
"Ordered events" are discoverable, and the amount of possible permutations is very limited for cases like these. Especially if the entropy is poor, it's not going to keep you safe.
EDIT: It's fucking 2015. Why are we still having this discussion? Come on.