[Snort-users] HOME_NET, EXTERNAL_NET, var negatation and unwanted triggered rules

Denis Sacchet mailinglist at ...13903...
Thu Aug 17 03:03:22 EDT 2006


In fact, it is not my final production configuration, it is only a test
configuration. My reporting tools (BASE) is flooded by SNMP rules
triggered from my monitoring server to all my internal servers. What I
try to do, is to limited the perimeter to external hosts to my network
(not in 10.0.0.0/8 network) which try to run SNMP to my internal host
(10.0.0.0/8 network). Moreover, I put bracket because in my original
configuration, I have several address, but it isn't working even with
only one bracket. Finally, in my message, it is not a dump of my
configuration, it is just a description of what I have done ("or"
between the two var declaration), I try both configuration, and both failed.

I'm sorry for the cut/paste from BASE, it was a very bad idea :) I just
wanted to show that despite of the "var EXTERNAL_NET !10.0.0.8" before
my rules inclusion, I still have alert from "10.0.0.0/8" address to
"10.0.0.0/8" address.

Don't know if it is clearer ?

Thanks for your answer, I will try your last proposal to see if it is
possible in my network topology.

Best regards

Denis Sacchet

Jeruvy wrote:
> Just some comments more than anything...
>
>   
>> -----Original Message-----
>> From: snort-users-bounces at lists.sourceforge.net
>> [mailto:snort-users-bounces at lists.sourceforge.net] On Behalf
>> Of Denis Sacchet
>> Sent: Wednesday, August 16, 2006 9:21 AM
>> To: snort-users at lists.sourceforge.net
>> Subject: [Snort-users] HOME_NET, EXTERNAL_NET,var negatation
>> and unwanted triggered rules
>>
>> Hi everybody,
>>
>> I try to setup a Snort installation onto my firewall, but in
>> a standard one, too much rules triggered, so I am trying to
>> reduce unwanted triggered rules to the minimum to only get
>> the serious security problems.
>>     
>
> This is generally a bad idea.  Snort and Firewalls do not co-exist well
> together.
>
> But there are also reasons for having snort 'inside' the firewall's
> perimeter and 'outside' the firewall...even on workstations and/or
> management stations.
>
>   
>> To do that, I enable only one rules set (snmp.rules) because
>> this rules set triggered a lot of time because of my
>> nagios/cacti monitoring servers using snmp v2, and try to set
>> up EXTERNAL_NET and HOME_NET to avoid logging of SNMP message
>> from local workstation to local workstation.
>>     
>
> ???
>
> I don't get this.  You enable ONLY SNMP rules, but then you try to avoid
> getting alerts to the rules.
>
> ???
>
>   
>> To do that, I set up as following :
>>
>> var EXTERNAL_NET [!10.0.0.0/8]
>> var HOME_NET [10.0.0.0/8]
>>     
>
> Off hand I cannot say I see a problem syntactically with this, I've always
> preferred the following logic when using or creating var's in snort:
>
> 1.  Never use brackets unless you have to.  Since you only have one address
> entry, they are not required.  If you had address lists ie:
> 10.1.0.0/16,10.2.0.0/16, etc. then you would need the brackets.
> 2.  Typically let external_net be the IP BLANKET (something that covers ALL
> IP ADDRESSES) if you will.  By setting to ANY I ensure I can report on any
> NON-HOME_NET alert will be logged correctly.  However I can see that yours
> works.  My confusion must be over what your trying to do above and how it
> relates to this logic.
>
>   
>> include $RULE_PATH/snmp.rules
>>
>> and also :
>>
>> var EXTERNAL_NET ![10.0.0.0/8]
>> var HOME_NET [10.0.0.0/8]
>>     
>
> Ok this also is correct and in your case means the same thing, but:
>
> 1.  Why are you redeclaring these variables again?
> 2.  Why are you 'now' using the NOT outside the brackets (and using brackets
> again)?
>
> Honestly I can't see a difference in the declaration above or here since you
> are not using IP lists.
>
>   
>> include $RULE_PATH/snmp.rules
>>
>> and comment all the preprocessor and all the other rules files.
>>     
>
> Some of the pre-processors serve important duties, and in some cases I could
> see where traffic is not normalized could be misinterpreted by snort or even
> missed.  Fragmentation is a big problem on most networks from a sniffer's
> perspective...not from the user or the network since he benefits from
> fragmentation.
>
>   
>> But I still got the following type of alert :
>>     
>
> [snip]
>
> Um, that was unreadable.
>
> Instead next time pull an ascii dump, save it as a text file, then paste it
> into an email.
> Don't try that within the browser unless you clean up all the links.
>
> OR,
>
> Save the PCAP file, and use snort from the command line to replay it then
> capture the text output and forward on email.
>
> OR,
>
> Have BASE display a plain text of the alert, and copy and paste that (may be
> a tiny bit of link clean up, but nothing like copying from the view alerts
> page.
>
>
>   
>> in my BASE frontend.
>>     
>
> We noticed ;)
>
>   
>> Could someone help to figure out how to configure my NET
>> variable to avoid such alert to be logged.
>>     
>
> I don't think I understand what you want.  And without reviewing the alert
> data it's hard to see what your seeing.
>
> So far, I think you want to only 'log' snmp.rules but 'alert' on nothing.
> Something tells me that's not correct.
>
> But...to assist in some manner, why not alert only SNMP rules, set
> EXTERNAL_NET to your network space ONLY and HOME_NET to your boxes you wish
> to actually review the alerts from.  That should eliminate alerts from any
> other space.  Sorry if that sounds off the wall, but it works.  For instance
> I have a few windows boxes that use NETBIOS, and I don't care to see all the
> alerts EXCEPT for boxes that do NOT have netbios.  Sometimes somebody uses
> samba and I want to know, otherwise the traffic would be alerting constantly
> and I'd spend hours deleting bogus alerts from machines that do this and
> possibly missing the alerts I do want to review.
>
> Good luck,
>
>
>
>
>   





More information about the Snort-users mailing list