The most commonly asked question when installing a firewall is, “What should be allowed and what should be blocked?” This question assumes a distinct and definitive answer. The answer, however, is subjective and variable. A single security stance or filtering configuration that works for every situation, every organization, and every system doesn’t exist. Network security managers must investigate the needs and threats to the business and make informed decisions about what traffic to allow and what traffic to block.

The first stage in making this determination is to perform a complete inventory of all needed or desired communications. This should include every transaction between internal systems, as well as any interaction with external systems. As part of this inventory, indicate the protocol in use, the port(s) in use, and the likely source and destination addresses.

A possible inventory of network communications could look like TABLE 8-1.

This is not an exhaustive table, but it shows the basic idea of an inventory of network communications. Notice that some communications are internal only, while others cross the network boundary. Based on a complete and exhaustive inventory of your network’s communications, you can establish a potential rule base.

From the inventory, block from crossing the network border all communications that should only be internal. In most cases, the default-deny rule of a rule set will block those communications from exiting the network. However, when a port or protocol is in common, it is possible that an Allow rule for a valid external communication would also allow external entities access to an internal-only communication.

In Table 8-1, an example of this issue is the email protocol Simple Mail Transfer Protocol (SMTP) operating over port 25. By defining an allow-exception rule, you could create a loophole that threatens the internal communication on this same port. Reduce or eliminate this risk by using a very specific rule or by adding an additional Deny exception. A very specific rule in this example would allow external communication over port 25 only if it originated from the internal email server at 192.168.42.115. With this rule defined, if any other internal host attempted an external SMTP communication on port 25, it would not be allowed because the IP address would not match this specific rule. The communication would instead be blocked by the default deny.

If an allow-exception rule for external communications also applies to internal communications, you can add a specific deny-exception rule just prior to the Allow rule. The Deny exception can specifically block internal communications from crossing the network border, but still allow the subsequent Allow exception to grant access to the valid transactions.

After you complete a thorough inventory of network communications, you should determine which communications are mission-critical, important, optional, for personal recreational use, or actually malicious. Block any traffic you deem malicious or just unwanted, whether through an explicit Deny or via the catchall default deny.

Evaluate all other forms or types of traffic against several factors, including policy. If it is not in support of the business, is it really needed? Are communications for personal entertainment or nonbusiness functions permitted by policy or considered a waste of resources? Are any communications duplicated or redundant? Is this a waste of resources, an expansion of the attack surface, a valid redundancy, or avoidance of a single point of failure? Are any of the communications no longer necessary? If so, should you disable or remove that communication type?

Base your evaluation of the many other possible questions or issues on your organization’s policy statements, including mission and goals. Take the time to understand the communication needs of your network, then design the filtering rule set accordingly. Remember that the firewall is often the front sentry or the first line of defense against malicious communications originating from outside networks. Leaning toward caution and locking things down is a more effective security stance than leaving communications open and hoping detection mechanisms will notice and identify malicious events.

Although some exceptions to these suggestions will arise from your organization’s business model or strategies, the following items are commonly considered communications to block in most, if not all, circumstances:

• All Internet Control Message Protocol (ICMP) traffic originating from the Internet
• Any traffic directed specifically to the firewall
• Any traffic to known closed ports
• Any traffic to ports of known malware, such as 31337, used by Back Orifice
• Inbound Transmission Control Protocol (TCP) 53 to block external Domain Name System (DNS) zone transfer requests
• Inbound User Datagram Protocol (UDP) 53 to block external DNS user queries
• Any traffic from IP addresses on a blacklist
• Any traffic from internal IP addresses that are not assigned

As an organization manages its security over time, especially as it reacts to intrusion attempts, experiences scanning, and becomes the target of hacking and flooding, it must create additional communication filtering rules to respond to real-world conditions. Hackers are constantly evolving their skills and techniques. Thus, the filtering rules that work well today may be insufficient in the near future.

Networks can be very large and very complex. Be fully aware of the communications taking place across your network to know what to allow and what to block. In addition to this knowledge, having established a security strategy through a written security policy will direct and guide the deployment of firewall rules, as well as other aspects of your security infrastructure.