Examples

Note: The various configuration parameters are described earlier in this chapter.

Configuring Message Handling for SNMP Traps

This is an example of how to set up Traverse to receive an alert when there is a trap sent by a Netscreen firewall for a UDP flood alert.

Configuring Message Handling

1. Add a rule in your ruleset definition file. For example, add the following text to the plugins/messages/00_rule_traps.xml file:

<Traverse>

<message-handler>

 <!-- udp flood rule -->

 <ruleset type="trap" name="162">

 <rule>

  <description>Netscreen: UDP Flood Attack</description> <pattern>TRAP:\s+\S+\s+(\S+)\s+\(\S+\)\s+\.1\.3\.6\.1\.4\.1\.3224\.1\.4:200\s+1:[^=]+=12;\s+2:[^=]+=([^\:]+:\s+)?(.*);</pattern>

  <action>accept</action>

  <mapping>

    <field name="device_name" match="-1"/>

    <field name="device_address" match="1"/>

    <field name="alert_text" match="3"/>

  </mapping>

  <transform>${alert_text}</transform>

  <severity>warning</severity>

  <show-message>true</show-message>

  <auto-clear>300</auto-clear>

</rule>

</ruleset> <!-- end UDP flood rule -->

</message-handler>

</Traverse>

1. Provision the firewall device into Traverse as an end user by going to Administration > Devices > Create a Device. There is no need to create any specific test for this purpose.
2. Make sure you are accepting SNMP traps from this device by going to Administration > Other > SNMP Trap, Windows EventLog and add this device to the accept list or else select accept all events.
3. If the device is provisioned under a name or address that is not same as the source of incoming traps, you must add this address in Administration > Other > SNMP Trap, Windows EventLog > Device Aliases.
4. Finally, apply an action profile to this type of event. Navigate to Administration > Actions > Assign to Events, enable Select Message Types next to the firewall device, and on the following page, select the same event (as above). If you didn't want to individually select message types (that is, only filter by type that you accept), you could use Administration > Other > SNMP Trap, Windows EventLog > Message Notification, and apply an action profile for actions in the selected profile should be executed. This will cause this action profile to be executed for all matched message events.

This example triggers the following email notification:

From: traverse@Kaseyacustomer.com

Date: Wed, 27 Apr 2008 08:03:41

To: root@Kaseyacustomer.com

Subject: [Traverse] fw00.dnvr01/Warning: Netscreen: UDP Flood Attack

Event Match Notification from Traverse:

Department Name : Acme_Company

Device Name : fw00.dnvr01

Device Address : 204.0.80.43

Event Source : trap/162

Current Severity : Warning

Test Time : April 27, 2008 8:03:41 AM MDT

Transformed Message :

Port Scan Attempt from 213.46.8.202 to 204.0.80.49 protocol 6 (No Name) (2005-4-27 08:46:38)

Handling Syslog Messages from a Router

1. Start by creating a "source" for the syslog file where messages from routers are being sent. Lets say you have configured your syslog daemon on the DGE host to log all such messages into /var/log/router. A corresponding source definition file should be created in plugin/messages with a filename such as 00_src_syslog_router.xml. Inside this file is a source definition, e.g.

<message-handler>

 <source type="file" name="router">

   <enabled>true</enabled>

   <input>/var/log/router</input>

 </source>

</message-handler>

On a Windows host, you will need to set up the native syslog handler as described in Processing Syslog Messages.

1. Next, we need to create a rule for this source (type="file", name="router") if using the file source, or (type="syslogd", name="default") for syslogd. The rule will accept all messages in the log file/syslogd and display it on the Event Console for 15 minutes. After that time, the message is auto-acknowledged and removed from view. For now, all of these messages will be displayed with OK severity. You will need to create plugin/messages/90_rule_syslog_router.xml with following contents:

<Traverse>

<message-handler>

 <ruleset type="file" name="router">

 <!-- <ruleset type="syslogd" name="default"> -->

  <rule>

   <description>Default Action for Router Messages</description>

   <pattern>:\d+\s+(\w+)\s+(.*)</pattern>

   <action>accept</action>

   <mapping>

     <field name="device_name" match="1"/>

     <field name="message_text" match="2"/>

   </mapping>

   <severity>ok</severity>

   <show-message>true</show-message>

   <auto-clear>900</auto-clear>

   <transform>${message_text}</transform>

  </rule>

 </ruleset>

</message-handler>

</Traverse>

1. Restart the Traverse components so that the new source and ruleset are activated (using etc/traverse.init restart)
2. Before the Message Handler accepts a message from a router, it will check to see if the device is provisioned in Traverse so you should provision your routers and switches into Traverse at this stage if they are not already provisioned.
3. Make sure that the Message Handler is configured to accept messages from your routers by logging in to the web application (as end user) and navigating to Manage > Messages > Message Filters. You should either use the accept all messages... option, or ensure that the devices in question are listed under accept from list. For the latter option, after you click continue, you should see (file/router) Default Action for Router Messages as one of the available message types. Either choose that option, or select the option to accept all messages.
4. The Message Handler will try to match the device sending syslog message by it's source IP address, as recorded in the log file and the provisioned device's IP address. For example, in the following log entry from a Cisco router:

Aug 1 06:54:10 172.27.72.254 13822: Aug 1 06:51:46.772:

%CRYPTO-6-IKMP_NOT_ENCRYPTED: IKE packet from 65.203.13.221

was not encrypted and it should've been.

The source address of this message is 172.27.72.254. If this is the same IP address that was used to provision the device in Traverse, no further action is required.

1. If this particular address is the loopback address on the router (as an example), and the device was provisioned into Traverse using (for example) it's fast-ethernet interface, then you need to tell the Message Handler that 172.27.72.254 is an additional address for this device. This is accomplished by logging in as end user into the web application, navigating to Administration > Other > SNMP Trap, Windows EventLog > Device Aliases, and then clicking Load after selecting the device in question. On the text box, supply the alternate IP address (172.27.72.254) or names (e.g. "The FQDN for 172.27.72.254"), one on each line.

   As messages are logged in /var/log/router or received via the syslogd listener in Traverse, you should now see them show up on the Event Manager console. You should customize which events you want to display and possibly trigger alerts.