Limit what Snort listens to
-
So I'm having to L3 route on my switch two of my VLANs which means that snort will no longer have these as separate interfaces in pfSense. The two VLANs correspond to what is my "trusted" network and my "DMZ" network. Before I went this route I'd have more strict snort rules on the DMZ and more casual rules like just malware on the "trusted" VLAN. Now that pfSense doesn't have them broken apart it will see both sets of traffic coming in on the transit VLAN I am setting up. Is there a way I can split the rules by subnet, or put my DMZ rules on that transit interface, but restrict the rules to only browse that subnet, not the trusted?
-
Short answer is "No". If you want different rules sets per interface, then you need separate interfaces for Snort to run on.
-
I figured you couldn’t break up the rules but is there a way to limit what it’s applied to based on subnet and have the other packets go through unfiltered? I know snort operates via copied packets so it’d still see them but if I can stop one subnet from being scanned that’d be better than nothing. Thanks!
-
@realityman_ said in Limit what Snort listens to:
I figured you couldn’t break up the rules but is there a way to limit what it’s applied to based on subnet and have the other packets go through unfiltered? I know snort operates via copied packets so it’d still see them but if I can stop one subnet from being scanned that’d be better than nothing. Thanks!
Well, not easily. You could in essence write your own custom rules and use multiple different $HOME_NET variables within them, but that would break and have to be redone with every rules update (at least twice per week with Snort Subscriber Rules). Many of the rules (but not all) use the variable $HOME_NET to contain the IP addresses that are being protected (and thus the IPs that are being used in the rule logic). If you had multiple $HOME_NET variables (each with a different name, of course, like maybe $HOME_NET1, $HOME_NET2, etc.), you could in theory limit when certain rules triggered by customizing $HOME_NET in the rule.
But that is not really a workable situation. Why did you have to move your routing to a switch? Couldn't you re-architect your network so that the firewall can route? That's really the only way to put Snort back into the mix.
-
I'll probably just run anti-malware then and front everything in the DMZ with a WAF. I already have it behind NGINX and cloudflare. Thanks for the help!