Firewall Technologies

Firewalls and traffic control

Home and enterprise networks exchange traffic with other networks that may have a different security posture. A firewall is a device or program that applies a traffic policy between these zones. Rules can refer to addresses, ports, protocols, connection state, and data recognized by specific inspection functions. Firewall documentation should state direction, rule owner, justification, scope, and test method. It should also describe log handling, device failures, and configuration changes.

A firewall evaluates incoming and outgoing traffic according to rule order and the configured default policy. It can allow a connection, reject it, log an event, or pass the traffic to further inspection. Effectiveness depends on traffic visibility, precise rules, updates, and monitoring of decisions. A policy should have an owner, a justification, and a review period. Temporary rules need an expiration time so they do not remain active after the task ends. Change records should link each rule to a service requirement and a test result. Review should include shadowed rules, unused exceptions, expected return traffic, logging volume, and the effect of address translation. The review should verify that logging does not expose sensitive payloads and that denied traffic remains available for incident analysis.

Packet filtering

A packet filter makes a decision from header fields. It does not inspect the full application content, so it can operate quickly and predictably for simple policies.

This type of firewall examines the header of each packet. Its allow or deny decision uses information available in that header, which can include addresses, ports, protocols, and flags. Depending on the implementation, a filter can also use input and output interfaces or VLAN tags:

• Source IP address: The sender address visible in the packet.
• Destination IP address: The receiver address carried by the packet.
• Source port: The port used by the sender application, such as $49152$ on a client computer.
• Destination port: The receiver service port, such as $443$ for HTTPS.
• Protocol: The transport or network protocol, such as TCP for a web connection or UDP for a media stream.

The firewall compares this information with rules in an Access Control List (ACL). An illustrative ACL might look like this:

In this example, Rule 1 allows any source to connect to the HTTP server at $192.168.1.10$ on port $80$. Rule 2 explicitly blocks Telnet on port 23. Rule 3 rejects traffic that does not match an earlier allow rule. In a real network, the source range and services should follow the server's required function. Rule order matters because the first match can end evaluation. Each allow rule should limit addresses and ports and log a decision at a level appropriate for audit needs.

This approach is stateless. Each packet is judged independently, without memory of earlier packets in the same flow. The rules do not identify whether a packet belongs to an established connection, so return traffic needs separate treatment. Filtering the source IP address does not remove source spoofing, and a large policy can become difficult to review.

Stateful inspection

A stateful firewall keeps information about flows passing through the device. It evaluates headers together with connection context, so it can distinguish a response belonging to an accepted flow from a new inbound request. For TCP it can consider state transitions and flags, while for UDP it commonly uses a timeout and flow parameters.

The core mechanism is a state table. When a connection starts, the firewall records the source and destination IP addresses, ports, protocol, flags, and an expiration time. The exact fields depend on the implementation and protocol.

When a response packet returns, the firewall compares its parameters with the state entry and still applies the security policy. A packet matching an active state may be allowed. Traffic that matches neither a state entry nor an allow rule is rejected or logged according to the configuration.

Stateful inspection simplifies common outbound connections and limits unexpected inbound traffic. It does not replace allow rules, logging, or application controls. It operates mainly at the Network and Transport layers, so it identifies a flow and protocol without usually interpreting the full application logic. The state table consumes memory and therefore needs limits, protection against connection floods, and monitoring of entries rejected by policy. A rule update should be tested against representative traffic and include a rollback plan. Administrators should check timeout behavior for long-lived sessions, asymmetric routes, failover, and state synchronization between redundant devices.

Application-level proxy firewalls

An application proxy operates at the application level and analyzes messages from a supported protocol. It may understand HTTP requests or FTP commands, but the scope depends on the available module and on traffic encryption.

A proxy firewall intermediates traffic and terminates the client connection. After checking the request against policy, it creates a separate connection to the external server:

1. The client connects to the firewall's proxy module.
2. The module analyzes the request and checks it against policy. After approval, it initiates a separate connection to the external server on behalf of the client.

This position allows the firewall to analyze protocol commands and fields. An FTP module can allow downloads while blocking uploads or deletion. An HTTP module can filter requests by host, path, or method. With HTTPS, full-content inspection requires explicitly configured TLS inspection and an appropriate trust policy.

A proxy adds processing cost because it maintains two connections and parses messages. It also needs separate support for each protocol, such as HTTP, FTP, or SMTP. Performance, scalability, and control depend on the implementation and the number of inspected connections. Authentication, errors, timeouts, and large files also need explicit handling. A protocol without a proxy module may require another control mechanism. Documentation should distinguish cleartext from encrypted traffic and state where the client connection terminates.

Next-generation firewalls (NGFW)

A next-generation firewall (NGFW) combines functions that depend on the product. It usually retains stateful filtering and may add application identification, content inspection, and an integrated IPS.

Typical NGFW functions include:

• Core firewall functions: An NGFW uses address, port, and protocol filtering together with stateful inspection as the policy foundation.
• Application identification and control: An NGFW can classify traffic by application as well as port and protocol. Deep Packet Inspection (DPI) can use signatures and protocol analysis. An example policy can allow an approved collaboration application while limiting file-sharing traffic. Encryption, protocol changes, and classification errors affect this function.
• Integrated Intrusion Prevention System (IPS): Some NGFWs include an IPS module that compares traffic with rules and signatures and can block a match. Operation depends on inline deployment, exceptions, and the configured failure-handling policy.
• User identity integration: An NGFW can obtain information from directory services such as Microsoft Active Directory and bind rules to a user or group. A policy might allow a selected service to an administrative group while limiting access for other groups.
• Threat information feeds: A product may consume feeds containing addresses, domains, signatures, or rules. An administrator should assess the source, lifetime, and impact of each entry because an update still needs validation and alignment with local policy.

Securing public servers: DMZ

Web, mail, and DNS servers may be reachable from the Internet, but placing them in the same zone as internal systems increases the impact of a compromise. A DMZ segment limits connections between public services and the trusted network.

A demilitarized zone (DMZ) is a physical or logical segment between the Internet and the internal network. Isolation is effective only when the firewall and systems in each segment enforce precise rules.

A DMZ can use a firewall with at least three interfaces or equivalent logical zones. Rules should state the allowed directions and services clearly. They should also cover administration, monitoring, name resolution, and updates. Administrative access should use a restricted path and separate credentials. Public services should be patched, monitored, and separated from management interfaces:

• Traffic from the Internet to the DMZ is allowed only for specified services, such as port $443$ on the web server.
• Traffic from the Internet to the internal LAN should be rejected by default, with exceptions defined by policy. Exceptions need logging and periodic review.
• Traffic from the DMZ to the Internet should be limited to required updates and services and should be logged.
• Traffic from the DMZ to the internal LAN should be blocked or tightly limited. If a server is compromised, this reduces the possible onward traffic. Permitted exceptions should name a specific service and direction.
• Traffic from the internal LAN to the DMZ can be allowed according to user and administrator needs.
• Traffic from the internal LAN to the Internet should follow outbound rules, logging, and any required filtering.