Securing risky network ports
Data packets travel to and from numbered network ports associated with particular IP addresses and endpoints, using the TCP or UDP transport layer protocols. All ports are potentially at risk of attack. No port is natively secure.
“Each port and underlying service has its risks. The risk comes from the version of the service, whether someone has configured it correctly, and, if there are passwords for the service, whether these are strong? There are many more factors that determine whether a port or service is safe,” explains Kurt Muhl, lead security consultant at RedTeam Security. Other factors include whether the port is simply one that attackers have selected to slip their attacks and malware through and whether you leave the port open.
CSO examines risky network ports based on related applications, vulnerabilities, and attacks, providing approaches to protect the enterprise from malicious hackers who misuse these openings.
What makes these ports risky?
There is a total of 65,535 TCP ports and another 65,535 UDP ports; we’ll look at some of the diciest ones. TCP port 21 connects FTP servers to the internet. FTP servers carry numerous vulnerabilities such as anonymous authentication capabilities, directory traversals, and cross-site scripting, making port 21 an ideal target.
While some vulnerable services have continuing utility, legacy services such as Telnet on TCP port 23 were fundamentally unsafe from the start. Though its bandwidth is tiny at a few bytes at a time, Telnet sends data completely unmasked in clear text. “Attackers can listen in, watch for credentials, inject commands via [man-in-the-middle] attacks, and ultimately perform Remote Code Executions (RCE),” says Austin Norby, computer scientist at the U.S. Department of Defense (comments are his own and don’t represent the views of any employer).
While some network ports make good entry points for attackers, others make good escape routes. TCP/UDP port 53 for DNS offers an exit strategy. Once criminal hackers inside the network have their prize, all they need to do to get it out the door is use readily available software that turns data into DNS traffic. “DNS is rarely monitored and even more rarely filtered,” says Norby. Once the attackers safely escort the data beyond the enterprise, they simply send it through their DNS server, which they have uniquely designed to translate it back into its original form.
The more commonly used a port is, the easier it can be to sneak attacks in with all the other packets. TCP port 80 for HTTP supports the web traffic that web browsers receive. According to Norby, attacks on web clients that travel over port 80 include SQL injections, cross-site request forgeries, cross-site scripting, and buffer overruns.
Cyber criminals will set up their services on individual ports. Attackers use TCP port 1080, which the industry has designated for socket secure “SOCKS” proxies, in support of malicious software and activity. Trojan horses and worms such as Mydoom and Bugbear have historically used port 1080 in attacks. “If a network admin did not set up the SOCKS proxy, its existence might indicate malicious activity,” says Norby.
When hackers get lackadaisical, they use port numbers they can easily remember, such as sequences of numbers like 234 or 6789, or the same number repeatedly, such as 666 or 8888. Some backdoor and Trojan horse software opens and uses TCP port 4444 to listen in, communicate, forward malicious traffic from the outside, and send malicious payloads. Some malicious software that has used this port includes Prosiak, Swift Remote, and CrackDown.
Web traffic doesn’t use port 80 alone. HTTP traffic also uses TCP ports 8080, 8088, and 8888. The servers attached to these ports are largely legacy boxes that have been left unmanaged and unprotected, gathering increasing vulnerabilities over time. “Servers on these ports can also be HTTP proxies, which, if network administrators did not install them, could represent a security concern within the system,” says Norby.
Supposedly elite attackers have used TCP and UDP ports 31337 for the famed Back Orifice backdoor and some other malicious software programs. On the TCP port, these include Sockdmini, Back Fire, icmp_pipe.c, Back Orifice Russian, Freak88, Baron Night, and BO client to name several; examples on the UDP port include Deep BO. In “leetspeak”, which uses letters and numbers, 31337 spells “eleet,” meaning elite.
Weak passwords can make SSH and port 22 easy targets. Port 22, the designated Secure Shell port that enables access to remote shells on physical server hardware is vulnerable where the credentials include default or easily guessed user names and passwords, according to David Widen, systems engineer at BoxBoat Technologies. Short passwords of less than eight characters using a familiar phrase together with a sequence of numbers are far too easy for attackers to guess.
Criminal hackers are still attacking IRC, which runs on ports 6660 through 6669. “There have been many IRC vulnerabilities, such as Unreal IRCD that allow for trivial remote execution by attackers,” says Widen.
Some ports and protocols can give attackers a lot of reach. Case in point, UDP port 161 is enticing to attackers because the SNMP protocol, which is useful for managing networked machines and polling information, sends traffic through this port. “SNMP allows you to query the server for usernames, network shares, and other information. SNMP often comes with default strings that act like passwords,” explains Muhl.
Securing ports, and services and vulnerabilities
The enterprise can protect SSH by using SSH public key authentication, disabling logins as root, and moving SSH to a higher port number so that attackers won’t easily find it, says Widen. “If a user connects to SSH on a high port number like 25,000, it will be harder for the attackers to locate the attack surface for the SSH service,” says Widen.
If your enterprise runs IRC, keep it behind the firewall. “Don’t allow any traffic to the IRC service that came from outside the network. Have users VPN into the network to use IRC,” says Widen.
Repeated port numbers and especially long sequences of numbers rarely represent a legitimate use of ports. “When you see these ports in use, make sure they are genuine,” says Norby. Monitor and filter DNS to avoid exfiltration. And stop using Telnet and close port 23.
Security across all network ports should include defense-in-depth. Close any ports you don’t use, use host-based firewalls on every host, run a network-based next-generation firewall, and monitor and filter port traffic, says Norby. Do regular port scans as part of pen tests to ensure there are no unchecked vulnerabilities on any port. Pay particular attention to SOCKS proxies or any other service you did not set up. Patch and harden any device, software, or service connected to the port until there are no dents in your networked assets’ armor. Be proactive as new vulnerabilities appear in old and new software that attackers can reach via network ports.
Use the latest version of any service you support, configure it appropriately, and use strong passwords; access control lists can help you to limit who can connect to ports and services, says Muhl. “Test your ports and services often. When you have services such as HTTP and HTTPS that you can customize a lot, it is easy to misconfigure the service and accidentally introduce a vulnerability,” explains Muhl; “and change those default SNMP strings.”
Safe harbor for risky ports
Experts publish different lists of ports that carry significant risk based on varying criteria such as the type or severity of the threats attached to each port or the degree of vulnerability of the services on the given ports. No one list is a catch-all. For further investigation, you can start with lists from SANS.org, the internet SpeedGuide, and GaryKessler.net.
This story, “Securing risky network ports” was originally published by CSO.