Snort not honoring ipvar EXTERNAL_NET value

[jyn...@gmail.com]

Hi,

I have the HOME_NET and EXTERNAL_NET variables set in /etc/nsm/SENSORNAME/snort.conf as follows:

ipvar HOME_NET [192.168.0.0/16,10.0.0.0/8,172.16.0.0/12]

ipvar EXTERNAL_NET !$HOME_NET

However, rules that should be firing only on inbound traffic from $EXTERNAL_NET are firing on traffic originating from addresses in the $HOME_NET range. Example:

alert tcp $EXTERNAL_NET any -> $HOME_NET 1433 (msg:"ET POLICY Suspicious inbound to MSSQL port 1433"; flow:to_server; flags:S; threshold: type limit, count 5, seconds 60, track by_src; reference:url,doc.emergingthreats.net/2010935; classtype:bad-unknown; sid:2010935; rev:2;)

I would expect this rule not to fire for traffic between internal hosts 172.19.1.1 and 172.19.2.2, but it still does.

At this point I am stumped. Is there any way to dump the variable values snort reads in at runtime to confirm the variables are set correctly? Or another method to troubleshoot?

Thanks,
N

[Matt Gregory]

Did you restart Snort after making changes to snort.conf?

sudo nsm_sensor_ps-restart --only-snort-alert

Matt

--
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/groups/opt_out.

[jyn...@gmail.com]

Hi Matt,

Yes, several times and also rebooted the server. I should also note this behavior is occurring on two separate installs of SO.

[Doug Burks]

Which interface are you using to view the Snort alerts (Snorby,
Squert, Sguil, or ELSA)?

Are you classifying/acknowledging alerts, or is it possible you're
looking at older alerts that occurred before you changed EXTERNAL_NET?

--
Doug Burks
http://securityonion.blogspot.com

[jyn...@gmail.com]

Hi Doug,

All of the above.. as well as querying the securityonion DB directly using mysql. These are definitely fresh events; I had purged the database a few times during the tuning process.

[Doug Burks]

How much traffic are you monitoring? Is it possible that barnyard2 is
still processing a large backlog of IDS alerts from before you changed
EXTERNAL_NET? When did you make the change?

[jyn...@gmail.com]

Actually changed the variables several weeks ago, after installing. So everything should be caught up by now.

[Doug Burks]

Are you sure that EXTERNAL_NET is only defined once?

What is the output of the following?
grep EXTERNAL_NET /etc/nsm/*/snort.conf

Have you made any other modifications to snort.conf, like including
another .conf file?

[jyn...@gmail.com]

Output of grep EXTERNAL_NET /etc/nsm/*/snort.conf:

ipvar EXTERNAL_NET !$HOME_NET

Looks like it's only defined once.

Haven't included any other conf files. Other than these two variables I don't believe I have made any other edits to snort.conf.

[Doug Burks]

Is this a standalone sensor, or do you have a dedicated master server
and dedicated sensor(s)?

Let's try this:
- Reboot the box in question.
- Log into Sguil, select all existing instances of "ET POLICY
Suspicious inbound to MSSQL port 1433" and press the F8 key to
classify them.
- Wait for a new instance of "ET POLICY Suspicious inbound to MSSQL
port 1433" to appear and click on it.
- Enable "Show Packet Data" and "Show Rule".
- Take a screenshot and attach it to your reply.

Also send the output of the following (redacting sensitive info as necessary):
sudo sostat

[jyn...@gmail.com]

Found it.. there is another sensor sending events to the main one (sensor + server). When I got to the step of selecting all MSSQL events I realized they were all coming from that second sensor. Sure enough, snort.conf on that sensor was still the default. Setting the variable there seems to have done the trick.

Thanks for the help. Security Onion is turning out to be a great tool.

N