[Snort-sigs] Help on an ICMP rule: sid 486

Alex Kirk alex.kirk at ...435...
Wed Aug 25 14:04:01 EDT 2004


Seth,

Yes, actually, you're right...for a moment I had it in my head that your 
pass rule was just a duplicate of the alert rule, I'd forgot that you'd 
created variables like that. It's been a long day, pardon my stupidity.

As for the use of the -o flag, 99% of the time you're right, you'd want 
to use it if you have pass rules. I spoke to Matt Watchinski, who's got 
a lot more experience here than I do, and he says that he knows there's 
at least one perfectly valid use of alert -> pass -> log when you have 
pass rules, but that for the moment it's escaped him. So suffice it to 
say that unless you can think of a really good reason for it, you should 
just go with the -o flag. :-)

Alex Kirk
Research Analyst
Sourcefire, Inc.

>Well i still would like to see if this alert started
>firing off on something new (ie. anything except
>between my sensors and my vpn pool).  So this is a
>perfect case FOR a pass rule for me.  Correct?  
>
>Thanks for the -o insight.  Does this mean that anyone
>using pass rules should use the -o?  If not, could you
>explain to me a case where a pass rule would be useful
>in the default order of alert -> pass -> log?
>
>-Seth
>
>
>
>--- Alex Kirk <alex.kirk at ...435...> wrote:
>
>  
>
>>Seth,
>>
>>That's because of the way Snort configures its order
>>of alerting, and 
>>the fact that your alert rule is still in there. By
>>default, Snort 
>>processes alert rules, then pass rules, then log
>>rules; if you use the 
>>-o flag, they'll process as pass, alert, and then
>>log. Of course, it'd 
>>be equally easy to just comment out the offending
>>alert rule and not 
>>fiddle with a pass rule...it's up to you how you
>>want to do it.
>>
>>Alex Kirk
>>Research Analyst
>>Sourcefire, Inc.
>>
>>    
>>
>>>Thanks so much alex.  The host firewall on the
>>>sensors.  That makes perfect sence.  
>>>
>>>Now a question about my pass rule.  It doesnt seem
>>>      
>>>
>>to
>>    
>>
>>>be working.  This is my first attempt at a pass
>>>      
>>>
>>rule
>>    
>>
>>>and ive studied other pass rules that I have found
>>>      
>>>
>>in
>>    
>>
>>>the archives  but nothing is working.    
>>>
>>>In snort.conf i made to var's
>>>
>>>var SNORT_SENSORS [192.168.200.100,192.200.101]
>>>var VPN_POOL 192.168.216.0/24
>>>
>>>then added my pass rule to local.rules:
>>>
>>>pass icmp $SNORT_SENSORS any -> $VPN_POOL (msg:
>>>"Ignore ICMP dest. Admin. Prohib"; icode:10;
>>>      
>>>
>>itype:3;
>>    
>>
>>>sid:999901; rev:1;)
>>>
>>>I have tried it with any any -> any any, and also
>>>      
>>>
>>with
>>    
>>
>>>no sid or rev because i have seen some pass rules
>>>without them in the archives.  Snort always loads
>>>      
>>>
>>back
>>    
>>
>>>up after the restart but I still get the alerts. 
>>>      
>>>
>>What
>>    
>>
>>>am I missing.  
>>>
>>>Thanks again,
>>>Seth
>>>
>>>
>>>--- Alex Kirk <alex.kirk at ...435...> wrote:
>>>
>>> 
>>>
>>>      
>>>
>>>>Seth,
>>>>
>>>>You are correct in that your variables aren't
>>>>        
>>>>
>>really
>>    
>>
>>>>relevant to this 
>>>>alert.
>>>>
>>>>This alert's message is actually taken from the
>>>>actual error type/codes 
>>>>that go along with ICMP itself; I strongly suspect
>>>>that, if the wording 
>>>>isn't straight from the RFC itself, it's from page
>>>>71 of Steven's TCP/IP 
>>>>Illustrated Volume 1 (which is what I used to just
>>>>check myself with -- 
>>>>great book for anyone interested in networking).
>>>>        
>>>>
>>All
>>    
>>
>>>>it means is that 
>>>>there's some sort of policy/firewall/routing
>>>>setup/whatever on the 
>>>>subnet/IPs that the messages are dealing with that
>>>>blocks pings. 
>>>>Considering that it's your Snort sensor and your
>>>>        
>>>>
>>VPN
>>    
>>
>>>>pool interacting, 
>>>>my guess is that you've either got a tightly
>>>>configured firewall on your 
>>>>Snort box (which would of course make sense), or
>>>>that your VPN software 
>>>>is sending these messages back. They're nothing to
>>>>worry about, I'd 
>>>>definitely go with a pass rule.
>>>>
>>>>Alex Kirk
>>>>Research Analyst
>>>>Sourcefire, Inc.
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>>>Hello all.  Quick question.  I get a couple of
>>>>>thousand "ICMP Destination Unreachable
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>Communication
>>>>   
>>>>
>>>>        
>>>>
>>>>>with Destination Host is Administratively
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>Prohibited"
>>>>   
>>>>
>>>>        
>>>>
>>>>>alerts a day.  
>>>>>
>>>>>The source addr's are always the LAN cards on my
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>snort
>>>>   
>>>>
>>>>        
>>>>
>>>>>sensors and the destination addr's are only IPs
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>from
>>>>   
>>>>
>>>>        
>>>>
>>>>>our VPN pool.  
>>>>>
>>>>>Before I write a pass rule I was just wondering
>>>>>          
>>>>>
>>if
>>    
>>
>>>>>someone has any insight on why I am getting the
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>alerts
>>>>   
>>>>
>>>>        
>>>>
>>>>>and what they mean?   
>>>>>
>>>>>The rule is an any any ->  any any. icode:10;
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>itype:3;
>>>>   
>>>>
>>>>        
>>>>
>>>>>so i don't think it has to do with me fine tuning
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>the
>>>>   
>>>>
>>>>        
>>>>
>>>>>variables more ... right?
>>>>>
>>>>>It's only the one sensor that is monitoring the
>>>>>          
>>>>>
>>lan
>>    
>>
>>>>>side of the firewall that picks up the rules up
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>even
>>>>   
>>>>
>>>>        
>>>>
>>>>>tho the sources are coming from all thee linux
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>box's
>>>>   
>>>>
>>>>        
>>>>
>>>>>(snort database, DMZ sensor and LAN sensor.  
>>>>>
>>>>>
>>>>>Thanks,
>>>>>Seth 
>>>>>          
>>>>>




More information about the Snort-sigs mailing list