The core idea
A firewall is a checkpoint. Traffic arriving at it is compared against a list of rules, and each rule says to allow or block matching traffic. The firewall does not understand what you intend; it only applies the instructions it has been given. Good filtering is therefore mostly a matter of writing clear, minimal instructions.
Firewalls take different forms. Some are software on a single computer, some are features of a home or office router, and some are dedicated appliances at the boundary between networks. The principle is the same in each.
What a rule looks at
At the simplest level, a rule matches on a few attributes of a packet:
- the source address
- the destination address
- the protocol, such as TCP or UDP
- the port number, which identifies the kind of service
- the direction, inbound or outbound
A rule might say, in words: allow traffic from the internal network to any destination on the port used for secure web browsing. Another might say: block everything arriving from outside that was not asked for.
Ports are numbered doors. A web server listens on particular ones, mail servers on others. Blocking a port closes that door for the traffic types that use it.
Rule order and default behavior
Most firewalls check rules from top to bottom and apply the first match. This makes order important. A broad “allow all” placed above a narrow “block this” means the block never takes effect.
If nothing matches, the firewall falls back to a default policy:
- Default deny blocks anything not explicitly permitted. It is generally considered the safer approach because new, unexpected traffic is stopped until someone decides it is needed.
- Default allow permits anything not explicitly blocked. It is easier to run but relies on you foreseeing every threat.
Many organizations use default deny for inbound traffic and a more permissive but still reviewed policy for outbound.
Stateful inspection
Early packet filters judged every packet in isolation. Modern firewalls are usually stateful: they remember connections. When an internal laptop opens a connection to a web server, the firewall records it and automatically allows the matching replies. Unsolicited packets from outside that do not belong to any known connection are dropped.
This is why you can browse freely from behind a firewall without writing a rule for every reply, and why outsiders cannot simply start a conversation with an internal machine.
Inbound and outbound
Inbound rules control what the outside world can reach. Typically very little should be exposed, and each opening deserves a reason, an owner and a review date. Outbound rules control what internal devices can reach. These are often left loose, but tightening them can limit damage when something goes wrong, for example by preventing a compromised device from contacting unknown servers. This overlaps with ideas from incident containment, where limiting a device’s reach is a first step.
Network address translation and the firewall
Routers that share one public address among many devices implicitly block unrequested inbound connections, since they do not know which internal device should receive them. People sometimes mistake this for a full firewall. It provides some protection, but explicit rules are clearer and more controllable.
Segmenting with firewalls
Firewalls are not only for the internet edge. Placed between internal subnets, they can restrict which groups talk to each other. Guest Wi-Fi might be allowed to reach the internet but not internal file servers; cameras and other Internet of Things devices might be allowed to reach only their recorder. Dividing a network this way, as described in the guide to subnet masks, makes such rules easy to express.
Beyond ports and addresses
Some firewalls inspect more than headers. They may identify applications, filter by website category, scan for known malicious patterns or terminate encrypted sessions to look inside. These features can be useful but add complexity, performance costs and privacy considerations, and the effectiveness varies. Encrypted traffic is harder to inspect, which is part of why data encryption in transit is a double-edged topic for defenders.
What a firewall cannot do
It helps to be realistic:
- A firewall cannot stop a user from willingly running a malicious attachment that arrives by allowed email traffic. Phishing and social engineering work through permitted channels.
- It cannot fix weak passwords or missing multi-factor authentication.
- It does not remove software flaws, which is the job of patch management and vulnerability scanning.
- It sees only traffic that passes through it. Devices on a different connection, or traffic inside the same subnet, may bypass it.
A firewall is one layer in a layered defense, not a complete answer.
Looking after the rules
Rules tend to accumulate. A temporary exception made for a project can stay for years. Habits that help:
- Give every rule a comment explaining why it exists and who requested it.
- Review the list periodically and remove what is no longer needed.
- Treat changes as formal requests, using change management, so there is a record and a way to roll back.
- Keep logs of blocked and allowed connections, then actually read them. Reading system logs can reveal scans, misconfigurations or a service that has silently stopped working.
- Back up the configuration so a failed device can be replaced quickly.
A simple starting policy
For a small office, a sensible starting point is: block all unsolicited inbound traffic, allow established return traffic, allow staff devices to browse and send mail, keep guests separated from internal systems, and open nothing else without a documented reason. From there, adjust to the real needs of the organization, and test after every change.