Snort mailing list archives

RE: Snort Rules Help


From: "Cunningham, Andy" <acunningham () rsasecurity com>
Date: Thu, 15 Jul 2004 12:23:26 +0100

Tyler
 
Thank to you and the others who responded to my question.  I've been
doing a lot of experimentation (and learning!).
 
It turned out that to start with I didn't actually have frag2 compiled
into my version of snort (oops).   I've since rebuilt it, upgraded to
2.1.3 and also tried the 2.2.0RC1 versions and they all have the same
problem. 
 
I can simplify the rules down as follows:
 
pass udp $VPNCENTRAL any <> $VPN_EXTERNAL 500 (classtype: ignore;)
pass udp $VPNCENTRAL any <> $VPN_EXTERNAL 10000 (classtype: ignore;)
pass ip $VPNCENTRAL 50 <> $VPN_EXTERNAL 50 (classtype: ignore;)
 
alert udp any 10000 -> any any (msg: "Still getting port 10000;
classtype: unexpected-traffic; )
alert ip any any -> any any (msg: "Unexpected IP unclassified traffic";
classtype: unexpected-traffic; )
 
This is seems straightforwd:   if it's any variation of the IPsec tunnel
(either direct or encapsulated in UDP port 10,000 to allow NAT bypass),
consider it legit traffic, and ignore it from further analysis.  Of
course, in reality I want to do lots more alerting.... 
 
I'm still getting the final alert rule activating, though, on these two
packets:
 
12:41:21.765179 VPNCENTRAL > VPN_EXTERNAL : (frag 59477:60@1480)
12:41:21.781412 VPNCENTRAL.10000 > VPN_EXTERNAL.10000:  udp 1532 (frag
59477:1480@0+) 
 
I wish I could not worry about this, but this fragmentation is normal
for the network I'm looking at (and the fragments arriving out of order
also seems normal -- there are two load-balanced circuits to the
location of "VPNCENTRAL", and it seems to reliably get the small
fragment out ahead of the bigger one).
 
I can stop the alert on the first fragment (logically first, not first
to arrive) with this:
 
pass ip $VPNCENTRAL 10000 <> $VPN_EXTERNAL 10000 (ip_proto: 0x11)
 
But unless I ignore all fragoffset: >0 fragments between the hosts, I
can't stop the second fragment being seen as "bad".
 
So, since I don't want my pager to go off several thousand times a day,
I'd really like to fix this :-)
 
Any and all help greatly appreciated.  
 
 
Andy Cunningham
 
 
 
 



  _____  

        From: Hudak, Tyler [mailto:Tyler.Hudak () roadway com] 
        Sent: 09 July 2004 21:11
        To: 'snort-users () lists sourceforge net'
        Cc: Cunningham, Andy
        Subject: RE: Snort Rules Help
        
        

        Andy, 

          What is going on here is that Snort sees fragmented packets as
IP packets, not UDP packets.  Unless you have the frag2 preprocessor
turned on, Snort will see the fragments as IP packets.  Once you turn on
the frag2 preprocessor Snort will look at each individual fragment as IP
packets and the completed packet as its protocol, in this case UDP.  In
other words, with frag2 on Snort will essentially see the packet twice.

          If you set your alert rule as the following: 

        alert ip any any -> any any (msg: "Unexpected unclassified
traffic"; classtype: unexpected-traffic; fragoffset:0;) 

          then it will only alert on the initial fragment of the
packets, and no others.  I assume that you must have two rules to alert
then - the one above and the original one.  If that is the case, then
you will still get all of the individual fragments as they will alert on
your original rule.

          Can you send exactly what your new rules are? 

          To solve your immediate need, you could set up the following
two rules: 

          alert ip any any -> any any (msg: "Unexpected unclassified
traffic - initial fragment"; classtype: unexpected-traffic;
fragoffset:0;)

          alert ip any any -> any any (msg: "Unexpected unclassified
traffic"; classtype: unexpected-traffic; fragoffset:0; fragbits:!M;)

          The first rule will alert only on the initial fragment.  The
second rule will alert on any IP packet that does not have the more
fragbits flag set (meaning its part of a fragment train) and the
fragmentation offset is 0.  The caveat to the second rule is that if
someone sets the fragmentation offset on a non-fragmented packet you
will not log it, even it you had wanted to.

          May I make a suggestion though and leave it like it is?
Fragmentation on a network isn't necessarily normal and so you typically
want to see all the fragmentation that comes into your network.  It
could be a sign of someone trying to bypass your firewall/IDS.

        Tyler 


Current thread: