Firewall Policy Guidelines

A firewall policy specifies how firewalls can manage network traffic based on the organization’s information security policies for different IP addresses and address ranges, protocols, applications and content types.

Before a firewall policy is developed, some sort of risk analysis should be performed to build a list of the organization’s types of traffic needed and categorize how to protect them.

See Also: Firewall Rule Configuration Best Practices For PCI Compliance

This risk analysis should be based on a threat assessment; vulnerabilities; existing vulnerability mitigation measures; and impact if systems or data are compromised. In the system security plan, firewall policy should be documented and maintained and updated frequently as classes of new attacks or vulnerabilities arise, or as network applications need to change the organization. The proposal will also provide detailed guidance on how to deal with changes to the rules and regulations.

See Also: PCI DSS Firewall Requirements

Firewalls should generally block all inbound and outbound traffic not expressly permitted under firewall policy. This method, called by default negation, decreases the risk of attack and can also minimize the amount of traffic on the organization’s network. By default, denying is a more secure approach than allowing any traffic that is not explicitly prohibited due to the dynamic nature of hosts, networks, protocols, and applications.  

Policies Based on IP Addresses and Protocols

Firewall policies should only allow IP protocols through which they are required. Examples of commonly used IP protocols are ICMP (1), TCP (6), and UDP (17), with their IP protocol numbers. Other IP protocols, such as IPsec Encapsulating Security Payload (ESP) components and Authentication Header (AH) and routing protocols, may also need to pass through firewalls.

See Also: Firewall Audit Tools to Ease PCI Compliance

These necessary protocols should be limited to the specific hosts and networks within the organization with a need to use them whenever possible. By allowing only protocols which are necessary, all unnecessary IP protocols are denied by default.

Some IP protocols are seldom passed between an external network and the LAN of an organization, and can therefore simply be blocked at the firewall in both directions.

IGMP, for example, is a protocol used to control multicast networks, but it is rarely used for multicast, and when it is, it is often not used over the Internet. Hence it is feasible to block all IGMP traffic in both directions if multicast is not used.  

IP Addresses and Other IP Characteristics

Firewall policies should only allow for the use of appropriate IP addresses for source and destination. Specific IP-address recommendations include:  

• No matter where the firewall is, traffic with invalid source or destination addresses will always be blocked. The fairly common examples of invalid IPv4 addresses are 127.0.0.0 to 127.255.255.255 and 0.0.0.0. These don’t have legitimate network usage. Traffic can also be blocked using the link-local addresses (169.254.0.0 to 169.254.255.255).
• Traffic for incoming traffic or destination address with an invalid source address for outgoing traffic should be blocked at the edge of the network. Such traffic is mostly the result of spoofing, malware, denial of service attacks or equipment misconfigured. The most prevalent form of invalid external address is an IPv4 address reserved for private networks within the ranges set out in RFC 1918, Address Allocation for Private Internet. These ranges are 10.0.0.0 to 10.255.255.255 (10.0.0.0/8), 172.16.0.0 to 172.31.255.255 (172.16.0.0/12), and 192.168.0.0 to 192.168.255.255 (192.168.0.0/16).
• Traffic with a private destination address should be blocked at the edge of the network for incoming traffic or source address for outgoing traffic (an “internal” address. Perimeter devices can conduct address translation services to allow private hosts to communicate through the perimeter, but private addresses should not be transmitted through the perimeter of the network.  
• Outbound traffic should be blocked, with invalid source addresses. Systems that were hacked by attackers can be used to target other systems on the Internet; using invalid source addresses makes it harder to avoid these kinds of attacks. Blocking this kind of traffic at the firewall of an organization helps to reduce the effectiveness of such attacks.
• Incoming traffic with the firewall’s destination address itself should be blocked unless the firewall provides incoming traffic services that require direct connections. For example, if the firewall acts as a proxy for the application.

The following types of traffic should also be blocked at the perimeter by organizations:

• Traffic containing information on the IP source routing, which allows a system to specify the routes that packets will use while traveling from source to destination. This could potentially allow an attacker to create a packet that will bypass network security controls. Modern networks rarely use IP source routing, and valid applications are even less common on the Internet.
• Traffic from outside the network, with broadcast addresses that are directed to the network’s interior. Any system that responds to the guided broadcast will then send its response not to the source system itself, but to the system specified by the source. Those packets can be used to create huge network traffic “storms” to deny service attacks. Standard broadcast addresses as well as addresses used for multicast IP may or may not be appropriate for blocking at the firewall of an organization. Multicast and broadcast networking is rarely used in normal networking environments but it should be allowed through firewalls when used both inside and outside the organization.  

Firewalls at the perimeter of the network should block all incoming traffic to networks and hosts not to be accessed from external networks. Such firewalls will also block all outgoing traffic from networks and hosts within the enterprise that are not permitted to access external networks.

Deciding which addresses to block is often one of the most time-consuming aspects of developing IP policies on firewalls. It is also one of the most vulnerable to errors, since the IP address associated with an unwanted entity often changes over time.

IPv6

IPv6 is a new, increasingly deployed version of the IP. While the internal format and address length of IPv6 is different from IPv4’s, several other features remain the same. Firewalls will function the same for the features which are the same between IPv4 and IPv6. For example, blocking all incoming and outgoing traffic not specifically allowed under the firewall policy should be done irrespective of whether or not the traffic has an IPv4 or IPv6 address.  

Some firewalls can’t handle IPv6 traffic at all as of this writing; others can handle it but have limited capabilities to filter IPv6 traffic; and still others can filter IPv6 traffic to about the same extent as IPv4 traffic. Every company, whether IPv6 traffic reaches its internal network or not, requires a firewall capable of filtering that traffic. These firewalls should have the following capabilities:  

• In all filtering rules using IPv4 addresses, the firewall should be able to use IPv6 addresses.
• Administrators should be able to clone IPv4 rules to IPv6 addresses using the administrative interface to make administration easier.
• As specified in RFC 4890, Recommendations for filtering ICMPv6 messages in firewalls, the firewall must be able to filter ICMPv6.
• If not necessary, the firewall should be able to block IPv6-related protocols such as 6-to-4 and 4-to-6 tunneling, Teredo and ISATAP protocols.  
• Many IPv6 Packets tunnel sites in IPv4 packets. This is particularly common for sites experimenting with IPv6, as it is currently easier to obtain IPv6 transit from a tunnel broker through a v6-to-v4 tunnel than from an Internet service provider (ISP) to get native IPv6 transit from. There are a number of ways to do that and tunneling standards are still evolving. If the firewall is capable of inspecting IPv4 packet contents, it will need to learn how to inspect traffic for any tunneling system the company uses. A consequence to this is that if an organization uses a firewall to prevent IPv6 from entering or leaving its network, the firewall must identify and restrict all types of v6-to-v4 tunneling.

Note that the list above is short, and that not all rules are unique to protection. Since IPv6 implementation is still in its early stages, there is still not general consensus within the IPv6 operations group about what an IPv6 firewall can do, which is different from IPv4 firewalls.

Traffic with invalid source or IPv6 addresses of destination should always be blocked for firewalls which allow IPv6 use. Since much more effort has been made to draw up lists of invalid IPv4 addresses than IPv6 addresses, it can be difficult to find lists of invalid IPv6 addresses. In addition, IPv6 allows network administrators to allocate addresses in different ways within their assigned ranges.  

This means that there can be literally trillions of invalid IPv6 addresses in a particular address range assigned to an organization, and only a few that are valid. Needless to say, listing which IPv6 addresses are invalid will need to be less fine-grained than listing invalid IPv4 addresses, and the firewall rules using those lists will be less effective than their IPv4 counterpart.

Organizations not yet using IPv6 should at their firewalls block all native and tunneled IPv6 traffic. Remember that these blocking limits the testing and assessment for future deployment of IPv6 and IPv6 tunneling systems. Firewall admin may manually unblock IPv6 or the different tunneling technologies that are of interest to the authorized testers to allow such use.

TCP and UDP

Depending on the protocol design, application protocols may be using TCP, UDP, or both. As a rule, an application server usually listens to one or more of the specified TCP or UDP ports. Some applications use one port, but many use multiple ports. For example, while SMTP uses TCP port 25 to send mail, it does use TCP port 587 to send mail.

Similarly, FTP uses at least two ports, one of which may be unpredictable and while most web servers only use TCP port 80, websites that also use additional ports such as TCP port 8080 are common. Some applications use both TCP and UDP; for example, the UDP port 53 or TCP port 53 may contain DNS lookups. Usually applications clients use any of a wide variety of ports.  

As with other aspects of firewall rulesets, TCP and UDP traffic incoming should be used to deny by default policies. In general, less stringent policies are used for outgoing TCP and UDP traffic, since most organizations allow their users to access a wide range of external applications on millions of external hosts.

Besides allowing and blocking UDP and TCP traffic, many firewalls can also report or block malformed UDP and TCP traffic directed to the firewall or to firewall-protected hosts. This traffic is often used to scan for hosts, and can be used in some types of attacks as well. The firewall can help block such activity, or report at least when such activity occurs.

ICMP                                                  

Attackers can use different ICMP types and codes to perform network traffic recognition or manipulate the flow. However, many useful items, such as having fair output over the Internet, require ICMP. Certain firewall policies block all ICMP traffic, but this often leads to diagnostic and performance problems.

Other specific policies allow all outbound ICMP traffic, but limit inbound ICMP to the types and codes required for the discovery of the ICMP code 3 and destination accessibility.

To avoid malicious activity, all incoming and outgoing ICMP traffic should be rejected by firewalls at the edge of the network except for certain types and codes expressly approved by the organization. ICMP type 3 messages should not be screened for ICMP in IPv4 because they are used for essential diagnoses of the network.

The ping command is an important diagnostic network but incoming pings are frequently blocked by firewall policies to prevent attackers from learning more about the organization’s internal network topology.  

For ICMP in IPv6, several types of messages have to be enabled to trigger different IPv6 features in specific circumstances.

Low-level networking protocols often employ ICMP to increase networking speed and reliability. Therefore, ICMP should generally not be blocked by firewalls within an organization’s network that are not at the perimeter of the network, unless security needs outweigh the operational needs of the network. Similarly, if an organization has more than one network, there should be no blocking of ICMP that originates from or goes to other networks within the organization.  

IPsec Protocols

An organization needs to have a policy whether to allow IPsec VPNs starting or ending within its perimeter of the network. The ESP and AH protocols are used for IPsec VPNs, and a firewall blocking these protocols will not allow passage of IPsec VPNs.

While blocking ESP may hinder the use of encryption to protect sensitive data, it may also force users who would normally encrypt their data with ESP to allow it to be inspected, such as through a state-of-the-art inspection firewall or application-proxy gateways.  

Organizations authorizing IPsec VPNs will block ESP and AH except from and to the internal network from unique addresses. Enforcing this policy would allow people within the company to receive sufficient policy approval to open their IPsec routers to ESP and/or AH.

This would also that the amount of encrypted data coming from inside the network that cannot be scrutinized by network security tests.   

Policies Based on Applications

The majority of initial types of firewall works covered simply blocking unwanted or questionable boundary traffic on the network. User inbound firewalls or server proxies take a particular strategy. They let traffic into the network destined for a specific server but capture that traffic in a server that processes it like a port-based firewall.

See Also: Best Practices for Clean Up Your Firewall Rule Base

The application-based approach offers an additional layer of protection for incoming traffic by validating some of the traffic until it enters the server of your choosing. The theory is that the additional security layer of the inbound application firewall or proxy can better protect the server than the server can protect itself, and can also remove malicious traffic before it reaches the server to help lower server load.

In some cases, a firewall or proxy application may be able to remove traffic that the server might not be able to remove on its own because it has greater filtering capability. An application firewall or proxy also prevents direct server access to external network.

If possible, firewalls and proxies for inbound application should be used in front of any server that does not have sufficient security features to protect it from application-specific attack. The main considerations when deciding whether to use a firewall or proxy for the inbound application are:

• Is there an appropriate application firewall available? Or is there an appropriate application proxy available, if appropriate?
• Is the server now adequately firewall-protected?
• Can the main server block malicious content as effectively as the firewall or proxy application?
• Is it acceptable to apply for latency caused by an application proxy?
• How easy is updating the filtering rules on the main server and the firewall or proxy application to deal with newly developed threats?

If they are not highly efficient, application proxies may cause problems. Unless an application proxy is considerably more robust than the server and easy to keep up to date, staying alone with the application server is usually the best way to. Application firewalls can also cause problems if they aren’t fast enough to manage server-destined traffic.

However, consideration of the server resources is also important. The application firewall or proxy may be used as a defense if the server does not have adequate resources to withstand attacks.  

When a firewall or proxy of an inbound application is behind a perimeter firewall or in the DMZ of the firewall, the perimeter firewall should be blocked to reduce the load on the firewall or proxy, based on IP addresses.

Doing so puts more of the address-specific policy in one place and reduces the amount of traffic seen by the firewall or proxy application, freeing up more power to filter content. Of course, no such rules are needed if the perimeter firewall is also the application firewall and an internal application proxy is not used.  

Outbound application proxies are useful for detecting systems from inside the protected network making inappropriate or dangerous connections. For HTTP it is by far the most common type of outbound proxy.

Outbound HTTP proxies allow an organization to filter hazardous content prior to arriving at the requesting PC. They also help an organization better understand and log web traffic from its users, and detect activities that are tunneled via HTTP.

When an HTTP proxy filters content, the web user may be alerted that the website being visited will send the filtered content. HTTP proxies’ most prominent non-security benefit is the caching of web pages for increased speed and reduced use of bandwidth. HTTP proxies should be employed by most organizations.

Policies Based on User Identity

Traditional packet filtering does not see the identities of users who communicate through the firewall in the traffic, so without more advanced capabilities, firewall technologies cannot have policies that allow or deny access based on those identities.

Many other firewall technologies, however, can see these identities and hence enact user authentication based policies. Using a VPN is one of the most common ways of implementing the user identity policy at a firewall. Both IPsec VPNs and SSL VPNs have a variety of ways to authenticate users, such as user-by-user passwords, multi-factor authentication, or user-controlled digital certificates.  

NAC has also become a common firewall tool for permitting or refusing users access to different network resources. Additionally, application firewalls and proxies can allow or deny users access inside the applications themselves depending on the user authentication.

Firewalls that enforce user identity policies should be capable of reflecting those policies in their logs. That is, logging only the IP address from which a particular user connected is probably not useful if the user was allowed to log in through a user-specific policy; logging the user’s identity is also important.

Policies Based on Network Activity

After a certain period of inactivity many firewalls allow the administrator to block established connections. For example, if a user outside a firewall has logged into a file server but has not made any requests in the past 15 minutes, then the policy could be to block any more traffic on that link.

Time-based policies are useful to thwart attacks caused by a logged-in user walking away from a computer, and somebody else sitting down and using the connections established. However, these policies can also be frustrating for users who make connections but don’t often use them.

See Also: How to Prepare Network Documentation for PCI DSS Compliance Requirements?

For example, a user might connect to a file server to read a file and then spend a long time editing the file. If the user fails to save the file back to the file server before the timeout imposed by the firewall, the timeout may cause the file changes to be lost.

Some companies have policies on when firewalls will block unused connections, when apps will break sessions when there is no operation, etc. A firewall used by such an entity should be able to create policies that suit the mandates, while being precise enough to meet the mandates’ protection target.

A different kind of network-based firewall policy is one that throttles or redirects traffic if the traffic rate that matches the policy rule is too high. For example, if the connection rate is above a certain threshold, a firewall might redirect the connections made to a particular inside address to a slower route.

Another policy could be for incoming ICMP packets to drop if the rate is too high. It is quite difficult to formulate such policies, because throttling and redirecting can cause the desired traffic to be lost or have difficulty in diagnosing transient failures.

See Also: Firewall Audit Checklist

NIST: Guidelines on Firewalls and Firewall Policy