Port Scanning & Firewalls
Networking: Internet Protocol (IP)
The Internet is a network of computers, or hosts, that exchange messages over connections. Those messages are split into small packets of data (often 1–2 KB), which can be interleaved so the network can be shared between many connections at once. A packet may pass through dozens of intermediate hosts on its way to its destination, and can easily be lost along the way. Internet Protocol (IP) specifies the format of those packets.
Networking: IPv4
Every host has a numerical address, and every packet carries both a source and a destination address. In IPv4 — introduced in 1982 — that address is 32 bits, usually written as four numbers between 0 and 255, such as 192.168.1.2. Addresses are organised hierarchically: all addresses beginning 192.168.1. usually belong to the same local network, and an address ending .1 is often the router or gateway that passes packets on to another network.
Networking: The IPv4 Address Shortage
32 bits is not enough address space for every device now connected to the Internet. IPv6, standardised around 1998, uses 128-bit addresses and largely solves the problem — but adoption has been slow, and many networks either don't support it at all or support both protocols imperfectly. Network Address Translation (NAT) has been the dominant stopgap: networks use private address ranges internally and share a single external IP address, which is also why so many different internal networks end up reusing exactly the same private address ranges.
Networking: DNS
Humans don't want to remember IP addresses, and the computer performing a given role — a company's webserver, say — can change, or be handled by several machines at once. A DNS server turns textual names, like www.example.com, into IP addresses. DNS itself operates over IP, so resolving a name still requires already knowing the IP address of a DNS server to ask.
Networking: TCP — Reliable Connections
IP only guarantees that small packets might be sent; it makes no promise they will arrive, or arrive in order. Most networked applications need to send larger messages reliably, and TCP provides that on top of IP by adding sequence numbers to indicate packet ordering, acknowledging packets as they're received, and resending anything that appears to have been lost. Most high-level applications — a webserver, for instance — can then treat a TCP/IP connection as simply a stream of bytes to read and write, without worrying about any of that machinery directly.
Networking: UDP — Connectionless
Some applications don't need TCP's reliability. They might run on hardware too constrained for TCP's bookkeeping, or need fast responses and prefer to decide for themselves when, or whether, to resend — some online games work this way. UDP sends application messages (datagrams) over IP without any reliability guarantee. DNS is traditionally UDP-based, though a TCP-based fallback has become increasingly common.
Networking: TCP/UDP Ports
When a host receives a network message, how does it know whether to treat it as a request for a webpage, an email, a login attempt, or something else entirely? TCP connections and UDP datagrams carry source and destination port numbers, standardised in the range 1–65535, that identify which networked service a message belongs to. When opening a TCP connection, the destination port specifies the service being requested.
Networking: Port Ranges
Ports 1–1023 are privileged: only an administrator (root) can bind a program to them. This stops an ordinary, unprivileged user from starting, say, a fake SSH server on the standard port and quietly collecting passwords from anyone who mistakenly tries to log in. The source port of an outgoing connection, by contrast, is usually a high port chosen at random purely to identify that specific connection — an ephemeral port. A program that wants to receive connections on a given port listens on it; the operating system then notifies that program whenever a connection arrives.
Port Scanning
Port scanning is the process of probing a host or network to discover which ports are open. An open port means a program on that host is actively listening for connections on it — and because port numbers are broadly standardised, knowing which ports are open tells you a great deal about which services a host is running (email, a webserver, SSH, and so on).
TCP SYN Scan
┏━━━━━━━━━┓ ┏━━━━━━━━━┓
┃ ┣━━ SYN ━━━━━❯┃ ┃
┃ scanner ┃ ┃ target ┃
┃ ┃ ┃ ┃
┃ ┃ ┃ ┃
┗━━━━━━━━━┛ ┗━━━━━━━━━┛
The TCP SYN scan is conceptually the simplest port-scanning technique: the scanner sends only a TCP SYN packet to the target on port n — the packet normally used as the first step of opening a connection — without following through and completing the handshake. Sending a bare SYN packet like this, without the operating system automatically completing a full connection, requires administrator (root) privileges.
Open Port
┏━━━━━━━━━┓ ┏━━━━━━━━━┓
┃ ┣━━ SYN ━━━━━❯┃ ┃
┃ scanner ┃ ┃ target ┃
┃ ┃❮━ SYN/ACK ━━┫ ┃
┃ ┃ ┃ ┃
┗━━━━━━━━━┛ ┗━━━━━━━━━┛
If the port is open, the scanner receives a SYN/ACK in response, confirming both that the target is online and that port n is open; the scanner then sends a TCP RST packet to tear the half-open connection back down. The whole exchange is handled entirely by the target's operating system, without ever reaching an actual application.
Closed Port
┏━━━━━━━━━┓ ┏━━━━━━━━━┓
┃ ┣━━ SYN ━━━━━❯┃ ┃
┃ scanner ┃ ┃ target ┃
┃ ┃❮━━━━━ RST ━━┫ ┃
┃ ┃ ┃ ┃
┗━━━━━━━━━┛ ┗━━━━━━━━━┛
If the port is closed, the scanner receives a TCP RST packet instead — still confirming the target is online, but this time reporting that port n is closed.
Filtered Port
┏━━━━━━━━━┓ ┏━━━━━━━━━┓
┃ ┣━━ SYN ━━━━━❯┃ ┃
┃ scanner ┃ ┃ target ┃
┃ ┃ ... ┃ ┃
┃ ┃ ┃ ┃
┗━━━━━━━━━┛ ┗━━━━━━━━━┛
If nothing comes back at all, the packet may simply have been lost in transit, so the scanner retries. If it still gets no response after retrying, and has independent reason to believe the target is actually online, it concludes the port is filtered — blocked somewhere along the path rather than actively closed.
TCP Connect Scan
┏━━━━━━━━━┓ ┏━━━━━━━━━┓
┃ ┣━━ SYN ━━━━━❯┃ ┃
┃ scanner ┃❮━ SYN/ACK ━━┫ target ┃
┃ ┃━━ ACK ━━━━━❯┃ ┃
┃ ┃━━ RST ━━━━━❯┃ ┃
┗━━━━━━━━━┛ ┗━━━━━━━━━┛
Rather than stopping after the SYN/ACK, a TCP connect scan completes the full handshake — opening a real connection to the target on port n, exactly as if it genuinely intended to talk to the service. This doesn't require administrator privileges, but is slower, and is far more likely to be logged, since the connection now reaches the actual application rather than being handled entirely by the target's operating system kernel.
Nmap
Nmap is the best-known port-scanning tool, supporting many scan types beyond the SYN and connect scans above and highly configurable in how it probes a target [1]. It can also attempt to fingerprint which specific program is listening on a given port: rather than reporting simply "port 80 is open", Nmap can often report "port 80 is open, the webserver is Apache 2.4.52, and the operating system is Ubuntu Linux 20.04."
Why Port Scan?
From an attacker's point of view, a port scan produces a list of the server software running on a target, which can then be checked against published vulnerability databases — running exploit code that, in practice, was very often written by someone else entirely — or simply explored for misconfiguration. From a system administrator's point of view, the same technique is a defensive tool: it shows you what an attacker sees, reveals software running that shouldn't be, and confirms whether your own firewall is actually doing what you configured it to do.
Firewalls
A firewall is a computer, or software running on one, that restricts network access with the aim of blocking unauthorised or unwanted communication — most often to stop attackers reaching potentially vulnerable hosts on a network, but also to stop authorised users leaking data out, intentionally or not. A firewall running as a separate device, rather than on the host it protects, is generally more robust: a compromise of the protected host doesn't automatically compromise the firewall guarding it too.
Stateless Packet Filters
The simplest type of firewall is a stateless packet filter: it looks at each packet in isolation and decides whether to let it through (allow) or block it (deny), with no memory at all of any packet that came before it. The decision is made purely on the basis of that one packet.
Configuring a Firewall
In principle, firewall software could expose nothing more than a function taking a packet and returning true or false for allow/deny, configured by writing that function directly — but this would be needlessly complex and error-prone for most real deployments. In practice, most firewalls are instead configured through a table of rules: easy to reason about, and flexible enough for the great majority of applications [2].
Firewall Rules
A rule-based firewall checks each packet against its rules in sequence, and takes the action — allow or deny — of the first rule that matches. If nothing matches, it falls back to a configured default action:
| # | Proto | Source IP/port | Dest IP/port | Action |
|---|---|---|---|---|
| 1 | TCP | 10.0.0.1 | any | allow |
| 2 | TCP | 10.0.0.* | any : 23 | deny |
| 3 | UDP | 1.1.1.1 : 53 | 10.0.0.* | allow |
| 4 | TCP | any | 10.0.0.2 : 80 | allow |
| default | deny | |||
Connection-Tracking Firewalls
A connection-tracking firewall maintains a table of currently active network connections, rather than judging each packet in isolation. This lets it block packets that violate the TCP standard outright — some operating systems have historically been vulnerable to deliberately malformed TCP packets — and allow "related" new connections through while still blocking faked responses that don't correspond to any real connection. The cost is more memory and processing power, and a real operational risk: under high load, if the connection table fills up, new connections start getting dropped.
Application Firewalls
Application firewalls go a step further and inspect the actual contents of a connection, not just its headers — they can, for example, block emails with attachments, or hold them for manual inspection. This matters increasingly because so many different kinds of application now tunnel over HTTP, which pure port-based filtering cannot distinguish between; an application firewall can, for instance, recognise and block an instant-messaging service that happens to communicate over HTTP. It can also spot application-level attack patterns — a request for a webpage with a suspiciously long parameter, for instance, which could be an attempted buffer overflow — that a stateless or connection-tracking filter would have no way to see. The corresponding limitation is unavoidable: an application firewall cannot inspect the contents of an encrypted connection.
Firewall Policy
Configuring a firewall is a mechanical problem; deciding what policy it should enforce is not. That depends entirely on a specific organisation's actual needs, which services must be reachable, and by whom — and the answer is rarely uniform across an entire network. A webserver might need incoming HTTP requests allowed, but only to itself, not to every host on the network. The standard default is to block everything not explicitly needed, but that default only works in practice if it's genuinely acceptable to the people who have to use the network under it.
Ethical Issues: Port Scanning
Port scanning tools serve attackers and defenders equally well, which raises real, unresolved questions worth sitting with rather than glossing over. Is it ethical to write port-scanning software? To distribute it? To run it against a network you don't own or have permission to test? To restrict its distribution or use by law? And what about using it as part of a deliberate attack — against the infrastructure of an oppressive government or an exploitative company, to expose a corrupt official's secrets, or conversely to monitor a population and detect fraud committed by ordinary citizens? The tool is the same in every case; the answer to whether using it is ethical clearly is not.
Ethical Issues: Firewalls
Firewalls protect a network from attack and help preserve the confidentiality of the data on it — but exactly the same technology can be turned to censoring access to websites a government finds unfavourable, monitoring and recording employees' network traffic, or hiding a criminal network's infrastructure from the police looking for it. As with encryption, the technology itself is neutral; what makes a specific deployment ethical or not is who controls it and what they use it for.
References
- Lyon, G. F. (2009). Nmap Network Scanning: The Official Nmap Project Guide to Network Discovery and Security Scanning. Nmap Project. Freely available at https://nmap.org/book/
- Zwicky, E. D., Cooper, S., & Chapman, D. B. (2000). Building Internet Firewalls (2nd ed.). O'Reilly Media. Covers the rule-table and stateful/application-firewall models described above in much greater operational depth.