Q: How do I set up a policy on the DC to alert me or perform some other action when an IDS rule fires?

A:

Create the elements

You might have these already set up, in which case jump to the next section. Otherwise, take a gander at these instructions:

• Create or find the IDS rule and note the SID.
• Create the alert profile that sends you an email or syslog, if you don't already have it. You'll want to have alert profiles set up that you can use wherever needed, so do it now if you haven't. To do this, go to policy/repsonses/alerts
• Configure remediation profile instances if you don't already have them. An instance might be a certain type of NMAP scan or Nessus scan. These remediations, along with the alert profiles, will be there for you to choose from later as "responses" to an IDS event. To do this:
  1. policy/responses/remediations
  2. Pick a remediation, say "NMAP scan"
  3. Add an instance to hold your remediations, or use your existing instance.
  4. In the instance, add a remediation; the name you give it is not editable and will later appear as a "remediations" choice so be terse but explanatory.
  5. Set up the parameters for your scan and save.

Get the rule working

policy/compliance/rule management

1. Create a rule. You can put it in a group or not, it does not matter; rules are managed individually. The groups are there for you to organize your rules.
2. In the rule, choose the SID and perhaps the Detection Engines that control when the rule fires. You can do other granular stuff here too, such as filtering on IP address. Have fun.

policy/compliance/policy management

1. Create a policy or use one you already have. It doesn't matter; the responses will be configured per rule.
2. Add the rule you just created to your policy.
3. Click on "responses" next to your rule in the policy, choose one or more. This is where you will see the alerts and the responses that you configured in the first section of this instruction. Click "update" to save your choices.

Q: How do I know of my IS has enough processing power to process all the packets it hears?

A:

On the DC, go into operations / monitoring / performance / IPS.

Choose the IS you want to look at, choose the '% packets dropped' graph, and choose a suitable time period. The resulting graph will show you if and when packets got dropped because Snort couldn't handle them.

Q: Why do I get two identical syslog messages from some alerts, one from the DC, and the other from the IS?

A:

It is possible to configure the syslog settings separately for the DC and the IS. The IS alerts are produced according to each detection engine policy, where the DC alerts are produced according to compliance events or to "responses".

the Detection Engine controls the IS

To set the policy for the IS, set it on the detection engine. Edit the detection engine (D.E.) and choose "alerting". The syslog settings for the D.E. control where every alert for that D.E. is syslogged. In my case I wanted all alerting to come from the DC, so I turned it off on every D.E. so it would not come from the IS too.

The DC has granular alerting capability

For the DC, see Policy & Responses/Alerts. You can create one or more syslog-type alerting mechanisms there, and activate or deactivate each one.

Then, go to Policy & Responses/Impact Flag Alerts. Here you can select one of the syslog-type mechanisms you defined above, and choose whether to receive a syslog message according to the impact flag on the alert.

You can do the same for RNA Event Alerts too. There are other features on the DC which can be configured to generate a syslog event, such as in Policy & Response/Compliance/Policy Management.

Q: How do I generate a rule profiling report on my sensor?

A:

A rule profiling report is useful in determining which rules are putting the greatest load on your sensor. Changes are made to the sensor configuration to allow sampling. The report will show the aggregate time the D.E. spends on each rule during the sampling period. Sampling should then be disabled, as the sampling itself it adds a hefty load to the system.

Sampling is done one D.E., one sensor, at a time. Unfortunately, there is no way to perform the sampling using the GUI on either the DC or the sensor. You have to log in at the command line of the sensor and do it manually. Here's how:

1. Add the following lines to the user.conf file in /var/sf/detection_engines/{DE crazynumber}

   #Rule and Preprocessor profiling
   config profile_rules: print all, sort total_ticks config profile_preprocs: print 100, sort total_ticks
   

2. Restart the software using /etc/rc.d/init.d/sensor restart
3. Let the sensor run for the sampling period (about 30 minutes?), and then stop the sensor software with /etc/rc.d/init.d/sensor stop
4. Comment out the lines you added into the user.conf file by adding # in front of them. (Profiling does have an impact on sensor performance and should be disabled when not actively being run, which is why it is not on by default.)
5. Start the system back up: /etc/rc.d/init.d/sensor start. If you have a problem after doing this, as I did, you may rather just reboot the sensor.
6. Snort has put profiling data into /var/log/messages. Running 'cat /var/log/messages | grep snort | less' will limit the amount of log you need to scroll through. Scroll until you see the long list of rule sids.
7. To get other performance statistics, cd to /var/sf/detection_engines/{DE crazynumber}/ and do an 'ls'. You will see files named by date. Simply run 'cat {filename} | perfstats' to get the statistics for that day.

Q: How do I set up a custom rule that fires an alert by email or SNMP trap?

A:

Make sure the alert mechanism you will want to use (email to who? syslog where? etc.) is set up in [ Policy & Response // Responses // Alerts ]. Then:

1. First create the custom rule. Since later when we create the alert we will be able to filter on source or dest IP (or other criteria) you may not want to limit the custom rule to a group of IPs, if you still want the event detected but not receive an alert for most IPs. Make a note of the rule SID.
2. Now navigate to: [ Policy & Response // Compliance // Rule Management ] and create a rule. Give the rule a good name and description, and make it of type intrusion event. Add a condition that the rule SID match the custom rule you just created, and add other criteria if needed.
3. Now navigate to: [ Policy & Response // Compliance // Policy Management ] and create a new policy (or edit an existing policy of you want to group the alerts together). Give the policy a good name and description, and use the "add a rule" dialog to select the Compliance rule you just created. Once added, click on "responses" next to the rule, and use the quirky dialog to add one or more responses that alerts you in the manner desired using the alerts you already have configured.
4. Finally, activate the Compliance Policy.

Q: How can I put a favicon on my Sourcefire Defence Center's webpages?

A:

If you're like me, you like to have favicons because they make your browser's bookmarks look so much better. I don't know why Sourcefire does not include a favicon, but it seems to work (at least for Firefox) just to put a favicon in the correct location on the DC.

First get or make a favicon you want to use. I spent 10 minutes cutting out a little pig and converting it to favicon format, only to later realize that what I ended up with looked exactly like the favicon on http://www.snort.org/, except mine did not have the transparent background. So I grabbed http://www.snort.org/favicon.ico.

Once you have your favicon.ico file ready, just copy it to your Defense Center webserver's document root. For me this was /usr/local/sf/htdocs/favicon.ico. If you are using Firefox, it will find the favicon for you without it having to be in the HTML head section or anything like that.

Q: How do I put a bpf filter on a detection engine?

A:

• On the IS, create a file containing your bpf. This could be called /etc/sf/snort.bpf. This file can have multiple bpfs on one line. Comments are also allowed with the # sign. not net 192.168.0.0/16 and not port 80
• Edit /var/sf/detection_engines/{crazynumber}/user.conf. This file should be blank, and you will need to add the following line to the file: config bpf_file: /etc/sf/snort.bpf
• Restart the sensor software: /etc/rc.d/init.d/sensor restart

Once these files have been created, you can just copy the user.conf and snort.bpf files into place on your other sensors and detection engines and restart the sensor software to configure the rest of the machines. There is no way to verify that this is working other than checking your events. Snort will not start if there is a syntax error. This can be monitored from /var/log/messages.