Firewall Policies Best Practices

A secure network is vital to a business. To secure a network, a network administrator must create a security policy that outlines all of the network resources within that business and the required security level for those resources. The policy applies the security rules to the transit traffic within a context (source zone and destination zone) and each policy is uniquely identified by its name. The traffic is classified by matching source and destination zones, source and destination addresses, and the service (application) that the traffic carries in its protocol headers with the policy database in the data plane.

Configuring security policies to enforce traffic rules in a network can be relatively easy but requires careful consideration. There are several best practices to use when defining an effective firewall policy to ensure better use of system memory and to optimize policy configuration:

1. Use least privilege policies—Make the firewall rules as tight as possible in terms of match criteria and permitting traffic. Only permit traffic that is allowed by your organizational policy and deny all other traffic. This is true for both ingress and egress traffic, meaning traffic from the Internet to internal resources and also traffic from internal resources to the Internet. A least privilege security policy helps to minimize the attack surface, making other controls more effective.

2. Segment logically—Zone-based firewalls allow you to place different interfaces into different zones. This allows you to design your network such that you can place resources in a manner where the firewall can enforce controls (interzone and intrazone policies).

3. Place specific firewall rules first—Place the most explicit firewall rules at the top of the rule base because traffic is matched starting at the top of the rulebase and going down with the first match.

4. Use address sets where possible—Address sets simplify administration of firewall policies. They allow you to group large sets of objects so that you can address them as a single object in a security policy. The more rules you can reference to the address sets, the easier it is to make changes because most organizations have logical objects that can be grouped

   Use single prefixes for source and destination addresses. For example, instead of using /32 addresses and adding each address separately, use a large subnet that covers most of the IP addresses you require. Use fewer IPv6 addresses because IPv6 addresses consume more memory.

5. Use service sets where possible—Service sets simplify administration of firewall policies. They allow you to group large sets of objects so that you can address them as a single object in a security policy. Use service “any” whenever possible. Each time you define an individual service in the policy, you can use additional memory.

6. Use fewer zone pairs in policy configurations—Each source and destination zone uses about 16,048 bytes of memory. We recommend using global policies wherever possible. Global policies provide you with the flexibility to perform action on traffic without the restrictions of zone specifications.

7. Use explicit drop rules—To ensure that undesired traffic does not leak through a security policy, place an any-any-any drop rule at the bottom of each security zone context (for example, source zone to destination zone) along with a global policy. This does not mean that you should not define your firewall rules, it simply provides a catch-all mechanism for capturing unclassified traffic.

8. Use logging—We highly recommend that you log on all firewall policies. Logging provides you with an audit trail of all network activity, which helps in troubleshooting and diagnosis. Unless you are troubleshooting, it is best to use the Log on Session Close option instead of the Log on Session Initialization option. Session Close logs include a great deal more information about the session; this information is useful for diagnostic purposes.

9. Use Network Time Protocol (NTP)—NTP is a widely used protocol used to synchronize the clocks of routers and other hardware devices on the Internet. If any of the device clocks is wrong, then not only logs and troubleshooting information can be incorrect, but also security policy objects such as schedulers can have unintended results.

10. Check memory utilization—Check your memory usage before and after compiling policies.