Do your firewalls need a tune-up? In our last column, we looked at general ways that firewall performance can be improved to overcome problems such as high CPU utilization, low throughput, and slow applications.
This time, we are following up with a list of vendor and model-specific tips and best practices that can help you to optimize your firewall infrastructure. Thank you to everybody who responded to the last column and sent in their own tips!
- Use networks instead of address ranges in NAT.
- Avoid rules with Ident.
- Replace nested groups by flat groups.
- Be aware of configurations that SecureXL templates (fastpath) cannot handle, for example, security server, or syndefender.
- Note that SecureXL templates can be disabled from a certain rule onwards due to certain configurations such as client auth, time objects, etc.
- Be aware of configurations that SecureXL cannot handle, for example:FloodGate-1 (automatically disables SecureXL) Rules with user authentication Services with a port number range (disables connection-rate acceleration) Time object associated with the rule (disables connection-rate acceleration)
- Be aware of SmartDefense configurations that may impact performance:Network Security->Fingerprint scrambling->ISN spoofing Network Security->Fingerprint scrambling ->TTL
- Debug messages are known to affect performance.
PIX 6.3
- TCP Intercept is known to impact performance.
- If you are not using NAT and have no DNAT communications, disable the ILS fixup.
Cisco IOS Firewall
- Performance may be affected if the value of ‘ip inspect one−minute high’ is far greater than the value in the ‘show ip audit stat’ command.
Cisco ASA
- Verifying TCP checksums may impact firewall performance.
- Ideal performance is achieved when traffic enters and exits ports on the same adapter or ports on adapters serviced by the same I/O bridge (ASA 5580).
Cisco FWSM
- Deep packet inspection may cause high CPU (all inspection engines except for SMTP are handled in software).
- Before release 3.1, non UDP or TCP or ICMP flows are handled on a packet by packet basis. With 3.1 and higher, the FWSM creates flows in NP1 and NP2.
- Be aware of features that are not offloaded to network processors, they will use the CPU.
- Built-in ACL optimization algorithm: FWSM Release 4.0 incorporates an algorithm capable of optimizing ACLs by coalescing contiguous subnets referred to in different access-control entries into a single statement and detecting overlaps in port ranges. Note that after the optimization process, the ACL is likely to be different from the original one.
- ALG (application layer gateway) is applied globally to all policies by default but may have a major impact on performance. Disabling it on specific policies can make a significant improvement.
- On high-end firewall platforms, NS-5000, ISG-1000 and ISG-2000, with ScreenOS 6.2 and above, Juniper switched the default rule search algorithm from “hardware” (ASIC) to “software” (CPU). The software search algorithm provides faster policy search time compared to older versions, when the number of “rules” for a pair zone is more than 500 rules, but it could cause high CPU during policy changes.
- ScreenOS 6.1: using wildcard address/wildcard policy causes a performance penalty.
- Enable only the required management features you need. If you don’t need SSH or SNMP, don’t enable them.
- Enable only the required application inspections.
- Minimize use of alert systems. If you export syslog, you may not need SNMP or email alerts.
- Establish auto-updates (scheduled update) at a reasonable rate. Every 4 or 5 hours should be ok on most cases.
- Minimize use of Protection Profiles. If you don’t need a Protection Profile on a firewall rule, don’t put it there.
- Minimize use of Virtual Domains and avoid them completely on low-end models.
- Avoid Traffic Shaping if you need maximum performance. By definition, Traffic Shaping slows down traffic.
As usual, I’d love to have your feedback,
Reuven.
Don't miss out on more Tufin blogs
Subscribe to our weekly blog digest
