Firewall Explained: How It Actually Secures an Organisation

What a firewall really is

A firewall is a network security system that enforces a policy on traffic flow. At its simplest, it inspects packets as they cross a network boundary and decides whether to allow, drop, log, or redirect them based on rules. The real value is not the blocking itself, but the explicit definition of what should be allowed — everything else is denied by default.

Firewalls operate at multiple layers of the OSI model. Some look only at IP addresses and port numbers (Layer 3/4). Others inspect the actual application payload, such as HTTP headers, JSON bodies, or DNS query names (Layer 7). The modern expectation is layered inspection: a packet is checked at the network layer, then the transport layer, and finally the application layer before it is trusted.

Where firewalls sit in the stack

Firewalls are not a single point product. They are a design pattern that appears wherever trust boundaries exist. The most common placement is between the public internet and the corporate network, but that is only the outermost layer. Internal firewalls separate departments, production from staging, databases from application servers, and user devices from operational technology.

Each layer has a different purpose. The perimeter firewall filters broad traffic categories. The DMZ hosts services that must be reachable from the internet but cannot be trusted with internal data. The internal firewall restricts lateral movement, so a compromised endpoint cannot freely scan every subnet.

Types of firewalls

Packet-filtering firewall

The earliest form. It inspects individual packets against static rules: source IP, destination IP, protocol, source port, and destination port. It is fast and cheap, but it has no memory of previous packets. A packet-filtering firewall cannot tell whether an inbound packet is a genuine response to an outbound request or an unsolicited scan.

iptables -A FORWARD -s 192.168.0.0/16 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -p tcp --dport 443 -j DROP

Stateful firewall

A stateful firewall tracks the lifecycle of connections. When an internal host sends a TCP SYN packet to a web server, the firewall records that connection in a state table. Return traffic matching that state is allowed automatically. This means outbound connections work without writing explicit rules for every return path.

UDP and ICMP are connectionless, so stateful firewalls approximate sessions using source/destination pairs and timeouts. A DNS query to 8.8.8.8:53 creates a temporary permit that expires after a few seconds if no response is seen.

Proxy firewall (application-layer gateway)

A proxy firewall terminates the connection from the client and opens a new connection to the server. Because it sits in the middle, it can inspect the full application payload, strip malicious content, and enforce protocol correctness. A web proxy can block file uploads by type, rewrite headers, or authenticate users before forwarding requests.

• Strong inspection because it understands the protocol.
• Introduces latency and becomes a single point of failure.
• Must support every application it mediates; unsupported protocols break.

Next-Generation Firewall (NGFW)

NGFWs combine packet filtering, stateful inspection, intrusion prevention (IPS), application awareness, and user identity into one device. Instead of saying “allow TCP/443,” an NGFW can say “allow Slack traffic for authenticated users in the Engineering group.” This is a shift from port-based rules to identity and application-based rules.

Web Application Firewall (WAF)

A WAF is specialised for HTTP/HTTPS traffic. It protects web applications from attacks like SQL injection, cross-site scripting (XSS), and request forgery. WAFs can run as hardware, software, or cloud-native services in front of load balancers. OWASP maintains a core rule set that most WAFs support or extend.

Cloud-native firewalls

Cloud providers offer firewalls as virtual constructs: AWS Security Groups, Azure NSGs, and GCP Firewall Rules. These act at the instance or subnet level and are stateful by default. They are defined by code, versioned with infrastructure, and tied to identities rather than physical ports.

{
  "IpProtocol": "tcp",
  "FromPort": 443,
  "ToPort": 443,
  "IpRanges": [{ "CidrIp": "203.0.113.0/24", "Description": "Office" }]
}

How firewall rules work

Rules are evaluated in order, usually from top to bottom. The first matching rule wins, and a final implicit deny catches everything else. This makes rule ordering critical: a broad “allow any” placed above a specific “deny malware” rule will silently bypass the deny.

1. Define the source — a single IP, a subnet, a country code, a user group, or a service identity.
2. Define the destination — a host, a network segment, or an application endpoint.
3. Define the service — protocol, port, application signature, or API path.
4. Choose the action — allow, deny, drop silently, reset, log, or redirect.
5. Assign an identity — who can use this rule, and under what conditions.

object-group network OFFICE
  203.0.113.0/24

object-group network WEB_SERVERS
  10.0.1.10/32
  10.0.1.11/32

access-list OUTSIDE_IN extended permit tcp OFFICE WEB_SERVERS eq 443
access-list OUTSIDE_IN extended deny ip any any log

How a firewall secures an organisation

Security is never a single product. Firewalls are one layer of a defence-in-depth strategy. Their contribution to organisational security can be grouped into four areas.

1. Reduces the attack surface

Every exposed port, protocol, and service is a potential entry point. A firewall hides everything that does not need to be reachable from the internet. If a server only needs to serve HTTPS on port 443, the firewall blocks all other ports at the perimeter, including management interfaces like SSH and RDP.

2. Controls inbound and outbound traffic

Inbound rules protect against external attackers. Outbound rules are equally important: they stop compromised internal hosts from phoning home to command-and-control servers, exfiltrating data, or using unauthorised cloud services. A good outbound rule set only allows traffic to known destinations.

3. Enforces segmentation

Segmentation limits how far an attacker can move after breaching one system. If a developer laptop is compromised, a segmented network prevents that laptop from directly reaching the production database. Segmentation is enforced by internal firewalls between VLANs, subnets, or micro-segments.

4. Provides visibility and logging

Modern firewalls generate rich logs: who connected, when, from where, to which application, and how much data moved. This feeds SIEM tools, anomaly detection, and incident response. A firewall that silently drops everything is less useful than one that logs dropped attempts and unusual patterns.

Perimeter vs segmentation vs zero trust

The classic “castle and moat” model puts a strong firewall at the perimeter and trusts everything inside. That model failed because insiders can be compromised, and perimeters became porous with VPNs, cloud services, and remote work.

Zero trust does not mean removing firewalls. It means every access decision — by a user, a device, or a service — is authenticated, authorised, and continuously evaluated. Firewalls become the enforcement points for those decisions, not the source of trust.

Web Application Firewall (WAF) in depth

A WAF is a firewall for HTTP semantics. It inspects the request line, headers, cookies, body, and upload content before the application sees them. It can block requests that match known attack signatures, enforce rate limits, or require additional authentication for sensitive paths.

• Positive security model: allow only known-good inputs. Very strict but brittle without constant tuning.
• Negative security model: block known-bad patterns. Easier to start with, but can be bypassed by novel attacks.
• Virtual patching: block exploit traffic for a known vulnerability while the development team ships the real fix.

WAFs are not a replacement for secure code. A well-written SQL query with parameterisation does not need a WAF to save it. The WAF is a safety net for mistakes, misconfigurations, and zero-day traffic patterns.

Cloud-native firewalls

In cloud environments, the network is software-defined. Firewalls attach to instances, subnets, load balancers, or even individual pods. The same principles apply, but the enforcement points are more granular.

Kubernetes NetworkPolicy is a good example of micro-segmentation. A policy can say that only pods with label tier: frontend may talk to pods with label tier: backend on port 8080. Everything else is denied by default.

Common mistakes

• “Any-any” rules: rules like “allow all from 10.0.0.0/8” destroy segmentation and make incident response harder.
• Shadow rules: old rules that were never removed, often permitting access to decommissioned systems or departed employees.
• Logging failures: firewalls configured to drop silently provide no forensic trail.
• Over-reliance on the perimeter: assuming the internal network is safe once you pass the firewall.
• Ignoring egress: organisations spend enormous effort on inbound rules while malware walks out through unrestricted outbound DNS, HTTPS, and SMTP.
• Rule ordering errors: a permissive rule placed above a restrictive one silently wins.

Interview framing

In a system design interview, you will rarely be asked to “draw a firewall.” More often, you will be expected to explain where security controls belong, what traffic should be allowed, and how to balance security with availability.

Questions to ask the interviewer

• Who are the users? Internal employees, customers, or both?
• Which parts of the system must be internet-facing?
• What compliance or data-residency requirements apply?
• Is there a need for third-party integrations or partner access?

What to draw on the whiteboard

1. A perimeter firewall or cloud security group at the edge, allowing only ports 80 and 443 from the public internet.
2. A DMZ with reverse proxies, load balancers, and bastion hosts — never direct database access.
3. Internal subnets for application servers, caches, and databases, with restricted east-west traffic.
4. A WAF or application gateway in front of web APIs to protect against OWASP Top 10 risks.
5. An egress gateway or proxy for outbound traffic, ideally with allow-listed domains and TLS inspection.