Firewall

The moment a server is reachable from a broader network, it becomes reachable by both legitimate and unwanted traffic. A web service may need to expose port 443, but a database port or management port exposed in the same way becomes an obvious attack target. The difficult question is rarely 'open or closed' in the abstract; it is which sources, destinations, protocols, ports, and directions should be allowed under what conditions. Without explicit control, networks become too permissive to be safe or too restrictive to be usable. A firewall exists to make those traffic boundaries concrete instead of implicit.

In the early internet, many environments were small enough and trusted enough that strict boundary filtering was less central. As networks commercialized and hostile traffic became normal, operators needed a first line of defense at the network edge. Firewalling became that boundary discipline. In cloud environments, the same idea now appears in software-defined forms such as security groups and network ACLs rather than only in physical appliances. The key idea that survived the transition is not the box itself, but the principle that network reachability should be declared intentionally rather than assumed. Modern infrastructure keeps rediscovering that principle because growth without explicit traffic boundaries quickly becomes operationally dangerous.

A firewall evaluates traffic against rules built from attributes such as source IP, destination IP, protocol, port, and in many cases connection state. Matching traffic is allowed, denied, or otherwise handled according to policy, while unmatched traffic is usually subject to a default action. Stateful firewalls add practical intelligence by recognizing whether a packet belongs to an already permitted connection, which reduces the need for awkward mirrored rules. That is why the common security pattern is default deny with explicit allow rules rather than broad openness with scattered exceptions. A firewall is therefore not just a blocker; it is a way of translating intended network relationships into enforceable policy.

Firewalls and WAFs both filter traffic, but they inspect different layers and therefore solve different problems. A firewall typically reasons about network and transport details such as IP addresses, ports, directions, and protocols. A WAF assumes HTTP traffic and inspects request semantics such as URLs, headers, cookies, and query strings to identify application-layer attacks. Exposed database ports and subnet boundary control are firewall problems; malicious input in a web form is a WAF problem. Both can matter in the same architecture, but they should not be treated as interchangeable just because they both 'block bad traffic.'

Firewalls are a strong fit for limiting exposed ports, separating public and private subnets, constraining management access, and controlling which networks may talk to which systems at all. They are most effective when dependencies are fairly clear and the allowed communication paths can be described precisely. The difficulty comes later, when temporary exceptions accumulate and the ruleset no longer matches reality. That is why least privilege and policy-as-code practices matter so much: they keep the rule set understandable and reviewable. A good firewall posture is not the one that blocks the most traffic, but the one that leaves only the intended traffic paths open and makes those paths explicit.