Alerts

Now that I have discussed the two applications that let you look at logs and alerts, I will talk about alerts themselves; mainly, how they are generated. Aside from creating rules that have a Track of one of the alert types, you need to configure the Log and Alert frame of the Global Properties screen, which is shown in Figure 5.11. This allows you to configure some additional events that get logged. The alert types and the commands they execute are specified in the Alert Commands frame (subsection of the Log and Alert frame); see Figure 5.12. Note that all commands listed must be executable on the management console, not on individual firewalls.

NOTE!

All "alerted" entries also generate a log entry.

The additional activities on which you can control logging include those listed below. (The pop-up menu to the right of each item shown in Figure 5.11 controls how that action is logged or alerted.)

VPN successful key exchange: The appropriate log or alert is generated when a successful key exchange occurs for either a client-to-site VPN or a site-to-site VPN.

VPN packet handling errors: If errors occur while processing encrypted packets (e.g., because they are malformed or come from the wrong host), this activity generates the appropriate log and/or alert.

VPN configuration & key exchange errors: A log or alert is generated if a configuration error occurs in the VPN-related configuration (e.g., attempting to encrypt to a network within your encryption domain) or if an error occurs during a key exchange.

IP Options drop: All packets containing IP Options are dropped. This entry controls how IP Options drops are logged. This is set to None by default. Why this isn't set to at least Log is beyond me.

Administrative notifications: This generates a log or alert for various administrative items, such as when a certificate is about to expire.

SLA violation: If a virtual link is defined and the availability parameters defined for that link are not met, that is, the virtual link does not meet the established Service Level Agreement (SLA), this activity generates the appropriate log or alert entry.

Connection matched by SAM: If SmartDefense/SAM determines certain packets are among its predefined network attacks, this generates the appropriate log entry or alert.

Dynamic object resolution failure: If for some reason a module is not able to resolve a dynamic object (e.g., you have not executed the appropriate commands on the module to define it), this activity generates the appropriate alert or log entry.

Log every authenticated HTTP connection: In many cases, loading a Web page requires more than one connection to be opened. If this option is checked, each and every one of those connections will be logged instead of just the first one to a particular site.

Excessive log grace period: To try to limit the number of entries logged to the log file, FireWall-1 keeps track of everything logged for a set period of time, and if a particular activity (by source, destination, service, and source port) occurs within the excessive log grace period multiple times, only one log entry is generated. By default, this option is set to 62 seconds, which in reality results in about 60 seconds. Whatever setting you choose, be sure to add 2 seconds to the value.

SmartView Tracker resolving timeout: This option indicates the number of seconds the SmartView Tracker/Log Viewer spends on attempting to resolve the IP addresses of entries shown. Note that this timeout does not always seem to be enforced on Windows when WINS is used to resolve names.

Virtual Link statistics logging interval: When virtual links are defined, this option defines how often the statistics for these links are updated.

Status fetching interval: This determines how frequently the management station queries your other Check Point modules to obtain status information.

Log Traffic (for Community Default Rule): If you have enabled the "Accept all encrypted traffic" option in any of your VPN Communities, this option controls whether or not those default rules generate log entries.

As mentioned, Figure 5.12 shows the different types of alerts and the actions taken for those alerts. There are two types of actions for each alert; you can select either, neither, or both of them.

Send alert to Status Manager: The alert is sent to the Status Manager, where it is displayed in a pop-up window.

Run script: When the alert occurs, run the indicated script from your management console. Unless a full path is specified, the command is assumed to be in your OS path.

Note that it is possible to write your own script or program that parses the input and performs an action based on that input. The script must take a single line of text from standard input (stdin). The format used is identical to how log entries are output via the command fw log. Once you have your program written, you simply replace the appropriate alert command with the complete pathname to the script or program on the management console.

NOTE!

If you make any changes to these properties, you will have to reinstall the security policy before they will take effect.

A Word on Mail Alerts

A common belief among FireWall-1 administrators is that there is some magic to e-mail alerts. There really isn't. A command is executed on your platform that sends the e-mail. UNIX platforms usually have some sort of command-line utility (e.g., mail or mailx) that can take a subject and recipient via command-line arguments and message data until an end-of-file is reached. In order for these commands to deliver e-mails to anything beyond the local system, some sort of sendmail-type application must be available. If one of these is not available or not configured correctly, I recommend installing something like sSMTP (available at http://ibiblio.org/pub/Linux/system/mail/mta/, among other places), which is nothing more than a way to relay e-mail to a proper mail hub for processing. IPSO-based platforms have everything you need to do this, provided you have configured the appropriate mail gateway and from address in Voyager.

Windows-based platforms do not generally contain a command-line mail utility, so Check Point includes a sendmail binary, which functions like a mail or mailx program on UNIX. It also allows you to use the command line to specify the SMTP server to send the message through. You will need to change the command shown in the Alert Commands frame of the Global Properties screen to:

sendmail ?s Alert ?f fw1@yourdomain -t ip-of-smtp-server you@yourdomain