Check Point Software Technologies OPSEC, FireWall-1/VPN-1 4.1, Check Point RealSecure

Check Point was the only vendor to supply a fully integrated suite of applications. Although the products for our tests were from multiple vendors, the integration was tight, well-documented and easy-to-implement. Check Point boasts of more than 270 OPSEC partners, and there are even more developers attempting to integrate. By far, Check Point's OPSEC program leads the pack in providing a large number of third-party integrated applications. In response to our request to secure our Internet traffic, Check Point sent FireWall-1/VPN-1; Check Point RealSecure 5.0, an intrusion-detection application; Trend Micro InterScan VirusWall virus scanner, SurfControl SurfControl for FireWall-1 for URL filtering; and WebTrends Corp. WebTrends Fire Wall Suite reporting package. The combination of these products provided an integrated security suite that covered all the bases.

Check Point's OPSEC partner program will be the driving force behind the continued success of Check Point. Rather than purchase companies and integrate products in-house, Check Point has OPSEC bring vendors together through the use of published and supported APIs developed by the company for integrators and application vendors. To grant the OPSEC Certified logo, Check Point must test not only a vendor's software, but the documentation required to configure both the integrated product and the steps required for the firewall as well.

OPSEC-certified products are very specifically defined. A certified product is only applicable to a specific version of FireWall-1/VPN-1, the underlying OS and patch level, the version of the API used and the specific build of the integrated application. Check Point doesn't provide backward-compatibility testing unless the vendor requests and pays for it. If you are integrating existing versions of software, pay particular attention to the certification requirements. If there is a mismatch, test the integration thoroughly or make the version match as needed. If you are looking at a new installation, your value-added reseller or integrator (Check Point does not sell directly to the public) should have compatible versions.

Installation and Integration

We installed the individual servers on separate hardware; each one took no longer than 10 minutes to install and integrate. Within an hour, we had all the components working together. We originally integrated the products without security encryption or authentication to make sure we had communication channels properly configured. Once we had verified the products were working, we migrated to authenticated OPSEC connections for all interserver communication. While the process seems complex, it is not too difficult to complete. In each of the products we tested, we selected a check box that turned on the authentication mechanism. We then used a Check Point-supplied program, which ships with every OPSEC-certified application, to enter the password with which the product would authenticate. Next, we edited the fwopsec.conf file on FireWall-1 to define how products will communicate with FireWall-1.

Depending on whether the application was a server or a client--both the Trend Micro VirusWall and SurfControl applications are servers, while WebTrends is a client--we had to take different steps to establish communications with FireWall-1. For server applications, we had to enter the server IP address, port number and opsec_auth (stating we would use authentication with this server) into fwopsec.conf. For client applications, we simply turned on authentication for all applications using the service. Once completed, we restarted the firewall. When the firewall restarted, we used the venerable fw putkey command (which Check Point jockeys know and love) to add the key and corresponding peer IP address for each server we were authenticating on both the firewall and the server application.

As with nearly all firewalls available today, FireWall-1 forced us to define the server objects, but we added them as a resource. Resources define application services running on servers that perform a special task in FireWall-1, such as a UFP (URL Filtering Protocol) or CVP (Content Vectoring Protocol), which is used to shuttle data to inspection servers like virus scanning. Depending on the type of resource you are defining, you will have various options. In any case, the process has three steps. We first had to define the network object, which gave a name to an IP address. We then defined the server object, which ties a network object to a specific service like CVP or UFP. Finally, we defined a resource, which ties the server object to a specific protocol service. Once the resource is defined, it can be used in the Policy Manager just as with any other service. Different resources will have different configuration options depending on the type of resource. Using SurfControl as an example, once we defined the server object, we were able to import the URL category from SurfControl into FireWall-1.

Because resources are used just like services under the Check Point model, we could reuse them in multiple rules. For example, if we wanted to allow only the marketing department to have access to news sites, we would create two rules permitting that in the policy.

First, we would permit anyone from marketing to access news by selecting the appropriate categories in the UFP resource we had just defined and implementing a second rule denying access to news for everyone else. Anyone on the marketing network trying to access a news site would hit the first rule and pass on through, while engineering, for example, would be blocked. Similarly, defining virus scanning is just as simple by adding VirusWall as a resource to FireWall-1.

All the policy definition takes place in the management GUI. Depending on how granular you make your security policy, the rule base can get quite large. Fortunately, the rule-base view can be filtered by very specific criteria through the use of queries. It does take some time to learn how to build queries, but they are powerful tools for honing in on specific rules. For example, we configured several queries keyed to specific resources so we could make changes quickly.

Monitoring the Pulse

More than anything else, tracking security-related events and network anomalies is critical for proactive security. Your administrators are the best defense against attacks, bar none. To harness that power, you need to have strong reporting and alerting mechanisms. While each application keeps its own log files, efficient monitoring dictates that centralized reporting be established.

Check Point's Log Viewer application is not the most robust tool available, but it is extremely useful for real-time firewall monitoring. Judicious use of the logging per firewall rule lets you pare down what could be high-volume traffic to a manageable level. Additionally, some OPSEC applications log data to the firewall log utility.

On our network, for example, we ran multiple SNMP management stations that discovered and monitored the network. Because we wanted to log all unauthorized traffic hitting the firewall, our logs were quickly getting filled with garbage. After adding a few rules that denied specific traffic from specific hosts without logging the attempts, we ended up with mostly meaningful entries.

Looking at the log viewer is useful for real-time monitoring. With experience and patience, you can learn how to filter which messages get viewed for any given set of criteria. You need to use third-party tools, however, for historical analysis and reporting. We used WebTrends Fire Wall Suite, which grabs logging information from FireWall-1 and processes it in a variety of ways.

In addition to the various traffic reports (which present useful data like top talkers, top protocols, most-used URLs and the like), some custom reports can be generated as well. WebTrends will show some exception information, but that is limited to actions taken by the firewall, such as dropped or rejected packets. It won't report on other events logged to the FireWall-1 log utility, such as virus entries or denied URL entries. You'll have to rely on the FireWall-1 logs for that data.

Real-time reporting is leveraged through the use of alerts, which are definable in FireWall-1. For example, we set up a rule that triggered an alert when a virus in an e-mail attachment passed through the firewall. The virus event was logged in the FireWall-1 log and sent to the FireWall-1 alert mechanism in the System Status console. Unfortunately, each and every event is sent to the alerter program, so you need to be careful that you don't have more alerts than you can handle. Of course, we could also have e-mail messages or SNMP traps on events as well.

If you have alerts set for a lot of events, you would do well to have an event manager to put some intelligence behind the alerting. This is an area where Computer Associates shines, because event management is built into its TNG Framework. With OPSEC products, you will have to use your own event-management system or select another SNMP-capable or OPSEC-certified product.

Taking Automated Action

Shunning is the act of setting firewall rules based on some predefined event occurrence. For example, you may want to block a suspicious host's access to your Web server if your intrusion-detection system spots an HTTP exploit, such as the iishack buffer overflow or the more recent Unicode exploit against Microsoft's IIS (Internet Information Server). Combining Check Point Technologies' RealSecure IDS, an OEM of Internet Security Systems' RealSecure IDS, with FireWall-1 shows what might be a trend in security management. RealSecure can be configured to send just logs and alerts to FireWall-1, and you have the option to set firewall rules as well.

This is useful for a variety of potential problems. For instance, there are many attack signatures you just won't see in normal traffic, like buffer overflows.

We set up a series of rules to block access to specific source IP addresses for five minutes and send an alert and log to FireWall-1. After applying the profile in RealSecure, we ran the exploits successfully against our IIS server, but we couldn't access the server we just exploited because our IP address was blocked. Yes, there are several obvious ways around this particular blocking, but the point is not automated firewall management. The goal is automated reaction, which may give you more time to respond to an attack.

Beware of the kind of network traffic you shun, because it can be used as a denial of service. For example, if you shun traffic because of a port scan (which is easily spoofed), then a single attacker can cut you off from your customers. (See "Shunning: Good or Bad?" for more details.)

Check Point's OPSEC program is a successful solution that lets you integrate multiple security products into a cohesive security suite. If you are already using other OPSEC-certified products and you want to integrate them with FireWall-1, be careful to check the versioning, since OPSEC certification is so version- and platform-dependent.

FireWall-1/VPN-1 4.1 SP 2, $3,995 to $26,490; Enterprise Management Console with unlimited enforcement points, $11,995; Check Point RealSecure, $6,665 to $8,995; Check Point Software Technologies, (800) 429-4391; fax (650) 654-4233, www.checkpoint.com.

OPSEC partner products:

WebTrends Fire Wall Suite 3.0A, $1,199, WebTrends Corp., (503) 294-7025; fax (503) 294-7130, www.webtrends.com.

SuperScout for FireWall-1 2.0, $1,195 (50 users) to $45,000 (10,000 users), SurfControl, (831) 431-1400; fax (831) 431-1800, www.surfcontrol.com.

Trend Micro InterScan VirusWall 3.4, $29 per seat (25 seat minimum), Trend Micro, (800) 228-5651; fax (408) 257-2003, www.trendmicro.com.