Each of the aforementioned basic configurations and a variety of combinations that are derived from them are valid. Further, it is feasible to install additional Check Point products with the Integrity module. The following list presents a few of the many methods of installing and configuring this product.

First, we need to log in. Usually, you’d be connecting SmartDashboard to your SmartCenter, but there is also the option of Demo mode. This allows you to get familiar with the interface and take a look at some advanced configurations without risking any damage, because the only configuration you are changing is the local Demo databases. You can choose a number of different Demo databases, varying in complexity from a firewall only to advanced VPN scenarios. When you use Demo mode, SmartDashboard shows that it is connected to a SmartCenter named *local—that’s really just some static files. You can run SmartDashboard in Demo mode without any SmartCenter installed—choose a Demo Installation from your NGX CD.

For our tour, we will log in using Demo mode with the Basic Firewall +VPN database, as shown in Figure 3.1.

Figure 3.1. Logging in Using Demo Mode

The SmartDashboard window includes a number of different panes. Our tour begins with the rulebases—those Check Point administrators who remember FireWall-1 v4 will recall when there was nothing more than the Security and Address Translation rulebases!

The tabs in Figure 3.2 are the default tabs we see in the Demo mode. Each tab configures a different product feature, the Security tab being the most commonly used—the firewall rulebase. Some of the tabs reflect a particular policy, where different policies can be loaded and applied to different gateways, whereas others apply globally across all the gateways managed by your SmartCenter. The combination of policies that you view at one time is called a policy package. Other tabs will appear if other product features are enabled.

Figure 3.2. Rulebase Pane Tabs

To get your first firewall policy up and running, you probably will use only the Security and perhaps Address Translation tabs, but here is the full list.

Web Access Tab

This tab is the global configuration of UserAuthority WebAccess modules. UA WebAccess software can be installed on Web servers to provide URL level access control and single sign-on integration with gateways. This tab is disabled by default—if you are installing a WebAccess module, enable it in the Global Properties, UserAuthority page (see Figure 3.3).

Figure 3.3. Enabling the Web Access Tab

To the left of the rulebases, you should see the Objects Tree, as shown in Figure 3.4.

Figure 3.4. The Objects Tree Pane

The tree is a convenient way to browse, edit, and create the objects that you need to define for your rulebases. Objects are needed to represent the SmartCenter, gateways, networks, and hosts you reference in policies, user accounts, and so on.

There are actually several trees of objects—use the tabs at the top of the pane to select the required tree. To create new objects, simply right-click the top of the tree and choose New. To edit an object, double-click it.

This pane shows objects in a list format. The contents of the list are controlled by what is currently selected in the Objects Tree. For example, select the Network Objects—Nodes branch to see a list of all nodes.

SmartMap provides a visual representation of the network topology that can be gleaned from the network objects that have been defined. SmartMap can be disabled in Global Properties, SmartMap page. If you are not using SmartMap, disable it—this avoids the overhead of SmartDashboard calculating the visual topology.

Although most of the policy and object management can be performed via the panes we’ve looked at, there is plenty more that can be achieved via the drop-down menus or, for some of the most common actions, the toolbars.

To save changes to objects and the current policy package, create new policy packages, or open a different policy package, use the File menu. Remember that a policy package is all the policies you can see on the rulebase pane. If you wish to take a copy of just one of the policies—say the Desktop Policy—and save it in a new package, use the Copy Policy to Package option and specify a name for your new policy package.

Saving the Policy Package does not actually change the policy running on your gateways—it’s just updating the SmartCenter database. To update your gateways, use the Policy menu, Install Policy option—or find the toolbar icon for Install Policies.

There are plenty more menu options to explore in your own time. The final option we will look at is the big daddy of all: Global Properties, from the Policy menu.

The Global Properties window, as the name suggests, defines settings and fine-tuning of your Check Point systems that apply globally (rather than per policy or per gateway). To open the window from the menus, choose Policy | Global Properties, or from the toolbar, choose the icon that looks like a bulleted list (see Figure 3.5).

Figure 3.5. The Global Properties Window

A detailed look at everything here easily could fill a whole book! We’ll take a look at the more useful settings as well as new additions to NGX. Looking at new additions is fun since it’s an NGX book. NG users will find this useful.

In previous versions, every rule had a number. At a stretch, the administrator may have bothered to scroll over to the far left column of the rule to add a comment. Neither helped clearly identify the purpose of each rule when browsing through the rulebase.

NGX introduces rule names, now the first column in every rule. Describing each rule in one or two words should make the rulebase far more readable. Figure 3.6 shows an example of annotating a rulebase in this way.

Figure 3.6. Naming Rules

Also new are Unique Rule IDs. Every rule now has a hidden, unique ID that does not change throughout the rule’s life span—unlike the visible rule number, which will change when rules above are added or removed. This feature comes into its own when viewing log entries in SmartView Tracker. Now it is possible to identify which rule triggered the log entry—whether or not the rule number has since changed. For good measure, the rule name is included in the log entry, too. An example of the logging you’ll see is shown in Figure 3.7.

Figure 3.7. Logging with Rule IDs and Names

There is also an option in SmartDashboard to launch SmartView Tracker and view all logs relating to a rule. Right-click the rule to try this, as shown in Figure 3.8.

Figure 3.8. Launching SmartView Tracker for a Specific Rule

It is possible to specify a convention when defining a group. This consists of conditions based on object name, color, and IP, as shown in Figure 3.9.

Figure 3.9. Groups with Conventions

This can be used to assist when adding members to a group: a list of existing objects that meet the convention is provided. In addition, in the future when a new object is defined, SmartDashboard will check whether it meets a group convention. If so, you will be prompted to add the object to the relevant group.

The Network Objects view in the Object Tree pane has been enhanced for Group objects to allow “drilling down” into groups. Right-click the Groups branch and choose Show Groups Hierarchy, as shown in Figure 3.10.

Figure 3.10. Enabling Group Hierarchy View

The tree will now show the members of groups, including subgroups. An example is shown in Figure 3.11.

Figure 3.11. Drilling into Groups

For those times when you need to create a large number of similar objects, Clone Object is here to help. Right-click any Node or Network object and you have the option to Clone. This creates a new object with the same properties. Just change the name and IP and you are done.

In previous versions, it was possible to supply a Session Description when logging in to SmartDashboard, and this would be written to the Audit Log. This provided a rudimentary way of tracking the reason for which administrators had logged into SmartDashboard, should they choose to supply one.

SmartDashboard NGX provides the ability to require a Session Description in order to log in: enable this in Global Properties, SmartCenter Access. However, as yet there is no way of forcing the administrator to enter something helpful.

In the rulebase, tooltips are provided for host and network objects—hover your mouse pointer over an object for a summary: for example, for a network, its IP, subnet mask, and object comment (see Figure 3.12). This is particularly useful when analyzing a rulebase, allowing you to understand what the objects used in rules are representing. Of course, to make the tooltip really useful, you do need to have provided a helpful Comment in the object definition. This should be considered standard practice in order to make the effect of your rulebase clear. Losing track of what objects represent can easily lead to your defined security policy not providing the protection that you expected, or perhaps (in practice, more often) blocking legitimate traffic.

Figure 3.12. Tooltips Are Your Friend

We’ve now completed our SmartDashboard tour and highlighted the new features in NGX. With some luck you are now familiar enough with the interface to create a simple security policy.

Your first job is to create an administrator’s user account. Select the Users tab of the Objects Tree, right-click on Administrators, and choose New Administrator. Your user ID will be clauss. In order to configure your level of privileges, create a new Permissions Profile called fulladmin. You should select Read/Write Access, and the ability to Manage Administrators so that you can create further accounts for other admins, operators, and so on. Don’t forget to choose an authentication method, too—in the object Admin Auth tab, you should select a Check Point password and set it. Note you can use stronger external mechanisms if you wish, such as RSA SecurID. Additionally, you can create a certificate and use that to authenticate instead of a regular password.

Now that you have an administrator account, save your changes (File | Save) and then exit from SmartDashboard. Then, start SmartDashboard and log in again, this time using the new account.

You are now ready to hook up the SmartCenter to your new VPN-1 gateway, vixen. As part of the installation of NGX on vixen, you were supplied a SIC activation key: you need that in order to define your object for the gateway.

To create your object, right-click on the Network Objects tree and choose New | Check Point | VPN-1 Pro/Express Gateway. You are prompted for the choice of a wizard or manual classic configuration. Unless you have a real aversion to wizards, the wizard is pretty reliable. We recommend that you use the wizard, supplying the following details:

Hopefully the SIC connection is successful—if not, take a look at the sidebar, “Can’t Communicate?”

The wizard will now ask you whether to automatically retrieve interfaces and topology from the gateway. This will fetch a list of interfaces and inspect the routing tables on the gateway in order to identify what subnets are connected to each interface of the gateway, creating any necessary objects for you—on complex networks this can save you a lot of time. It is also important that the interface list is defined accurately, so automatically fetching the list is highly recommended.

When the wizard completes, you can check the box to Edit the Gateways Properties to review the configuration of the new object. The hostname, IP address, OS, and Products Installed should all be as required.

It’s worth reviewing all the objects settings: first, to make sure the wizard got it right (they aren’t perfect, you know), and second, so that you are aware of the available options to be configured if you need to later. The object for vixen is shown in Figure 3.15.

Figure 3.15. Gateway Object for Vixen

If you are satisfied that these general properties look good, move on to the Topology page for the object. Here you’ll see a list of interfaces on the gateway and the IP addresses behind those interfaces, based on the routing tables. On your vixen gateway, the eth4c0 interface has an additional routed subnet behind that interface and SmartDashboard has created objects to reflect that. The topology is shown in Figure 3.16.

Figure 3.16. Gateway Topology

To edit the settings for each interface, just double-click the interface name. As well as the name and IP, the topology should be reviewed to ensure it correctly reflects what IP addresses lie behind that interface. Accurately configuring this allows anti-spoofing protection to be enabled on the interface—essential in securing your networks against spoofed packets arriving at untrusted interfaces.

You may want to browse through the raft of other pages and settings available in the gateway object, but these are best left at their defaults for now.

Before defining rules in your policy, you will likely need to define a few objects to represent internal hosts and networks. SmartDashboard automatically created objects for two of your internal networks when it fetched the gateway topology, so you can just change those object names to something more meaningful rather than creating new objects.

You will also create a group, sleigh_internal, which will include all your internal networks. To add the networks to the group, just drag and drop them into the group using the Objects Tree.

Figure 3.17 shows the Objects Tree with all our objects defined. You have objects for your networks plus an object for the Internet mail relay server on our DMZ. There is also a group that was automatically defined for use in the gateway topology.

Figure 3.17. The Objects Tree

A firewall security policy should be designed with the principle of least privilege in mind: accept only the traffic that is required, drop anything else. When the firewall gateway implements the rulebase, each new connection is compared against the rulebase top down—when a rule is matched, that action is followed and no more rules are checked. Check Point helps you out with best practice by dropping any traffic that is not accepted by either implied rules or a rule you have added to the policy—in other words, there is an invisible rule at the bottom of rulebase: drop anything.

Two rules are usually explicitly added as part of every policy: the Stealth rule and the Clean Up rule.

A Stealth rule is placed near the top of the policy and explicitly blocks access to the firewall. It should be placed above other more general rules that would otherwise allow access (maybe a rule allowing internal users access to the Internet—i.e., any address—which would include the firewall itself). Don’t forget to add a rule above the Stealth rule to allow access for administrators—for example, ssh to the gateway.

A Clean Up rule is placed at the bottom of the policy and explicitly drops and logs all traffic that has not matched other rules. This traffic would have been dropped by the gateway anyway because of the invisible drop-anything rule, but the Clean Up rule ensures it gets logged.

In addition to the aforementioned rules, your security policy should be developed in order to reflect the formal network usage policies of your organization.

Before we begin creating rules, it is a good idea to save the Policy Package using a descriptive name. You will notice that the current policy name is “Standard.” It is good practice to use policy names that identify the date/time of the policy, or some versioning reference. There are two reasons for this—first, it is easy to check what revision of the policy package is installed on a gateway—SmartView Monitor will show the current installed package name. Second, it makes it easy to roll back changes to the policy (although be aware that saving the policy does not provide version control over changes to objects—we’ll discuss Change Management later in this chapter). To save the policy under a new name, use File | Save As.

To add a rule to the rulebase, use the Rules Toolbar. This provides buttons for adding rules at the top or bottom of the policy, and above or below the current selected rule. Clicking one of these buttons adds a rule that by default will drop all traffic. First you should give the rule a Name; then we can modify the rule Source, Destination, and Service by dragging objects into the fields or right-clicking and adding objects from a list. Then choose the Action you wish to take if a connection matches this rule (right-click and choose from the list); to start with, choose between Accept or Drop. Other options can be used to perform authentication or require encryption. The Reject option drops traffic but informs the client by means of either a TCP Reset or ICMP destination unreachable message.

The full security rulebase for our example is shown in Figure 3.18.

Figure 3.18. A Full Example Rulebase

Reviewing the rules, you have allowed our administrators PC access to the gateway and SmartCenter for the required protocols. You had to define a new Service object (right-click in the Services tab of Objects Tree) to represent the Microsoft Remote Desktop protocol (TCP port 3389). You ensured that ssh access to the gateway is using the more secure ssh version 2, not version 1, by using the special service ssh_version_2.

Once you have your policy defined, remember to review the implied rules that are enabled in Global Properties. The defaults in NGX are sensible, but make sure that you are aware of what they are. In the example in this chapter, you have left Control Connections and Outgoing Packets from Gateway enabled. It is a good idea to enable Log Implied Rules so that it is clear what connections are being accepted and dropped.

To be allowed to access the Internet, and for your mail relay to receive incoming mail, you need to configure some address translation. Add Hide NAT to your internal networks (hiding behind the gateway itself) and Static NAT to your mail relay. The mail relay will be translated to an address supplied by our ISP, in the same range as our gateway external IP. This is simple to configure using Automatic NAT—edit the relevant objects and configure the NAT page. Figures 3.19 and 3.20 show the NAT configuration on an internal network object and the mail relay object.

Figure 3.19. Internal Network Hide NAT Configuration

Figure 3.20. Host Object Static NAT Configuration

In the Network Address Translation rulebase tab, you can review the rules that have been created. You can add more rules to the rulebase manually if you need to—this is discussed further in the Network Address Translation chapter.

At last you are ready to test your policy!

To install the policy, use the Policy toolbar—the policy install button shows a rulebase with a downward arrow above it. SmartDashboard will prompt you to select which gateways the policy should be installed on—in this case, there is only one gateway to choose from, and it will be selected by default. If you later choose to enable the QoS or Policy Server modules on the gateway, you will also be able to select whether you wish to update the QoS and Desktop Security policies. Clicking OK to continue the process will show the Install Progress dialog box. This will indicate that the policy is first Verifying and then Installing. The Verify phase identifies any logical problems with your policy—for example, rules that “hide” later rules, making the later rule redundant. Installation is the process of connecting to the gateway, transferring the policy and database files to the gateway, instructing the gateway to update its policy, and waiting for a successful confirmation from the gateway. If all this succeeds, you will see a reassuring large green tick appear, as in Figure 3.21.

Figure 3.21. Success!

If you see anything else—red crosses, warnings, or the like—click the Show Errors button that will appear in order to view the reasons for this. This may not be critical in some cases—sometimes it is just a recommendation about your policy. Other times it will indicate the policy has not been installed, maybe due to connectivity to the gateway or some other serious error during the policy compilation process.

Before you make any further changes to the policy, you may want to save the current policy using a new name, indicating a new policy version.

Once you have your policy installed it is time to test whether connectivity is as expected: now is probably a good time to read the SmartView Tracker chapter so you can observe your connections being accepted, and the bad guys being dropped. Hopefully.

Rulebases tend to quickly become long and cumbersome—you might even end up with a few hundred rules. Keep in mind that the longer the rulebase, the more work the gateway needs to do per new connection. This can be reduced by making sure that the most common connections match rules early in the rulebase. The tools described in this section will help manage bigger rulebases.

Right-click on Network Objects in the Objects Tree and choose New | Check Point | Connectra Gateway or Interspect Gateway.

Define the object’s name and IP, then use the Communication button to initialize SIC keys. Configured objects are shown in Figures 3.22 and 3.23.

Figure 3.22. Check Point Connectra Object

Figure 3.23. Check Point Interspect Object

Once the object has been defined, you need to update the SmartCenter running configuration in order to allow connections from the device. To do this, use the SmartDashboard menu option Policy | Install Database. Then on the new object, you can right-click and choose Manage Device in order to launch the management client for the device.

In the Connectra or Interspect management interface, configure Central Management/Logging as per the device documentation. You will need to specify the SmartCenter name/IP and the object name that you have given to the new object.

After these changes have been made, the device logs should begin to appear in SmartView Tracker.

SmartDefense Updates

SmartDashboard also provides centralized SmartDefense Updates for Connectra and Interspect. If you have purchased a SmartDefense subscription for the device, you can update its SmartDefense features directly from the SmartDashboard rather than the management interface of the device: right-click on the object and choose SmartDefense Service Update. The latest SmartDefense database can then be downloaded to the SmartCenter and pushed out to internal Connectra and Interspect gateways, as shown in Figure 3.24.

Figure 3.24. Updating Connectra SmartDefense from SmartDashboard

SmartUpdate Enhancements

In NGX 65, the license Repository window of SmartUpdate displays both contracts and regular licenses. Selecting a particular contract will show the contract’s properties including the contract ID and expiration date. It will also provide information as to the gateways that are included within the contract.

The License management window can display if an individual license is linked to a contract. SmartUpdate will also verify if the contract file on the gateway is more up to date then the contract file on the SmartCenter Server, adding an additional menu item to enable the more up-to-date contract information to be loaded into the management server.

The SmartPortal interface provides:

The SmartPortal server is available as an option when you first install NGX on the supported platforms: Windows, Solaris, Red Hat EL 3.0, and SecurePlatform.

Note that SmartPortal requires a license, although that license is included in most VPN-1 Pro and some extended VPN-1 Express licenses. To check yours, run cplic check swp on your SmartCenter.

If you didn’t choose SmartPortal at install time, you can just run the wrapper again on Windows or Solaris—it should detect that NGX is already installed and give you the option to install additional products. Do this and choose SmartPortal. On SecurePlatform, you will need to install SmartPortal manually: enter Expert mode from a console session and run the command:

Usually you would install SmartPortal on the SmartCenter; however, it is possible to install it on other Check Point hosts or its own dedicated server. The SmartPortal server then makes an onward connection to the SmartCenter. A dedicated server would be advisable if there are likely to be many concurrent SmartPortal users.

Once the product is installed, ensure that the relevant object has SmartPortal checked in the Check Point Products list. Having done so, perform a database install to the SmartCenter (Policy | Install Database).

To access the portal, point your browser to https://smartcenter-host:4433.

At the welcome page (see Figure 3.25), supply your administrator credentials (this should be an account created in SmartDashboard) and the name (or IP) of the SmartCenter server.

Figure 3.25. Welcome to SmartPortal

After a few seconds you should be connected to the SmartPortal front page, as shown in Figure 3.26. If the SmartPortal connection fails, check that you have correctly followed the installation steps and are using the correct SmartDashboard administrator credentials. Check that the SmartCenter Server name you supplied resolves successfully on the server running SmartPortal.

Figure 3.26. Logged In: SmartPortal Front Page

A sidebar allows selection of the different features.

The Gateway Status page will show a summary of status for each gateway and the SmartCenter itself (see Figure 3.27). To see more detailed status information, click the name of the gateway.

Figure 3.27. SmartPortal Gateway Status Page

The Logs page can show either the Traffic Log or the Audit Log. The view is similar to SmartView Tracker but with a restricted set of columns shown. The Traffic Log is shown in Figure 3.28. Note the toolbar allowing navigation of the log, automatic scrolling, searching, filtering, and access to older log files. If the administrator has write access to the logs, it is possible to switch and purge logs. Clicking the record number will open a new window showing that log entry.

Figure 3.28. SmartPortal Traffic Log Page

The Policy and Objects page provides a view of the Security rulebase. Figure 3.29 shows the SmartPortal view of the policy that was created in SmartDashboard.

Figure 3.29. SmartPortal Policy View

If you have multiple policy packages, you can view the security rulebase from these packages, too.

There are a number of pages for viewing objects: Network Objects, Services, Users, and Time objects. The views are equivalent to the Objects List view in SmartDashboard. A simple Filter on object name can be used to narrow down the list.