Firewall Rule Design Guidelines

Regardless of which type of rules you choose to implement, here are some guidelines for the creation of those rules:

Use a restrictive approach as opposed to a permissive approach for all interfaces and all directions of traffic. By using this as a starting point, you can then permit only traffic that you specify while denying everything else. This might take a little while to fine-tune because many administrators often discover additional required protocols for the functionality of their networks that may not have initially been considered, such as routing protocols, network management protocols, and so on.

Presume that your internal users’ machines may be part of the security problem. If you blindly trust all devices on the inside to access resources through the firewall, this may also include an attacker who has physical access to the building or malicious code that is unknown to the user running on one of his PCs.

Be as specific as possible in your permit statements, such as avoiding the use of the keyword any or all IP protocols if possible.

Recognize the necessity of a balance between functionality and security. Customers have a network for a reason, and they need to allow traffic through the firewalls to meet their business needs. At some point, you might need to point out a potential security weakness based on allowing something through your firewall but allow the traffic anyway based on the business need. It is usually up to someone higher up in the political food chain to make those final decisions.

Filter bogus traffic, and perform logging on that traffic. Some packets should never be allowed into your network. For example, if your network is the 23.1.2.0/24 network, there should never be a packet that is entering your network (from a remote network) that (based on its source address) claims it is also from the 23.1.2.0/24 network. Traffic from the RFC 1918 private address space is unlikely to be legitimate traffic if coming in from the Internet. Bogus traffic, such as the two examples just provided, should be filtered at the edges of the network. Even if you think your service provider will deny the traffic, you should implement the same filtering on your perimeter routers as well.

Periodically review the policies that are implemented on the firewall to verify that they are current and correct. Obsolete rules that are no longer in use should be removed or at least updated through documented change control.