Packets, ports, and protocols

Why it matters

In Networking Fundamentals you learned how data moves: IP addresses get packets to the right machine, ports get them to the right program, and TCP or UDP decides how they travel. This course asks a different question about the same ideas: what can an attacker reach, and what would they do with it?

Defenders call the answer the attack surface: every place where someone outside your control can send input to your systems. On a network, the biggest part of the attack surface is simple to describe. It is every IP address you expose, every port that is listening on it, and every protocol spoken on that port.

The core idea: a listening port is an open door

A program that accepts network connections listens on a port. A web server listens on 443, an SSH server on 22, a database on 5432. Each listening port is a door, and behind each door is software that might have bugs, weak passwords or bad settings.

Three questions turn a port list into a security review:

1. Should this service be running at all? Unused services are pure risk.
2. Who needs to reach it? The whole internet, the office network, or only the machine itself (127.0.0.1)?
3. Is the protocol safe on this network? Some old protocols send passwords in cleartext.

Common ports and what defenders worry about

You do not need to memorise every number, but the ones above appear constantly in logs, firewall rules and certification exams.

TCP and UDP from the defender's side

TCP opens a connection with a three-way handshake: the client sends SYN, the server answers SYN-ACK, the client finishes with ACK. Two security facts follow from this:

• A port scan works by sending SYNs and watching the replies. SYN-ACK means "open", RST means "closed", silence usually means a firewall dropped it.
• A SYN flood sends huge numbers of SYNs and never finishes the handshake, so the server fills up with half-open connections. Operating systems defend with SYN cookies, and providers filter floods upstream.

UDP has no handshake, so the sender's address is easy to forge. Attackers send small requests to open DNS, NTP or memcached servers with a forged source address (the victim's). The servers send much larger replies to the victim. This is an amplification attack, and it is why you should not run open resolvers on the internet.

Worked example: reviewing a server

You manage a small Linux server that should only host a website. On that server you run:

sudo ss -tulnp

-t TCP, -u UDP, -l listening, -n numeric ports, -p show the owning process. Part of the output:

Netid State  Local Address:Port  Process
tcp   LISTEN 0.0.0.0:22          sshd
tcp   LISTEN 0.0.0.0:443         nginx
tcp   LISTEN 0.0.0.0:80          nginx
tcp   LISTEN 0.0.0.0:5432        postgres
tcp   LISTEN 127.0.0.1:6379      redis-server
udp   UNCONN 0.0.0.0:161         snmpd

Read it line by line, asking the three questions:

• 22 (sshd) on 0.0.0.0 means every interface. SSH is needed for administration, but it should accept keys only and, ideally, only from your admin network or a VPN.
• 80 and 443 (nginx) are the job of this server. Keep them, and make port 80 only redirect to 443.
• 5432 (postgres) on 0.0.0.0 is a problem. The database only serves the local website, so it should listen on 127.0.0.1 or be blocked by the firewall.
• 6379 (redis) on 127.0.0.1 is fine: only programs on the same machine can reach it.
• 161/udp (snmpd) was installed by default and nobody uses it. Remove it.

Then make the firewall match the plan, with a default deny rule for incoming traffic and explicit allows for 22 (from the admin range), 80 and 443. The result: three doors instead of six, and each one is there on purpose.

Packets tell stories

Every packet carries a source and destination address, ports, and flags. Defenders rarely read single packets for fun; they look for patterns:

• One source touching hundreds of ports in a few seconds: a port scan.
• Thousands of failed SSH logins from many addresses: a password-guessing botnet.
• An internal machine suddenly sending large amounts of data to an unfamiliar address at 3 a.m.: possible data theft, or "exfiltration".

Watching outbound traffic matters as much as inbound. Malware has to call home, so egress filtering (only letting servers talk to destinations they need) limits the damage of a compromise.

Common mistakes

• Trusting "it's only internal". Attackers who get one foothold move sideways through internal networks. Internal services need authentication too.
• Binding to 0.0.0.0 by default. Many tools listen on every interface unless told otherwise. Check after every install.
• Allow-all firewalls with a few blocks. Default deny with a short allow list is easier to reason about.
• Scanning networks you don't own. Scanning someone else's systems without written permission can break laws such as the US Computer Fraud and Abuse Act, and it breaks most providers' terms of service. Practise only on your own machines or lab (lesson 4.2 covers the rules).

Quick recap

• The attack surface is everything outsiders can send input to; on a network, that means exposed addresses, listening ports and protocols.
• For every listening port ask: should it run, who needs it, and is the protocol safe?
• TCP handshakes explain port scans and SYN floods; UDP's forgeable sources explain amplification.
• Default deny inbound, filter outbound, and keep internal-only services on localhost or private networks.