SmartDashboard
This chapter is from the book
This chapter is from the book
This chapter is from the book
Terms you'll need to understand:
-
Network object
-
Cleanup rule
-
Stealth rule
-
Anti-spoofing
Concepts you'll 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
Out of all the SmartConsole utilities, you'll 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.
The rules themselves are individual statements that permit or deny traffic. When you collect all the rules in an ordered list, it's 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.
)
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 Objects—Matches objects representing an IP address, such as hosts, networks, and groups.
Services—Matches the layer 4 port, or the layer 3 protocol.
Resources—Matches upper-layer protocols, such as http URLs (outside the scope of the CCSA).
Servers and OPSEC Applications—Defines hosts that will be integrated into the system, such as antivirus servers and other OPSEC devices (outside the scope of the CCSA).
Users and Administrators—Defines users and groups that will be used in authentication rules.
VPN Communities—Defines 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 Point—A Check Point firewall product running on some device. It may or may not be under your control.
Node—A host, or in the case of a multihomed host, a gateway.
Interoperable Device—A non–Check Point firewall that will be involved in a VPN connection.
Network—An object representing a network and network mask.
Group—A collection of other objects, including other groups.
Address Range—A contiguous list of network addresses, similar to a network, but not necessarily defined by a network and netmask combination (for example, 192.168.0.1 to .99).
Dynamic Object—An object whose address is not fixed but is resolved on each enforcement point.
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, you’ll 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.
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.
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.
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.
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.
Services
Services represent layer 3–7 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-1’s 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."