User-Defined Tracking

User -Defined Tracking

CP VPN-1/FW-1 features very robust event handling, but it isn t always able to do exactly what you want. In some cases you need to send multiple alert types, or need to send them to many different people. Check Point foresaw this need and has included the user-defined alert type. With this alert type, VPN-1 /FW-1 NG AI provides you the ability to create your own event-handling scripts to suit your needs. You also don t have to learn a new programming language to do so. If you are proficient in C, C++, Perl, WSH, the various UNIX shell-scripting languages, or even writing BAT files, then you are well on the way to creating a user-defined response. You also might be able to find an existing script via the Internet that would suit your needs.

The process of writing your own script is fairly simple; however; there are a number of ways to go about it. Initially, you may be more inclined to use user-defined alerts to generate multiple alert types. Suppose, for example, that you want to send an SNMP trap to a network management console, to a security console, and also mail an alert to yourself. Writing a simple Windows batch or

Figure 9.4: Alerting in Use

UNIX shell script will get this done for you with minimal effort, as shown in Figure 9.5.

 snmp_trap 172.17.2.15 snmp_trap 172.17.2.16 mailx -s Warning [e-mail] 

Advanced User-Defined Alerts

If you want to move into more advanced realms, the first step is to understand what VPN-1/FW-1 NG AI will be sending as input to your script. The format for this input is as seen in this example:

 10Nov2003 15:00:12 drop   ExternalFW   >eth1 proto tcp       src 172.17.3.2 dst 172.17.2.10 service 1234 s_port 2345       len 40 rule 5 

The various fields are described in Table 9.1.

Table 9.1: Basic User-Defined Alert Input

Field	Example
Date	10Nov2003
Time	15:00:12
Action	Drop
Originating firewall	ExternalFW
Traffic direction and interface	>eth1
Protocol in use	proto tcp
Source address	src 172.17.3.2
Destination address	dst 172.17.2.10
Service in use	service 1234
Source port	s_port 2345
Length of data captured	len 40
Rule matched	rule 5

Note that values these are the basic log input values. The values will change depending on your use of network address translation (NAT), VPN encryption, or the alerting of Internet Control Message Protocol (ICMP) packets. For example, an ICMP packet will include field information for the icmp-type and icmp-code . These additional fields are detailed in Table 9.2.

Table 9.2: ICMP and NAT User-Defined Input

Field	Explanation
icmp-type	ICMP type
icmp-code	ICMP code
Xlatesrc	When using NAT, this indicates the address to which the source IP was translated.
Xlatedst	When using NAT, this indicates the address to which the destination IP was translated.
Xlatesport	When using NAT, this indicates the port to which the source port was translated.
Xlatedport	When using NAT, this indicates the port to which the destination port was translated.

Once you understand what VPN-1/FW-1 NG AI will be sending your program, you can then make logical decisions as to what to do with the data. User-defined alerting can be very useful as a method to inform various people based on what the rule detects. For example, the script could parse out the destination IP address or system name , compare that information to a database and then, from the database, locate the proper contact information for the individual responsible. Once this person is located, he or she can be notified via any of several means, allowing the person a more rapid response to the attack. Some other common examples use the global WHOIS database to attempt to locate the administrator of the source of the event, and attempt to notify that person as well. Figure 9.6 includes a partial script as an example of how to get started. It s written in Perl, but, as mentioned earlier, the choice is yours.

 #!/usr/bin/perl -w # # Here we'll request strict pragma checking and import a module to  # assist in sending a mail message. use strict;   use Net::SMTP; # Good programming practice mandates security! $ENV{'PATH'} = '/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin'; umask (0177); # Get the log entry and break it up into smaller, useable bits. my $log = <STDIN>;          my @elements = split (/[ ]+/, $log); # Identify the most commonly used elements and assign them for frequent # use. my $date      = $elements[0]; my $time      = $elements[1]; my $source    = $elements[9]; my $destination = $elements[11]; # The array element to use can vary depending on the use of NAT, among other factors. Be sure to test.  my $service    = $elements[13]; (...) 

You can see that it is actually very simple to get the log data. Any program that can gather one line of input and parse it up will do the trick. The only remaining tasks are to install your program in $FWDIR/bin on the machine running the firewall management module, and point to it within the Global Properties. The fact that the alert script runs on the management module makes deploying this user-defined script much easier, especially in a large network. And, since it runs in one central location with access to all the firewall logs, you can also perform simple event correlation. OPSEC partners provide packages that provide more complex event correlations to suit your needs.