What Is This TCP or UDP Port

While working with firewalls, IDSs/IPSs, sniffers, or Threat Hunting tools like AC-Hunter we’ve commonly seen references to TCP and UDP port numbers. The challenge is interpreting these to decide if the traffic over them is benign/necessary/serving a business purpose or malicious/unwanted/should be blocked.

We wanted to go over some of the more common ones so you could start with an educated guess and know what to look for next.

Before we begin, remember that simply going over a certain port does not mean that the traffic is of a certain type. While TCP port 22 is commonly used for SSH, I may see packets on TCP 22 that aren’t SSH and SSH can be carried over any TCP port. The “Normal Usage” notes below don’t guarantee that traffic on a given port must be this type.

 

TCP

 

Port 21/TCP

Normal usage: FTP (file transfer, unencrypted)

Note that FTP is one of very few protocols that use more than one port. 21/TCP is used for the control channel – the client and server talk over this port and when the client is ready to upload or download a file or directory, the client and server discuss what port number they want to use for the data channel for this single transfer.

Since this causes no end of headaches for firewalls that now have to parse the control channel to see what additional ports have to be opened up for data – and FTP is unencrypted – this is waning in popularity; HTTPS is more commonly used for downloads.

 

Port 22/TCP

Normal usage: SSH (terminal traffic, file transfers, port and X-Windows forwarding)

Commonly used by: Admin workstations, Linux, Unix, Mac (and to a slightly smaller degree, Windows) systems, routers and network devices. Attackers will sometimes try to guess passwords by connecting over and over again with different passwords; see your system logs for failed login attempts to see these.

Note that the SSH protocol commonly carries terminal traffic (keystrokes and screen updates) for SSH sessions and file transfers (via SCP, SFTP, and rsync-over-SSH). However, it can carry any TCP traffic tunneled inside its encrypted session with port forwarding. It can also carry non-TCP traffic by setting up a VPN inside an SSH connection. There’s almost no limit on what might actually be using that encrypted link, so allowing SSH across your perimeter – on any port, not just 22 – makes it almost impossible to effectively enforce perimeter security.

 

Port 23/TCP

Normal usage: Telnet (terminal traffic, unencrypted)

Telnet is largely replaced with SSH as SSH offers all of the features of telnet and is encrypted. It may still be used with very old equipment that does not offer SSH terminal connections.

 

Port 25/TCP

Normal usage: SMTP (outbound email) traffic. This is unencrypted – for the encrypted version, see 465/TCP

Inbound port 25 traffic may be blocked by one’s ISP; this policy came in response to spammers using unprotected SMTP servers to relay spam.

 

Port 53/TCP

Normal usage: unencrypted DNS requests

Note that most DNS happens over port 53 UDP; this is reserved for large answers and Zone Transfers between DNS servers. Most of your traffic will be over 53/UDP, and some sites unconditionally block 53/TCP at the border with a firewall or router.

 

Port 80/TCP

Normal usage: HTTP (Web) traffic. Specifically, this is unencrypted web traffic – see 443/TCP for encrypted web (HTTPS) traffic.

Commonly used by: any web browser on any operating system. It’s also used by applications to connect to web services. Note that HTTPS is more prevalent; it’s more secure in that it can’t be modified or read in between the client and server.

 

Port 179/TCP

Normal usage: BGP. This is used to transfer routing changes between larger routers (and is not commonly used for routers at a home or small business where there’s a single Internet connection).

Both ends of a BGP connection are almost always routers – the only exceptions should be workstations attempting to monitor and analyze routing changes.

BGP is not encrypted.

 

Port 443/TCP

Normal usage: HTTPS (encrypted web) traffic.

 

Port 465/TCP

Normal usage: SMTPS (outbound email)

 

Port 5000/TCP

Normal usage: unencrypted uPNP conversations (not broadcast like 1900/UDP)

 

Port 5355/TCP

Normal usage: local network unencrypted DNS (“LLMNR” stands for Link-Local Multicast Name Resolution).

 

 

UDP

 

Port 53/UDP

Normal usage: unencrypted DNS

 

Port 443/UDP

Normal usage: Quik (encrypted web) traffic.

 

Port 1900/UDP

Normal usage: unencrypted uPNP broadcasts. These should have destination IP 239.255.255.250 .

 

Port 5353/UDP

Normal usage: local network multicast unencrypted DNS.

 

Port 5355/UDP

Normal usage: local network unencrypted DNS (“LLMNR” stands for Link-Local Multicast Name Resolution).

 

 

Confirming the Traffic

We can only discuss traffic that will normally be using a given port. In almost any case a given protocol (like HTTP) that runs on a standard port (like 80/TCP) can absolutely run on any of the other ports from 1-65535 (such as running a test or development web server on port 8000/TCP).

To confirm what’s actually running on a port, we’ll want to watch some of that traffic. Start up a sniffer program on one end of the connection. When you tell it to start capturing traffic, include a filter for just the port you care about (see the “BPF” section of https://www.activecountermeasures.com/improving-packet-capture-performance-1-of-3/ ).

Here’s where Wireshark (or its text-based/console/terminal based counterpart, tshark) shines. In addition to showing you the basic details of the packet, Wireshark tries to interpret the payload, giving you its best guess on what protocol is actually using that port instead of simply guessing based on the port number.

A second approach is to watch the traffic with Zeek. In addition to reporting the port used, Zeek will show the actual protocol being used by that traffic for many common traffic types. Here’s the relevant section of a line from Zeek’s conn.log:

...10.0.0.111 57345 216.146.43.70 80 tcp http...

Zeek is able to parse the traffic inside that connection and verify that not only is it traveling over port 80 but that it also looks like valid http traffic.

AC-Hunter can use this information provided by Zeek to show the protocol in the connection details:

 

What Program Is Communicating on That Port?

If you have command line access to a system – either the client or the server in a connection – you can ask for a list of programs communicating on a given port. In this example we ask for a) servers listening on port 25 and/or b) clients or servers with an open connection using port 25 on either end:

The “LISTEN” means both of these are servers waiting for incoming connections on port 25. Because the IP addresses on which these are respectively listening are 127.0.0.1 and ::1 , only processes on this actual system can talk to the exim4 mail server (the “851” before “/exim4” is the process ID of the running mail server). Connections coming from other computers, whether on this lan or not, will only find a closed port 25.

In this second example we ask for all connections whose port numbers start with 53 :

The first 5 lines show the Bro application with 5 separate client connections to a known DNS server, Comcast’s 75.75.75.75 . The final 3 lines show the avahi-daemon program with 2 “listening” ports for incoming queries (the port 5353 ones) and one “client” port (53169) to make outgoing queries of its own. These are quoted since UDP doesn’t have a strict separation between a port being used as a server (waiting for incoming queries, commonly on a well-known port like 5353) and as a client (a high numbered port through which queries can be sent to other servers).

 

Glossary

Client: System initiating a conversation.

Server: System listening on the port in question, ready to accept connections from a client.

Peer: System listening on a UDP port that can either start talking to another system listening on that same port, or accept incoming traffic from another system.

 

References

Alternative DNS Techniques