Administering Check Point VPN-1FW-1 NG AI for Performance


Administering Check Point VPN-1/FW-1 NG AI for Performance

With FW-1 NG AI, Check Point has made a number of improvements over previous versions. One major improvement is with INSPECT XL, which is responsible for evaluating packets based on rules. The new version of INSPECT XL is supposed to be optimized and much more efficient because it uses only one state table, as opposed to earlier implementations that used multiple state tables. Despite these improvements, ensuring that your firewall is performing up to your expectations as well as everyone else s is important. There are a number of best practices that you should keep in mind when configuring and administrating your firewall to ensure that Check Point NG performance is at its optimum.

Configuring NG for Performance

There are a number of things that you can do when you re initially configuring FW-1 NG AI so that it provides optimum performance for your environment:

  • Use hosts files on management servers and remote enforcement modules.

  • Disable decryption on accept.

  • Modify logging Global Properties.

The recommendation to use hosts files should be part of every installation. To clarify, every time you install a policy, the management station must resolve its name to an IP address and each of the enforcement modules onto which it is installing policy. In the event that a DNS server cannot be contacted or the name is not found in DNS, policy installations can fail or take a very long time ”both undesirable consequences. Using hosts files, the host will parse the hosts file first for IP address mappings and not make a network query. This will speed up the install of security policy and ensure that it will install even during times when DNS servers are unavailable. On UNIX systems, the hosts file is located at /etc/hosts. On Windows NT/2000, the hosts file is located at %SystemRoot%\_System32\drivers\etc\hosts.

For example, if the name of your FW-1 object in the Rule Base GUI is ExternalFW, you must be sure that the name ExternalFW is mapped to an IP address in the hosts file. Additionally, let s say that part of your policy installs policy onto a remote firewall named RemoteFW. The mapping of RemoteFW must also be defined in the hosts file. Here is a sample hosts file:

 127.0.0.1 localhost 11.12.13.14 ExternalFW 15.16.17.18 RemoteFW 

Another setting you can change right off the bat is decryption on accept . If you are not using encryption, you should uncheck Enable decryption on accept . This option can be found in Global Properties under the VPN-1 tab, as shown in Figure 8.1. This setting prevents FW-1 NG from attempting decryption of packets even when the rule doesn t require it. This setting allows FW-1 NG to free some resources for other tasks , but it should be noted that this setting is relevant only if you are using Traditional Mode policies.

click to expand
Figure 8.1: Global Properties
start sidebar
Configuring & Implementing
NT Name Resolution

Windows NT 4 uses NetBIOS name resolution to find services on the network. WINS is a dynamic name registration service that a workstation can use to resolve NetBIOS names to IP addresses. Additionally, the LMHOSTS file located at %SystemRoot%\System32\drivers\etc can be used to statically map NetBIOS names to IP addresses. The NetBIOS name and TCP/IP host name can be two different names on an NT 4 workstation, although this is not recommended. Despite Microsoft s dependence on NetBIOS names, your FW-1 NG AI relies on TCP/IP host names .

Windows 2000 uses host name resolution to find services on the network. DNS is the network service that a Windows 2000 workstation can use to resolve name to IP addresses. However, the hosts file will always be parsed first; if there is no mapping, the host will attempt DNS resolution.

end sidebar
 

Other Global Properties that you should consider changing are related to logs and alerts, as shown in Figure 8.2. Although the default settings are generally effective, you might need to make changes, depending on your environment. For example, you can limit the amount of activity that gets logged to the log file by decreasing the Excessive log grace period . This is the period in seconds that FW-1 NG AI will not log the same activity multiple times. Decreasing this number will probably reduce the number of resources that the Log Unification Engine uses to consolidate activity into the log view.

click to expand
Figure 8.2: Log and Alert Global Properties

There are also a couple of performance tweaks that will not affect firewall throughput but that do have an effect on overall performance. One such setting is the SmartView Tracker resolver timeout . Decreasing this value will decrease the amount of time in seconds that FW-1 NG AI spends resolving IP addresses to names for log entries. If names are not critical to your understanding of the logs and if DNS queries frequently timeout, this option would be good to decrease. Doing so increases the Log Viewer but not the firewall throughput.

And finally, you can decrease the Status fetching interval to decrease the frequency in seconds that the management server queries the modules that it manages for status. If your environment is pretty static, this setting could be reduced. Again, this decrease will not affect firewall throughput and will not even be an issue if the System Status window is not open and querying modules.

Administering NG for Performance

In addition to the initial configuration of FW-1 NG AI, you should keep in mind a number of administration best practices to ensure that the firewall is performing up to expectations and its capabilities:

  • Keep the Rule Base simple.

  • Put the most frequently applied rules near the top of the Rule Base.

  • Keep accounting to a minimum.

  • Use the Active Log mode sparingly.

  • Use logging wisely.

  • Consider limiting the use of security servers.

  • Implement NAT wisely.

  • Avoid the use of domain objects.

The first recommendation, to keep the Rule Base simple, will probably have the greatest impact on overall performance. Unfortunately, it is the most difficult to define and control. The reason this is so important is that every packet that isn t a part of an existing connection must be evaluated against the Rule Base sequentially, from the top to the bottom, until a match is found. A long, complex policy will introduce latency into the processing of packets, not to mention that a long, complex policy is hard to administer. When making modifications to the Rule Base, you should consider the best way to write the rule and where to place it. For example, instead of writing an extra rule to give FTP to the internal network, if you already have a rule for HTTP, simply add FTP to the HTTP rule. Just remember that there is almost always a simpler way to write rules. Keep the number of rules as low as possible.

start sidebar
Designing & Planning
Top Performers

On the top end, Check Point has posted a number of top-performance numbers for throughput, concurrent firewall connections, and other data. According to Check Point, it is possible to have up to 4+ Gbps in a software installation. A firewall appliance optimized installation can see throughput upward of 8 Gbps, as shown in Table 8.1.

end sidebar
 
Table 8.1: FireWall-1 Throughput

Platform

Mbps

Windows 2000/NT Dual Xeon 2.4 GHz

625

Solaris Dual UltraSPARC-III Cu 750 MHz

900

Linux Dual Xeon 1.7 GHz

1,000

SecurePlatform Dual Xeon

4,000

Nokia IP740

2,000

Nortel Alteon Switch Firewall System 5710

4,200

Crossbeam X40

8,000

Putting this in perspective, keep in mind that the average Internet connection is around T1 speeds of 1.54 Mbps. Unless your firewall is protecting enclave networks internally running at Gigabit speeds or an OC12 connection to the Internet, the firewall will not be a performance bottleneck.

Another statistic, concurrent connections, is the number of connections maintained between hosts on either side of the firewall. The number of connections is highly memory dependent. On an installation with 512 MB of memory, Check Point NG AI can support 1,000,000 concurrent connections. That same installation with 512 MB of memory can support 20,000 VPN tunnels. You will probably run out of bandwidth before you exceed one of these limiting factors. Hopefully this proves to some extent that FW-1 architecture can meet the most demanding environments. In fact, performance issues are typically a result of administration or configuration issues. If you would like more performance information, you can visit www.checkpoint.com/techsupport/documentation/FW-1_VPN-1_performance.html.

It s also interesting to note that Check Point has released VPN-1 Edge devices, which are hardware/software combinations that produce very high speeds for small offices at a very low price.

Remember in Chapter 4 we looked at a security policy that allowed our internal users the use of HTTP to anywhere and the use of HTTPS everywhere but the local service net. We chose to write the rule as Source- LAN, Destination- Service Net, Service -HTTP / HTTPS, Action -Accept, and Track- None with the Destination- Service Net Negated . And because another element of our policy allowed everyone HTTP access to the Web server in the service net, we wrote a second rule as Source- Any , Destination- Web Server , Service- HTTP , Action- Accept , and Track- Log . This rule could have been much more complicated. For example, we could have written our Rule Base to look like Figure 8.3.

click to expand
Figure 8.3: A Bad Example

Translating our policy this way, we used three rules instead of two. If we repeated this process over and over while writing the Rule Base, we would have one-third more rules than we need!

In addition to keeping the Rule Base simple, put the most frequently applied rules near the top. This will get packets through inspection more quickly and routed by the OS. Remember that a packet is processed from top to bottom until a match is made on the Rule Base; so, when optimizing, be aware of the effect of reordering rules. As an aid to optimization, monitoring your logs using the FW-1 predefined selection criteria can help you determine the most frequently applied rules. Take a look at Figure 8.4. Here you will see the most activity on Rule 12, which allows HTTP traffic outbound. Although this isn t enough information for you to decide that Rule 12 should be moved up, it is the kind of monitoring you should undertake. Keep in mind that you need to log all rules to see what is going on and that some rule order can t be changed or else it weakens the security policy.

click to expand
Figure 8.4: Logs and Optimum Rule Placement

Accounting is an improved feature in FW-1 NG AI. In previous versions, accounting decreased performance 10 to 15 percent. However, because of NG

AI s consolidation of connection tables, accounting information need only be pulled from one table and written to one log. Although this makes accounting in NG AI much more efficient, the accounting data is still pulled from the logaccount.fwl file and consolidated into the fw.log by the Log Unification Engine. Obviously, this extra work requires resources. Unfortunately still, rules that use Account as the Action , such as Figure 8.5, have a price and should be implemented only as required by policy and when it is worth the performance hit.

click to expand
Figure 8.5: Rules That Perform Accounting

As with accounting, using the Active Mode log requires that resources be used to consolidate log data. As a result, use the Active Mode logs only when actively blocking connections. The section on Active Mode logging discusses this topic in further detail.

Although one of the primary functions of the firewall is to monitor and log connections, carefully consider what is being logged. Over-logging not only decreases performance, it also may make it hard to review the logs. One hint is to create a special rule that drops and doesn t log noisy services such as NetBIOS or DHCP.

start sidebar
Designing & Planning
Extreme Performance

If you need even greater performance or need to maintain a high number of concurrent VPN tunnels, you should consider Check Point s SecureXL API technology and hardware acceleration. First, the SecureXL API is an open interface that vendors can use to offload security operations such as state table lookups, encryption, and network address translation. One currently available solution that utilizes the SecureXL API is the Nortel Alteon Switched Firewall and Check Point s own FW-1/VPN-1; another is the SecureXL Turbocard. Second, using optimized hardware cards with network processors that offload encryption from the CPU, you can speed up encryption and decryption operations without burning in the security capabilities like an ASIC.

end sidebar
 

If you decide to use security servers for HTTP, FTP, SMTP, Rlogin, or Telnet, realize that the kernel may divert all packets that meet the Rule Base demand for content checking or authentication to the security servers for processing. The security servers then perform any authentication or content checking as required, and then, if allowed, they establish a second connection to the destination host on behalf of the originating source host. Both the connection from the source to the security server and from the security server to the destination are maintained in the connections table. You can open the fwauthd.conf file in a text editor to view which security servers are running. Security servers are turned on automatically when a rule requires content checking or authentication unless the Performance Pack is enabled or SecureXL is being used. With NG AI, more inspection capabilities have been added to the INSPECT engine, enabling options that previously required a security server to be handled in the kernel without the significant performance overhead. A good example of this is the option to select Enhance UFP performance in a URI resource that uses kernel inspection instead of a security server.

In addition, if you are using the HTTP security server, you can improve performance for your users by increasing the number of concurrent processes. Setting this number too high can degrade overall performance, so a good number is usually 4. Keep in mind, however, that Check Point recommends that you have multiple processors if you intend to modify this value. To make the change for additional HTTP processes, in the fwauthd.conf, modify the corresponding line for HTTP to the following:

 80     in.ahttpd    wait    -4 

Another recommendation is to consider limiting the number of NAT rules in your Address Translation Rule Base. Although this is probably something you will just have to live with, realize that NAT requires considerable resources. Fortunately, NAT performance is one of the things that Check Point claims to have improved in NG due to the single connection table. Moreover, you can further optimize your usage of NAT by limiting rules and combining objects intended for NAT. For example, if you or the network engineers have efficiently laid out the IP addressing scheme, you can use a subnet mask to combine multiple networks. For example, if you have several internal networks that are sequential, such as 172.16.1.0, 172.16.2.0, 172.16.3.0, , 172.16.128.0, all with 255.255.255.0 subnet masks, you can create these objects separately for use in the Security Policy Rule Base if you need specific access restrictions for each network. However, if you don t need separate restrictions for each network, you can supernet them by creating one object with the subnet mask of 255.255.128.0 subnet mask. This will cover all the networks 172.16.1.0 through 172.16.128.0 as mentioned.

And finally, try to avoid the use of domain objects ”network objects based on the TCP/IP domain name. Using them is unwise because every time a packet is matched up with a rule that has a domain object, FW-1 NG must do a domain name lookup. This slows the overall processing of packets. If you must use domain objects, place them as far down in the policy as possible so that connections that do not require that name resolution be accepted can be processed more quickly.

Monitoring NG for Performance

Memory is probably the most important commodity to Check Point FW-1 NG ”or any other firewall, for that matter. According to Check Point, the formula for determining your required amount of memory is as follows :

 MemoryUsage = ((ConcurrentConnections)/(AverageLifetime))*(AverageLifetime + 50     seconds)*120 

ConcurrentConnections is the number of connections for hosts at one moment in time. Remember that the use of security servers will make what seems to be one connection really two. AverageLifetime of a connection is defined as the number of seconds a session will typically last from handshake to termination. You can use your accounting log to determine this figure.

No matter what the platform, you can use tools specific to FW-1 to monitor your firewall for performance. The easiest is to take a quick look at the System Status Viewer, an application that will show you the license status, alerts, and details from the different modules deployed in your enterprise.

By selecting the SVN Foundation object, you can see some performance-related details in the right windowpane, as shown in Figure 8.6. From SVN Foundation details you can view CPU usage, memory usage, and disk space.

click to expand
Figure 8.6: SVN Foundation Details

Obviously, high CPU usage that is consistently above 60 percent should be a concern, as should as a low amount of free real memory or free disk space.

A final method for checking the amount of memory available to the kernel is by executing at a command line:

 FW ctl pstat 

Executing this command will show you internal statistics of FW-1.

You can modify the amount of memory available to the kernel by changing the parameters in the Capacity Optimization section of the firewall s object.

There are also command utilities that help you understand how well the firewall is performing internally. An example is fw tab . Issuing the command fw tab “t connections “s will show you the connections table as specified by the “t , and in short format, as specified by the “s . This command will tell you how many connections are in the state table. Because the state table has a limit of 25,000 items by default, if the results are near 25,000 or if you know that you have 10,000 concurrent connections, you should increase the size of your state table. Changing the size of your state table in Check Point NG is a different process from changing it in previous versions of FW-1. In Check Point NG AI, the size of the state table is defined in objects_5_0.C, not $FWDIR/lib/table.def. Remember that new to

Check Point NG AI is the use of dbedit to modify objects_5_0.C and other system files. To alter the size of the table, follow these easy steps:

  1. Close all GUI clients that are connected to the management server.

  2. Execute dbedit .

  3. You will be prompted for the server name. (Enter the name of the localhost.)

  4. Enter your Check Point NG AI administrator user ID, followed by the password.

  5. At the Enter the Command prompt, type modify properties firewall_properties connections_limit [Value] .

  6. After pressing Enter , on the next line, type update properties firewall_properties .

  7. After entering the preceding line, you can end your dbedit session by typing Quit .

  8. Next you must reboot the machine. Any time you modify a table with the Keep attribute, you have to reboot the machine. You can tell if a table has the Keep attribute by typing fw tab -t ˜table name as shown in Figure 8.7.

    click to expand
    Figure 8.7: Viewing the Keep Attribute for Tables

  9. Finally, for changes to take effect, you must install the policy.

As you are modifying the connections table, you will probably need to modify the hash size as well. The hash size value should be a power of 2 that is as close as possible to the limit on the connections table. As you can see in Table 8.2, if you have modified the connection limit to 50,000, you should set your hash size to 65536.

Table 8.2: Relevant Powers of 2
 

Hash Size

Connection Limit

214

16384

4097 “24576

215

32768

24577 “49152

216

65536

49153 “98304

217

131072

98305 “196608

Note  

Check Point does sell a product called SmartView Monitor (formerly the Real-Time Monitor) that integrates nicely into the Check Point framework. SmartView Monitor is included with SmartCenter Pro, SmartCenter Express Plus, or SmartView. It enables you to monitor bandwidth, bandwidth loss, and round-trip time in end-to-end VPNs.

Platform Specific Tools

In addition to the Check Point NG AI tools provided for measuring performance on Windows NT, a number of FW-1 specific counters are installed to the Windows NT Performance Monitor. The counters provided include the following:

  • Number of packets accepted

  • Number of packets dropped

  • Number of current connections

  • Number of packets decrypted

  • Number of packets encrypted

  • Number of packets that fail encrypt/decrypt

  • Amount of hash memory currently in use

  • Amount of system kernel memory currently in use

  • Number of packets logged

  • Number of packets rejected

  • Number of total packets processed

  • Number of packets undergoing address translation

These counters can be invaluable in further tuning your firewall.

Performance Conclusion

And finally, if none of these suggestions improves the performance of your FW-1 NG, consider upgrading your hardware based on the recommendations in Table 8.3 and on your own observations of CPU, memory, and I/O usage:

Table 8.3: Quick Recommendations

If you require a large amount of

Then you need

Encryption/decryption

CPU

Network address translation

Memory

Logging

Memory and I/O

Sessions

Memory

Security servers

CPU and I/O




Check Point NG[s]AI
Check Point NG[s]AI
ISBN: 735623015
EAN: N/A
Year: 2004
Pages: 149

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net