21–30 of 192 posts
That was my biggest reason not to bother changing the port.
Is there any real reason beyond that? (I do use fail2ban to block repeated attempts.)
Its kinda silly to move the port, a targeted attack is going to start with an portscan of you box, the attacker is going to say "oh what’s this here on port 2222?" and promptly discover that its ssh listening on a high port. Port knocking would make that discovery less likely I suppose but its still all treating a symptom of a bigger problem. So why not solve the problem with something a little more proactive like tu…
Yes, you have pointed out - a targeted attack. What if non-targeted attack like a robot scanning all port 22 in your datacenter?
Earlier quoted context omitted.
If you have random people spinning up daemons on your servers then you don't have an SSH problem.
UNIX is built as a multi-user operating system. You may not use that ability very much, but there's a reason the operating system was built this way and there's a reason these things work the way they do. It is completely valid to point that out. You're free to say you don't care, but it isn't really valid to brush aside the point by pretending a security model that's there for a reason isn't there. Also it isn't unc…
A young software engineer in today's environment can easily never have any exposure to a truly multi-user OS.
In most cases the dimension is IP range - an automated process moves from IP address to IP address examining port 22 for any common vulnerabilities. Rarely do these processes check all ports. Moving your SSH deamon to a different port prevents those automated processes from then hitting your security layer on whichever port you are running.
The other dimension of attack is when an attacker is focusing on your IP address specifically. Then he probably is going to nmap your IP and discover which port(s) SSH is running on. Changing the default port for SSH doesn't help here, but this use case is far less common.
Like others have said, changing port doesn't remove the need for security measures (cert-based/passwordless login, disable root, fail2ban) but it reduces any of those even being tested in the first place when most of your attempted attacks are IP-range based.
Its kinda silly to move the port, a targeted attack is going to start with an portscan of you box, the attacker is going to say "oh what’s this here on port 2222?" and promptly discover that its ssh listening on a high port. Port knocking would make that discovery less likely I suppose but its still all treating a symptom of a bigger problem. So why not solve the problem with something a little more proactive like tu…
I think you've missed the point. Ultimately, moving the port isn't securing the service but is just one more layer. It won't hold against a focused attacker but will hold against a majority of casual scanners just looking for a large number of SSH targets. The goal isn't to do keys OR move the port. The goal is to combine all the factors at your disposal to disrupt and discourage attacks.
However, it's not hard to imagine these scanners have moved further past the days of the Morris worm and aren't just simple port scanners. Identifying what services are on what ports is a relatively easy process that doesn't remove much from the discovery phase of a bot or script kiddie. Hell, code review metasploit for a half hour and rip theirs out.
Earlier quoted context omitted.
UNIX is built as a multi-user operating system. You may not use that ability very much, but there's a reason the operating system was built this way and there's a reason these things work the way they do. It is completely valid to point that out. You're free to say you don't care, but it isn't really valid to brush aside the point by pretending a security model that's there for a reason isn't there. Also it isn't unc…
In fairness, multi-user linux systems have been losing popularity for a long time, with KVM/xen-based VPS services taking over for having significant advantages in security and software compatibility. A young software engineer in today's environment can easily never have any exposure to a truly multi-user OS.
Even if only one person (or no persons) ever log in, the machine is capable of running processes under multiple users and it is best practice to maintain this so that all users do not share the same level of privilege.
2. Next he talks about this non-root listener issue. He claims that you shouldn’t run your SSH daemon on a non-privileged port because anyone can spin up a daemon up there. Great point, except you can still do that even if you run your main one on 22. I don't think I understand this point at all. What is it that you're trying to say? Are you sure you understood the original post's point? djc@capelis.dj:~$ nc -l -p 14…
If you have random people spinning up daemons on your servers then you don't have an SSH problem.
If a zero-day gets discovered in the kernel that allows the former, you'll be hoping that it isn't also the latter. This is why trusting unprivileged ports is a bad idea.
(...until, you know, we finally start using DNS service-records for this sort of thing.)
Earlier quoted context omitted.
UNIX is built as a multi-user operating system. You may not use that ability very much, but there's a reason the operating system was built this way and there's a reason these things work the way they do. It is completely valid to point that out. You're free to say you don't care, but it isn't really valid to brush aside the point by pretending a security model that's there for a reason isn't there. Also it isn't unc…
In fairness, multi-user linux systems have been losing popularity for a long time, with KVM/xen-based VPS services taking over for having significant advantages in security and software compatibility. A young software engineer in today's environment can easily never have any exposure to a truly multi-user OS.
But maybe I just miss computers where finger, write, wall and talk were all useful commands.
And people say things are more social now? The growth of hypervisors made our operating systems desolate and lonely! :)
Here is something to think about, the author is right, but if you follow many ssh setup tutorials that say to move to say port 25000, you are less likely to be port scanned than the default, but still more likely than if you had used something totally random like say port 42 or 818. By me even writing this clever hackers will start scanning those ports too, just to be sure they are hitting everyone. That being said,…
Basically, there are two classes of people:
1. Those who use port scanners.
2. Those who do not.
If you are being attacked by someone in class 1, then moving your port gives you absolutely no protection. Thus moving your port is only worth anything at all if the percentage of class 2 people is significant.
However, if you also consider the probability a person in each class has of actually compromising your machine, then the security looks less convincing. Yes, it might be true that 95% of people don't bother to use a port scanner, but the most competent hackers are almost certainly going to be in the 5% that do use one.
How about: Why it doesn't matter what port you run SSH on * Because anything but the IP address of your office or VPN connection should be blocked at the firewall level for that port