Information Security

Defending the digital infrastructure

iSTOCK/GETTY IMAGES

Problem solve Get help with specific problems with your technologies, process and projects.

Thwart attacks by switching vulnerable SSH daemon to random ports

Switching a vulnerable SSH daemon to a randomly chosen port can slow or even thwart an attacker.

A colleague recently suggested that I move my SSH daemon from TCP port 22 to a randomly chosen port. Does this protect me from hackers? Won't they just find the daemon on that port?

You can change the port if you can easily communicate the new port to your users, and if they can configure their clients to use that new port.

You can easily tell the five users logging in via SSH to one system to use SSH's -p <port> flag. But does this increase security?

Let's consider the case where we change the port number on a potentially vulnerable SSH daemon. We face danger from three main attack classes: worms, script-kiddies and sophisticated attackers.

Worms create havoc because they spread quickly, often taking over most machines on a LAN before security managers can address the first compromise.

What happens if we change our SSH daemon's port from the standard port 22? Well, most worms probe only the standard port when looking for vulnerable machines. Smarter ones might connect to a few ports, say, ports 80, 8080 and 8000 for Web servers. Why don't they scan all ports? Partly because worms tend to be very simple, and attempting to connect to 65,535 ports would slow their progress and generate a lot more traffic. Security managers could detect attacks early and fix infected machines before the worm saturated the network.

A script-kiddie is much like a worm in that he is an unsophisticated attacker made dangerous by automated tools. His tools generally probe one port, or a small set of ports, at a large number of IP addresses. He's focused on scanning as many machines as possible to find vulnerable systems, so he avoids scanning every port. Again, we'd dodge most attacks on our vulnerable daemon by changing its port.

What about the sophisticated attacker? She's not dependent on tools for her attack intelligence -- she understands what she's doing and may even create tools from scratch. Since she can focus only on one site or one machine, she can afford to scan every port. If she wants to expend the effort, she'll find every SSH daemon, even if the port has changed.

If our attacker has to scan 65,535 ports per target machine instead of just one, she's throwing lots of packets at our network and runs a greater risk of detection. To counter this, she might slow down her scan, increasing the delay between probe packets. This delay will decrease her compromise rate and buy us time to patch vulnerable servers. Addressing vulnerabilities before they are attacked is a race -- slowing the attacker gives us better odds of winning.

Or, she might scan fewer ports -- perhaps a few hundred or a thousand. If we choose sufficiently random port numbers, we improve the odds that she won't find our vulnerable daemons.

She might scream, "damn the torpedoes," and scan all ports at full speed. Her compromise rate is still decreased and we still gain an increased chance of detecting her. A well-trained, empowered incident response team might even stop or contain her attack.

Clearly, there's a lot of security upside to changing a port on a server. So, why wouldn't you change the port? First, you can't change the port if any of the firewalls between your clients and the server in question won't allow it. This is fairly uncommon unless they are very restrictive firewalls. Second, you can't change the port on servers where the connecting client can't be easily reconfigured, as in the case of DNS servers. Finally, you can't change the port if you have no easy way to communicate the change to all of your users -- you'll lose in connectivity what you gain in security. If you can avoid these issues, however, changing your SSH daemon to a random port is an excellent way to improve your odds against compromise.

About the author:
Jay Beale is the lead developer of the Bastille Linux project, which creates a hardening script for five Linux distributions, HP-UX and Mac OS X.

Article 8 of 12
This was last published in December 2003

Dig Deeper on Network intrusion detection and prevention (IDS-IPS)

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

Get More Information Security

Access to all of our back issues View All

-ADS BY GOOGLE

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchEnterpriseDesktop

SearchCloudComputing

ComputerWeekly.com

Close