Filtering models
Packet filters evaluate header rules; stateful firewalls track conversations; proxies terminate and inspect application exchanges; next-generation products add application/identity features with vendor-specific capabilities. Choose controls for required trust boundaries and observable enforcement, not a label alone.
Rules and least privilege
Specify source, destination, protocol, service and action. Ordered policies can shadow later entries; implicit deny is useful only with an intentional allowance plan. Verify permitted and forbidden examples after changes. An any-any allow is not equivalent to a narrowly successful service rule.
Architecture and zones
Separate user, management, server and external segments. A DMZ reduces direct exposure between Internet-facing services and internal data, but security still depends on explicit flows and identity. Stateful return handling needs correct path symmetry and tuple context; NAT and zone policy are different functions.
Operations and limitations
Record reasons and owners for rules, monitor hits, review exceptions and test rollback. Encryption can limit inspection and inspection can introduce privacy/performance concerns. The ITAV topology evaluates simplified first-match rules; stateful and zone lessons are additional explicit teaching models.
Signal / protocol flow
- 1Source zone
- 2Flow classification
- 3Ordered policy
- 4Connection state
- 5Destination zone
Technical terminology
- State table: tracked flow context
- DMZ: constrained service segment
- Implicit deny: default reject
- Rule shadowing: earlier rule prevents later use
Worked example
Permit application subnet→database TCP/5432 only; deny guest→management; allow matching established returns where the model supports state. Test both the required service and a forbidden management port.
Configuration reference
# Teaching policy reference 1 allow tcp/443 from users to web 2 allow tcp/5432 from app to database 3 deny any from guest to management 4 deny all remaining flows
Troubleshooting scenario
An early deny any any makes a later HTTPS allow ineffective. Inspect evaluation order and scope, move/replace the intended rule safely, then prove unrelated traffic is still denied.
Knowledge check
Why test a forbidden flow after adding an allow rule?
Related practice
References
Educational model — not real hardware, traffic or official certification.