Ports, Protocols, and Why They Matter for Security

You’ve heard “port 80,” “port 443,” “port 22” mentioned everywhere in security. But what exactly is a port? Why do they have numbers? And why does security care about them so much?

This post completes the networking foundation. After the first post on addressing and DNS, and the second on the request lifecycle, you now have the full picture of how data moves. Here, we zoom into the rules that govern that movement.

What Is a Port?

An IP address gets data to the right machine. A port gets it to the right application on that machine.

Analogy: If an IP address is the street address of an apartment building, a port number is the apartment number. The mail carrier (router) delivers to the building (IP). The mailbox number (port) makes sure it reaches the right tenant (application).

A single server might run:

• A web server
• An email server
• An SSH server
• A database

Each one listens on a different port. When data arrives, the operating system checks the port number and routes it to the correct application.

Port Numbers

Ports range from 0 to 65,535. That’s it. Each is just a number.

Range	Name	Who Uses Them
0-1023	Well-known ports	Standard services (HTTP, SSH, DNS)
1024-49151	Registered ports	Applications (databases, game servers)
49152-65535	Dynamic/ephemeral ports	Your computer picks these for outgoing connections

When your browser connects to a web server on port 443, your computer also picks a random high port (say, 52847) for its side of the connection. The conversation is between your_ip:52847 and server_ip:443.

Ports You Should Know

You don’t need to memorize all 65,535. But certain ports come up constantly in security work.

Port	Protocol	Service	Why It Matters
21	TCP	FTP	File transfer, often unencrypted, frequently misconfigured
22	TCP	SSH	Secure remote access, brute-force target
23	TCP	Telnet	Unencrypted remote access, should be disabled everywhere
25	TCP	SMTP	Email sending, used in spam/phishing infrastructure
53	TCP/UDP	DNS	Name resolution, data exfiltration via DNS tunneling
80	TCP	HTTP	Unencrypted web traffic
443	TCP	HTTPS	Encrypted web traffic
445	TCP	SMB	Windows file sharing, EternalBlue exploit target
3306	TCP	MySQL	Database, should never be internet-facing
3389	TCP	RDP	Windows Remote Desktop, major attack target
5432	TCP	PostgreSQL	Database, should never be internet-facing
8080	TCP	HTTP Alt	Common for web proxies, admin panels, development servers
8443	TCP	HTTPS Alt	Alternative HTTPS port

Security tip: If you see ports like 3306, 5432, or 445 exposed to the internet in a scan, that’s almost always a misconfiguration and a serious security risk.

What Is a Protocol?

A port is just a number. A protocol is the language spoken on that port.

When two computers communicate, they need to agree on rules: how to start a conversation, how to format data, how to handle errors, how to end the conversation. That set of rules is a protocol.

TCP vs UDP

These are the two main transport protocols. Almost everything uses one or the other.

TCP (Transmission Control Protocol):

• Reliable. Guarantees data arrives, in order, without errors
• Connection-based. Three-way handshake before sending data
• Slower. All that reliability has overhead
• Used for: Web browsing, email, file transfer, SSH - anything where missing data is unacceptable

UDP (User Datagram Protocol):

• Unreliable. No guarantee data arrives. No ordering.
• Connectionless. Just fire packets and hope
• Faster. No handshake, no tracking, minimal overhead
• Used for: DNS queries, video streaming, online gaming, VoIP - where speed matters more than perfection

Analogy:

• TCP is like a phone call. You connect, confirm the other person is there, have an orderly conversation, and hang up.
• UDP is like shouting across a room. Fast, but some words might get lost, and you’re not sure the other person heard everything.

Why This Matters for Security

• TCP scans (like nmap SYN scan) rely on the handshake to determine if a port is open
• UDP scans are harder and slower because there’s no handshake to confirm a response
• DNS uses UDP for speed, which makes it easier to spoof (no connection to verify)
• DoS attacks often use UDP because the attacker doesn’t need to establish connections - just flood packets

Application-Layer Protocols

Above TCP/UDP sit the protocols that applications actually use. These define what the data looks like and what it means.

HTTP/HTTPS

The web’s protocol. We covered this in detail in the previous post.

• HTTP (port 80): Plaintext. Don’t use it for anything sensitive.
• HTTPS (port 443): HTTP wrapped in TLS encryption. The standard today.

SSH (Port 22)

Secure Shell. Encrypted remote access to a system’s command line.

ssh user@server.com

SSH replaced Telnet (port 23), which sent everything - including passwords - in plaintext. If you ever see Telnet running on a system, that’s a finding.

Security relevance:

• SSH brute-force is one of the most common attacks on internet-facing servers
• Key-based authentication is much stronger than passwords
• SSH tunneling can bypass firewalls (forward traffic through an encrypted SSH connection)

DNS (Port 53)

Domain Name System. Translates domain names to IP addresses.

Normally uses UDP for speed. Switches to TCP for large responses or zone transfers.

Security relevance:

• DNS traffic is rarely encrypted by default (though DNS-over-HTTPS and DNS-over-TLS are changing this)
• Attackers use DNS tunneling to exfiltrate data - hiding stolen data inside DNS queries
• Monitoring DNS is one of the highest-value detection activities

SMB (Port 445)

Server Message Block. Windows file and printer sharing.

Security relevance:

• EternalBlue (the exploit behind WannaCry ransomware) targeted SMB
• Should never be exposed to the internet
• Often used for lateral movement inside corporate networks

RDP (Port 3389)

Remote Desktop Protocol. Graphical remote access to Windows systems.

Security relevance:

• One of the most targeted services by ransomware groups
• Brute-force attacks against RDP are constant
• Often exposed accidentally through cloud misconfigurations

Port Scanning: Finding Open Doors

Port scanning is how you discover what services are running on a target. It’s the most fundamental reconnaissance technique.

How It Works

The scanner sends a packet to each port and observes the response:

Response	Meaning
SYN-ACK	Port is open - something is listening
RST	Port is closed - nothing is listening
No response	Port is filtered - a firewall is blocking it

Nmap Basics

Nmap is the standard port scanner. You’ll use it throughout your security career.

# Scan the most common 1000 ports
nmap 10.10.10.10

# Scan specific ports
nmap -p 22,80,443 10.10.10.10

# Scan all 65,535 ports
nmap -p- 10.10.10.10

# Scan and try to identify services/versions
nmap -sV 10.10.10.10

# Scan UDP ports (slower)
nmap -sU 10.10.10.10

Important: Only scan systems you own or have explicit permission to test. Unauthorized port scanning is illegal in many jurisdictions.

Reading Nmap Output

PORT    STATE  SERVICE
22/tcp  open   ssh
80/tcp  open   http
443/tcp open   https
3306/tcp closed mysql
8080/tcp filtered http-proxy

From this, you can tell:

• SSH, HTTP, and HTTPS are running and accessible
• MySQL was installed but isn’t accepting connections
• Something on port 8080 is being blocked by a firewall

This is the starting point for almost any security assessment. What’s running? What’s exposed? What shouldn’t be?

Firewalls: Controlling Port Access

A firewall decides which ports accept traffic and from where.

Basic Firewall Logic

Firewalls work on rules:

ALLOW TCP from any to port 443        → Let HTTPS traffic in
ALLOW TCP from 10.0.0.0/8 to port 22  → SSH only from internal network
DENY  TCP from any to port 3306       → Block database from outside
DENY  all                              → Block everything else

Rules are processed top to bottom. The first match wins.

Egress Filtering

Most organizations focus on ingress filtering (what comes in). Fewer restrict egress (what goes out).

This is why reverse shells work. A firewall might block all inbound connections but allow outbound connections on ports 80 and 443. An attacker’s reverse shell rides that allowed outbound path.

Good security practice: Filter both directions. If a server only needs to reach a database and a few APIs, restrict its outbound connections to only those destinations.

Try It Yourself

Safe exploration commands - run these on your own systems:

# See what ports are open on your machine
ss -tlnp        # Linux (TCP listening)
ss -ulnp        # Linux (UDP listening)
netstat -an      # Windows/Mac

# Scan your own machine (localhost)
nmap 127.0.0.1

# Check what a remote server exposes (use a server you own)
nmap -sV your-server-ip

# See what established connections exist
ss -tnp         # Linux
netstat -an | grep ESTABLISHED  # All platforms

What’s Next

With networking covered, you now understand:

• How devices find each other (IP, MAC, DNS)
• How connections work (TCP handshake, TLS, HTTP)
• How services are organized (ports) and how data is structured (protocols)
• How to discover what’s running (port scanning)
• How access is controlled (firewalls)

This is the foundation everything else builds on. When we cover Linux fundamentals, you’ll use these concepts. When we get to web vulnerabilities, you’ll understand where they fit. When we discuss reverse shells, you’ll know exactly why they work.

The networking module is complete. Up next: the operating system.

References

• IANA - Service Name and Transport Protocol Port Number Registry
• Nmap Documentation
• Cloudflare - TCP vs UDP

---

Ports are just numbers. Protocols are just rules. But knowing which numbers and which rules is the difference between finding the vulnerability and missing it entirely.