Any Port in a Storm: Ports and Security, Part 1

Whether it’s on Windows…

While on most Unix/Linux systems (e.g. MacOS, BSD, and Linux variants) the file is located at:

…Or on your preferred Unix/Linux/BSD variant, the services file helps define what services and network application protocols typically run on which port, and/or whether or not the services runs on TCP, UDP, or both.

This file helps the operating system and its applications define what ports and what transport protocols are used to contact a particular network service. But how did these network services get assigned, and under whose authority?

Port Authority

Most network services are assigned an official port number courtesy of the Internet Assigned Numbers Authority (IANA):

• Ports 1 through 1023 are considered “Well-Known” ports and are specially assigned. 
• Ports 1024 through 49151 are considered “Registered Ports.” When a company asks for a port number for their network application, those port numbers will usually be assigned in those ranges. 
• Ports 49152 through 65535 are considered private or ephemeral ports that are for temporary use. 

If you want to see a list of all the services that are officially and/or unofficially registered to a given port number, Wikipedia is actually one of the better sources for that information.

Here’s the thing though: while those port number assignments may be official to the IANA, they’re suggestions to everyone else. 

With the exception of the well-known ports, there is next to nothing that will prevent users from running their service on a different port–whether that be through a software configuration the network service supports, a reverse proxy, or through the use of a network address and/or port address translation device or service, most TCP and UDP port numbers are fungible: you have the power to re-assign them at will. The only thing different about the well-known set of ports is that most Unix and Linux operating systems require superuser (read: root/sudo) privileges to assign a network service to a port number in that 1-1023 range. That’s it. 

Right now, I could re-assign the port numbers for all of my Linux VMs running SSH to a random port using the /etc/ssh/sshd_config file on each system. The only thing I’d have to do after that is to tell my ssh client to contact the SSHD service on those virtual machines on the specified port (for example, the ssh command-line client has the -p option. So for example, ssh -p 2222 [email protected] will attempt to connect to the ssh service on foo.example with the username of user on port 2222/tcp). 

The only reason most don’t change their port numbers is because having those defaults is convenient and requires no further thought. The network client already knows what port to talk on, so there’s no need to try and reconfigure it further.

Batten Down the Hatches

This fungible nature of network ports and the ability to reconfigure software to accept port connections other than a service or network protocol’s default or registered ports has led to a game of cat and mouse for network security professionals and adversaries over the years. 

Now, let’s talk about firewalls and network intrusion detection software. 

As most know, firewalls provide access control and segmentation. They let us define what traffic we want to allow and what traffic we want to reject. They define boundaries between your network and the internet, between the engineering department and the marketing department, and so on. 

For the most part, traditional firewalls have controlled what traffic is and is not allowed between segments through a few criteria:

• Source and/or Destination IP address
• Network Protocol (e.g. TCP, UDP, ICMP, etc.)
• Port numbers (if the network protocol is TCP and/or UDP)

As an example, if one wants to block DNS traffic to the IP address 8.8.8.8, the firewall rule would generally look something like:

On the other hand, maybe an allow rule to allow RDP traffic to 10.10.10.10 from IP address 10.1.1.1 would look like:

The most obvious question for firewall block rules would be: What happens if I choose to host the network service on a different port? 

Fortunately most firewall vendors came up with a pretty smart (if a little lazy) solution called the “default deny any.” That is, if there is no firewall rule that explicitly allows a connection, then by default it is denied. 

Note that some firewall software implements the opposite of this solution called default allow any–most of the time, it’s implemented on host-based firewalls in order to prevent massive headaches with regards to network troubleshooting. 

That’s all well and good for firewall software, but most netflow software and/or network intrusion detection/prevention software didn’t have that luxury. So, they relied on users to define the ports they were expecting network application protocols and services to be communicating on in order to correctly log the type of connection or to trigger IDS rules correctly. 

For an example of this, I’m going to pick on Snort–specifically the 2.x (or older) versions of Snort, since things have changed a bit with Snort 3 (we’ll be getting to this in a minute). 

Snort.conf used to be the main configuration file for Snort, and one of the first things users had to check were a set of variables that define home and external IP addresses as well as variables that define what ports various services were expected to run on. As one might expect, this is easier said than done.

Because of course you know all of the ports that your business, users, and attackers are going to use for various network protocols.

In recent years, firewalls and network security devices have gotten a little bit smarter. In addition to defining firewall rules, traffic analysis, and/or IDS rules based on port numbers and IP addresses, many of these tools began to include protocol parsers. A protocol parser is a piece of software that can be used to detect network applications and protocols regardless of the TCP or UDP port their traffic is observed on. The integration of these parsers as well as the integration of firewall, IDS/IPS, and network analysis software onto a single platform gave birth to “Next Generation” firewalls and/or IDS/IPS. 

For an example of a software that includes protocol parsers, I’m going to pick on another IDS/IPS suite, Suricata, next. 

In addition to being able to define IP address ranges and port variables, Suricata allows its users to define detection rules based on the network service protocol, referred to as Layer 7 Protocols. Some examples include http, nfs, and rdp. There is a whole host of layer 7 protocols that Suricata supports. In general, the ability to define firewall and/or IDS/IPS rules by the network service’s protocol, regardless of the TCP or UDP port it is running on, is a game-changer. Now, instead of defining IDS rules or firewall rules based on TCP or UDP port numbers, security engineers can define rules based on the protocol parsed, or the service detected.

On to Metadata

In addition to protocol parsers, some firewalls and/or modern IDS/IPS solutions rely on collecting metadata about connections in order to be able to identify the service. Metadata about network connections may include destination ports numbers, number of packets transferred, IP addresses or DNS domains the client communicated with, SSL certificate details from HTTPS conversations, and many more details. From this metadata, an intelligent guess is made to determine the service a client is communicating with. 

Why is this necessary? Because now, more than ever, there are several services and applications that overlap and use the same service port, with port 443/HTTPS being the biggest offender. 

For example, many streaming services like Twitch.tv, Hulu, and Netflix are viewable in a web browser–and all communicate over HTTPS. Many chat programs such as Discord or Slack have web-based HTTPS clients and/or communicate over HTTPS. DNS over HTTPS relies on HTTPS communication and is the default DNS service for the Mozilla Firefox web browser. 

All of these services using port 443 and the HTTP protocol for their communication makes them exceptionally hard to set limits and boundaries for if all you have are firewalls or IDS/IPS appliances that identify services by port number. In many cases, these design choices are intentional to make the services easier for consumers to access without worrying about poking holes in their firewalls–or they are intentionally designed to be harder to block in order to get around internet censorship.

For examples of software that attempts to perform network service detection, check out Snort 3’s openappID, or for a more enterprise example, palo alto next gen firewalls rely heavily on application detection.

In Conclusion

In this lesson, we learned what a port number is and how it’s used to define and identify the various network services we interact with on a daily basis. 

We also learned that the Internet Assigned Numbers Authority defines a set of TCP and UDP ports and their designated services, but that ultimately, users with the proper authorization can redefine them at will. This has resulted in a cat and mouse game when it comes to evading network security appliances such as IDS/IPS and firewalls, but this is overcome through the use of protocol parsers and application detection through metadata analysis. 

Stay tuned for part two of this series, where we’ll learn more about the network security implications for service port numbers and how they impact network forensics, penetration testing, and vulnerability management.