Alerts Commands | Check Point NG[s]AI

Your main day-to-day interaction with the firewall will be the handling of the alerts that it generates and creating new rules. These alerts are generated by the rules you have configured, and are also customizable. Using the SmartDashboard graphical user interface (GUI), you can customize the various alert types. Select Policy Global Properties and then select the Log and Alert branch from the left. You ll see a screen like the one shown in Figure 9.1.

This panel contains a significant amount of information, but it is all pretty straightforward. The default settings are shown in Figure 9.1, but these settings may be altered to be any of the valid responses (including Log , Popup Alert , Mail Alert , and so on).

Figure 9.1: Log and Alert Main Menu

Using Track Options

The Track Options are very useful for seeing information about administrative happenings, such as virtual private network (VPN) information, as well as for a couple of security related issues, such as connections matched by suspicious activity monitoring (SAM). Say, for example, that your organization has placed the burden of configuring a VPN on your lap, and now you must troubleshoot while you attempt to establish this VPN with your parent organization. These options could be useful to you while you are in the first stages, by logging or alerting based on the criteria you select here.

VPN successful key exchange This event is triggered by the successful exchange of VPN keys.
VPN packet handling errors This denotes an error in a VPN connection, such as a method mismatch.
VPN configuration and key exchange errors This field defines the behavior that FW-1 will exhibit when a VPN configuration or key exchange event fails.
IP Options drop This is triggered by an Internet Protocol (IP) packet with options set. Since options are rarely (if ever) useful in a valid connection, CP VPN-1/FW-1 will always drop these packets. You may, however, do something when you see such a packet. Often, such packets are used to probe a network, so it might be wise to at least log them.
Administrative notifications This action is triggered by a FW-1 administrative notification.
SLA violation Used in concert with the Traffic Monitor, this event will alert you when a Service Level Agreement (SLA) has been breached.
Connection matched by SAM This defines action taken when a packet belonging to a SAM inhibited connection is matched. SAM is discussed later in this chapter.
Dynamic object resolution failure This defines action taken when a firewall loads a policy in which a dynamic object is used but it cannot resolve it. Most often this is used in conjunction with SmartLSM.

Logging Modifiers Options

The Logging Modifiers section features only a single option, Log every authenticated HTTP connection . This option instructs CP VPN-1/FW-1 to log each HTTP (Hypertext Transfer Protocol) request when a user has been authenticated. Because with the HTTP 1.1 protocol specification more than one request can be made in a single TCP connection, the firewall will only log the first request for brevity.

Time Settings Options

The Time Settings options can help decrease the amount of data that you see in your Log Viewer. You can accomplish this by setting thresholds on the packet flows, and recording only the data that is unique within that threshold.

Excessive log grace period This defines the time in which packets belonging to an established Transfer Control Protocol (TCP) flow are considered uninteresting to CP VPN-1/FW-1 for logging purposes. Increasing this value has a proportionate decreasing impact on your log volume. Packets are considered part of the same flow if they have an identical packet header, meaning that they contain the same source address, source port, destination address, and destination port (for example, Telnet), and that they use the same protocol (for example, TCP=protocol 6). You can find a list of commonly used protocol numbers on most UNIX systems in the /etc/protocols file. Note that packets will still be inspected and acted on, but the logging of the packet will be suppressed.
SmartView Tracker resolving timeout This indicates the amount of time that CP VPN-1/FW-1 will attempt to resolve Internet Protocol (IP) addresses into hostnames before quitting. If this time is reached, the IP address will be displayed in the Log Viewer instead. If the CP VPN-1/FW-1 Log Viewer GUI is slow in being displayed, you could adjust this setting to increase the Viewer s speed.
Virtual Link statistics logging interval Specifies the amount of time between Virtual Link informative packets. This is meaningful if you are using SmartView Monitor and if you have properly defined virtual links between modules you manage.
Status fetching interval Specifies how often your management station will query other systems it manages for status information. This can be any value between 30 and 900 seconds.

There is also a sub-panel, which is shown in Figure 9.2. This panel enables you to configure your response programs. Generally, most of the information on this panel does not require any altering, with the exception of the pointers for user-defined scripts.

Community Default Rule

Similar to the Logging Modifiers section, the Community Default Rule section features only one option: Log Traffic . This option specifies whether or not to log connections established through the VPN community. This is only meaningful if you select Accept all encrypted traffic in the community . The selection you make here will be shown (read-only) in the General page of the Community s configuration as well as the Track column in the VPN community s Accept rule in the rulebase.

The default alert, fwalert from the command line, is enabled by default for both the normal alert handling as well as the three optional user-defined alerts (a nice increase from the single user-defined alert offered by pre-NG installations). As you can see in Figure 9.2, each field enables you to interact with the SmartView Status component by sending the information for the log to the SmartView Status GUI as well as run a custom executable or script.

Figure 9.2: Alert Commands Sub-Menu

Keep in mind that the event is acted on by the machine that records the logs. While in the majority of cases this is the management machine, it does not necessarily have to be. Also note that the actual executables and scripts reside in the $FWDIR/bin directory on the system recording the log, which is typically the Management module. This is also where you would need to save your user-defined alert programs. You will also need to remember to copy your programs to the new $FWDIR/bin directory after an upgrade if you choose to use other utilities. Below is a brief description of how each scripting option may be used.

Pop-up alert script This is the script that will be executed when you select Popup Alert as the action for a matched rule. Generally, this option should not be changed. One item of special note here is the actual function of a Popup Alert. When you are running the SmartView Status GUI, and a rule is matched whose action is alert, and Send popup alert to SmartView Status is selected, you will be notified with a window containing details of the alert. These details include the packet information as well as items such as the component generating the alert. The pop-up window enables you to delete single events or all selected events.
Mail alert script This specifies the command that will be run to send an e-mail alert regarding the matched event, assuming that this action is the specified one. You will need to change this and the command will be specific to your system. The syntax for the command is:
```
 internal_sendmail [-s subject] -t mailserver [-f sender_email] recipient_email [recipient_email ...] 
```
SNMP trap alert script Defines the action when a rule with the Simple Network Management Protocol (SNMP) trap action is matched. You may decide to alter this to send your traps to alternate locations, such as to a network management station instead of the default system, localhost.
User defined script (No. 1, 2, and 3): These allow for you to write your own programs to handle a matched rule, and are very handy. User-defined alerts are covered later in this chapter.

Configuring Alerts

Once you have properly configured the commands to be run, you are ready to begin using them as an action. Your most frequent interaction with them will be in the rules you create for your firewall. When you create a new rule, or wish to modify an existing rule, simply right-click on the Action column and you ll see a Context menu, as shown in Figure 9.3.

Figure 9.3: Alert Context Menu

You also may interact with the alerting function within various network objects. For example, Figure 9.4 shows us the Firewall Object s Interface Properties window with the Topology panel active. Note the field labeled Spoof Tracking. In this field you ll be able to configure alerting for this event.