RE: rules and the EXTERNAL_NET variable

["Schmehl, Paul L" <pauls () utdallas edu>]

________________________________

        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/