Firewalls

Put a policy on a traffic path

A firewall enforces rules about network traffic at a particular boundary or endpoint. Rules may consider addresses, protocols, ports, direction, connection state, or application information, depending on the product and configuration. The useful starting point is the intended communication policy, rather than a list of features.

A firewall can reduce unwanted reachability. It cannot make every permitted request legitimate or guarantee that the destination application is free from vulnerabilities. Network access-control lists and Authorization describe related controls at different scopes.

Write a complete permission

Imagine a fictional academy separates its public web application from its database. The application needs a specific database connection; learners' laptops do not. A useful rule identifies the source, destination, protocol, required service, direction, and purpose.

“Allow the database port” is incomplete. It could accidentally permit far more sources than intended. An owner should be able to explain why the connection exists, what depends on it, and when the permission should be reviewed.

Before changing the rule, identify the operational effect and a way to recover if the change blocks required traffic. This turns a security idea into a manageable configuration change.

Connection state changes interpretation

A stateful firewall can track exchanges and distinguish traffic associated with an existing permitted communication from unrelated traffic. Stateless filtering evaluates individual traffic units against configured conditions without the same connection context.

These are simplified descriptions: implementations differ, and protocols have different behavior. UDP does not establish a TCP-style connection even when a firewall tracks recent UDP exchanges. Consult the actual device documentation before interpreting its state labels or timeout behavior.

Allowed traffic can still be harmful

Suppose the academy permits HTTPS to a web service. The rule provides a path; it does not establish that every upload is safe or that every account is allowed to access every record. Encryption can also limit what an intermediate device can inspect.

For an incident, distinguish a firewall log recording a permitted connection from application evidence showing a particular action. Include event time, rule, interfaces or zones, and relevant endpoint context. A rule hit can be useful evidence without being the whole explanation.

Keep the rule set understandable

Temporary exceptions should have owners and review dates. Broad rules, obsolete services, overlapping conditions, and undocumented dependencies make the effective policy harder to assess. Rule order can matter, so reading one entry in isolation may misrepresent behavior.

In an authorized lab, define one permitted application-to-database path and one path that should be denied. Verify both using appropriate non-destructive requests, then inspect the corresponding records. Continue with Network segmentation to understand the boundary design and Ports and services to describe the endpoints precisely.