Posts Tagged ‘SecureTrack’

Tufin Firewall Expert Tip #3: Best practices for optimizing firewall performance

January 11, 2010

Is your firewall overloaded? Symptoms include high CPU, low throughput and slow applications.  Before upgrading your hardware, it is worth checking whether the firewall configuration can be optimized.

Optimization techniques can be divided into two groups – general best practices, and vendor-specific, model-specific configurations. This column focuses on best practices. Next time, we will look at vendor-specific tips, so if you have any to share, we would like to hear from you.

Optimizing firewalls for better performance and throughput:

  1. Remove bad traffic and clean up the network.  Notify server administrators about servers hitting the firewall directly with outbound denied DNS/NTP/SMTP/HTTP(S) requests as well as dropped/rejected internal devices. The administrators should then reconfigure the servers not to send this type of unauthorized outbound traffic, thereby taking load off the firewall.
  2. Filtering unwanted traffic can be spread among firewalls and routers to balance the performance and effectiveness of the security policy.
    1. Identify the top inbound dropped requests that are candidates to move upstream to the router as ACL filters. This can be time consuming, but it is a good method for moving blocks upstream to the router and saving firewall CPU and memory.
    2. If you have an internal choke router inside your firewall, also consider moving common outbound traffic blocks to your choke routers, freeing more processing on your firewall.
  3. Remove unused rules and objects from the rule bases.
  4. Reduce rule base complexity – rule overlapping should be minimized.
  5. Create a rule to handle broadcast traffic (bootp, NBT, etc.) with no logging.
  6. Place the heavily used rules near the top of the rule base. Note that some firewalls (such as Cisco Pix, ASA version 7.0 and above, FWSM 4.0 and certain Juniper Networks models) don’t depend on rule order for performance since they use optimized algorithms to match packets.
  7. Avoid DNS objects requiring DNS lookup on all traffic.
  8. Your firewall interfaces should match your switch and/or router interfaces.  If your router is half duplex your firewall should be half duplex.  If your switch is 100 Mbit your firewall interface should be hard-set to match your switch; both should most likely be hard-set to 100 Mbit full duplex. Your switch and firewall should both report the same speed and duplex mode. If your switch is gigabit, your switch and firewall should both be set to auto-negotiate both speed and duplex.  If your gigabit interfaces do not match between your firewall and switch, you should try replacing the cables and patch panel ports. Gigabit interfaces that are not linking at 1000 Mbit full duplex are almost always a sign of other issues.
  9. Separate firewalls from VPNs to offload VPN traffic and processing.
  10. Offload UTM features from the firewall: AV, AntiSpam, IPS, URL scanning.
  11. Upgrade to the latest software version. As a rule of thumb, newer versions contain performance enhancements but also add new capabilities, so a performance gain is not guaranteed.

If you use Tufin SecureTrack, you can automate a number of these tasks.

Here are a few ways that SecureTrack can help:

  1. Identify unused rules and objects with the Rule and Object Usage Report, and consider removing them. The longer the reporting period, the more reliable the rule usage status will be. Remember that certain rules, like the ones allowing disaster recovery services, are only used rarely. You can also identify and cleanup unused group members.
  2. Analyze rule shadowing with Policy Analysis. Run Policy Analysis with “Any;Any;Any;Any” to identify completely shadowed rules. These rules are redundant and should be deleted. You can re-validate the redundancy with an unused rules report.
  3. Identify the most-used rules with the Rule and Object Usage Report and move them up in the rule base hierarchy. To find the top-most location for placing a rule without affecting connectivity, run an “Any;Any;Any;Any” policy analysis query, then, for each most-used rule:
    1. If it is not shadowed, move it to any higher location.
    2. If it is shadowed, find the lowest-ranked shadowing rule with a contradictory action and place the most-used rule below that one.
  4. Other things to keep in mind when re-ordering rules:
    1. You’ll probably want to preserve the rule base structure, for example, rule grouping by service or application, source or destination, projects etc.
    2. Be careful with policies containing rules with special actions such as authentication or encryption – shadowing becomes more tricky in this case.
  5. You may also use the Best Practices Rule Order Optimization test to quickly identify candidates for relocation.
  6. Use the Automatic Policy Generator (APG) to identify and remove unwanted traffic from the firewall. Read more about APG here.
  7. Use the “Software Version Compliance Report” to control your firewall software versions.

Last but not least, remember that optimization can have a price, too – beyond the time you’ve invested. If you are not careful, you can wind up with a rule base which is too hard to maintain.  If you have the budget, there are times when upgrading the hardware is the easiest alternative.

In our next column, we’ll focus on ways to optimize specific models of firewalls from the different vendors. If you have any tips that you would like to share, please contact me at


Tufin Firewall Expert Tip #2: Analyzing Network Connectivity Problems

November 10, 2009

Network connectivity problems are some of the most common – and aggravating – for business users. With distributed systems, as soon as an application does not behave as expected, the firewall is suspect. There are many other possible points of failure – the client application, the user’s PC, intermediate switches, routers, filters, load balancers and the application itself. But, because of its nature (secretive and designed to keep people out) the firewall is a prime suspect. As a firewall administrator, you are guilty until proven innocent.

So how can you quickly determine if the problem is due to the firewall or not?

One approach is to analyze the firewall traffic logs. Contact the user, obtain his IP address and ask him to access the application again. Ideally, this should trigger the connection in question. Then you can review the firewall traffic logs and locate the dropped or accepted packets. How easy this is depends on the tools – unless you have a smart log browser, you may have to work with syslogs.  Normally there will be a lot of logs so a filter on the source IP and, if possible, on the destination IP or port will make things easier.

Unfortunately, in many cases, you will find nothing. One possible reason is that the rule that allows or blocks the relevant traffic is not configured to generate logs. Another possibility is that you are not looking at the right firewall or are simply missing the relevant logs.

Another method is to analyze the firewall rule base. In many cases this is not feasible due to the size and complexity of the network and firewall policies. But if the network is relatively small and you know the rule base very well, you may be able to narrow the problem down to a specific rule or to a recent change that might have affected the application flow.

If you have Tufin SecureTrack, you can use the Policy Analysis tool to query the rule base. Get the user’s IP address, the IP address of the application and the service or port, if possible. Log into SecureTrack and create a policy analysis query with these inputs. You can run the query on all firewalls or, if you are sure which ones are relevant, on a subset. For the report, you can choose to show all traffic or only dropped or accepted traffic.  SecureTrack does not send any packets over the network. It analyzes its own copy of the rule base, which is always up to date from continuous monitoring. Since SecureTrack does not depend on traffic logs, it doesn’t matter whether log data is missing or unavailable.

Policy Analysis will quickly determine whether the firewalls are allowing the user’s traffic or not. If it turns out that the firewall is, in fact, blocking traffic, Policy Analysis will point you to the rule that’s causing the problem as well as when it was last changed, and by whom.