Snort mailing list archives
RE: rules and the EXTERNAL_NET variable
From: "Schmehl, Paul L" <pauls () utdallas edu>
Date: Wed, 26 Nov 2003 16:57:10 -0600
________________________________ From: snort-users-admin () lists sourceforge net [mailto:snort-users-admin () lists sourceforge net] On Behalf Of adam_peterson () splwg com Sent: Wednesday, November 26, 2003 3:47 PM To: snort-users () lists sourceforge net Subject: [Snort-users] rules and the EXTERNAL_NET variable I've now defined the EXTERNAL_NET variable as !$HOME_NET, excluding my defined internal subnets. I have 2 sensors running to compare the results of also having the EXTERNAL_NET set to 'any' and found that, much to my dismay, the vast majority of rules specify EXTERNAL_NET as the source so even though I'm getting far less false-positives with the new/test sensor, I'm also going to potentially miss a virus-based attack on my LANs. It seems as though certain types of attacks, specifically any attack coming from a virus, should not specify the EXTERNAL_NET variable as the source because this means that the EXTERNAL_NET varilable MUST be defined as 'any' or viruses will be missed. What you are talking about is alerts as they apply to *your* network. Only *you* can decide what's appropriate for those. In my case, I chose to disable all worm-type alerts (Slammer, Welchia, Code Red, etc.) and write custom alerts that change the flow from EXT->HOME to HOME->EXT, because *I* don't care about worms that someone else has. I care about worms that we have. Others may think differently. if you're using EXTERNAL_NET to mean what, again IMHO, should mean? It's the same for Nimda except there isn't an outbound rule for Nimda so more could be missed. It seems it would make more sense this way but maybe my configuration is unique? Or maybe it's just Wednesday afternoon before a 4-day weekend... *I* think EXTERNAL_NET should mean "not on my network", so I chose to define it as !$HOME_NET. Others may disagree. Should I expect to customize my rules to this level of detail if I expect to seriously limit the amount of false-positives? I've always just disabled as many rules that cause false-positives as possible but now I'm running into rules that I can't in my right mind disable. Maybe I'm just reaching the next step in customization? I could really use a sanity check before going through every rule. Yes, I think what you're running in to is that stage where you have to start creating customized rules that provide the kind of information that *you* want to see. I think making EXTERNAL_NET = !$HOME_NET makes eminently good sense, but as you point out that makes some rules "blind" to internal problems. So, I chose to create special rules for those. In most cases I simply took an existing rule and swapped $EXTERNAL_NET and $HOME_NET *in that rule*, so that I would see internal problems going out of my network. I then commented out the "default" rule, because I don't care about, for example, someone who has Code Red that is "attacking" my network. Paul Schmehl (pauls () utdallas edu) Adjunct Information Security Officer The University of Texas at Dallas AVIEN Founding Member http://www.utdallas.edu/~pauls/
Current thread:
- rules and the EXTERNAL_NET variable adam_peterson (Nov 26)
- <Possible follow-ups>
- RE: rules and the EXTERNAL_NET variable Schmehl, Paul L (Nov 26)