Custom Rules Files

[Tim Desrochers]

I know this has been asked before but I haven't seen a concrete answer that I can completely understand.

I have one server with multiple sensors. I'd like to create custom rule files (ie: zeustracker.rules, spyeye.rules, watchlist1.rules, etc) that would be applicable to all of my sensors but that need to be updated regularly with additions and subtractions. I'd like to be able to create these files once on the server and have them pushed to each sensor.

I know that I can edit the snort.conf files on each sensor and each interface monitoring and add an include line to the path of my file but what i'd really like is to not have to do that on each and every monitored interface. Then copy the file to each sensor but that is very labor intensive.

Is there anyway to accomplish this with SO?

[Doug Burks]

Hi Tim,

Replies below.

One option would be to simply dump the contents of zeustracker.rules,
spyeye.rules, watchlist1.rules, etc into /etc/nsm/rules/local.rules on
the server. This file gets distributed to all sensors and is already
included in snort.conf.

If you really need the files to be separate and you're running salt,
here's another option:
- copy zeustracker.rules, spyeye.rules, watchlist1.rules, etc to
/etc/nsm/rules/ on the server
- add the individual include statements to /etc/nsm/rules/local.rules
on the server
- salt should automatically replicate the entire /etc/nsm/rules/
directory from the server to all sensors every 15 minutes
- snort on the sensor should include its local
/etc/nsm/rules/local.rules which will then in turn include the
individual rules files

--
Doug Burks
Need Security Onion Training or Commercial Support?
http://securityonionsolutions.com
Last day to register for 3-Day Training Class in Augusta GA is 12/11!

[Tim Desrochers]

So here is what I did.

I do need the watchlists in separate files so I made sure they were included in the /etc/nsm/rules directory on the server.

I added at the top of my local.rules file on the server the statements:
include $RULE_PATH/zeustracker.rules

I ran sudo rule-update on the server

I ran sudo rule-update on the sensor and the ids engine will not restart. I get an error stating it cannot find zeustracker.rules. Also I do not see the entire /etc/nsm/rules folder copied to my sensors.

What did I do wrong

Thanks
Tim

[Doug Burks]

Are you running salt?

--
You received this message because you are subscribed to the Google Groups "security-onion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-onio...@googlegroups.com.
To post to this group, send email to securit...@googlegroups.com.
Visit this group at http://groups.google.com/group/security-onion.
For more options, visit https://groups.google.com/d/optout.

[Tim Desrochers]

Yes I am running salt. I can hit all my sensors with sudo salt '*' test.ping

[Doug Burks]

What is the output of the following command? (Run on your server and
then redact sensitive info as necessary.)
sudo salt-call state.highstate

On Thu, Dec 11, 2014 at 6:28 PM, Tim Desrochers <tgdesr...@gmail.com> wrote:
> Yes I am running salt. I can hit all my sensors with sudo salt '*' test.ping
>

[Tim Desrochers]

I will get you the info first thing tomorrow.  I will not be able to remote into my server until then.  Again thank you for your help

--
You received this message because you are subscribed to a topic in the Google Groups "security-onion" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/security-onion/PZIdezJUidM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to security-onio...@googlegroups.com.

[Tim Desrochers]

See attached for an output from the requested command

[Doug Burks]

Server looks OK. Can you repeat the same command on a sensor?

On Fri, Dec 12, 2014 at 2:06 PM, Tim Desrochers <tgdesr...@gmail.com> wrote:
> See attached for an output from the requested command
>

[Tim Desrochers]

Here you go.

[Doug Burks]

Something doesn't look right. There should be more modules than this:

ID: sudoers
Function: file.append
Name: /etc/sudoers
Result: True
Comment: Appended 0 lines
Changes:

Summary
------------
Succeeded: 1

Did you enable Salt during Setup?

Or did you add it later using the following instructions?
https://code.google.com/p/security-onion/wiki/Salt

Did you perform this step?
# Edit /opt/onionsalt/salt/top.sls and add the new minion as a "sensor"

[Tim Desrochers]

I enabled salt at setup of both the server and sensor. I can run that command and see of that fixes the issue.

Should i ?

> You received this message because you are subscribed to a topic in the Google Groups "security-onion" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/security-onion/PZIdezJUidM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to security-onio...@googlegroups.com.

[Doug Burks]

Does /opt/onionsalt/salt/top.sls have any sensors listed?

[Tim Desrochers]

See attached. I have a sensor listed. Here may be an issue. I changed the hostname of my sensor after I built Ubuntu 12.04 server. my salt commands list my sensor name as ubuntu but I changed it to satcon97, could that be the issue.

[Tim Desrochers]

FIXED!!! The issue was the name in the top.sls file. When installing my sensor with Ubuntu 12.04 server, I named the sensor's hostname "ubuntu". When I started to configure things I renamed the hostname in the hostname file and one other files to "satcon97". When I run salt test.ping SO always called my sensor ubuntu and I couldn't figure out how to change that.

So. I went into the top.sls file and renamed my sensor from satcon97 to ubuntu and that fixed this issue.

Question: What else can this issue effect. What would have been the correct way to change the name of the computer after already installed SO and salt?

Thank you for all of your help. Now at least I know how to stop this from happening again.

[Doug Burks]

When you ran Setup on the sensor, it would have run the following code
(in /usr/bin/sosetup) to add the new salt minion to the master server:

# Enable Salt
# Salt uses FQDN instead of just hostname
FQDN=`python -c 'import socket; print socket.getfqdn()'`
if [ $SERVER -eq 1 ]; then
# If this box is a Master Server we need to
run salt-master
# Copy template files to production location
cp
/opt/onionsalt/pillar/users/init.sls.template
/opt/onionsalt/pillar/users/init.sls
cp /opt/onionsalt/salt/top.sls.template
/opt/onionsalt/salt/top.sls
# Add backend config to salt/top.sls
echo " '$FQDN':" >> /opt/onionsalt/salt/top.sls
echo " - backend" >> /opt/onionsalt/salt/top.sls
echo "" >> /opt/onionsalt/salt/top.sls
# If salt-master is DISABLED we need to enable it
[ -f /etc/init/salt-master.DISABLED ] && mv
/etc/init/salt-master.DISABLED /etc/init/salt-master.conf
[ -f /etc/init/salt-master.override ] && rm -f
/etc/init/salt-master.override
# Start salt-master
service salt-master restart >> $LOG 2>&1
ufw allow salt >> $LOG 2>&1
else
# If this box is not a Master we need to
disable salt-master
# Stop salt-master
service salt-master stop >> $LOG 2>&1
# Disable salt-master
[ -f /etc/init/salt-master.conf ] && echo
"manual" > /etc/init/salt-master.override
# Tell the salt-master that we are a sensor
cat << EOF >> /tmp/sosetupscp
echo " '$FQDN':" >> /opt/onionsalt/salt/top.sls
echo " - sensor" >> /opt/onionsalt/salt/top.sls
echo "" >> /opt/onionsalt/salt/top.sls
EOF


The lines to focus on here are:

# Salt uses FQDN instead of just hostname
FQDN=`python -c 'import socket; print socket.getfqdn()'`

If you manually run the following command, what do you get?
python -c 'import socket; print socket.getfqdn()'

When you changed the hostname, did you change it in /etc/hostname and
also update /etc/hosts?

[Tim Desrochers]

Sorry for the delay in getting back to you.

I did change the hostname in both /etc/hostname and /etc/hosts. When I run the cmd you asked I get the name I renamed my sensor to not Ubuntu. I reran sosetup and ITT still sees my sensor name as Ubuntu not satcon97.

> You received this message because you are subscribed to a topic in the Google Groups "security-onion" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/security-onion/PZIdezJUidM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to security-onio...@googlegroups.com.

[Doug Burks]

After updating /etc/hostname and /etc/hosts, did you also run "sudo
hostname satcon97" and/or reboot?

What is the full output of the following commands?

cat /etc/hostname

cat /etc/hosts

hostname

python -c 'import socket; print socket.getfqdn()'

[Tim Desrochers]

here is the output from the commands requested.

[Doug Burks]

All of that looks correct. In your previous email, you said " ITT
still sees my sensor name as Ubuntu not satcon97". What exactly do
you mean by that?

On Wed, Dec 17, 2014 at 10:22 AM, Tim Desrochers <tgdesr...@gmail.com> wrote:
> here is the output from the commands requested.
>

[Tim Desrochers]

That should have said salt. Darn autocorrect  

> You received this message because you are subscribed to a topic in the Google Groups "security-onion" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/security-onion/PZIdezJUidM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to security-onio...@googlegroups.com.

[Doug Burks]

First, check /opt/onionsalt/salt/top.sls on the master server to make
sure the sensor is defined correctly there.

You may also need to manually override the salt minion id on the
sensor. Copy the id section from /etc/salt/minion to a new file under
/etc/salt/minion.d/, set the id in the new file, and then restart the
salt-minion service.

You may also need to (re)accept the minion key on the server side.

Also see:
https://code.google.com/p/security-onion/wiki/Salt

[Tim Desrochers]

I would like to revisit this post. The above information worked well when using SNORT as my IDS. Now that I am using SURICATA it will not process the $RULE_PATH variable because it does not seem to use the same variable syntax.

How can I include rules files in my /etc/nsm/rules folder and comment them in my local.rules file so they are copied to each of my sensors.

Thanks

[Doug Burks]

For Suricata, you may need to add your individual rules files to
suricata.yaml in the rules-files: section.

Or you could always just concatenate the individual rules files into
local.rules, which would require no changes to suricata.yaml.

[Tim Desrochers]

That is what I did and it works. I was just wondering if there was an easy way like with snort. Due to the way my org does watchlisting I do need to keep them separate, but I will look into attempting to script a way to cat them together and replace the the local rules file daily, shouldn't be to hard.