Defining $HOME_NET and $EXTERNAL_NET in a distributed setup

Nick Magallanes

unread,

Jun 27, 2019, 9:31:13 AM6/27/19

to security-onion

Hi all,
As I've worked through my distributed deployment, I've finally come to the place where I need to tune the ruleset. I need to be able to define the $HOME_NET and #EXTERNAL_NET variables properly, however, all of the docs I find reference the path /etc/nsm/"$SENSORNAME"/snort.conf (from the SO setup) on the sensors themselves, not from the master. I've also found a doc here (https://github.com/Security-Onion-Solutions/security-onion/wiki/ManagingAlerts)saying that I can create some variables at this path, which I would do on the master: /etc/nsm/rules/local.rules. So my question is whether or not I can create "new" $HOME_NET and $EXTERNAL_NET variables in /etc/nsm/rules/local.rules on the master and have that override the $HOME_NET and $EXTERNAL_NET settings on the sensors? Thanks for any info! Is there a better way to do this with a distributed setup?

Thanks,
Nick

Wes Lambert

unread,

Jun 27, 2019, 2:50:59 PM6/27/19

to securit...@googlegroups.com

Hi Nick,

You'll need to modify in each respective sensor configuration file. It's easier if you use a bond interface, so you only have to edit one file per box. The reasoning behind having different configs was that folks may have separate networks being monitored per interface on each box, with different home/external nets. You could also set it up to have different configs pushed through Salt if you wanted, having a template file pushed to the boxes, then edited and propagated based on sensor interface, etc.

Thanks,

Wes

--

https://twitter.com/therealwlambert

https://securityonion.net/

Nick Magallanes

unread,

Jun 28, 2019, 8:46:01 AM6/28/19

to security-onion

On Thursday, June 27, 2019 at 2:50:59 PM UTC-4, Wes wrote:
> Hi Nick,
>
>
> You'll need to modify in each respective sensor configuration file. It's easier if you use a bond interface, so you only have to edit one file per box. The reasoning behind having different configs was that folks may have separate networks being monitored per interface on each box, with different home/external nets. You could also set it up to have different configs pushed through Salt if you wanted, having a template file pushed to the boxes, then edited and propagated based on sensor interface, etc.
>
>
> Thanks,
> Wes
>
>
> On Thu, Jun 27, 2019 at 9:31 AM Nick Magallanes <nick...@gmail.com> wrote:
> Hi all,
>
> As I've worked through my distributed deployment, I've finally come to the place where I need to tune the ruleset. I need to be able to define the $HOME_NET and #EXTERNAL_NET variables properly, however, all of the docs I find reference the path /etc/nsm/"$SENSORNAME"/snort.conf (from the SO setup) on the sensors themselves, not from the master. I've also found a doc here (https://github.com/Security-Onion-Solutions/security-onion/wiki/ManagingAlerts)saying that I can create some variables at this path, which I would do on the master: /etc/nsm/rules/local.rules. So my question is whether or not I can create "new" $HOME_NET and $EXTERNAL_NET variables in /etc/nsm/rules/local.rules on the master and have that override the $HOME_NET and $EXTERNAL_NET settings on the sensors? Thanks for any info! Is there a better way to do this with a distributed setup?
>
>
>
> Thanks,
>
> Nick
>
>
>
> --
>
> Follow Security Onion on Twitter!
>
> https://twitter.com/securityonion
>
> ---
>
> 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 securit...@googlegroups.com.

>
> To post to this group, send email to securit...@googlegroups.com.
>
> Visit this group at https://groups.google.com/group/security-onion.
>
> To view this discussion on the web visit https://groups.google.com/d/msgid/security-onion/2d24d59b-d5cc-4f34-aa80-ce1fb6eee495%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
>
>
> https://twitter.com/therealwlambert
>
> https://securityonion.net/

Thanks so much for that explanation Wes. That helped a lot. Definitely understandable with the possibility of having different networks monitored and therefore needing different $HOME_NET and $EXTERNAL_NET variables. I'll try getting it set up through salt. Great suggestion with the bond interface! Thanks again!

Nick

Nick Magallanes

unread,

Jul 19, 2019, 9:30:42 AM7/19/19

to security-onion

One more question. We defined the variables $HOME_NET and $EXTERNAL_NET in snort.conf, but they don't seem to taking effect. Should they be defined in the local.rules instead?

Wes Lambert

unread,

Jul 19, 2019, 10:16:12 AM7/19/19

to securit...@googlegroups.com

Hi Nick,

Can you provide an example of how you have the variables set, and how they are not getting applied?

Have you made sure to put the changes into the correct snort.conf (within the correct sensor-interface directory), and have you restarted Snort?

You may need to explicitly stop the process, confirm it is stopped, then start it again.

Additionally, you may be receiving a backlog of alerts that is making you think your changes are not taking effect.

Thanks,

Wes

Nick Magallanes

unread,

Jul 19, 2019, 11:59:08 AM7/19/19

to security-onion

On Friday, July 19, 2019 at 10:16:12 AM UTC-4, Wes wrote:
> Hi Nick,
>
>
> Can you provide an example of how you have the variables set, and how they are not getting applied?
>
>
> Have you made sure to put the changes into the correct snort.conf (within the correct sensor-interface directory), and have you restarted Snort?
>
>
> You may need to explicitly stop the process, confirm it is stopped, then start it again.
>
>
> Additionally, you may be receiving a backlog of alerts that is making you think your changes are not taking effect.
>
>
> Thanks,
> Wes
>
>
> On Fri, Jul 19, 2019 at 9:30 AM Nick Magallanes <nick...@gmail.com> wrote:
> On Thursday, June 27, 2019 at 9:31:13 AM UTC-4, Nick Magallanes wrote:
>
> > Hi all,
>
> > As I've worked through my distributed deployment, I've finally come to the place where I need to tune the ruleset. I need to be able to define the $HOME_NET and #EXTERNAL_NET variables properly, however, all of the docs I find reference the path /etc/nsm/"$SENSORNAME"/snort.conf (from the SO setup) on the sensors themselves, not from the master. I've also found a doc here (https://github.com/Security-Onion-Solutions/security-onion/wiki/ManagingAlerts)saying that I can create some variables at this path, which I would do on the master: /etc/nsm/rules/local.rules. So my question is whether or not I can create "new" $HOME_NET and $EXTERNAL_NET variables in /etc/nsm/rules/local.rules on the master and have that override the $HOME_NET and $EXTERNAL_NET settings on the sensors? Thanks for any info! Is there a better way to do this with a distributed setup?
>
> >
>
> > Thanks,
>
> > Nick
>
>
>
> One more question. We defined the variables $HOME_NET and $EXTERNAL_NET in snort.conf, but they don't seem to taking effect. Should they be defined in the local.rules instead?
>
>
>
> --
>
> Follow Security Onion on Twitter!
>
> https://twitter.com/securityonion
>
> ---
>
> 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 securit...@googlegroups.com.

>
> To view this discussion on the web visit https://groups.google.com/d/msgid/security-onion/e99dd836-44b5-4997-9f5b-61568b2b97aa%40googlegroups.com.
>
>
>
>
> --
>
>
> https://twitter.com/therealwlambert
>
> https://securityonion.net/

Hi Wes,
Absolutely. Attached is an example of how the variables are applied in snort.conf in one of the interfaces. For the $EXTERNAL_NET variable, we originally tried doing ipvar EXTERNAL_NET !$HOME_NET, but that didn't work, so we tried what's in the screenshot.

An example of the variables not being applied correctly is the sig id 2101411 (GPL SNMP public access udp). It looks for $EXTERNAL_NET any -> $HOME_NET. We are consistently seeing internal IPs, which are specifically negated in the $EXTERNAL_NET variable, as a source. This is of course just an example, there are other signatures that behaving in the same fashion.

We've put the variables in the snort.conf files for each of the interfaces on one of our forward nodes. After applying it, we ran so-restart to restart all SO services. We've even had a reboot in between all this. It's been almost 2 weeks since we made the initial changes. Are we applying it to the correct file (snort.conf) based on the engine being used?

Thanks!
Nick

variables.PNG

Wes Lambert

unread,

Jul 19, 2019, 6:32:50 PM7/19/19

to securit...@googlegroups.com

To confirm, you are using Snort, correct? If not, the correct config file would be suricata.yaml.

Thanks,

Wes

Nick Magallanes

unread,

Jul 19, 2019, 6:57:18 PM7/19/19

to security-onion

> To view this discussion on the web visit https://groups.google.com/d/msgid/security-onion/c7b57271-5d74-470c-8e2f-368bd98518a4%40googlegroups.com.

Yep, confirmed. Although this is the case, we did try modifying the suricata yml file in the same way, just in case.

Thanks,
Nick

Wes Lambert

unread,

Jul 22, 2019, 7:50:52 AM7/22/19

to securit...@googlegroups.com

Hi Nick,

Would you be able to provide an example of a rule that is still triggered?

Thanks,

Wes

Nick Magallanes

unread,

Jul 22, 2019, 8:00:07 AM7/22/19

to security-onion

> To view this discussion on the web visit https://groups.google.com/d/msgid/security-onion/e12ed275-476b-47b0-b28c-44aa8c6fdc50%40googlegroups.com.
>
>
>
>
> --
>
>
> https://twitter.com/therealwlambert
>
> https://securityonion.net/

Absolutely, sig id 2101411 (GPL SNMP public access udp), which looks for $EXTERNAL_NET any -> $HOME_NET. This still triggers very consistently on internal to internal traffic (which is defined in $HOME_NET).

Thanks,
Nick

Wes Lambert

unread,

Jul 22, 2019, 8:56:53 AM7/22/19

to securit...@googlegroups.com

Hi Nick,

You may want to try checking the snortu-x.log in /var/log/nsm/sensor-interface/ for clues.

Otherwise, I would start with some simple tests with specific IPs and Scapy to see if alerts are still triggered after configuration and restarting of the services.

Thanks,

Wes

Justin Store

unread,

Jan 23, 2020, 3:10:45 PM1/23/20

to security-onion

How would someone go about pushing this with Salt? I'm in an environment where we are rolling out SO to 9 locations in the next few months, but I have a lot of custom suricata variables that I use to tune our IDS ruleset in modifysid.conf. In my case, the variables need to be the same for all sensors and I'd prefer not to have to login to each box and update suricata.yaml each time we add a new variable (which happens as often as about once per week).

Is it possible to put these all in local.rules and modify the per interface suricata.yaml files to include the variables in local.rules? And then push local.rules with salt?

Steven J

unread,

Jan 23, 2020, 8:27:24 PM1/23/20

to securit...@googlegroups.com

https://groups.google.com/forum/#!topic/security-onion/xncvoPKPDyg

Last question in the thread, Doug gives one option for downloading different rulesets to different sensors.

As well, you aren't restricted to accessing all minions in a single call.

E.g.
sudo salt '*' test.ping Yields either a response or unreachable for each minion.
sudo salt-key -L Yields a list of names for all reachable minions.

sudo salt '<minion-name>' test.ping Allows test.ping to be sent to just 1 minion, where <minion-name> is the result from salt-key -L

One idea, you could use the master script to call a separate script for the unique bits for each minion, separate scripts for specific groups of minions if required, and allow the master to manage all the bits that would be the same for all minions.

On your issue with setting EXTERNAL_NET, did you make the change in all instances of /etc/nsm/<interface>/snort.conf ?

In general, you will have at least 2 interfaces set up, 1 for sniffing and 1 for management. e.g. host-ens160 and host-ens192

I presumed it was best to update both .conf files to ensure the change was consistent, no matter which profile a service chose to work from.

Having said that, I suspect !$HOME_NET is a convenience, whereas setting the specific ranges to exclude could be advantageous and especially if you were monitoring a segregated network existing in the same private address space. :-)

Justin Store

unread,

Jan 24, 2020, 6:01:26 PM1/24/20

to security-onion

Yeah, I understand all of that. I'm not the original poster. This was just the closest thread I found for what I was trying to do. My problem is deploying the same customer suricata variables to all sensors (all suricata.yaml files) since my environment needs to have the same variables through for things like MAIL_SERVERS, DNS_SERVERS, VPN_SUBNETS, etc. I have a lot of IDS rules tuned to exclude certain systems and it's pain to update the suricata.yaml files by hand. I tried using include statements in the suricata.yaml file but couldn't get it to work so far, but haven't given up yet.

Steven J

unread,

Jan 25, 2020, 12:53:42 PM1/25/20

to securit...@googlegroups.com

It may be more meaningful to open your own thread, because your specific situation and needs may benefit from a more specific answer.
https://github.com/Security-Onion-Solutions/security-onion/wiki/Upgrade includes a link to using Soup and Salt for updating your Master and downstream nodes.

Scroll to Using Salt to Install Updates Across Your Entire Deployment to see where you would manage the items that may be unique between nodes, where each has a distinct minion.

Justin Store

unread,

Jan 25, 2020, 6:54:34 PM1/25/20

to security-onion

Yeah. I didn't realized piggybacking on threads is also discouraged.

Anyway, my issue was just the syntax of my yaml file. Once I fixed that I was able to include my custom NIDS variables by using the include: directive in the suricata.yaml file. I the put variables in a file in /etc/nsm/rules/ on the master so that file gets replicated to the sensors

Reply all

Reply to author

Forward