Managing Objects


Managing objects is the most common task you will perform as a firewall administrator. Luckily, Check Point has made this task much easier. Every year, Check Point wins awards for its manageability, which is a large reason companies continue to choose Check Point Software. While there is a lot of information needed to set the foundation for your rule base, you do not have to put forth a great deal of effort to get that information into a useable format.

Your first task is to log into the FW-1 GUI management client (SmartDashboard). On a Windows system, simply start the SmartDashboard or your GUI client by double-clicking its icon. On a Unix system such as Solaris or AIX, execute the fwpolicy command found in $FWDIR/bin . You will be presented with a login window, as displayed in Figure 3.1. Note that if this is the initial connection from a GUI client, FW-1 will present the management server fingerprint . This is used as a security measure to enable you to validate the identity of that management server.

Once you have logged into the GUI, you will see a lot of information. Do not worry; you can easily customize this default view to show just what you need. You can also add or subtract from this view as needed. A couple of changes have been made from previous versions of the SmartDashboard (named the Policy Editor in previous versions). Figure 3.1 shows you the new default view.

click to expand
Figure 3.1: SmartDashboard

The window panes are called (from left moving clockwise) the Objects Tree, Rule Base, Objects List, and SmartMap. You can toggle which one is displayed by selecting View from the SmartDashboard menu, as displayed in Figure 3.2.


Figure 3.2: View Selection

The Objects Tree gives a concise and orderly view of the defined objects of each available type. If you are asked which networks are defined, the Objects Tree will give you the quickest answer. The Rule Base enables you to instantly sum up the totality of what your firewall is enforcing, and also enables you to quickly view network address translation (NAT), Quality of Service (QoS), and Desktop Security rule information. The Objects List presents a little more detail than the Objects Tree about your defined objects.

SmartMap is new in FW-1. This gives you a network map showing the interconnections of all of your defined objects. Figure 3.3 shows that pane enlarged to full screen.

click to expand
Figure 3.3: Topology Map

The map is automatically created based on the topology of your objects, and is completely interactive. You can rearrange the placement of the objects and even query them for information and alter their configuration. Click on any link to show the interface properties of the device it is connected to.

Network Objects

Network objects are simply the objects within a network. For example, an object can be a network range, a group of users, or a single workstation. Objects can also be groups of other objects, allowing for hierarchical layering and a more concise and descriptive rule base. Most importantly, the objects of interest within a network must be properly defined before using them in a FW-1 rule. As certain network objects are defined, they will automatically be added and arranged within the SmartMap.

Network objects can be defined in several ways, with the most common method being through the Network Objects Manager, which is shown in Figure 3.4. This GUI window enables you to create, delete, and alter all of the various types of network entities. To access this screen, select Manage Network Objects from the SmartDashboard GUI.


Figure 3.4: Network Objects Manager

Check Point Gateway or Host Object

The Check Point gateway or host object defines a system with Check Point products installed on it, and contains many options. This computer may be a VPN-1/FW-1 system, a VPN-1 Net device, a Secondary Management Station, a log server, or any combination of those and more. This flexibility comes with a slight increase in complexity. The Check Point gateway or host properties page contains many more options than its counterpart in previous versions of FW-1, but luckily there is intelligence built in to the window. The branches on the left become visible as they are needed. A simple firewall gateway or host will have limited options, but the choices expand when dealing with Check Point installed products. Table 3.1 defines some of the more common configurations and their displayed options.

Table 3.1: Configuration Matrix
 

F W-1

VPN-1 Pro

VPN-1 Net

Floodgate-1

Secondary
Management
Station

Log Server

UserAuthority
Web Plugin

General

X

X

X

X

X

X

X

Topology

X

X

X

X

X

X

X

NAT

X

X

X

X

X

X

X

Authentication

X

X

X

X

     

VPN

 

X

X

 

X

   

Remote Access

 

X

X

       

Logs and Masters

X

X

X

X

X

X

 

Capacity Optimization

 

X

X

X

     

UserAuthority Web Access

           

X

Advanced

X

X

X

X

X

X

X

The General configuration window, as shown in Figure 3.5, enables you to associate a system name and IP address with this object. If the name is resolvable via Domain Name System (DNS) or Windows Internet Name Service (WINS), you can use the Get Address button to retrieve the IP address or you can type it in manually. If this system will have a dynamically assigned IP address (via dynamic host control protocol [DHCP]), check the Dynamic Address box, which will disable the IP Address field. The Comment field is optional. Like all FW-1 objects, you can assign a color to the object. The remaining fields have special meanings when selected, which impact the way VPN-1/FW-1 interacts with them. A gateway means that there are multiple interfaces on the device that will be routing traffic. A host can also have multiple interfaces, but will likely only be terminating connections, not routing them through.

If you accidentally define a system as a host instead of as a gateway, you can right-click on the object in the Object Tree and select Convert to Gateway . Similarly, you can convert a gateway to a host or even convert a node to a Check Point system. The difference between a host and a gateway is that it will be assumed that a host is an endpoint that will only receive traffic for itself (even if it has multiple interfaces), whereas a gateway will be routing traffic between the multiple interfaces it has.

  • Check Point Products This section designates the products and version of Check Point products installed on this system. As you select products, others become grayed out as they are not compatible. For example, VPN-1 Net and VPN-1 Pro are two separate licensing schemes for the same software and are not able to be mixed on the same system.

    click to expand
    Figure 3.5: Check Point Gateway Properties, General Properties Window

  • Additional Products Here, the Web Server option is available. This option is also available for Node objects. This defines whether or not the Cross Site Scripting inspection of SmartDefense will be applied to this system. By selecting this, you will also see a new option on the left-hand side of the window.

  • Secure Internal Communication This is where you define the activation key for setting up a secure channel between the enforcement module and management station. You can also verify that you are able to securely communicate with this host inside this section.

start sidebar
Configuring & Implementing
What s in a Name?

Although the value in the Name field does not have to be anything but unique, it is strongly recommended that you use an actual resolvable name. It is also strongly recommended that you include the hostname to address mappings in your systems host files. These files can be found in the following locations:

  • For Unix systems, edit the /etc/ hosts and /etc/networks files

  • For Win32 systems, edit the %SYSTEMDIR%\system32\drivers\etc\hosts and %SYSTEMDIR%\system32\drivers\etc\networks

    This will ensure the proper function of the Get Address function. Be careful to maintain these files. Hostname and address changes could lead to potential exposure if not properly done.

    Also, if the Check Point system you are defining is a gateway (a multi- homed system that is able to pass traffic between its interfaces), and you are using Internet Key Exchange (IKE) encryption, be sure to specify the outside address. If you fail to do so, IKE encryption will not function properly. Remember that this address is the address that the Management Station communicates with, so this change may cause some routing problems. In our example, we could either set ExternalFW ( specifically the 192.168.0.2 interface) as our default route from the management station or set a static route for 11.12.13.14 to 192.168.0.2. Keep in mind that most of the problems engineers run into in the field are routing related , so when debugging a connectivity issue, check the routing first.

end sidebar
 

The Node Object

The node object is used to define a single system (host) or a system that will be routing traffic (gateway). A node is usually used to create a placeholder for a single IP address. To create a new node object, select New Node from the Network Objects management window. This will present you with the panel shown in Figure 3.6.

click to expand
Figure 3.6: Node Properties

The Network Object

The network object defines a group of hosts or, more specifically, a network range such as a subnet. When defining individual systems as workstations becomes too tedious or otherwise untenable, it is easy to arrange them with this object type. To create a new network object, select New Network from the Network Objects management window. This will present you with the panel shown in Figure 3.7.

click to expand
Figure 3.7: Network Properties: General Window

The General window allows some simple configuration information to be entered, such as an IP address, netmask , and a comment. You should already be familiar (at least slightly) with IP subnetting. In the example panel, the network is 172.17.0.X with a 24-bit subnet, producing a mask of 255.255.255.0. In this case, you enter the host portion as a zero. Keep in mind, though, that the host portion might not always be set at zero, and might not always fall on a tidy boundary. For example, you might have a network address of 10.3.4.128, with a subnet of 255.255.255.128. When in doubt, consult your local networking expert or become one. To ease your understanding, there are many subnet calculators available online such as the one at: www.telusplanet.net/public/sparkman/netcalc.htm

As with all object types, a color can be assigned as well. The Broadcast Address field denotes whether you desire the broadcast addresses to be included within the defined network. The broadcast address is defined as the first and last possible IP within that range. The NAT panel includes the option to establish automatic translation rules. (NAT is covered in detail in Chapter 5.)

For added simplicity, when you define interfaces on Check Point objects, it automatically shows each attached network as an implied network in SmartMap. You can right-click on any one of them and select Actualize Network . This will automatically create Net_ < network address >, as shown above, as a naming scheme and fill in the network and subnet. Once an object has been actualized and an object has been created, it can be used in rules as well as in the other SmartConsole clients .

The Domain Object

The domain object is used to group hosts by commonly used techniques. A machine is determined to be within the domain if a reverse DNS lookup on the machine s IP address yields the proper domain information. Figure 3.8 illustrates this panel, which is accessed by selecting New Domain from the Network Objects management window.

Notice that in the previous example the domain name begins with a period. You may be wondering how FW-1 knows what to do with a domain object. When a domain object is used in the rule base as a source or destination, FW-1 will attempt to do a reverse DNS lookup (that is, getting the name for a specified IP) on the appropriate portion of the incoming packet. If the lookup yields the domain information, you have a match. If there is no reverse record, the object will be useless. It is also possible that, through DNS poisoning , this sort of object could lead to a security breach. Furthermore, the performance overhead for looking up each address as well as the latency added on making a rule decision while waiting for a DNS resolution is significant. For these reasons and others, Check Point does not recommend the use of Domain objects in your rule base. If you decide to use them, use them as close to the bottom of the rule base as possible.

Open Security Extension Device

Open Security Extension (OSE) technology allows FW-1 to manage third-party devices that support these extensions. Most notable among these devices are Cisco routers running IOS version 9 and higher. The number of devices that you may manage depends on your license. The configuration for an OSE-compliant device features five windows. To create a new OSE device, select New OSE Device from the Network Objects management window. Figure 3.9 illustrates the General window.

click to expand
Figure 3.8: Domain Properties

This window enables you to specify some of the basic information about the device, specifically the IP address, name, comment, and device type. The device type may be either of the following:

  • Nortel

  • Cisco

  • 3Com

When a device from this category is managed by the firewall, access control lists (ACLs) are generated based on the security policy. As with other object types, the Get address button will attempt to resolve the specified name to an IP address, saving you that one step.

The Topology window is identical to that of its counterpart for the other devices. The main caveat is that at least one interface must be defined (as opposed to, say, a simple workstation) or the ACL entries will not be created successfully. Anti-spoofing and related topology information are also defined by editing the interface properties, just as with a workstation. If you choose to only allow certain administrators to manage the ACLs on this router, you can specify a group of administrators defined in the GUI (not in cpconfig ) in the Permissions to Install page. However, there are some additional steps to take, which are accomplished by editing the information on the Setup window.

click to expand
Figure 3.9: OSE Device: General Window

The Setup window differs depending on the OSE type specified on the General window. The window as displayed with a Cisco router, is shown in Figure 3.10.

click to expand
Figure 3.10: Cisco OSE Setup Window

The following fields are displayed in this window:

  • Access List No. The number of the ACL that will be applied.

  • Username This is the exec mode username that will be used for initial access to the device. It, along with the remaining drop-down lists, can be set to None, Known, or Prompt. If set to Known, the gray box to the right will become active and allow the entry of a username.

  • Password Enter the password associated with the exec mode username.

  • Enable Username The name, if any, of a user with privileged exec access.

  • Enable Password The password associated with the privileged username.

  • Version The IOS version installed on this router.

  • OSE Device Interface Direction The direction in which to enforce the security policy. This can be Inbound, Outbound, or Eitherbound.

  • Spoof Rules Interface Direction The direction in which to enforce anti-spoofing behavior. This can be Inbound, Outbound, or Eitherbound.

The fields for the 3Com and Nortel devices are similar in their requirements, and the security policy is enforced in an identical manner.

Interoperable Devices

An interoperable device is used to define any third-party device you wish to establish a site-to-site virtual private network (VPN) to. This device could be a Cisco Router, a Netscreen Firewall, or one of literally hundreds of IKE-compatible products from as many vendors. In all actuality, you will not need to know the type of device on the other end, however, it can help you debug problems if you run into them, as not all vendors interpret the IKE Request for Comments (RFC) specifications the same.

The configuration is pretty straightforward, with the common rules applying. Define the name, IP address, and an optional comment. Then define the topology (VPN domain) of the remote object. Figure 3.11 illustrates the configuration panel. To open this panel, select New Interoperable Device .

click to expand
Figure 3.11: Interoperable Device General Properties

The Group Object

The group object can be used to manage other objects of dissimilar types. There are three types of groups that can be defined within FW-1. To create a new group, select New Group from the Network Objects management window. The group types are as follows :

  • Simple group

  • Group with Exclusion

  • UserAuthority Server group

A Simple group is a collection of network objects. A Group with Exclusion allows some granular control over the contents of a group. For example, if you are working in a network with a flat topology, you may be in a situation where there is not much physical separation within the network. A group of this type enables you to force some structure here. Figure 3.12 illustrates a Simple group.

click to expand
Figure 3.12: Group Properties

Inside the Manage Network Objects , you can only specify Network Objects. A Network Objects group is different than a User Group.

A Group with Exclusion is similar, with the difference being that you specify a major group, defined by Check Point as an outer group. This will be the group that is included for this definition. You then specify minor, or inner, groups. These will be the groups culled out and excluded from the major group.

Logical Server

The Logical Server group (available by selecting New Logical Server from the Network Objects window), enables you to group like servers (FTP, HTTP, SMTP, and so forth) to be treated as one and used in a sort of resource sharing or server pooling. Note that this is an optional feature and may not be included within your FW-1 installation. Workload is distributed among these servers in a user-configurable manner. Figure 3.13 shows the configuration options for this object type.

click to expand
Figure 3.13: Logical Server Properties Window

As usual, the name must be entered, and, if resolvable, the Get address button can be used to gather the associated IP address.

Note  

Regarding the IP you will select; this address should be that of a non-existent server located on the same network as the destination servers, but can also be that of the FW-1 module. Think of this IP as a virtual IP address. It will be used by the clients to connect to the Logical Server group, and therefore cannot belong to any one member of that group.

The Server s Type feature defines the method of load balancing, or more specifically, the type of algorithm used. The two methods behave very differently. For example, with HTTP selected, only the initial connection will be handled by the logical server address. A redirection is sent to the client informing their browser of the new IP (that of the selected destination server), and the remainder of the conversation goes forth without the intervention of the firewall module. If Other is selected, address translation is performed and the conversation is balanced per connection, with the firewall module constantly involved, unless Persistent server mode is checked.

The Servers section enables you to select the server group that will make up this logical group. If selected, Persistent server mode allows some fine-tuning of the balancing mechanism. When enabled, you can enforce connection persistence, meaning you can force packets from an established flow to continue to a single destination. This is very useful for something like an HTTP conversation when using Other as the server type. You can select between two modes here: Persistency by service and Persistency by server . The main difference between the two is that, when the former is selected, only connections to a single server for a single service will have persistency enforced, while in the latter any service on a specific server will be impacted.

The final settings define the type of balancing to be performed. The Balance Method has several possible options.

  • Server Load FW-1 sends a query using port 18212/UDP, to determine the load of each server. There must consequently be a load-measuring agent on each server to support this method.

  • Round Trip FW-1 sends a simple Internet Control Message Protocol (ICMP) ping to each server. The fastest round-trip time is chosen as the preferred server. This lacks somewhat, in that the ping is from the firewall to the server, and may not be optimal from a remote client. (Remember, the servers need not be centrally located to participate in a server group.) Also, a ping does not tell you that the HTTP daemon has crashed on the server. As long as the server is up and on the network, regardless of the status of any of its services, traffic will be sent to it.

  • Round Robin FW-1 selects sequentially from a list. This is among the simplest methods.

  • Random FW-1 selects randomly from a list.

  • Domain FW-1 attempts to select the closest server to the client, based on a domain naming convention. This method is not recommended.

Address Range

An address range defines a sequential range of IP addresses for inclusion with a rule base. In previous versions, the Address Range object usage was restricted to the Address Translation rule base only. Starting with Next Generation (NG), the ability to use an Address Range in the Security Policy has been enabled. An Address Range is similar in use to a Network object, with the major difference being that you specify a starting and ending IP address instead of a network number and subnet mask. Figure 3.14 illustrates the General panel for this object type, which is available by selecting New Address Range from the Network Objects management window. As usual, the NAT panel features no special information and is the same as that found on most other object types.

click to expand
Figure 3.14: Address Range Properties Window

Gateway Cluster

A gateway cluster is a grouping of machines running VPN-1/FW-1 that is grouped together as a means of fail over or load sharing support. Clustering is a complex subject, and configuring it is much more detailed than the majority of other object types. (Detailed coverage of clustering is discussed in Chapter 12.)

The next step is to create your workstation objects. In order to support clustering, you must have at least three objects, two of which must be firewall modules, and one a manager. The workstation object should be created as normal for a machine with FW-1 installed. It is important that the interfaces are properly defined, as anti-spoofing is required for proper high-availability function. Next, you create a new gateway cluster object. The General panel is illustrated in Figure 3.15, and is accessed by selecting New Gateway Cluster from the Network Objects management window.

click to expand
Figure 3.15: Gateway Cluster ”General Panel

This panel allows the initial configuration for the cluster. The name and IP address are defined here, as are the specific Check Point products that will reside within this cluster. Also, you can specify whether you or another party manage the cluster. You can specify on the topology panel which addresses reside behind this cluster. This is similar to the features on a workstation object s interface properties topology panel.

Dynamic Object

A dynamic object is perhaps the most interesting object type supported on FW-1. It is also one of the most useful in a large enterprise, when managing Safe@ appliances or when using dynamically assigned IP address firewalls. This object type enables you to define a logical server type, one in which the actual IP address will resolve differently on each FW-1 machine. This enables you to create rules referencing mail server and distribute that policy to several different FW-1 machines, all of which will resolve mail server as the proper machine within their realm. NG Application Intelligence (AI) comes with a number of dynamic objects pre-defined. Figure 3.16 shows the basic configuration window, which you can see by selecting New Dynamic Object from the Network Objects management window.

click to expand
Figure 3.16: Dynamic Object Properties Window

The real key to a dynamic object is the dynamic_objects command. This command is run on the firewall module where the name will be resolved, and enables you to specify the values to which it will resolve. Table 3.2 describes this command and its options.

Table 3.2: dynamic-objects Command Options

Option

Explanation

-o <object name>

Specifies the object name to work with. This option is often used with operators such as “a to add addresses to an existing object.

-r <from starting address> <to ending address>

Specifies an address range.

-a <from starting address> <to ending address>

Adds the address of <range> to the object.

-d <from starting address> <to ending address>

Deletes addresses from the object.

-l

Lists all dynamic objects.

-n <object name>

Creates a new dynamic object; assuming the VPN-1/FW-1 process has been stopped .

-c

Compares the defined dynamic objects to those defined in the objects_5_0.C file.

-do <object name>

Deletes the specified object.

-e

Removes all dynamic object data

Services

The services objects give you a finer level of access control as compared to exclusive use of network entities. With the service object, you can define protocol-specific information like the protocol in use (Transmission Control Protocol [TCP], User Datagram Protocol [UDP], and so forth) and port numbers . FW-1 comes preconfigured with many of the more common services in use today, and further enables you to create custom services based on your unique needs. In addition, SmartDefense updates this list of objects as necessary.

To add, modify, or delete services, access the Services window by clicking Manage Services . From here, you will be able to act on the following service types.

TCP

The TCP service object enables you to define a basic TCP service. Figure 3.17 illustrates this service type, using the DNS service as an example. To bring up this window, select New TCP from the Services Management window.


Figure 3.17: TCP Service Properties

The information for this is very limited. Besides a name and comment, all you have to enter is the destination port number. This can be a specific port, as shown in Figure 3.17, a range (e.g., 1024 through 1028), or a greater-than/ less-than definition (e.g., <56). The Keep connections open after Policy has been installed checkbox allows all control and data connections utilizing this service to continue until the session has ended, even if they are not allowed by the new policy. This overrides the related setting in Global Properties. There is also an Advanced button, which displays the window shown in Figure 3.18.

click to expand
Figure 3.18: Advanced TCP Service Properties

The advanced settings enable you to specify a source port, and allow for the same modifiers as in the General panel s port specification. You can also specify the protocol type that impacts which set of extended security definitions (INSPECT Code or Security Servers) will be applied for this service. . The checkbox marked Enable for TCP resource , if checked, enforces screening using a Content Vectoring Protocol (CVP) server, mitigating the intervention of a security server. The next item, Match for ˜Any allows connections using this service to be matched when a rule is crafted with ˜Any as the service. There can only be one service for each protocol (i.e., TCP) and port (i.e., 53), that uses the Match for ˜Any . The Session Timeout is a local setting meant to allow override of the global session timeout. FW-1The option to Synchronize connections on Cluster enables connections matching this service to be synchronized with other members of a cluster. For connections that do not require synchronization, one can stop them from being synchronized. This reduces synchronization traffic on the synchronization network. Connections can also be synchronized after a certain period of time if utilizing a compatible SecureXL-enabled device. This is useful when a large number of connections are flowing through the firewall and are short-lived. The synchronization of connections of this nature (HTTP, for example) is less useful simply because synchronization consumes gateway resources and the connection will have probably finished by the time a failover happens.

UDP

The UDP service object enables you to define a basic UDP service. An example of this is the NTP service. UDP tracking poses a problem for many firewalls, especially circuit level gateways. Since UDP is connectionless, it is generally an all-or-nothing approach to security. Whole port ranges are often opened to allow UDP traffic, which is not a very nice notion. With FW-1, a second mechanism has been designed to keep track of a virtual connection.

The General properties are identical to those for TCP, as seen in Figure 3.17. The Advanced options are slightly different, and are therefore depicted in Figure 3.19.

click to expand
Figure 3.19: Advanced UDP Service Properties

As with the TCP settings, you can specify a source port and a protocol type as well as the ability to selectively synchronize connections. Additionally, there are the familiar checkboxes, but this time with slightly different values. These are as follows:

Accept Replies If checked, allows for a bidirectional communication to take place.

Accept replies from any port Allows the server to reply from any port. An example of the need for this is the Trivial File Transfer Protocol (TFTP) service. This option is not enabled by default.

Match for ˜Any Allows connections using this service to be matched when a rule is crafted with ˜Any as the service.

Remote Procedure Call

Remote Procedure Call (RPC) services are usually tricky for a firewall administrator. RPC-based connections do not use a fixed port number, so allowing these types of connections is either an all-or-nothing exercise. Usually, administrators choose to block all RPC connections on their external firewalls, while being far more permissive within their network boundaries.

To alleviate this potential risk, FW-1 transparently tracks RPC ports. Application information is extracted from the packet in order to identify the program used. FW-1 also maintains a cache that maps RPC program numbers to the assigned port numbers. The configuration panel, viewed by selecting New RPC from the Service management window, is as shown in Figure 3.20.

click to expand
Figure 3.20: RPC Service Properties

ICMP

ICMP is used for things like network troubleshooting and discovery. Unfortunately, attackers looking to gain information about you also use it. For this reason, many sites block all ICMP traffic. This is not necessary, and may cause more problems than it solves . Using FW-1, you can FW-1pick and choose the specific ICMP types (and even subtypes , or codes ) allowed. Table 3.3 details some of the more useful ICMP types, their associated codes, and their meanings, as defined by the Internet Assigned Numbers Authority (IANA) (www.iana.org/assignments/icmp-parameters). In Check Point NG AI, Stateful ICMP has been added to allow replies and errors to be returned to the requesting application, which removes the need to allow certain types of ICMP traffic into your network just to allow outbound ping and traceroute to function.

Table 3.3: ICMP Codes

ICMP Type

ICMP Code

Explanation

 

Echo (ping) reply

3

 

Destination unreachable:

 

-network unreachable

 

1

-host unreachable

 

2

-protocol unreachable

 

3

-port unreachable

 

4

Dropped because DF (do not fragment) bit was set; fragmentation needed.

 

5

Source routing not allowed or otherwise failed.

4

 

Slow transmission rate

5

 

Better network path available:

 

-for entire network

 

1

-for specific host

 

2

-for tos and entire network

 

3

-for tos and specific host

8

 

Echo (ping) request

11

 

Time exceeded for reason:

 

-TTL reached 0 in transit

 

1

-fragment reassembly time exceeded.

12

 

Bad IP header

Figure 3.21 shows the configuration panel for an ICMP service. Using Table 3.3, you can see how simple it would be to create services, and thus rules, to allow the beneficial types of ICMP while excluding those that may do harm.

click to expand
Figure 3.21: ICMP Service Properties

Other

Often called user-defined services, Other {{FILL IN BLANK}} is a catchall for whatever is missing. Its presence gives you a great deal of flexibility, but requires at least a familiarity with the inspect language. The General panel is similar to that found in its cousin objects, allowing you to define a name, add a comment, and assign a color. It also enables you to define the protocol identifier. This is a very important field, as it is the key to matching against the incoming traffic. Figure 3.22 shows the General panel for this service type.

Clicking on the Advanced button brings up a screen that allows the entry of the most crucial part of this object, the Match field. This field is a snippet of inspect code that will be used to check the incoming packets. It can, therefore, be as complex as you can imagine. This makes the user-defined object a truly powerful tool for the enforcement of very specific requirements.

click to expand
Figure 3.22: User-Defined Service Properties ”General Panel

Group

The group object enables you to combine different protocols. For example, it can be used to define a service whose individual parts must also be separately defined, such as a ping. It consists of an echo request and an echo reply. These can be defined and then combined into a group, and that group used in the rule base. Figure 3.23 displays the configuration window, which is accessed by selecting New Group from the Services Management window.

click to expand
Figure 3.23: Group Properties

DCE-RPC

This service type works in a similar fashion to the RPC service, in that it tracks DCE-RPC based connections, extracting the information from the packet and creating a virtual session whose information is stored in a local cache. When you define the DCE-RPC service, you are asked for the Universally Unique Identifier (UUID) for the specific interface as well as the protocol type. In NG AI, a service of 0 was defined as a wildcard named ALL_DCE_RPC. This will log the UUID in the Information column in SmartView Tracker. Figure 3.24 illustrates this panel.

click to expand
Figure 3.24: DCE-RPC Properties
Warning  

Many administrators define a service for port 135 to enable Microsoft applications (i.e., Exchange) to function through the firewall. This is very dangerous as it subverts for the granular filtering of DCE-RPC, which can have devastating effects. When granular inspection for DCE-RPC is enabled, attacks that do not follow the DCE-RPC specification (like the MSBlaster worm) will be blocked. If you do not know the UUIDs of your programs you can use the ALL_DCE_RPC service to accept the connections and the SmartView Tracker to view the UUIDs being used. It is highly recommended, however, to get the UUIDs from the software vendor directly.

Resources

Resource objects are used to configure content security on FW-1, and will be covered in greater detail in Chapter 7. Content security includes support for the HTTP, FTP, SMTP, and CIFS protocols. FW-1 provides part of this support by using the FireWall-1 Security Servers and the rest using its TCP Streaming technology. For each connection established through the FireWall-1 Security Servers, you are able to control access on a very granular level according to protocol-specific information unique to a specific service. This includes Uniform Resource Locators (URLs), file names , FTP commands, and so on.

Uniform Resource Identifier

A Uniform Resource Identifier (URI) defines how to access resources on the Internet. Most of us are familiar with the URI by another name: URL. A URI can contain HTTP, gopher, and mailto type addresses for specifying different applications to handle the resource. They are represented in the following form: www.syngress.com or mailto:user@mycompany.com

URI for QoS

Another type of URI object is the URI for QoS , which is used when defining a rulebase for FloodGate-1. This resource type allows the security administrator to classify certain URIs as part of a QoS policy. This object type is fairly simple to create. You will need to define a name and comment, and select the color for the object. Additionally, you will need to define a Search for URL . This specifies the URL that will trigger a match, and it can be as specific as a complete URL, or as general as *.JPG, which would match any JPEG file.

SMTP

The SMTP resource defines the methods used by FW-1 to handle incoming or outgoing e-mail. There are many options, including the ability to remove active scripting components , rewriting fields in the envelope (such as To: or From:), or filtering based on content. The configuration of this resource type is similar to that of the URI, including the ability to use a CVP server.

FTP

An FTP resource is defined in order to enforce content security for FTP connections. One function of an FTP resource is to define the verbs or methods that will be allowed through a firewall. For example, one can restrict downloading access to only a certain directory on the FTP server, adding a second layer of security over and above what security is enabled on the FTP server itself.

Open Platform for Security Applications

The Open Platform for Security (OPSEC) object defines a means of interacting with a third party-developed security application. These applications add extended functionality to the FW-1 installation. Some examples include virus scanning, content filtering, and intrusion detection. OPSEC allows FW-1 to send its data stream to other applications, and allows those applications to send data to the firewall (for example, log entries via the ELA or status via AMON interfaces). This is covered fully in Chapter 7.

Servers

A server is a host computer running a specific application or service. The server object is the representation of that relationship.

Remote Authentication Dial-In User Server

A Remote Authentication Dial-In User Service (RADIUS) server is used to provide authentication services. While originally used for remote access services, it is also now commonly used for various network devices such as routers and firewalls. To define a RADIUS server, select Manage Servers from the SmartDashboard drop-down menu and then select New RADIUS . The configuration appears, as shown in Figure 3.25.

click to expand
Figure 3.25: RADIUS Server Properties

The RADIUS server object is configured in a way that is fairly common with the other server types. After defining the name, adding a comment, and selecting the associated color, you need to specify the Host that the RADIUS server is running on. You also need to assign a Priority . The priority is used to determine the preference for an individual server when more than one is available for contact, for example, when the server is assigned to a RADIUS group.

The next step is to define the Service , which is RADIUS. The Shared Secret must be entered in order to establish communication between the firewalled object and the RADIUS server. Consequently, it must be the same on both devices. The final step is to select the proper version from the Version drop-down menu.

RADIUS Group

A RADIUS group is used to form a group of RADIUS servers to be used as one logical RADIUS server. These servers are then available for use as a single object, with authentication services being performed by the server with the highest priority (e.g., the lowest number). Unlike most other groups, server groups such as this may not contain any object of other types.

Terminal Access Controller Access Control Server

A Terminal Access Controller Access Control Server (TACACS) is another access control method. The definition of this object shares the same generalities of the other server entities, those being name, comment, color, and host. Once these are defined, you have only to specify if the server is running TACACS or a TACACS+, enter a secret key, if necessary, for TACACS+, and select the appropriate Se r vice from the drop-down menu. (Note that you will not have to select a service with TACACS+.) This panel is illustrated in Figure 3.26.

click to expand
Figure 3.26: TACACS Server Properties

Lightweight Database Access Protocol Account Unit

Lightweight Database Access Protocol (LDAP) is used for a bevy of purposes. With regards to FW-1, this server object is used for the purposes of user management. A full discussion of the workings of LDAP is beyond the scope of this book but it is reasonable to assume if you are configuring an LDAP object, that you have access to an existing LDAP server and the necessary information. Figure 3.27 illustrates the General panel for LDAP configuration.

click to expand
Figure 3.27: LDAP Account Unit Properties

Certificate Authority

Even though Check Point builds has an Internal Certificate Authority (ICA), it will often not meet your Public Key Infrastructure (PKI) flexibility requirements when used outside the Check Point infrastructure. The inclusion of a Certificate Authority (CA) in your security infrastructure enables you to use certificate-based authentication and encryption that eases (or perhaps shifts) the administrative burden of VPN development.

There are three tabs for the CA object, with the first being the General tab. The associated panel allows the standard configuration information of name, comment, and color, as well as the ability to specify the CA vendor via a drop-down menu. Your choices in this drop-down will be determined by what you will be interoperating with. The contents of the second panel depend on the selection in this drop-down box.

The contents of the second panel will vary depending on your CA selection, but generally allow for the importing of a configuration from the PKI server and the importing of the CA s public certificate. You may also be able to specify the method of accessing the CAs certificate revocation list (CRL).

The Advanced panel deals with the CRL for this server; specifically, it configures the desire to cache the CRL and when to fetch a new CRL. You can also assign what branches are to be allowed.

SecuRemote DNS

SecuRemote DNS is an internal server type used to resolve private addresses to names. SecuRemote DNS replaces the need to create a dnsinfo.C file on the management server s $FWDIR/conf directory. You will, however, still need to edit $FWDIR/lib/crypt.def , adding the line #define ENCDNS to enable SecuRemote users to download this information along with their topology. This is not necessary if you are not using SecuRemote, but rather using SecureClient with Office Mode.

Configuration of this server type is fairly straightforward. You have two tabs: General and Domains . The General panel allows the configuration of the name, comment, color, and host. As usual, the host must have previously been defined as a workstation object.

The Domains panel lists the domains that are included for resolution, as well as something called a Maximum Label Prefix Count . This count defines the number of prefixes that will be allowed for the specific domain. For example, if the domain is .edu , then troll.gatech.edu has two prefixes. If the maximum prefix count were 1, this domain would not be resolved through the encrypted tunnel.

Internal Users

The ability to define users on the firewall is a nice feature, but is also administratively intensive . The benefit is that you can select specific groups of users as the source for traffic in a rule. The downside is you have to define these users. Fortunately, Check Point has simplified this process somewhat with the ability to define generic user templates. The use of LDAP as an external source of user information is also supported, which greatly decreases the workload redundancy of a firewall administrator. The user creation process is looked at in detail in Chapter 6.

The first step is to bring up the Users interface. This is accessed by selecting Manage Users from the SmartDashboard menu. This window is used to define and modify users, and to install the user database to the VPN-1/FW-1 systems on which this policy is installed.

Time

Time objects are objects that enable you to schedule events, restrict connections, or simply quantify a time period. For example, you can restrict web browsing not only to specific sites, but also to specific times. There are three possible object types to select from. You can specify a time, a scheduled event, or a group of one or more of these types. To create a new time object, select Manage Time from your SmartDashboard window.

The Time object is used to restrict the application of rules to specified times. There are two panels to this object: General and Days . The General panel allows the standard settings, as well as up to three time ranges. These ranges specify the time spans in which this object would be applicable . The Days panel enables you to enforce a finer-grained access control on the time object. You can specify days of a week, or a specific date, or a numbered day in each month. This is a very flexible tool. Figure 3.28 illustrates the Days panel.

click to expand
Figure 3.28: Time Object ”Days Panel

Group

A group is formed by the combination of several time object types, and can be used to simplify time-based rules. Instead of using multiple rules, you can create a group of time objects and assign this to a single rule. Creating a time group is similar to the other group types, and consists of assigning a name, comment, and color and then moving time objects from the Not in Group list to the In Group list.

Scheduled Event

A scheduled event is most often used for administrative purposes, such as scheduling log changes. Configuration is simple, with the only interesting field being the specification of the time at which the event will be triggered. As with the Time object, you can also schedule the repetition frequency of the object. For example, when you define the Management machine, you have access to the Management branch of the Workstation properties. The Schedule log switch to: field requires the use of a time object as its option.

Virtual Link

A virtual link is a path between two VPN-1/FW-1 modules or FloodGate-1 modules. Virtual links are defined in the SmartDashboard, and can be given Service Level Agreement (SLA) parameters. They can then be monitored using Check Point s SmartView Monitor GUI. To add a new virtual link, select SmartView Monitor Virtual Links from the Manage menu in the SmartDashboard.

There are two panels to be configured. The General panel defines the name, comment, and color for the link, and also enables you to define the endpoints and to optionally activate the link.

The SLA Parameters panel, shown in Figure 3.29, enables you to specify the criteria that will be used to measure the integrity of the link. Thresholds are defined in three directions of traffic. You can specify the Committed Information Rate (CIR) for traffic point A to point B, and the reverse as well. You can also specify a maximum round trip time (RTT) for bidirectional communication, and optionally log the SLA statistics.

click to expand
Figure 3.29: Virtual Link Properties ”SLA Parameters



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

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