Corelan Cybersecurity Research

As far as I know, there are no free Management Packs available for monitoring Juniper/Netscreen firewalls with Operations Manager 2007. Catching snmp traps and syslog events seems to be the only "easy"/free way to monitor what is going on on your Juniper devices.

The following steps will need to be taken :

• Prepare the OS running Ops Mgr to perform snmp discoveries and accept snmp traps
• Set up the Juniper device to send snmp traps and syslog events to Ops Mgr
• Discover the Juniper devices in Ops Mgr
• Determine what you want to look for and alert on
• Create rule to catch all syslog events
• Create specific rules based on what you want to look for

Prepare the (OpsMgr) Windows OS for snmp discovery and traps

Open "Control Panel" – "Add or Remove Programs", choose "Add/Remove Windows Components", go to "Management and monitoring tools" and enable SNMP and WMI provider for SNMP

After installing SNMP, open "Services.msc" and locate the SNMP service. Make sure the service is set to start automatically.
Next, Right-click SNMP Service and choose properties. Go to the security page and add all of your accepted community names. Make sure you set the Rights to "READ CREATE" for each community name. Finally, verify that SNMP will accept packets from any host

Save these settings, and then restart the snmp service. Since snmp is listening on udp port 161, you should see a corresponding entry to this port in the output of a netstat –na :

Set up Juniper to forward snmp traps and syslog events

You can set this up using the web console or the command line. These are the command line entries :

First, enable snmp on one of the interfaces (so you can discover the device using snmp). I’ll assume that ethernet0/0 is the LAN interface and that is was enabled for management.

set interface ethernet0/0 manage snmp

Set up communities. Assuming that you will send snmp v2c traps with community "public" to OpsMgr running at 192.168.0.1

set snmp community "public" Read-Only Trap-on traffic version v2c
set snmp host "public" 192.168.0.1 255.255.255.255 src-interface ethernet0/0 trap v2
set snmp location "Location of the firewall"
set snmp contact "Who to contact"
set snmp name "firewall01"
set snmp port listen 161
set snmp port trap 162

Notes :
1. if you have created a virtual IP address for management, then that is the IP address that will be used for snmp and syslog.
2. You can use the name of the firewall for dynamic firewall discovery. A good naming convention (which could be as easy as firewall01, firewall02, etc) will be very helpful later on in this document.

Now set up syslog on the Juniper. If 192.168.0.1 is the IP address of your server running OpsMgr and if you want to forward all local1 facilities to that host, then you should use the following commands :

set syslog config "192.168.0.1"
set syslog config "192.168.0.1" facilities local1 local1
set syslog src-interface ethernet0/0
set syslog enable

Discover the devices in OpsMgr

We are ready to discover the devices in OpsMgr. We’ll have to use snmp for this, as we cannot push out an agent to the firewall (which would be a bad idea anyway)

Open the Operations Manager console and go to Administration. Somewhere under Device Management, right click and choose "Discovery Wizard"

Choose Advanced discovery and set the type to "Network Devices"

Enter the IP address or address range that needs to be snmp queried in order to find your firewall. Set the community string to the same string that was configured in the SNMP Service properties and SNMP parameters on the Juniper. Version : v2

Start the discovery and wait for the process to complete. You can discover up to 1000 hosts per run.

If the hosts were discovered, you should see their IP address in the list of Network Devices

Go to the Authoring pane in OpsMgr, right click and choose "Create a new Group". Choose a name for the group and save the group in your custom management pack.

Leave the explicit members empty (unless you don’t want this group to get populated automatically), and under Dynamic Inclusion Rules, click the "Create/Edit rules" button. This is where our naming convention will come handy. Suppose your naming convention says "firewall1", "firewall2" and so on, then you will be able to use the ‘firewall’ part of the string as selection criteria to populate the group.

Select SNMP Network Device and click the Add button

Select "Device Name" as property

Operator : contains, Value firewall

Save/Close the rule

Leave "subgroups" empty

Leave "excluded members" empty

Save the new group.

Find the newly created group in the list of groups, right click and choose ‘View group members’

You should see your firewall(s) listed in this group. Note : it might take a couple of minutes before the members are populated. If they don’t populate, verify the group definition and make sure group population is enabled

Determine what you want to look for and alert on

This next step is very important, as it will dictate the number of rules and content of rules that need to be generated. Before continuing : this document will only describe how to use the syslog messages. We have only used snmp to discover the devices and to group them so we can create an override for them later on.

In this example, I want to know when a policy has been changed, when a configuration has been changed, and when someone has logged on to the firewall. So I need to create 3 rules for this. But before you can create the rules, you need to know how to identify these alerts. The best way to do so is to create a "catch all" syslog rule, alerting on every syslog packet that is presented to OpsMgr.

Create the catch all rule

In the authoring pane of OpsMgr, go to rules. Set the scope of the view to SNMP Network Device.

Right click and choose "Create a new rule"

Create an alert generating rule, event based, for syslog events. Save the rule in your custom management pack

Set a rule name and choose a category (such as notification)

Target : do NOT select the Group as a target, as the rule would look for the events coming from the group object, not the members.
We know that the Juniper firewalls are snmp devices, so choose SNMP Network Device as the target, and leave the rule disabled

Event expression : we only want to look for syslog events coming from firewalls, so we’ll use that criterium to filter events. Click "insert"

Set parameter name to "Hostname", operator to "Contains" and Value to "firewall". Again, this assumes that you have created a naming convention that implies the use of the word "firewall" in the hostname/device name of the firewall.

In the alert section, make sure the rule creates an alert. Put the following lines in the alert description field :

Facility : $Data/EventData/DataItem/Facility$
Severity : $Data/EventData/DataItem/Severity$
Priority : $Data/EventData/DataItem/Priority$
PriorityName : $Data/EventData/DataItem/PriorityName$
TimeStamp : $Data/EventData/DataItem/TimeStamp$
HostName : $Data/EventData/DataItem/HostName$
Message : $Data/EventData/DataItem/Message$

Note : if you want a syslog rule that really catches all events, then first create a rule that contains one expression. Save the rule, edit the rule again, and then remove the expression again. You’ll need to do it this way because you cannot create a rule without setting an expression. So you need to remove the expression after creating and saving the rule.

Save the rule. The rule is still disabled, so we will create an override and target it to the group of Juniper firewalls.

Right click on the rule, choose ‘overrides – override the Rule – For a group"

Select the Juniper/Netscreen Firewalls Group

Enable the Override for "Enabled" and set the override setting to "True"

Save the override.

From this point forward, all syslog messages coming from your Juniper firewall will be catched by the OpsMgr. You should see an entry in netstat –na on the firewall that indicates that UDP port 514 is listening

We have determined that we want to look for 3 types of events :

• Policy changes

• Configuration changes
• Users logging on

You will need to create those 3 events, basically by performing those 3 tasks on your firewall. This will ensure they are being logged within OpsMgr, so we can look at them and create a specific rule for those 3 tasks.

Create specific rules

If you have generated those 3 events, you can look at the body/alert description and use contents of that field to create your rules.

When creating rules, these are the fields that can be used in the parameter name field :

Facility (numeric value)
Severity (numeric value)
Priority
PriorityName
TimeStamp
HostName (string)
Message (string)

http://support.microsoft.com/kb/942863

Facilities are configured using the values in the table below : (use the numeric value from the second column in your rule expression)

Severities are configured using the numeric values in the table below :

So if you want to create an expression that filters on events from Facility Local1, with severity Error, the expression should look like this :

Let’s now create those 3 rules. First disable the override for the "catch all" rule/group again.

First rule : check for policy changes

Create a new rule and choose a good name. Set the Rule Target to SNMP Network Device and leave the rule disabled. Save the rule in your custom management pack.

Rule expression : "Message" contains "Policy". Set the alert settings and save the rule.

Now create an override for the group of Juniper firewalls, enabling the rule, and you’re all set.

Second rule : check for configuration changes. Set the rule expression to
"Message" contains "configuration" AND
"Message" does not contain "policy"

Save and create the override

Third rule : check for logon events. Set the rule expression to "Message" contains "logged in".

Save and create the override

Wait for the events to happen (or re-generate the events) and see if your rules kick in.

If you are getting multiple similar alerts for a single policy change, you’ll need to configure alert suppression.

Edit the rule, go to alerting, and click the "Alert Suppression" button. Click advanced, and enter the following 2 lines in the box :

Save the rule and see if the duplicate alert issue was solved. (You will still see 3 events for a single policy change – that’s just the way Netscreen works)