Firewall Security Policy: Best Practices for Configuration and Management

This technote provides a high-level methodology for introducing security policies on firewalls. You can learn some best practices, which will help you correctly configure security policies, as well as facilitate subsequent management and maintenance.

This technote provides a high-level methodology for introducing security policies on firewalls. You can learn some best practices, which will help you correctly configure security policies, as well as facilitate subsequent management and maintenance.

Firewall Security Policy: Best Practices for Configuration and Management

Firewall Security Policy: Best Practices for Configuration and Management

Why Are Best Practices Required?

As a firewall administrator, you are facing great challenges. In this information era, services require faster network connections but at the same time they are exposed to increasingly active cybercrimes. You need to strike a balance between performance and security. The configuration and management of security policies is the key to solve this problem. According to a report from Gartner, 99% of firewall problems are caused by incorrect configurations. Before configuring security policies, you can learn some best practices, which will help you correctly configure security policies, as well as facilitate subsequent management and maintenance.

Establishing a Complete Security Policy Management Process

The security policy management process is a part of the information security policy. It is a management method ensuring that technologies can serve services properly. Initially, the security policy of each firewall is simple. With the deployment of new services and devices, an increasing number of security policies are required, complicating configuration changes and management. An organization needs to establish and strictly implement a policy management process, which is used for reviewing all security policy applications. This process can be adjusted dynamically based on service requirements. To ensure reasonable and traceable security policy addition and modification, include the following aspects in the policy management process:

  1. The applicant in the service team initiates an application for adding a security policy and specifies the security policy to be added. The business director evaluates the necessity of the security policy and submits the application to the security team. Generally, the service team needs to provide the following information:

    Any network change must be submitted to the security team in advance to evaluate the change impact and formulate the security policy adjustment solution.

    • Access destination (service, port, or application)
    • Access source, which generally refers to a subnet. If the access is initiated from a server, the IP address of the server needs to be specified.
    • Function and purpose of the security policy to be added
    • Validity period of the security policy to be added. If no validity period is specified, the security policy is a long-term policy.
  2. The security team evaluates the risks of the application submitted by the service team and determines the specific security policy implementation solution. If necessary, communicate with the business director or applicant about the new security policy application to ensure that the new security policy can meet service requirements and inform them of the security policy complexity and risks.
  3. The security team deploys and verifies the security policy. Key roles including the service team and data owner (service or application to access) must participate in the verification. Full verification can help find problems in a timely manner.
  4. All security policies must be recorded. Some industry specifications such as the Payment Card Industry Data Security Standard (PCI DSS) require that all application and approval documents be recorded and that security policies be audited periodically. Recording each security policy may complicate the process, but it is reasonable and efficient in the long run. Anyone in the security team can view the records to understand the intent of each security policy and establish the association between the security policy and the application process. This helps auditing and problem locating. It is recommended that the following information be recorded for a security policy:
    • Content of the security policy application provided by the service team
    • Applicant and approver in the service team
    • Application date and time
    • Handler of the security team

If the organization has a well-developed IT system, the preceding content is usually recorded in the service request process, which can greatly reduce the security policy recording workload. The combination of IT processes and firewall configurations makes policy management easy. For example, the creation time, operator, or IT process number can be recorded in the description field of the security policy to establish the relationship between the security policy and the application process, facilitating tracing and auditing.

Dividing a Network into Security Zones

A security zone is a subnet that has similar security requirements and security levels. Although the security zone is a unique concept of firewalls, it originates from network segmentation and has universal significance on the data communication network. Network segmentation refers to dividing an Ethernet network into several subnets that are isolated from each other based on certain rules. Data packets are transmitted on specified subnets only, not to all devices on the network. Network segmentation improves network performance and ensures network security. Firewalls are deployed on segmented networks and use security zones to enhance security.

By default, a firewall provides the Untrust, Trust, and DMZ zones, which are used to connect to the external network, internal network, and DMZ respectively. By default, devices in the same security zone can communicate with each other. To enable devices in different security zones to communicate with each other, you need to configure security policies. This design achieves a good balance between performance and security. To be specific, if a subnet is intruded, attackers can access only resources in the security zone corresponding to the subnet. To access resources on other subnets, attackers must break through the control of the security zone and security policies. The use of security zones and security policies minimizes the loss.

Properly planning security zones and deploying resources help improve network security and resilience. The following lists some rules for planning security zones and deploying resources:

  • Many security zones can achieve precise network control and network security, which however will complicate management.
  • Do not place systems that do not interact with each other on the same subnet. Otherwise, attackers can easily access all these systems as long as they break through the defense.
  • Deploy the devices and service resources with the same security level in the same security zone. Then, allocate IP addresses to devices based on security zones. The IP addresses of the devices with the same service attributes and security level can form an address set. Using address sets in security policies makes security policies easy to understand and manage.
  • Deploy systems of different security levels that need to interact with each other in different security zones and configure strict security policies for them. For example, all servers (such as web servers and email servers) that provide services for external systems must be deployed in a dedicated zone (generally DMZ), and servers (such as database servers) that cannot be directly accessed by external networks must be deployed in the internal server zone.

The following uses an example to describe the best practices of security zone division and resource deployment.

Figure 1-1 Security zone division and resource deployment

In this example, the network is divided into four security zones. In addition to the default Trust, DMZ, and Untrust zones, an Isolated zone is added. The arrows indicate the directions of permitted traffic.

  • The proxy server, email server, and front end of the web server are deployed in the DMZ. These servers need to provide services for the Internet. Corresponding security policies need to be configured on the firewall. Servers oriented to the Internet are most vulnerable to attacks and need to be isolated from other servers.
  • Back end of the web server, including the application server and database server, stores important data and needs to be deployed in the Isolated area. Servers in the DMZ can access specific services in the Isolated zone.
  • The DHCP server, DNS server, and AD server do not need to be connected to the Internet infrastructure. They need to receive access requests from clients on the internal network and are deployed in the Trust zone. By default, the communication between these servers and clients on the internal network is allowed. Clients on the internal network need to access the Internet through a proxy server.

In this way, even if the servers connected to the Internet are attacked, threats can be controlled in the DMZ, and the damage can be minimized.

Following the Principle of Least Privilege

By default, a firewall denies all interzone traffic, and all traffic that is not explicitly permitted is denied. This is the basis for implementing the principle of least privilege on the firewall. On this basis, security policies are configured to permit authorized traffic only to minimize the attack surface.

First, exercise caution when using any as the matching condition in a security policy that permits authorized traffic. You are advised to set accurate matching conditions, which involves the following aspects:

  • Specify source and destination IP addresses and services.
  • Specify matching conditions as many as possible, including users and applications.

If an organization needs to open some services (for example, web services) to the Internet, the source IP address can be set to Any in the security policy. The destination IP address must be specified as the IP address of the server or server group that is open to external systems, and the service or port must be specified. If all services or ports are open, attackers may use dictionary attacks to perform brute force cracking.

For non-public services, the source IP address range must be specified for accessing key information assets such as database servers and sensitive services such as SSH and Remote Desktop Protocol (RDP). You are advised to specify users who can access the service.

Application identification is a key capability of firewalls. It can implement refined management and control. It is complicated to analyze network traffic and identify authorized applications. You can set the matching conditions of a security policy to an application type or application label, for example, the enterprise application label so that applications can be identified.

Second, set a validity period for a temporary security policy. For example, if a third-party partner needs to access a service, you need to set the validity period of the security policy in addition to specifying the destination IP address and service. When the validity period expires, the security policy automatically becomes invalid. An invalid security policy is marked with . In addition, an organization will not affect service running for security purposes. Therefore, even if matching conditions of services cannot be determined, temporary security policies may be configured to permit specified service traffic. If a validity period is set in the security policy, ensure that the system time is correct. NTP is recommended for time synchronization.

Third, pay attention to the direction of the security policy. Huawei firewalls are stateful inspection firewalls. The return traffic can pass through the firewalls as long as the firewalls allow the service initiator to set up connections. Bidirectional security policies need to be configured only when both communication parties need to initiate connections. Take a web server as an example. Generally, the web server only needs to respond to connection requests from the Internet, and does not need to proactively access the Internet. The system and software updates of the server should be obtained through the unified central server, and the domain name or application (such as WindowsUpdate) must be specified in the security policy.

The minimum authorization principle is the most important security principle. You may not be able to achieve absolute minimum authorization, but you can endeavor to achieve it.

Configuration Sequence Matters

After receiving a packet, the firewall matches the packet based on the sequence of security policies in the security policy list. Once a security policy is matched, the firewall stops matching. Therefore, the sequence of security policies is very important. If the same security policies are arranged in different sequences, the matching results may be different and the device performance may be affected.

Security policies with accurate matching conditions take precedence. The security policy that is configured with the most accurate matching conditions based on the minimum authorization rule must be placed at the top of the list. The security policies with accurate matching conditions must be placed preceding the security policies with general matching conditions. General matching conditions of security policies need to be gradually refined or disabled.

Security policies that are frequently matched take precedence. If a security policy is frequently matched, much traffic matches the security policy. Quickening matching major traffic with security policies can significantly improve device performance. This is especially evident in high-load environments.

After ensuring that high-hit-rate security policies will not shadow low-hit-rate security policies, place the high-hit-rate security policies preceding the low-hit-rate security policies.

You are advised to configure security policies in the following sequence:

  1. Anti-spoofing security policy. If the access traffic from the public network uses a private IP address, the traffic is pretended to be initiated by an internal device. Such traffic must be denied. Huawei firewalls provide the IP spoofing attack defense function (which can be configured using the firewall defend ip-spoofing enable command). However, this function can be applied to limited scenarios only. You can use security policies to prevent IP spoofing attacks.

  2. Security policy that allows authorized user services, for example, a security policy that allows HTTP traffic for internal network users to access external web services.

  3. Security policy that allows authorized management services, for example, a security policy that allows SNMP traffic for the firewall to send SNMP traps to the NMS.

  4. Security policy that blocks unauthorized traffic. For unauthorized services, you can configure a blocking security policy to quickly discard the service traffic, improving the matching speed.

  5. Security policy that blocks suspicious traffic. Administrators need to keep observing suspicious traffic. Therefore, logs need to be recorded when the traffic is blocked so that the administrators can analyze and adjust security policy actions in a timely manner.

The default security policy will deny all traffic that is not explicitly permitted. However, it takes time for such traffic to match the default security policy at the end of the security policy list, which will severely affect device performance. Therefore, you must configure a security policy to deny the known traffic that needs to be blocked.

There are two methods to adjust the sequence of security policies. One is to use the Move menu on the security policy list page. You can also run the rule move rule-name1 { { after | before } rule-name2 | up | down | top | bottom } command to achieve the same effect.

Figure 1-2 Using the Move menu

The other method is to directly drag a security policy. You can select a security policy and drag it to the desired position.

Figure 1-3 Dragging a security policy

Identifying and Controlling Both Incoming and Outgoing Traffic

It is not enough to protect internal network resources against external attacks.

Attackers may embed Trojan horses or set traps on the websites that are frequently visited by users to launch pass-by download or watering hole attacks. These attacks enable malware to enter the internal network through authorized traffic. After successful penetration, attackers usually further download malware, connect to C&C servers, and transmit data to external networks through convert channels. In addition, internal assets of an organization may be hijacked by attackers to attack other networks. Therefore, security personnel must pay attention to both internal and external security threats.

For example, you need to create a whitelist of authorized websites and applications to allow outgoing traffic to the whitelisted websites and applications only. To completely control a system, attackers must download malware to the internal network. Restricting users' online behaviors can greatly reduce the attack surface.

Strict traffic control in the inbound and outbound directions is a key measure to ensure network security. To achieve this goal, security personnel need to understand common attack means used by attackers and design and adjust service solutions accordingly. In a service solution, security policies are used to control incoming and outgoing traffic. For example, malware that penetrates the internal network usually establishes C&C connections and obtains data in an unauthorized manner through DNS covert channels. The most effective method for defending against such attacks is to set the destination address of DNS requests to the address of the DNS server built by an organization or trusted DNS server. Table 1-1 shows an example of Google Public DNS used by an enterprise. Allow all devices on the internal network to initiate DNS resolution requests to the Google Public DNS server. Generally, the UDP-based DNS service is used. Then, forbid the devices to access other DNS servers through UDP and TCP. Accordingly, you need to use a DHCP server to allocate the Google Public DNS server to clients.

Table 1-1 Restricting DNS requests

No.

Name

Source Security Zone

Destination Security Zone

Source Address/Region

Destination Address/Region

Service

Application

Action

201

Trusted DNS server

any

Untrust

any

8.8.8.8

8.8.4.4

dns (UDP: 53)

any

permit

202

Other DNS server

any

Untrust

any

any

dns (UDP: 53)

dns-tcp (TCP: 53)

any

deny

Recording Logs

Logs record information such as the service running status, traffic distribution, and application distribution on the network. They are the basis of network visibility and facilitate fault locating, source tracing, and policy optimization. Table 1-2 lists the logs that are closely related to security policies.

Table 1-2 Security policy-related logs

Log Type

Configuration Suggestion

Configuration Method

Traffic logs

Traffic logs record information about traffic that arrives at or passes through the firewall. You can learn about all traffic information related to a specified security policy from traffic logs. The traffic reports generated based on traffic logs provide traffic trends and top rankings in terms of source addresses, applications, users, and security policies. Traffic logs and reports help analyze network traffic composition for further security policy adjustment.

You can configure the traffic logging function on the firewall for a specified security policy or for all security policies. By default, this function is disabled.

You are advised to enable the traffic log function for a specified security policy.

Web UI: On the security policy editing page, set Record Traffic Logs to Enable.

CLI: Run the traffic logging enable command in the security policy rule view. To record traffic logs for the default security policy, run the default traffic logging enable command.

Session logs

Session logs record all network activities on the firewall, including the access permitted and denied by security policies. Such logs are mainly used for fault locating and source tracing. Session logs must be exported to the log server for display.

Session logs are classified into session aging logs, session creation logs, and periodic session logs. By default, the firewall only records session aging logs, which are generated at the end of a session and contain detailed session information. Such logs facilitate fault diagnosis.

Web UI: On the security policy editing page, set Record Session Logs to Enable.

CLI: Run the session logging command in the security policy rule view.

Policy matching log

Policy matching logs record security policy matching information. You can learn about the traffic that matches the specified security policy based on the logs to evaluate the validity of this security policy.

The firewall provides the global and security policy-specific policy matching log functions. By default, the firewall records policy matching logs for all security policies. You are advised to enable the policy matching log function for a specified security policy.

Web UI: On the security policy editing page, set Record Policy Matching Logs to Enable.

CLI: Run the policy logging command in the security policy rule view.

Ensure that the retention period of logs meets management requirements and comply with local laws and regulations. You are advised to configure the firewall to forward logs to the eLog or other professional log management systems for centralized storage.

Changing Policies at Off-Peak Hours and Enabling Policy Backup-based Acceleration as Required

You are advised to change security policies during off-peak hours to minimize the impact on firewall performance and established sessions. This is especially important for high-load firewalls.

To improve the security policy matching speed, the firewall creates an index for each security policy and accelerates policy query (index matching) during policy matching. This function is known as policy acceleration. When a security policy changes, the new security policy takes effect immediately. However, the firewall creates an index for the new security policy after an acceleration delay (60 seconds by default) to ensure that the index is created after the change is complete. Before the index update is complete, the firewall performs regular policy matching, resulting in low efficiency of policy matching. To resolve this problem, you can configure the policy backup-based acceleration function. When a security policy changes, the firewall backs up the index of the original policy and uses the backup index to match security policies. After an index is re-created, the firewall uses the new index for policy matching and the new security policy takes effect.

Determine whether to enable the policy-based backup acceleration function by referring to Table 1-3.

Table 1-3 Policy backup-based acceleration configuration guide

Function Status

Without Policy Change

Policy Changed

Application Scenario and Impact

Enabled

policy accelerate standby enable

Accelerate policy query by using original indexes to match security policies.

Accelerate policy query by using backup indexes to match security policies.

The security policy change takes effect only after the new index is generated.

The firewall service traffic is heavy, and there are more than 100 security policies.

Security policy change takes effect after a delay of about 2 minutes. Verify that the security policy takes effect after the delay.

Disabled

undo policy accelerate standby enable

Accelerate policy query by using original indexes to match security policies.

Perform the regular policy matching and accelerate policy query after the new index is generated.

The security policy change takes effect immediately.

There are less than 100 security policies.

The device performance deteriorates during the policy change.

Periodically Auditing and Optimizing Security Policies

Since a network is constantly changing, old security policies may need to be deleted because they are not applicable anymore, and security policies need to be created for new users, devices, services, and applications on the network. As the security policy list expands, management is complicated, security risks may be hidden, and the firewall performance is affected. To solve this problem, you can periodically audit security policies. This is a must operation in some industries. For example, PCI DSS requires that security policies be audited once every half a year.

You are advised to periodically audit, simplify, and optimize security policies, which helps the firewall strike a balance between performance and security. The detailed operations are as follows:

  • Understand the intent and background of each security policy, which can be obtained from the security policy name and the description field that reflects the security policy change history. If possible, confirm with the service side whether the security policy needs to be retained.
  • Check the security policies whose description field is empty. You are advised to set the description field because an empty description field will complicate security policy management.
  • Check temporary security policies and delete the expired ones. The icon next to a temporary security policy indicates that the security policy has expired.
  • Delete the unnecessary security policies that are disabled.
  • Check for unused, duplicate, or inapplicable security policies. Duplicate security policies may exist if multiple users maintain security policies. Inapplicable security policies exist if devices or assets retire. No traffic will match these security policies. Therefore, you can identify these security policies by analyzing the security policies that are not matched. Then, delete redundant security policies based on the analysis result.
  • Check for security policies whose matching conditions overlap. If the actions of such security policies are the same, combine the security policies. If the actions of such security policies are different, adjust the security policy configurations to ensure that the actions are proper.
  • Check for security policies whose matching condition contains any. Check whether these security policies are necessary and whether specific matching conditions can be specified. Generally, a service type should not be specified as any.
  • Check whether traffic of insecure services, such as FTP and Telnet, is permitted. The traffic of these services is transmitted in plaintext, which poses security risks.
  • Check the security policies that are frequently matched. Move these policies up in the policy list, while ensuring the policy matching result is not affected. This can significantly improve the matching speed.
  • Check logs and optimize security policy configurations based on session logs and policy matching logs.

If a security policy is deleted, it is difficult to restore the specific configuration and its location in the policy list. If the security policy is disabled, you can quickly enable it if necessary. Therefore, before deleting a policy, you are advised to disable it to ensure that the deletion does not affect services.

It is difficult to analyze a security policy during audit and optimization. Huawei firewalls provide the smart policy function to implement policy redundancy analysis, policy matching analysis, and policy tuning on a single device. You can also use dedicated security policy management products, such as FireMon and AlgoSec.