EN
What a Firewall Actually Does on the Network
A firewall device sits at the boundary between networks, making decisions about what traffic gets through and what gets blocked. That sounds simple enough, but the reality is more nuanced. Early firewalls essentially checked packet headers against a rule list—source IP, destination IP, port numbers—and either passed or dropped each packet in isolation. Modern firewall devices do much more than that. They maintain state tables, track active connections, and inspect traffic patterns rather than just individual packets. This stateful inspection means the device understands whether a packet belongs to an established session or represents something new and potentially suspicious.
The basic function remains the same: enforce a security policy by controlling traffic between zones with different trust levels. But the sophistication of that enforcement has grown considerably. A decent firewall device today handles deep packet inspection, application identification, and even user-based policies. For anyone managing a network that faces the public internet—which is just about every network—understanding these fundamentals isn't optional.
Why Software-Only Solutions Fall Short
Software firewalls running on general-purpose operating systems have their place. They're convenient, often free, and easy to deploy on individual machines. But relying on them as the primary defense for a business network introduces several problems. The host operating system itself becomes an attack surface. If the underlying OS has vulnerabilities, the firewall software running on top of it inherits those risks. Hardware firewall devices, by contrast, run on purpose-built firmware with stripped-down operating systems that present a much smaller attack footprint.
Performance is another factor. Software firewalls compete for CPU cycles and memory with every other application running on the same host. Under heavy traffic loads, packet processing can introduce latency or even drop connections. A dedicated firewall device uses specialized processors and hardware acceleration to handle traffic without impacting other systems. This distinction matters most in environments where network reliability directly affects operations—manufacturing floors, control rooms, and facility management networks.
The Evolution from Packet Filtering to Application Awareness
The shift from simple packet filtering to application-aware inspection represents one of the more significant changes in firewall technology over the past decade. Traditional firewalls looked at Layer 3 and Layer 4 information—IP addresses and port numbers. That worked reasonably well when applications used predictable ports. HTTP on port 80, HTTPS on 443, SSH on 22. But modern applications are more complex. They tunnel traffic over unusual ports, use encryption that hides payload contents, and dynamically negotiate connections.
Next-generation firewall devices address this by inspecting traffic at the application layer. They can identify specific applications regardless of which port they're using. This capability proves particularly valuable in industrial settings where operational technology networks use specialized protocols like Modbus, EtherNet/IP, or OPC. A conventional firewall might not distinguish between legitimate Modbus traffic and malicious packets that happen to use the same port. An application-aware device can.
How Firewall Devices Fit into a Defense-in-Depth Strategy
No single security measure provides complete protection. Firewall devices serve as one layer in a broader defense-in-depth approach. The concept is straightforward: multiple independent security controls, each covering gaps that others might leave open. A firewall handles network-level filtering. Endpoint protection deals with host-based threats. Access controls manage who can do what. Monitoring catches what slips through.
NIST Special Publication 800-82, the guide to industrial control system security, specifically addresses firewall placement and configuration for operational technology environments. The guidance emphasizes segmentation—dividing networks into zones with different security requirements and controlling traffic between those zones. This zone-and-conduit model, also formalized in the IEC 62443 series of standards, treats firewalls as the primary mechanism for enforcing boundaries between security domains.
| Security Layer | Primary Function | How Firewall Devices Contribute |
|---|---|---|
| Network Perimeter | Block unauthorized external access | First line of defense at network boundary |
| Internal Segmentation | Limit lateral movement between zones | Enforce zone-to-zone traffic rules |
| Host Protection | Secure individual endpoints | Complement host-based firewalls and AV |
| Monitoring & Detection | Identify active threats | Provide traffic logs and alerting data |
| Access Control | Authenticate and authorize users | Integrate with directory services for policy enforcement |
Real-World Constraints That Change Everything
Theory looks clean on paper. Practice rarely does. A manufacturing facility in the southeastern United States ran into this reality during a network upgrade project. The team had designed a segmented architecture with firewall devices separating the corporate IT network from the production floor. Standard practice, by the book. But when they deployed the rules, a batch of programmable logic controllers started throwing communication timeouts. The firewalls were inspecting Modbus traffic and introducing just enough latency to push the PLCs past their timing tolerances.
The fix wasn't to remove the firewalls—that would have defeated the security purpose. Instead, the team reconfigured the inspection depth, applied less aggressive rules for known-safe traffic flows, and added dedicated industrial firewall appliances that understood the protocol's timing requirements. The lesson stuck: security controls need to account for operational constraints, not just theoretical best practices. A firewall that breaks production is worse than no firewall at all, because it gets bypassed or disabled.
Practical Considerations for Deployment
Deploying firewall devices requires answering a few fundamental questions before touching any hardware. What traffic actually needs to flow between zones? What protocols are in use, and do they have specific timing or latency requirements? Who needs administrative access, and from where? What happens when the firewall fails—does traffic default to allow or deny?
The answers vary by environment. A corporate office network has different priorities than a wastewater treatment plant or a warehouse automation system. The common thread is that firewall rules should follow the principle of least privilege: allow only what's explicitly necessary, deny everything else. This sounds obvious, but real-world rule sets often accumulate exceptions over time until they resemble Swiss cheese. Regular rule reviews and cleanup sessions prevent this gradual erosion of security.