3

SmartDashboard
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Terms youll need to understand:

Network object Cleanup rule Stealth rule Anti-spoofing

Concepts youll need to master:

Creating an object Creating a rule Understanding the behavior of a simple rule base Using the command line Installing and uninstalling a policy from the GUI

40

Chapter.3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Out of all the SmartConsole utilities, youll be spending the most time in SmartDashboard. This is where the security policy is defined and pushed out to the enforcement points. Before we continue, though, some terms have to be explained. They help you not only at exam time, but in your everyday job as well. The security policy is a combination of rules and system properties that come together to define how the firewalls protect your network.
In the real world, a security policy is usually associated with a document that defines in plain language which activities are permitted, which are denied, and what procedures exist for monitoring. This is where youll find things such as your acceptable use policy and incident handling procedures. As a security guy (or gal), you have the job of implementing solutions that follow and enforce the policy, which includes firewalls. However, in Check Point land, a security policy refers to the configuration of the firewalls (which should be in accordance with your company security policy). Keep them straight, for both the exam and the auditors.

The rules themselves are individual statements that permit or deny traffic. When you collect all the rules in an ordered list, its called the rule base. The rule base is processed from top to bottom, stopping at the first match. In conformance with the that which is not permitted is prohibited philosophy of Check Point, any unmatched packets are silently dropped. The rule base is only half of the security policy. The other half is the properties of the policy, which affect the generated INSPECT code by implicitly adding extra rules, changing timing values, and turning on additional security checks. It is the whole security policy that is enforced by each enforcement point, not just the rule base.

Working Within SmartDashboard

Figure 3.1 shows the SmartDashboard interface. It is divided into several panes that can be turned on and off through the View menu. The leftmost pane in the example is the objects tree. The upper-right pane is the rule base, and the lower-right pane is the objects list. Through the View menu, you can turn on other options such as SmartMap, which shows a graphical representation of your network.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SmartDashboard . . . . . . . . .

41

Figure 3.1 SmartDashboard view showing the various panes.

One important thing to note is that only one person can have a security policy open for writing at a given time. Anyone connecting in while this person has the policy locked has the choice of connecting back later or opening a read-only version of the policy. This is to ensure that two people do not make changes that adversely impact each other. The status of the policy is located in the lower-right part of the SmartDashboard frame.

Objects Tree
The leftmost pane is called the objects tree. Objects are the basis of all FireWall-1 configurations because they represent everything from a host that gets protected to a time of day at which rules are enforced. Even the enforcement points themselves are represented by objects. When creating rules, one selects the necessary objects (creating new ones if needed) and drags them into the rule base. If the object is edited later, the change carries over into the rule base. Across the top of the objects tree are tabs to select the various sections:
Network ObjectsMatches objects representing an IP address, such as

hosts, networks, and groups.

ServicesMatches the layer 4 port, or the layer 3 protocol.

42

Chapter.3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ResourcesMatches upper-layer protocols, such as http URLs (outside

the scope of the CCSA).

Servers and OPSEC ApplicationsDefines hosts that will be integrated

into the system, such as antivirus servers and other OPSEC devices (outside the scope of the CCSA).
Users and AdministratorsDefines users and groups that will be used in

authentication rules.
VPN CommunitiesDefines sites that communicate over Virtual Private

Networks (outside the scope of the CCSA). Although you can manage these objects from the objects tree, each component has an identical menu option under the Manage menu. For example, to create a new network object you could right-click on the network branch in the objects tree, or select Manage, Network Objects, New.

Network Objects
Network objects represent such things as hosts, firewalls, address ranges, and networks. Under the network objects tree you will find the objects broken down in a similar fashion:
Check PointA Check Point firewall product running on some device. It

may or may not be under your control.

NodeA host, or in the case of a multihomed host, a gateway. Interoperable DeviceA nonCheck Point firewall that will be involved in

a VPN connection.
NetworkAn object representing a network and network mask. GroupA collection of other objects, including other groups. Address RangeA contiguous list of network addresses, similar to a net-

work, but not necessarily defined by a network and netmask combination (for example, 192.168.0.1 to .99).
Dynamic ObjectAn object whose address is not fixed but is resolved on

each enforcement point.

There exist several other types of network objects, such as domains and voice-overIP objects, but they are outside the scope of the CCSA exam.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SmartDashboard . . . . . . . . .

43

Simple objects such as nodes, networks, and address ranges represent their real-life counterparts. For example, if you have a main server that is only allowed to talk to one network, you are going to need an object representing the mail server, and one representing the network. Later, youll drag these objects into a rule in order to make it enforce your policy. In these simple objects, there is very little to configure other than a name and the IP information, except for perhaps Network Address Translation (NAT), which is examined later in the book. More complex objects, such as Check Points, bring with them more options to configure depending on the type of device. Check Points are firewall objects that run software, such as FireWall-1. Although there are several types of Check Points that can be configured, it really comes down to whether the device is managed by the SmartCenter Server you are logged in to. If so, it is a regular gateway; otherwise, it is an externally managed gateway.
An externally managed gateway looks similar to a regular Check Point, though there is no SIC connection. No SIC connection means you cant push a security policy to it.

To create a new Check Point gateway, select the Manage, Network Objects menu item, click the New button, and then select Gateway. Next, give it a name and an IP address that your SmartCenter Server can contact it on. You must then initialize SIC by selecting Communication, and then entering the password you submitted during the enforcement point installation.
If you forgot the password already, or things just arent working, you can reset SIC on the enforcement point by going into the Check Point configuration utility (or cpconfig on Unix platforms), entering the Secure Internal Communications menu, and selecting the Reset option.

After initializing SIC, you should set the product information so that the proper options are shown. First, click the Get Version button to set the product versions. Then, check the boxes under the version that correspond with the role of the firewall, such as Firewall and VPN. Note that SVN Foundation is already checked, because you have established SIC connectivity. As you click products, more items appear in the left pane of the window. The detailed configurations of the items relevant to the CCSA exam are investigated throughout the rest of the book.

44

Chapter.3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Network objects can be combined with other network objects through the use of groups. Groups act merely as a container to hold multiple objects, so they do not have any configurable properties themselves other than their name, appearance, and members. Groups can also include other groups. When including a group inside another group, you have the choice of adding the members separately or adding the group object itself. For instance, if the Servers group has five node objects inside of it and you want to add it to the ImportantNodes group, adding the members separately will add the five node objects into ImportantNodes. If you add the group instead, only the one group object shows up. Functionally, they are the same because the INSPECT compiler has to check for all hosts, but they have different management implications. If you were to add a new node to the Servers group, it would show up only in ImportantNodes if you chose to add the group object. If you added the members separately, the connection to the Servers group would be lost, and no changes would be propagated from one group to the other. It is of extreme importance to understand that only other network objects can be placed inside a network group. Adding a user or a service is forbidden. It is correct to have different network objects, such as nodes and networks, within the same group, because they are all network objects.
Network groups can only contain network objects.

By using the groups in the rule base, you can manage part of your security policy through group membership rather than constantly modifying the rule base. For example, you may have a rule that controls access to all the firewalls. By creating a group object containing all the firewalls and using that in the rule, you make your rule base simpler. As you add more firewalls, simply drop the Check Point object into the group object and push your policy out to the devices. This saves the complexity of finding all the rules that need to be changed.
As with so many other things, changes in group memberships dont actually take effect until you push the policy to the enforcement point.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SmartDashboard . . . . . . . . .

45

Services
Services represent layer 37 protocols. When building your rule base, you will on many occasions want to match certain protocols, such as SMTP or HTTP, which is where services come into play. Services are not limited to the traditional TCP and UDP ports. ICMP types can also be matched, permitting you to block only echo-request type packets while allowing destination-unreachable packets to be passed through. Furthermore, IP protocols themselves can be matched, such as OSPF routing and GRE tunnels. Depending on the service, it may specify more than simply a port number. FTP, for example, has several different objects that represent passive FTP or the normal PORT mode. Depending on the method chosen, FireWall-1 also has to keep state of the data connections that will be generated in response to commands. Secure Shell (SSH) has different objects, some of which match specific protocol versions. Services under the Other branch not only can represent IP protocols such as OSPF and GRE, but also can have INSPECT code attached to the rule to further qualify traffic. The RPC branch of the tree contains services related to Remote Procedure Calls, a Unix method of communicating between applications. Rather than fixed port numbers, RPCs use program numbers which are dynamically mapped to TCP and UDP ports by a service called the portmapper. FireWall-1s Stateful Inspection can watch for the portmapper packets and read the TCP or UDP port that must be opened to allow the RPC if it has been permitted by the security policy. Although hundreds of services are predefined, the administrator can create new ones as needed through the Manage, Services, New menu options. Similar to network groups, service groups can also be created. Service groups can contain only other services, so mixing them with users and networks is not allowed. Service groups are very helpful because applications often require several ports to be opened for proper operation. Service groups let the administrator collect these ports into one object, ensuring consistency in configuration, and easier understanding for others.

Users and Administrators

Users and administrators are used to identify people rather than machines. Accounts can be defined locally, pulled off an existing directory, or a combination of both. A more detailed look at this tab will happen when we look at authentication in general in Chapter 7, Authentication and Users.

46

Chapter.3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

The Rule Base

As mentioned before, the rule base is composed of multiple rules. Figure 3.2 shows a sample rule base.

Figure 3.2 A sample rule base.

Each rule is independent of the others and is processed in sequence, meaning that the whole rule must match and that a lower numbered rule could potentially negate the effects of a higher numbered rule. This last point could use some more explanation. Take for instance the following plain-English rules:
1. HostA can connect to any web server using HTTP. 2. No one can connect to WebServer1.

HostA is able to connect to WebServer1 via HTTP by virtue of rule 1, even though rule 2 says that no one can connect to WebServer1. Because rules are processed in order, stopping with the first match, rule 1 is matched and rule 2 is never considered.

Examining a Rule
Understanding the individual components of a rule is important to understanding the function of the whole rule. One of the things youll be expected to do on both the exam and in real life is to look at a rule base and determine what traffic is matched, and what actions will be performed.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SmartDashboard . . . . . . . . .

47

These are the fields of a rule:

NumberThe rules position in the rule base. SourceA set of network objects representing the origin of the traffic. DestinationA set of network objects representing the recipient of the

traffic.
VPNIf desired, can specify that the traffic is to be encrypted. ServiceA set of service objects indicating which protocols are to be

matched.
ActionA set of predefined items telling the gateway what to do with

the packet if this rule is matched.

TrackA set of predefined items indicating whether any log entries or

other notifications are to be made if this rule is matched.

Install OnSpecifies which enforcement points will enforce this rule. TimeOptionally specifies the time at which this rule will be enforced. CommentFor administrative purposes, allows you to make a comment

about who put in the rule, what it does, and any other pertinent information. The Source, Destination, and Service fields use objects from the object tree. By double-clicking, or right-clicking and selecting Edit, you can see the specifics of the object. If multiple objects are within the same column, this forms an OR relationship. If no objects are placed in the column, it defaults to Any, meaning any value will match. If the icon for the cell has an through it, like the source address in Figure 3.3, the selection is negated. That is, a match will occur only if the cells value is not matched. With multiple objects in the column, none of the objects can match for the rule itself to be considered a match. For instance, the rule in the example will match any HTTP packets that dont come from Network1 or Network2.

Figure 3.3 A rule with a negated source address.

48

Chapter.3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

When youre reading a rule, it is important to understand that a rule represents the conversation, not the individual packets. Allowing traffic for a particular source to a given destination implicitly allows packets in the return direction after the connection has been established. The action of the rule tells FireWall-1 what to do when a match is found. These are the possible actions:
AcceptPermit this packet for further processing. DropDiscard the packet with no notification to the sender. RejectDiscard the packet, sending an ICMP unreachable message to

the sender.
User AuthRequire user authentication to allow this connection. Client AuthRequire client authentication to allow this connection. Session AuthRequire session authentication to allow this connection.

The authentication rules are covered in Chapter 7.

Most often, you will be using Accept and Drop. Firewall administrators often prefer to make protected machines invisible, except for what needs to be exposed. Rejecting a packet sends notice back to the sender, making it visible to the attacker even though it is not accepting the packets.

In addition to deciding the action, the firewall must also decide whether any logging is needed. The Track column dictates what logging will happen, and may take one of the following options:
NoneDoes nothing. LogSends a logging entry to the logging server. AccountLogs more information about the flow, including number of

packets and size.

AlertLogs the event, but also sends a pop-up message to the

SmartConsole.
SNMP TrapSends an SNMP trap to a management station. MailEmails the details about the event. User DefinedRuns a user-supplied script.

The Install On column allows you to select which firewalls are to enforce the rule. For instance, if you have a mail server in a DMZ in Winnipeg, theres

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SmartDashboard . . . . . . . . .

49

little point in having the same rule enforced in Calgary. Either network objects representing the enforcement points will be here (Check Points or Groups), or the phrase Policy Targets, meaning all firewalls. The Time column allows you to dictate when the rule is valid. Within the cell are time objects, available through Manage, Time, that specify a time or date range. Finally, comments are necessary for administrative sanity. The comment field should contain a description of why the rule is there, or any other special notes (including Dont delete this or Oracle will break!).

Creating and Deleting Rules

To create a new rule, first determine where it is to be inserted. The Rules, Add Rule menu option then gives you four choices:
Bottom Top Below Above

The first two optionsBottom and Topplace the new rule at the bottom or top of the policy, respectively. Below and Above place the new rule next to the currently highlighted rule, either above or below, depending on which you chose. The rule that is created, called the default rule, is shown in Table 3.1.
Table 3.1 The Default Rule Source Any Destination Any Service Any Action Drop Track None Install On Policy Targets Time Any

As the default rule shows, it specifies that all packets are to be dropped on all firewalls. You must change the relevant fields to do what you want. All cells can be configured by right-clicking within the cell. The Action and Track columns give you a menu with the available options; the rest of the fields require you to select Add and then select the objects you want from the menu. If it turns out you forgot to create an object, this menu also has the option to create a new object. You can also populate cells by dragging objects from the objects tree, or dragging objects from other cells.

50

Chapter.3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Deleting all the objects in a cell returns it to the default of Any.

One of the options available when you right-click one of the Source, Destination, or Service cells is Negate Cell. As discussed previously, this causes a red to be displayed through the icon, and has the effect of matching anything except for the contents of the cell. To remove a rule from service, you have two options. One is to highlight the rule and press the Delete key; the other is to select the Rules, Delete menu item. This removes the rule completely from the rule base. If you just want to disable it temporarily, right-clicking on the rules number will give you the Disable Rule(s) option (or select Rules, Disable Rule). The rule will have a red through the rules number, and will not be enforced. To re-enable the rule, do the same thing again.
When you add, delete, change, or disable a rule, it doesnt take effect until you push the security policy to the enforcement points.

Hiding and Unhiding Rules

When working on a large rule base, you may be distracted by extra rules. SmartDashboard allows you to hide the rules from viewing, while still enforcing them. Contrast this with disabling or deleting a rule, which stops the rule from being processed. You can hide a rule from view by highlighting it and selecting Rules, Hide, Hide. Rules can be unhidden through Rules, Hide, Unhide. Note that when a rule is hidden, the numbering remains unchanged, and a small white spacer appears, letting you know that there are hidden rules there.
A rule is enforced even if it is hidden. Its still compiled into the security policy even if it doesnt show in SmartDashboard. Youll get a warning message informing you of this if you push a policy with hidden rules.

Querying the Rule Base

Sometimes hiding rules isnt enough to do what you want. Often, you want to ask questions like What rules apply to HTTP traffic? This is where queries come in.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SmartDashboard . . . . . . . . .

51

Queries are handled through the Search menu, or by a right-click on the column heading in the rule base. For example, right-clicking on the Service heading and selecting Query Column brings up the dialog shown in Figure 3.4.

Figure 3.4 The Rule Base Query Clause dialog showing the available options.

The pull-down at the upper left called Column lets you select the column to search from. All the relevant objects then appear in the left side of the dialog. If you highlight the objects you are interested in, and click Add, they are moved to the right side of the screen. If there is more than one object on the right side, the radio buttons at the top become enabled, and can be used to determine whether all the objects need to appear in the rule. There is also a check box at the bottom of the dialog that negates the selection. From here, you can click Apply to hide all the rules except those that match your query, or save your query with the Save button. The Search, Manage Rule Queries menu option brings up a dialog showing your saved queries. By highlighting a saved query and clicking And, you can further refine your query to handle multiple columns. The Or button shows rules that match either query. Finally, Search, Clear Rules Query unhides all the rules and shows the entire rule base.

52

Chapter.3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

The Security Policy

As mentioned before, the security policy encompasses both the rule base that dictates what traffic is allowed, and the global properties that introduce additional behavior into the firewall. A firewall administrator should understand how to develop a rule base, and how to manage the global properties to effectively secure the network.

A Skeleton Rule Base

Check Point recommends that there be a few standard rules in your rule base, for both security reasons and ease of management. The first recommended rule is the stealth rule. The purpose of the stealth rule is to disallow any communication to the firewall itself, protecting it from attacks. This rule should be placed near the top of the rule base, with the only rules above it being those that permit or require access to the firewall. A stealth rule looks like the one shown in Table 3.2.
Table 3.2 The Stealth Rule Source Any Destination Firewalls Service Any Action Drop Track Log Install On Policy Targets Time Any

Here, the stealth rule matches anything pointed at the firewall itself and drops it with a log entry. The Firewalls object is assumed to be a group containing all the Check Point objects under management. Check Point also recommends the use of a cleanup rule, which drops and logs all traffic not caught by other rules. Recall that the default behavior of FireWall-1 is to drop any packet that is not explicitly permitted, without logging it. From a security and troubleshooting standpoint, having a log of dropped packets is extremely beneficial. Table 3.3 shows the cleanup rule.
Table 3.3 The Cleanup Rule Source Any Destination Any Service Any Action Drop Track Log Install On Policy Targets Time Any

Note that the rule specifies Any for the Source, Destination, and Service fields. Any packet that doesnt get matched by a previous rule will be matched by this one. Because the action is set to Log, you will have a record of the packet details.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SmartDashboard . . . . . . . . .

53

Implicit and Explicit Rules

Normally only the rules you enter are shown in the rule base. These are called explicit rules, because they were created explicitly. However, there are many rules that are also enforced by the firewall that you do not see. These are called implicit rules (or implied rules), and they either are a part of every policy or are added and removed as part of features and options that you configure in other parts of the interface. To view the implicit rules, pull down the View menu and select Implied Rules.
Youre viewing the implicit rules, but the menu option says Implied.

Whether or not you are viewing the implicit rules has no bearing on what gets pushed out to the enforcement points. All enforcement points receive the implied rules, and they cannot be disabled.

Global Properties
The global properties of the policy can be accessed from the Policy, Global Properties menu. This brings up a dialog showing all the property sections, along with their values. The important ones will be examined in more detail.
None of the changes to the global properties takes effect until the policy is pushed to the enforcement point.

FireWall-1 Implied Rules

The options under the FireWall-1 Implied Rules section are shown in Figure 3.5. The changes to these settings add implicit rules into the rule base. If an option is enabled, you have three choices of where it will be placed in the rule base:
FirstThe rule will be placed before the explicit rules. LastThe rule will be placed after the explicit rules. Before LastThe rule will be placed before the last explicit rule.

54

Chapter.3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 3.5 The FireWall-1 global propertiesdefaults shown.

The significance of the Before Last option is that it doesnt interfere with the cleanup rule, which drops all traffic. If you have a cleanup rule and place the implicit rule in the last position, it will never be consulted. The choice of First versus Last/Before Last has to do with your rule base. Again, an incorrect choice may cause your stealth rules to block packets that the implicit rule would otherwise allow.
Rules that govern packets coming in to the firewall (for example, RIP and DHCP) are probably best placed first in the rule base. The other rules should probably go through the rule base first, and thus be placed before last. The exception to this would be if you want the behavior to occur regardless of your rule base. Because you will almost always have a cleanup rule, you will rarely select Last.

The options in the FireWall-1 implied rules cover basic behavior of the firewall itself:
Accept VPN-1 & FireWall-1 Control ConnectionsAllows required com-

munications between SmartConsole clients, the SmartCenter management server, and enforcement points.
Accept Outgoing Packets Originating from GatewayLets the enforcement

point itself send packets to other destinations.

Accept RIPAccepts Routing Information Protocol packets (UDP

port 520).

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SmartDashboard . . . . . . . . . Accept Domain Name over UDP (Queries)Allows DNS requests to tra-

55

verse the firewall.

Accept Domain Name over TCP (Zone Transfer)Allows DNS zone trans-

fers (such as secondary DNS servers pulling a zone from the primary), and large TCP responses to DNS queries.
Accept ICMP RequestsAllows all ICMP messages, including echo-

response and echo-reply packets.

Accept CPRID Connections (SmartUpdate)Accepts connections to the

Check Point Remote Installation Daemon for FireWall-1 upgrades.

Accept Dynamic Address Modules DHCP TrafficAllows modules config-

ured as dynamically addressed to accept DHCP packets. By default, control connections, CPRID, DHCP, and packets originating from the gateway itself are accepted. Note that it is possible to lock yourself out of the firewall by pushing control connections to the end of the policy, or disallowing them entirely. After this point, you will not be able to push a policy to fix it!

Security Servers
Check Point security servers provide deeper inspection of some protocols by taking over part of the connection for popular services. The properties here control the welcome messages that the services provide, any upstream HTTP proxies, and HTTP servers to protect. Much of the functionality is now available under SmartDefense, but you will be expected to know where this configuration is.

Stateful Inspection Properties

Stateful Inspection relies heavily on tracking connections that pass through the firewall. To avoid running out of memory from too many connections, the firewall must know when to stale out older ones. Also, the firewall must know how to deal with protocols that dont have intrinsic state, such as UDP and other IP protocols. Figure 3.6 shows the default settings for the Stateful Inspection properties. The Default Session Timeouts control how long state table entries will be held. Those called virtual sessions do not have intrinsic state in the protocol, but Stateful Inspection tracks state nonetheless. For example, if a host

56

Chapter.3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

sends an ICMP packet to another host, Stateful Inspection will open a state table entry watching for reply packets.

Figure 3.6 Stateful Inspection default timeouts and other properties.

Likewise, with UDP protocols, replies are tracked based on source and destination address and ports, called Stateful UDP. Where a UDP protocol is defined as a service in the objects tree, replies can be accepted by checking the Accept Replies option in the advanced properties of the service itself. Where there is no service defined, this global property sets the behavior. If the reply is on a different port, the Any Port option must be checked to accept the packet. For Stateful ICMP, replies to echo-requests are accepted if the Replies box is checked. The Errors box controls whether ICMP error messages are allowed. If an upper-layer connection was permitted by the rule base but resulted in an ICMP error message from the remote host, this option will allow it through. As with the Stateful UDP options, you have the option of allowing response packets in unknown services to be accepted. One of the benefits of tracking every facet of the conversations flowing through the firewall is that you know the state of the connection on both ends, and can drop anything that is out of the ordinary. For example, in a TCP connection, if the firewall sees a packet for an established connection, but knows the connection doesnt exist, it will drop it if the Drop Out of State TCP Packets option is checked.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SmartDashboard . . . . . . . . .

57

Log and Alert

The Log and Alert properties control the tracking type of some internal events. For example, the VPN Successful Key Exchange property dictates how you are notified when a VPN connection is made. The options you have in this page are the same tracking options you have in the rule base. Alert Commands is a related set of properties that controls how some of the events are actually run. For example, if an alert is set to email, this page defines how the email is sent. This is also where the user-defined alerts are defined.

Anti-Spoofing
Spoofing refers to an attacker forging the source address of a packet to make it look as though it comes from a higher security network. Because the rule base looks at IP addresses, among other things, if someone could spoof the source address of a connection, it could be used to allow a connection that would otherwise not be allowed. Check Point implements anti-spoofing measures by checking the source address of every packet against a predefined view of the network layout (called the topology). Figure 3.7 shows a case in which spoofing is happening. The BadGuy host is attempting to send a packet to Host2 that looks as though it is from Host1. Because the packet is being received on interface 1, but the source address belongs to a network on interface 2, it is being spoofed.

SRC = Host1 DST = Host2

Spoofed!

Firewall

BadGuy

Host1

Host2

Figure 3.7 A network in which spoofing is happening.

To properly protect yourself against IP spoofing, you must define the topology of your network within each gateways topology property. Figure 3.8 shows the topology properties of a sample enforcement point.

58

Chapter.3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 3.8 General topology properties of a gateway.

Each interface and its corresponding IP address is listed in the topology. The name of the interface must be the same as it is in the underlying OS. Using the Get button, you can populate these entries automatically through SVN Foundation. When clicking Get, you have the option of simply pulling down the interface name and network information, or also calculating the perinterface topology, which is shown in Figure 3.9.

Figure 3.9 Detailed topology configuration of an interface.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SmartDashboard . . . . . . . . .

59

To properly implement anti-spoofing, the enforcement point must know all the possible addresses that can come from a particular interface. There are three options, not including undefined:
Internal, defined by interface IP and netmask Internal, defined by a specific network object External

Internal topologies are used for your internal network, in which you understand all the networks. If there are no networks beyond the locally connected interface, you can choose to use the interfaces IP and netmask to define the topology (such as a stub network). If there are networks beyond the interface, such as those connected by a router or another firewall, then you should create a group object containing all the network objects, and choose the Specific option, selecting your group object. An external interface includes all the networks that are not covered by the internal interfaces. Put another way, a network is valid on an external interface if it is not defined as part of an internal interface. Figure 3.10 shows a sample network that uses the three types.
192.168.1.0/24 Internet 192.168.2.0/24 192.168.3.0/24

Figure 3.10 A network making use of the three types of topology settings.

The interface on 192.168.1.0/24 has no networks attached, so it can be defined by using the configured IP and netmask. Only packets with a source IP in that network will be accepted on that interface. The adjacent interface has 192.168.2.0/24 connected locally, but also 192.168.3.0/24 on a locally attached router. Thus, a group object will have to be created with the two network objects inside of it. The remaining interface, connected to the Internet, is an external interface, so the networks on it are irrelevant. Anything except for 192.168.1.0/24, 192.168.2.0/24, and 192.168.3.0/24 will be considered valid.
The network guys in the crowd might be thinking, Why not create a network object of 192.168.2.0/23 to cover both networks on the second interface? You could, but using a group allows for easier changes later when you add more networks, and its clearer to those who are looking at the configuration.

60

Chapter.3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

There are two more rules that might come in handy:

The same network can appear on multiple internal interfaces. You can have multiple interfaces defined as external.

In the first case, it is possible for a network to be valid on multiple internal interfaces, such as having multiple paths to the same destination. However, it cannot appear to be coming from any external interfaces (by definition of an external interface). In the second case, the same behavior of calculating external topology applies to all externally defined interfacesthat is, any network not included on any of the internal interfaces is valid on all external interfaces.

Verifying and Installing a Security Policy

None of your hard work in defining the security policy would be of any use if you didnt push it out to the enforcement points. This approach also has the benefit of allowing you to make all your changes at once, making them active in one action, and letting you revert to a previous configuration if necessary. If you want to check your policy for correctness, you can also verify it without having to install. The act of installing also forces verification before the actual push. Verifying a policy checks for errors such as conflicting rules, shown in Table 3.4, and contradicting NAT rules (for example, a single static NAT for several hosts).
Table 3.4 Two Rules That Will Cause a Verification Failure Source Any Any Destination Any Host1 Service HTTP HTTP Action Drop Accept Track None None Install On Policy Targets Policy Targets Time Any Any

Here, the second rule can never be reached because all HTTP traffic is denied in the first rule. Verification will fail with Rule 1 Conflicts with Rule 2 for services http. The actual installation of the policy is done through the Policy, Install menu option. You then are prompted to specify which gateways receive the policy. By default, all are selected. After you click OK, the policy is verified and sent to the gateways. If there are any problems, you will receive an error telling you what the problem is.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SmartDashboard . . . . . . . . .

61

To only verify the policy, select Policy, Verify. This will run the verification stage and give you a report on any errors. To remove the policy from the enforcement point, select Policy, Uninstall. This removes the policy, placing the firewall in a state in which it is open to the world, but will not pass packets.
When you unload a policy, youre dropping your pants to the world! This is usually used only if something goes wrong and you need to start over with your policy.

Rule Processing Order

As said earlier, the rule base is processed in order. However, other things happen in the security policy besides checking your defined rules. This is the order of operations:
1. Anti-spoofing checks 2. Rule base 3. Network Address Translation

When you take into account the FireWall-1 global properties, you end up with the following order:
1. Anti-spoofing checks 2. First Implicit Rules 3. Explicit Rules (except for the final rule) 4. Before Last Implicit Rules 5. Last Explicit Rule (should be cleanup rule) 6. Last Implicit Rules 7. Network Address Translation

When we look at Network Address Translation (NAT) in Chapter 8, Network Address Translation, youll see how it changes the source and/or destination addresses of the packet. Because NAT happens after the rule base is consulted, your rules will refer to the translated address in many cases. If you are using the NAT properties of the network object to implement NAT (also called automatic NAT), this is taken care of for you.

62

Chapter.3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Because anti-spoofing checks are done before anything else, you will find that if the topology is defined incorrectly, no conversation will occur regardless of the rule base. A log entry will be made to this effect.

Command-Line Utilities
A significant amount of administration can be done from the command line on both the SmartCenter Server and the FireWall-1 enforcement points. The command line provides a low-bandwidth and efficient way of getting information and performing emergency and maintenance actions. Most commands are actually options to either the fw or the fwm executables that is, they take the form of fw command options. The fw executable is for the FireWall-1 enforcement module, and fwm is for the SmartCenter Server.

Getting Basic Information

The first thing you want to know about a device is the version of software it is running. fw ver and fwm ver give this information:
C:\WINNT\FW1\R55\conf>fw ver This is Check Point VPN-1(TM) & FireWall-1(R) NG with Application Intelligence (R55) HFA_04, Hotfix 093 - Build 003 C:\WINNT\FW1\R55\conf>fwm ver This is Check Point SmartCenter Server NG with Application Intelligence (R55) HFA_04, Hotfix 093 - Build 001

As you can see, the major version (NG with Application Intelligence), the release (R55), and any hotfixes (Hotfix Accumulator 04 and Hotfix 093) are listed, along with the build number. If you ever open a case with Check Point support, you will likely have to provide a cpinfo dump to them. Running cpinfo dumps an incredible amount of information, so redirecting it to a file (for example, cpinfo > Winnipeg.cpinfo) is suggested. With your file, support can view your entire policy, including rules and options, so be cautious about sending it out! To get a snapshot of what policy is installed, and which interfaces are being protected, fw stat is used. With a policy loaded and active, you will see something like this:
C:\WINNT\FW1\R55\conf>fw stat HOST POLICY DATE localhost Standard 15Dec2004 22:10:41 : [>PCnet2] [<PCnet2]

[>PCnet0] [<PCnet0]

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SmartDashboard . . . . . . . . .

63

Here you can see that the Standard policy is loaded, and was installed at around 10 p.m. on December 15, 2004. Three interfaces are protected, with the arrows showing the direction of packets. After the policy has been uninstalled, the output changes:
C:\WINNT\FW1\R55\conf>fw stat HOST POLICY DATE localhost >PCnet2 <PCnet2

>PCnet0

<PCnet0

There is no policy installed, and the interfaces are no longer protected. To get a list of the interfaces on the gateway, use fw
C:\WINNT\FW1\R55\conf>fw ctl iflist 0 : PCnet0 1 : PCnet1 2 : PCnet2 3 : NDISWANIP ctl iflist:

does not show inactive interfaces by default (use the inactive flag to show the inactive interfaces), but iflist shows all.
fw stat

Managing Services
All the Check Point services on the machine can be managed through the command line. To completely restart all Check Point processes, except for CPRID (the remote installation daemon), use cprestart. Likewise, to only start or stop the services, use cpstart and cpstop. If you just need to start and stop the basic services, such as the firewall daemon, management station, and SNMP, use the fwstart and fwstop commands. This leaves both CPRID and cpshared running. To manage CPRID services, use cpridstop and cpridstart to stop and start the service.

Managing the Policy

Although you cant easily edit the policy from the command line, you can push, pull, and unload a policy. From the management station, you can push a policy to an enforcement point using fwm load. This command requires you to supply the name of a policy script (*.W, located in %FWDIR%\conf on Windows platforms, or $FWDIR/conf on Unix platforms) and optionally the name of an enforcement point to send it to. This operation compiles the script and sends it off to the

64

Chapter.3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

enforcement point. In this example, the Standard policy is sent to the localhost:
C:\WINNT\FW1\R55\conf>fwm load Standard.W Standard.W: Security Policy Script generated into Standard.pf Standard: Compiled OK. Installing CPMAD Policy On: localhost CPMAD policy installed successfully on winnipeg... CPMAD policy installation complete

CPMAD policy installation succeeded for: winnipeg Installing VPN-1/FireWall-1 policy on: localhost ... VPN-1/FireWall-1 policy installed successfully on winnipeg... VPN-1/FireWall-1 policy installation complete

VPN-1/FireWall-1 policy installation succeeded for: winnipeg

The messages here show that the policy installed successfully on the combination SmartCenter Server/VPN-1 Gateway. If you are on a gateway, and want to pull down a policy, you execute fw master, where master is the SIC name of your management station:
C:\WINNT\FW1\R55\conf>fw fetch localhost Installing Security Policy Standard on all.all@winnipeg Fetching Security Policy from localhost succeeded fetch

Here, the Standard policy was retrieved and installed. Finally, to unload the policy, use fw
C:\WINNT\FW1\R55\conf>fw unloadlocal Uninstalling Security Policy from all.all@winnipeg Done. C:\WINNT\FW1\R55\conf>fw stat HOST POLICY DATE localhost <PCnet1 >PCnet2 <PCnet2 unloadlocal:

>PCnet0

<PCnet0

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SmartDashboard . . . . . . . . .

65

Logs
Although SmartView Tracker is normally used to manage logs, it is possible to perform some actions at the command line. These commands are helpful for automating maintenance tasks or when scripting reports:

fw log aShows

the log of accounting data. the logs. the logs to the screen or a file.

fw logswitchRotates

fwm logexportDumps

Performance Considerations
Because a good deal of the packet delay through the firewall is due to evaluating your security policy, it stands to reason that there are things you can do to make the process more efficient. On the SmartCenter Server itself, defining the name to IP mapping in the local hosts file rather than through DNS can help performance. On Unix systems, this is /etc/hosts. In Windows, it is %SystemRoot%\system32\drivers\etc\hosts. For the gateways, the following changes in your rule base will increase performance:
Log connections sparinglyLogging takes time to process, so dont log

what you dont intend to read.

Minimize your rule bases complexityThe more rules, the longer it takes

to process. Complex rules, such as those with many objects inside, compile into a larger security policy too.
Use network objects or address ranges instead of multiple host objectsIts easi-

er to check whether an address falls within a network boundary than it is to check it against multiple host entries.
Put your high-traffic rules at the beginningRules are checked one by one,

stopping at the first match, so make sure that the match happens early for frequently used rules. In general, simplicity equals better performance, not to mention better security.

66

Chapter.3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exam Prep Questions

1. You have hidden rule 13, which drops all HTTP packets to a particular web server, but packets are still being dropped. What is the likely cause of this problem?
A. B. C. D. E. You did not push the policy to the enforcement point(s). A rule after rule 13 also blocks access. Hiding a rule does not remove it from the security policy. The server has a network problem. You must save the policy to the SmartCenter Server.

Answer: C. A is not correct because a hidden rule is still compiled into the security policy. B is not correct because rule 13 is still valid and it will therefore block the packet regardless of a successive rule. C is correct because the rule will still be enforced by the gateway, even though its hidden from view to SmartDashboard. D is not correct because it is the rule causing the drops, not a network problem. E is not correct because saving the policy to the SmartCenter Server has no effect on the enforcement points. 2. Trying to gain privileges by making a packet that is received on one interface look as though it is from a network connected to a different interface is called what?
A. B. C. D. E. Network Address Translation (NAT) Anti-spoofing Buffer overflow Spoofing Remote Procedure Call (RPC)

Answer: D. A is not correct because NAT is used on the gateway, and is not for gaining privileges. B is not correct because anti-spoofing is used to protect against this attack, not the attack itself. C is not correct because a buffer overflow works by getting a host to execute malicious code by filling unchecked buffers, not by faking addresses. D is correct because spoofing involves manipulating addresses to make a packet look as though it comes from another interface. E is not correct because RPCs are used by applications and operating systems to communicate. 3. Which three of the following are FireWall-1 global properties?
A. B. C. D. E. Accept RIP Accept HTTPS Accept Control Connections Anti-spoofing Accept Outgoing Packets Originating from Gateway

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SmartDashboard . . . . . . . . .

67

Answer: A, C, and E. A is correct because there is a FireWall-1 global property that enables the gateway to accept RIP. B is not correct because there is no such option. C is correct because by default, control connections are enabled in the global properties. D is not correct because anti-spoofing is configured at the Check Point level, not the global level. E is correct because there is an option to accept packets originating from the gateway. 4. With reference to the sample policy below, what is the function of rule 1?
Rule # 1 2 A. B. C. D. E. Source Any Any Destination Firewall HTTPServer Service Any HTTP Action Drop Accept Track Log None

Is the cleanup rule Is the stealth rule Prevents firewalls from sending packets Prevents spoofing attacks against the firewall Works with rule 2 to protect HTTPServer

Answer: B. A is not correct because the cleanup rule is the final rule, and drops everything. B is correct because the stealth rule drops packets sent to the firewall. C is not correct because this rule blocks packets into the firewall but does not specify what happens to packets with a source of the firewall. D is not correct because spoofing is not handled through the rule base. E is not correct because rules 1 and 2 are independent. 5. With reference to the sample policy shown here, who can access port 80 on HTTPServer?
Rule # 1 2 3 4 A. B. C. D. E. Source Any Net1 Net2 Any Destination Firewall HTTPServer HTTPServer HTTPServer Service Any HTTP HTTPS HTTP Action Drop Drop Accept Accept Track Log None None Log

Net1 Net2 Net1 and Net2 Anyone except Net1 Invalid policy; rule 2 masks rule 4

Answer: D. A is not correct because rule 2 explicitly drops any packets from Net1 to HTTPServer on port 80. B is not the correct answer because even though Net2 can access HTTPServer on port 80, it is not the best answer. C is not correct because Net1 cannot connect to the HTTP server. D is correct because rule 2 blocks Net1, and rule 4 allows everyone else. E is not correct because rule 2 does not mask rule 4it is more specific.

68

Chapter.3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6. Which of the following will have a negative impact on a gateways throughput? (Choose two.)
A. B. C. D. E. Small rule base Groups of hosts used instead of network objects Tracking option on all rules set to Log High-traffic rules near the top of the rule base Multiple administrators logged in to SmartConsole

Answer: B and C. A is not correct because a smaller rule base is good for performance, because fewer rules need to be checked on average. B is correct because network objects are more efficient than a group of hosts. C is correct because logging decreases FireWall-1 performance. D is not correct because high-traffic rules should be near the top of the rule base so that fewer rules need to checked on average. E is not correct because the number of administrators logged in to a SmartConsole does not affect the performance of the gateways. 7. Which of the following commands changes the installed security policy to one that will certainly accept control connections?
A. B. C. D. E. cpstop fw fetch localhost fw unloadlocal fwm unloadlocal fwstop

Answer: C. A is not correct because cpstop will stop all the Check Point services, and no one will be able to connect. B is not correct because it will fetch the latest policy from the management server, which is not guaranteed to allow control connections. C is correct because fw unloadlocal removes the policy from the gateway and allows management connections. D is not correct because unloading the policy is done on the enforcement point through fw, not on the management server through fwm. E is not correct because fwstop will stop the firewall service and will not allow anyone to connect. 8. Where are the global properties located?
A. B. C. D. E. Global Properties under Management Station Properties View, Global Properties Manage, Global Properties Manage, Policy, Global Properties Policy, Global Properties

Answer: E. A is not correct because the global properties are not a property of the management station. B is not correct because the View menu is for changing the look and feel of the SmartDashboard. C is not correct because the Manage menu is for managing objects. D is not correct for the same reasons as C. E is correct because that is where the Global Properties menu item is found.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SmartDashboard . . . . . . . . .

69

9. Which of the following objects may appear in a group together? (Choose three.)
A. B. C. D. E. Check Points Other groups Time objects Nodes configured as a gateway Services

Answer: A, B, and D. A is correct because a Check Point is another type of network object, and can share a group with other network objects. B is correct because groups can be nested. C is not correct because time objects are not network objects, and thus cannot be grouped with other network objects. D is correct because nodes, whether configured as a host or a gateway, are network objects. E is not correct because services cannot be grouped with network objects. 10. Which of the following have a SIC connection to the SmartCenter Server? (Choose two.)
A. B. C. D. E. Check Point, Gateway Check Point, Externally Managed Gateway Check Point, Host Nodes, Gateway Nodes, Host

Answer: A and C. A is correct because a Check Point gateway is managed by the SmartCenter Server and has a SIC connection. B is not correct because an externally managed gateway is not managed by the SmartCenter Server, and thus does not have a SIC connection. C is correct because a Check Point host is the same as a Check Point gateway in terms of management. D is not correct because a node does not have a policy and is not managed. E is not correct for the same reasons as D.