cancel
Showing results for 
Search instead for 
Did you mean: 
cancel

How to work with ’Variable Sets’ and why are they so important to SNORT?

2993
Views
10
Helpful
3
Comments
Contributor

When using the’ Variable Sets’ it important to understand how SNORT rules works. Cisco Firepower is using SNORT, and got a huge amount of SNORT rules in its database. SNORT is in general a heavy process in Firepower Threat Defense, so if we can free some recourses from the processes this would be great.

 

Below you see an example of a SNORT rule, it will create an alert when an ICMP event occurred from the $EXTERNAL_NET to $HOME_NET, with the message “ICMP test”. In this case I will be using the Variable Set called ‘VARSET-SITE-A’.

Our Variable Set is posted below:

I usually bind my Variable sets into Network-Groups, as this ease the use of the variable sets when adding a new subnet.

 

To make the SNORT Engine with the least load, we would need to make sure that the matching rule amount are as specific as possible. If we didn’t change the Variable Set, the default one would look like this below:

 

If using the default Variable Set:

 

alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:”ICMP TEST RULE”; sid:1000010; rev:1; classtype:icmp-event;)

 

Would match all traffic as we haven’t specified any $EXTERNAL_NET or $HOME_NET, now all rules will match both internal and external traffic. This would require more load from the SNORT Engine as the rule will match all traffic from both to external hosts and internal hosts.

DMZ and Internal subnets?

Some documentation also suggest that we make an Exclusion on our $EXTERNAL_NET with the Variable $HOME_NET, this should be done with caution on some Access Control Rules. If your IPS engine is routing traffic between two interfaces, a good example could be DMZ and INSIDE, and your DMZ Subnet is included in the $HOME_NET, IPS will not be inspecting traffic between DMZ and INSIDE correctly - which in general... it should. SNORT Rules that are written like then one below, would then So imho don’t include DMZ subnets into your $HOME_NET, below is a no-go:

 

 

My suggestion would be to create a different variable set to DMZ traffic, and use it on specific Access Control Rules like below.

 

We however need to keep in mind that when using "Intrusion Policy used before Access Control rule is determined" (Access Control Policy>Advanced) - You will have to create a Variable Set that include the DMZ in the $HOME_NET and use this here.

 

When the IPS Var-Sets is adjusted, next will be the Network Analysis Policy, where we can adjust what we exactly want to pre-proc and decode, this can be done with custom Network Analysis Rules on the traffic flow from DMZ to Inside. (Access Control Policy>Advanced)

 

Please like and share the post if you found it useful.

3 Comments
Cisco Employee
Please add a note about security posture and the effect on it when *_NET variables are more narrowly defined.

Thanks!

Cheers,
Sudhir
Beginner

Hi Nikolaj,

 

Thanks for useful post. Please elaborate what will happen to home_net traffic? shall it be totally exempted from IPS rule processing?

We are running FMC with default variable sets where nothing is defined under home_net or external_net. We need to exempt IPS rule processing between few subnets (DMZs). if we define these subnets under home_net, then what will happen? any traffic destined to these subnets shall got bypassed from IPS rule processing?

We just need few subnets bypassed from IPS rule processing to ease down ASA CPU

Contributor

@wzahoor123

 

The essens of this article is entirely that your DMZ subnet should not be contained in the $HOME_NET Variable - if you contain all subnets e.g RFC1918 IPS will not apply between 'Inside -> DMZ and DMZ - Inside'.

 

To secure best preformance i would suggest using a seperate varset for each DMZ interface.

Write me a PM to elaborate, or catch me on skype (ID: nikolajpabst)

 

/Nikolaj