Network Security
Firewall
A firewall is a security control that filters network traffic according to rules.
In plain terms
A firewall is the gatekeeper that filters network traffic against rules, allowing some connections and blocking others. Like a bouncer with a guest list deciding who may pass between networks.
A firewall evaluates packets, sessions, flows, or application requests against policy and decides whether traffic should be allowed, blocked, logged, inspected, rate-limited, translated, or routed differently. The decision may depend on source and destination addresses, ports, protocols, interface, user identity, device posture, session state, application category, URL, domain, TLS metadata, or payload content.
The core purpose is boundary enforcement. A firewall reduces unnecessary reachability between trust zones, such as the internet and a private network, a user segment and a server segment, a cloud workload and a database, or a workstation and a management plane. NIST SP 800-41 Rev. 1 frames firewall policy as a way to control the flow of network traffic between networks or hosts with different security postures.
Types of firewall
Firewalls exist at several layers. Packet filters and stateful firewalls focus on network and transport attributes. Proxy firewalls terminate and mediate connections. Host firewalls protect a single endpoint or server. Cloud security groups, network ACLs, Kubernetes network policies, and service mesh policies provide similar enforcement in virtualized environments. Web application firewalls inspect HTTP and API traffic for application-layer attack patterns.
Writing good rules
A good firewall rule expresses a specific business need. It defines the source, destination, service, protocol, direction, owner, purpose, logging expectation, and review date. Rules such as “allow any from corporate network,” “open SSH from the internet,” or “temporary vendor access with no expiration” are not precise controls. They create broad attack paths and make later investigation harder.
Default deny is a common design principle for sensitive boundaries: block traffic unless there is an approved reason to allow it. That does not mean every network segment must become unusable. It means access should be intentionally modeled, tested, and documented. Default allow often grows silently until segmentation exists mostly on diagrams rather than in enforcement.
Firewalls should be aligned with asset sensitivity and threat paths. A public web tier may need inbound HTTPS from the internet, but the database behind it should accept traffic only from defined application services. Administrative interfaces should sit behind stronger access paths such as VPN, ZTNA, jump servers, privileged access workflows, or management networks. Outbound traffic also matters because command-and-control and data exfiltration often use allowed egress paths.
NIST SP 800-53 Rev. 5 maps this kind of work to controls such as SC-7 Boundary Protection, AC-4 Information Flow Enforcement, CM-7 Least Functionality, and AU controls for security-relevant logging. The practical lesson is that a firewall is not just a device. It is a managed control with configuration, monitoring, change management, testing, and evidence.
Limits of firewalls
Firewalls have limits. They do not automatically know whether an authenticated user should perform an action inside an application. They may not see encrypted payloads. They can be bypassed by misrouted traffic, shadow IT tunnels, exposed cloud services, compromised allowlisted hosts, overly broad service accounts, or traffic that uses permitted ports for harmful purposes. A firewall rule that allows a compromised application server to reach a database can still be abused.
Operations and monitoring
Firewall changes need operational discipline. Requests should name the business service, expected traffic, accountable owner, duration, and rollback plan. Security teams should review high-risk changes, but the best process is not endless manual gatekeeping. It is clear policy, reusable patterns, automated validation where possible, and regular cleanup of exceptions.
Monitoring should focus on security value. Deny logs can show scans, misconfigurations, brute-force attempts, and blocked lateral movement. Allow logs can support investigations, but full allow logging at busy boundaries may be expensive. Useful logging covers high-risk zones, administrative protocols, internet-facing services, unusual outbound destinations, and policy violations.
Testing should verify that the implemented policy matches the intended policy. Teams can use rule reviews, configuration analysis, attack path analysis, packet captures, connection tests, cloud policy analyzers, and detection content that watches for unexpected traffic. Testing is especially important after network redesigns, merger integration, cloud migration, or emergency incident response changes.
Common failure modes
Common failure modes include stale rules after migrations, rule shadowing where a broad rule makes a narrow rule irrelevant, inconsistent policies between data center and cloud, missing egress controls, permissive temporary exceptions, weak administrative access to the firewall itself, and logging that is either absent or too noisy to use. Another frequent failure is treating firewall presence as proof of segmentation without testing actual reachability.
For example, an internal database should not accept connections from user laptops, development sandboxes, or the internet. A strong firewall design allows only the application services that need database access, blocks and logs other attempts, restricts administrative access to a controlled path, and reviews the exception whenever the application architecture changes.