The Bad News
Not directly, not in the way you want. You can specify multiple alert outputs, as described in the Section 2.6 of the manual. However, this will simply send the same alerts to multiple locations. You'll still have alerts from signatures imported from both ddos.rules
and log.rules
logged together.
The Good News
Fear not, we can make it work. What you'll have to do is create multiple config files and have each log separately. Depending on exactly how you want to split up the traffic there are a couple of ways you can go.
MultiConfig
Snort has a mechanism built-in to allow for processing different packet streams against different config files. This can be useful if you segment your applications based on network or VLAN. That is, all mail apps are on one VLAN, web servers on another, etc. The full details are provided in Section 2.10 of the manual, but the most relevant bits to understand are that it's dependent on VLAN or network, and there can be no duplicates. Meaning this is a valid configuration,
config binding: /etc/snort/snort.conf-ddos net 192.168.100.0/24
config binding: /etc/snort/snort.conf-log net 192.168.200.0/24
but this is not.
config binding: /etc/snort/snort.conf-ddos net 192.168.100.0/24
config binding: /etc/snort/snort.conf-log net 192.168.100.0/24
To use this feature in your situation you would have to run ddos.rules
against one set of hosts and log.rules
against another. I doubt you want to take this approach.
Multiple Instances
To date snort is single threaded so when processing is intense enough to utilize one complete processor it will begin dropping packets. Thanks to this you will often find snort sensors with several versions of snort running. Generally this works by using something called PF_RING, which is like a packet load balancer, or by chopping up your network space and running one version of snort per block. So one instance of snortd
monitoring 192.168.1.0/25
and another watching 192.168.1.128/25
. In most cases each process will use the same config file but just only watch certain addresses.
We can take that approach and turn it on it's head a bit to work in your situation. Let's create two config files and set the relevant portions thusly.
/etc/snort/snort.conf-ddos
output alert_syslog: LOG_LOCAL0 LOG_ALERT
include $RULE_PATH/ddos.rules
/etc/snort/snort.conf-log
output alert_syslog: LOG_LOCAL1 LOG_ALERT
include $RULE_PATH/log.rules
Then we set up your syslog engine, restarting it after making the change of course.
local0.alert /var/log/snort/alert-ddos.log
local1.alert /var/log/snort/alert-log.log
Now when you run snort you do it twice, each using the -c
option. The first time we'll use -c /etc/snort/snort.conf-ddos
and the second with -c /etc/snort/snort.conf-log
.
Now you should have two instances of snortd
running, one only with the ddos.rules
signatures and logging to LOCAL0 and one with the log.rules
signatures and logging to LOCAL1. As long as syslog is behaving you should have your alerts logging separately with no co-mingling.