NET.3.2 Firewall

Description

Introduction

A firewall is a system of software and hardware components used to securely couple IP-based data networks. For this purpose, a firewall structure is used to restrict the technically possible information flow to the communication defined in advance as secure in a security policy. “Secure” here means that only the desired accesses or data streams between different networks are permitted.

To secure network transitions, a single component is often no longer used; instead, an entire series of IT systems are used that take on different tasks—e.g., exclusively filtering packets or strictly separating network connections using proxy functions. The term “Application Level Gateway” (ALG) as used in this building block designates a firewall component that controls data streams based on security proxies.

A firewall is deployed at the transition between networks of different trustworthiness. Networks of different trustworthiness do not necessarily represent only the combination of the Internet and intranet. Rather, two institution-internal networks can also have different protection needs. For example, the office communication network usually has a lower protection need than the human resources network, in which particularly sensitive personal data is transmitted.

Objective

The objective of this building block is to be able to deploy a firewall or a firewall structure securely using the requirements described in the following sections, in order to securely connect networks with different protection requirements to each other.

Scope and Modeling

The building block NET.3.2 Firewall is to be applied to every firewall used in the information domain.

A typical use case is the securing of an external connection—e.g., at the transition from an internal network to the Internet or for connections to partner institution networks. But the building block is also to be applied when coupling two institution-internal networks with different protection needs—e.g., when separating the office communication network from the development department network if particularly confidential data is processed there.

This building block builds on building block NET.1.1 Network Architecture and Design Network Architecture and Design and contains concrete requirements that must be observed and fulfilled when network-based firewalls are procured, built, configured, and operated.

To secure networks, further network components are usually required, e.g., routers and switches. However, requirements for these are not listed in this building block but are found in NET.3.1 Routers and Switches. If a firewall takes on the tasks of a router or switch, the requirements of building block NET.3.1 Routers and Switches additionally apply to it.

Furthermore, products such as so-called next generation firewalls (NGFW) or unified threat management (UTM) firewalls, which contain additional functional extensions—e.g., VPN, intrusion detection and intrusion prevention systems (IDS/IPS), virus scanners, or spam filters—are not addressed. Security aspects of these functional extensions are not the subject of this building block but are addressed, for example, in building blocks NET.3.3 VPN and OPS.1.1.4 Protection Against Malware.

Likewise, application detection or filtering is not addressed. It is a common function of next generation firewalls and IDS/IPS. Since the implementations differ between products, it is recommended to consider it individually depending on the deployment scenario. This building block also does not address the individual protection options for externally offered server services—e.g., through a reverse proxy or for web services using a web application firewall (WAF). Furthermore, aspects of infrastructure security (e.g., appropriate placement or power supply) are not listed in this building block but are found in the respective building blocks of layer INF Infrastructure.

Firewalls SHOULD generally be taken into account within the building blocks ORP.4 Identity and Access Management, OPS.1.1.3 Patch and Change Management, and OPS.1.1.2 Proper IT Administration.

Threat Landscape

Since IT-Grundschutz building blocks cannot address individual information domains, typical scenarios are used to illustrate the threat landscape. The following specific threats and vulnerabilities are of particular importance for building block NET.3.2 Firewall.

Distributed Denial of Service (DDoS)

In a DDoS attack on a protected network (e.g., TCP SYN flooding, UDP packet storm), the firewall can fail due to the large number of network connections that must be processed. This can cause certain services in the local area network (LAN) to become unavailable or the entire LAN to fail.

Manipulation

If attackers succeed in gaining unauthorized access to a firewall or a corresponding management interface, they can manipulate files there as they see fit. They can, for example, change the configuration, start additional services, or install malware. They can also intercept communication connections on the manipulated IT system. The firewall rules can also be changed, for example, so that the firewall and the institution’s intranet can be accessed from the Internet. Furthermore, attackers can launch a denial-of-service (DoS) attack by preventing access to individual server services in the ruleset.

Bypassing Firewall Rules

Attackers can use fundamental mechanisms in the network protocols to bypass firewall rules (e.g., through fragmentation attacks) in order to penetrate an area protected by the firewall. In the protected area, they can then cause further damage—e.g., read out sensitive data, manipulate or delete it.

Incorrect Configuration and Operating Errors of a Firewall

An incorrectly configured or incorrectly operated firewall can have a serious impact on the availability of services. If firewall rules are set incorrectly, for example, network accesses can be blocked. Furthermore, incorrect configurations can result in IT systems no longer being fully or not at all protected. In the worst case, internal services are thereby accessible to attackers.

Requirements

The following are the specific requirements of building block NET.3.2 Firewall. The Information Security Officer (ISO) is responsible for ensuring that all requirements are met and verified in accordance with the established security concept. The ISO MUST always be involved in strategic decisions.

Additional roles are defined in the IT-Grundschutz Compendium. They SHOULD be filled insofar as this is sensible and appropriate.

Exactly one role SHOULD be Primarily responsible. There may also be Additional responsibilities. If one of these additional roles is primarily responsible for fulfilling a requirement, that role is listed in square brackets after the requirement heading. The use of singular or plural says nothing about how many persons should fill these roles.

Basic Requirements

The following requirements MUST be fulfilled with priority for this building block.

NET.3.2.A1 Creation of a Security Policy (B)

Based on the institution’s general security policy, a specific security policy MUST be created. In this, requirements and specifications MUST be described in a comprehensible manner regarding how firewalls can be operated securely. The policy MUST be known to all employees responsible for firewalls and fundamental to their work. If the policy is changed or requirements are deviated from, this MUST be coordinated with the ISO and documented. It MUST be regularly checked whether the policy is still correctly implemented. The results MUST be documented in a meaningful manner.

NET.3.2.A2 Definition of Firewall Rules (B)

All communication between the involved networks MUST be routed through the firewall. It MUST be ensured that no unauthorized connections can be established into the protected network from outside. Likewise, NO unauthorized connections from the protected network to the outside MAY be established.

Unambiguous rules MUST be defined for the firewall that specify which communication connections and data streams are permitted. All other connections MUST be blocked by the firewall (allowlist approach). The communication relationships with connected service servers routed through the firewall MUST be taken into account in the rules.

Responsible persons MUST be named to draft, implement, and test filter rules. Furthermore, it MUST be clarified who may change filter rules. The decisions made and the relevant information and reasons for decisions MUST be documented.

NET.3.2.A3 Setting Up Appropriate Filter Rules at the Packet Filter (B)

Based on the firewall rules from NET.3.2.A2 Definition of Firewall Rules, appropriate filter rules MUST be defined and established for the packet filter.

A packet filter MUST be configured so that it discards all invalid TCP flag combinations. In general, filtering MUST always be stateful. Stateful filter rules MUST also be configured for the connectionless protocols UDP and ICMP. The firewall MUST filter the protocols ICMP and ICMPv6 restrictively.

NET.3.2.A4 Secure Configuration of the Firewall (B)

Before a firewall is deployed, it MUST be securely configured. All configuration changes MUST be documented in a comprehensible manner. The integrity of the configuration files MUST be appropriately protected. Before access passwords are stored, they MUST be secured using a contemporary cryptographic method (see CON.1 Cryptographic Concept). A firewall MUST be configured so that only absolutely necessary services are available. If functional extensions are used, the institution’s security policies MUST continue to be fulfilled. The reasons for using such extensions MUST also be justified and documented. Unnecessary (information) services and unnecessary functional extensions MUST be deactivated or completely uninstalled. Information about the internal configuration and operating state MUST be concealed from the outside as much as possible.

NET.3.2.A5 DISCONTINUED (B)

This requirement has been discontinued.

NET.3.2.A6 Protection of Administration Interfaces (B)

All administration and management access to the firewall MUST be restricted to individual source IP addresses or address ranges. It MUST be ensured that administration interfaces cannot be accessed from untrusted networks.

To administer or monitor the firewall, ONLY secure protocols MAY be used. Alternatively, a dedicated administration network (out-of-band management) MUST be used. Appropriate time restrictions MUST be specified for the user interfaces.

NET.3.2.A7 Emergency Access to the Firewall (B)

It MUST always be possible to access the firewall directly so that it can be administered locally in an emergency even when the entire network fails.

NET.3.2.A8 Suppression of Dynamic Routing (B)

In the firewall settings, dynamic routing MUST be deactivated, unless the packet filter is used as a perimeter router in accordance with building block NET.3.1 Routers and Switches.

NET.3.2.A9 Logging (B)

The firewall MUST be configured to log at minimum the following security-relevant events:

• rejected network connections (source and destination IP addresses, source and destination port or ICMP/ICMPv6 type, date, time),
• failed access to system resources due to failed authentication, insufficient authorization, or non-existent resources,
• error messages from firewall services,
• general system error messages, and
• configuration changes (automatically where possible).

If security proxies are used, security violations and violations of access control lists (ACLs) MUST be logged in an appropriate manner. At minimum, the type of protocol violation or ACL violation, source and destination IP address, source and destination port, service, date and time, and, if required, the connection duration MUST be logged.

If users authenticate themselves at the security proxy, authentication data or exclusively the information about a failed authentication MUST also be logged.

NET.3.2.A10 Defense Against Fragmentation Attacks at the Packet Filter (B)

At the packet filter, protective mechanisms MUST be activated to defend against IPv4 and IPv6 fragmentation attacks.

NET.3.2.A11 DISCONTINUED (B)

This requirement has been discontinued.

NET.3.2.A12 DISCONTINUED (B)

This requirement has been discontinued.

NET.3.2.A13 DISCONTINUED (B)

This requirement has been discontinued.

NET.3.2.A14 Operational Documentation (B)

The operational tasks of a firewall MUST be documented in a comprehensible manner. All configuration changes and security-relevant tasks MUST be documented, in particular changes to the system services and the firewall ruleset. The documentation MUST be protected against unauthorized access.

NET.3.2.A15 Procurement of a Firewall (B)

Before a firewall is procured, a requirements list MUST be created by which products available on the market can be evaluated. Care MUST be taken that the security level sought by the institution can be achieved with the firewall. The requirements from the security policy MUST therefore form the basis for procurement.

If IPv6 is used, the packet filter MUST check the IPv6 extension headers. In addition, IPv6 MUST be configurable in a manner equivalent to IPv4.

Standard Requirements

Together with the basic requirements, the following requirements correspond to the state of the art for this building block. They SHOULD generally be fulfilled.

NET.3.2.A16 Building a “P-A-P” Structure (S)

A “Packet Filter - Application-Level Gateway - Packet Filter” (P-A-P) structure SHOULD be deployed. It MUST consist of several components with hardware and software suited for each purpose respectively. Security proxies at the application layer SHOULD be available for the most important protocols used. At least generic security proxies for TCP and UDP SHOULD be used for other services. The security proxies SHOULD also run within a hardened runtime environment of the operating system.

NET.3.2.A17 Deactivation of IPv4 or IPv6 (S)

If the IPv4 or IPv6 protocol is not required in a network segment, it SHOULD be deactivated at the respective firewall network access point (e.g., at the corresponding firewall interface). If the IPv4 or IPv6 protocol is not required or used, it SHOULD be completely deactivated on the firewall.

NET.3.2.A18 Administration via a Separate Management Network (S)

Firewalls SHOULD be administered exclusively via a separate management network (out-of-band management). Any administration interface via the actual data network (in-band) that may be present SHOULD be deactivated. Communication in the management network SHOULD be restricted via management firewalls (see NET.1.1 Network Architecture and Design Network Architecture and Design) to a few management protocols with precisely defined origins and destinations. The available security mechanisms of the management protocols used for authentication, integrity protection, and encryption SHOULD be activated. All insecure management protocols SHOULD be deactivated (see NET.1.2 Network Management).

NET.3.2.A19 Protection Against TCP SYN Flooding, UDP Packet Storm, and Sequence Number Guessing at the Packet Filter (S)

At the packet filter protecting server services accessible from untrusted networks, an appropriate limit SHOULD be set for half-open and open connections.

At the packet filter protecting server services accessible from less or untrusted networks, so-called rate limits SHOULD be set for UDP data streams.

At the outer packet filter, random generation of initial sequence numbers (ISN) SHOULD be activated for outgoing TCP connections, insofar as this is not already implemented by security proxies.

NET.3.2.A20 Protection of Fundamental Internet Protocols (S)

The protocols HTTP, SMTP, and DNS, including their encrypted versions, SHOULD be routed through protocol-specific security proxies.

NET.3.2.A21 Temporary Decryption of Data Traffic (S)

Encrypted connections to untrusted networks SHOULD be temporarily decrypted to verify the protocol and check the data for malware. The legal framework conditions SHOULD be observed here.

The component that temporarily decrypts the data traffic SHOULD prevent outdated encryption options and cryptographic algorithms from being used.

The TLS proxy used SHOULD be able to check whether certificates are trustworthy. If a certificate is not trustworthy, it SHOULD be possible to reject the connection. Own certificates SHOULD be retrofittable in order to also be able to configure and check “internal” root certificates. Pre-configured certificates SHOULD be reviewed and removed if they are not required.

NET.3.2.A22 Secure Time Synchronization (S)

The time of the firewall SHOULD be synchronized with a Network Time Protocol (NTP) server. The firewall SHOULD NOT allow external time synchronization.

NET.3.2.A23 System Monitoring and Evaluation (S)

Firewalls SHOULD be integrated into an appropriate system monitoring or monitoring concept. It SHOULD be continuously monitored whether the firewall itself and the services operated on it are functioning correctly. If errors occur or threshold values are exceeded, operations personnel SHOULD be alerted. In addition, automatic alert messages SHOULD be generated that are triggered at defined events. Log data or status messages SHOULD ONLY be transmitted via secure communication paths.

NET.3.2.A24 Revision and Penetration Tests (S)

The firewall structure SHOULD be regularly checked for known security problems. Regular penetration tests and revisions SHOULD be conducted.

NET.3.2.A32 Emergency Preparedness for the Firewall (S)

Diagnostics and fault resolution SHOULD be planned and prepared in advance. Corresponding action instructions SHOULD be defined for typical failure scenarios and updated at regular intervals.

Emergency plans for the firewall SHOULD be coordinated with the overarching fault and emergency preparedness. They SHOULD be aligned with the general emergency preparedness concept (see DER.4 Emergency Management). It SHOULD be ensured that emergency preparedness documentation and the action instructions it contains are available in paper form. The procedure described in the emergency preparedness SHOULD be regularly practiced.

Requirements for High Protection Needs

The following are exemplary proposals for requirements for this building block that go beyond the level of protection corresponding to the state of the art. The proposals SHOULD be considered when there are high protection needs. The specific determination is made within the framework of an individual risk analysis.

NET.3.2.A25 Extended Integrity Protection for Configuration Files (H)

To restore a crashed firewall, it SHOULD be ensured that no old or faulty configurations (including access lists) are used. This SHOULD also apply if an attack succeeds in restarting the firewall.

NET.3.2.A26 Outsourcing of Functional Extensions to Dedicated Hardware (H)

Functional extensions of the firewall SHOULD be outsourced to dedicated hardware and software.

NET.3.2.A27 Use of Different Firewall Operating Systems and Products in a Multi-Tier Firewall Architecture (H)

In a multi-tier firewall architecture, different operating systems and products SHOULD be used for the outer and inner firewalls.

NET.3.2.A28 Central Filtering of Active Content (H)

Active content SHOULD be centrally filtered in accordance with the institution’s security objectives. For this purpose, the encrypted data traffic SHOULD also be decrypted. The required security proxies SHOULD support the filtering of active content.

NET.3.2.A29 Use of High Availability Solutions (H)

Packet filters and application-level gateways SHOULD be designed for high availability. In addition, two mutually independent access options to the external network SHOULD exist—e.g., two Internet connections from different providers. Internal and external routers and all other active components involved (e.g., switches) SHOULD also be designed for high availability.

Even after an automatic failover, the firewall structure SHOULD fulfill the requirements of the security policy (fail safe or fail secure).

The function SHOULD be monitored using numerous parameters. Function monitoring SHOULD NOT rely on a single criterion. Log files and warning messages of the high availability solution SHOULD be regularly checked.

NET.3.2.A30 Bandwidth Management for Critical Applications and Services (H)

To ensure bandwidth management for critical applications and services, packet filters with corresponding bandwidth management functions SHOULD be deployed at network transitions and at the transition between different security zones.

NET.3.2.A31 Use of Certified Products (H)

Firewalls with a security evaluation according to Common Criteria SHOULD be used, at least at level EAL4.

Additional Information

Good to Know

The BSI has published the following further documents on the topic of firewalls:

• Technical guideline for organization-internal telecommunications systems with high protection needs: BSI-TL-02103 - Version 2.0
• Cryptographic methods: Recommendations and key lengths - Part 2: Use of Transport Layer Security (TLS): BSI-TR-02102-2
• Secure connection of local networks to the Internet (ISi-LANA)

The National Institute of Standards and Technology (NIST) provides recommendations on the use of firewalls in NIST Special Publication 800-41 “Guidelines on Firewalls and Firewall Policy.”