Re: Tagged Packet

[Dirk Geschke <dirk () geschke-online de>]

Hi Jason,

[...]
> Certainly that would not have been taken into consideration nor been a
> reason for stating there are default rules with tag since I did not read
> the thread. Disabling stream4 would have had the side effect of ensuring
> that the rules currently using tag never alerted because they also use
> flow:established.

that is not correct. If you disable stream4 than the flow-keyword 
is simply ignored. So you may get much more alerts, snort is then
open to attacks like with stick, snot or fpg. Sometimes this is a
nice behaviour to stress test snort and the output plugins...

[...]

> > BTW: An MTU of 200 is impossible if you want to use IP, the minimum
> > is 576 bytes...
> >  
> IPV4 systems are supposed to handle a minimum of 576 bytes without
> fragmentation. This does not prevent a host from choosing a much smaller
> MTU. It should prevent a host from using an MTU of greater than 576 when
> no other MTU is known.

Damn, you are right. I still had in mine that the minimum MTU has to
be 576 bytes without ever reading the rfc.

But RFC 791 states:

    Every internet destination must be able to receive a datagram of 
    576 octets either in one piece or in fragments to be reassembled.

So there are a lot of documents out there in the internet which 
are not correct in this point.

> $ sudo ifconfig en1 mtu 200
> $ ifconfig en1
> en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 200
>         inet 192.168.1.100 netmask 0xffffff00 broadcast 192.168.1.255
>         ether 00:11:24:8e:fe:f8
>         media: autoselect status: active
>         supported media: autoselect
>
> $ wget http://www.networksorcery.com/enp/rfc/rfc1191.txt
>
> You will notice that no IP packet is larger than 200 bytes and there is
> no IP fragmentation happening.

Yes, but this is tcp, here will the MSS work. With UDP you would get 
fragments but this will not matter as the 576 bytes may be fragemented
as RFC 791 states...

> "The use of tag is so that you can identify what kind of attack was
> launched since the exploit packets follow the triggering conditions and
> there would be no way to know what exploit was launched without the
> following packets." This applies equally to stream generated tagged
> packets and in rules. A pseudo packet may provide an acceptable
> representation but can also be inadequate to determine the true nature
> of an attack.

Ok, this is more regarding the "tag" keyword. Regarding the stream
see below.

> > The old unified output plugin stored the reassembled (or resegmentated?)
> > packet. Since the individual IP flags are not stored within stream4
> > this results in packets which may be different as the original ones.
> >
> > And yes, the complete stream would have the same misses but you would
> > see the parts which caused the alerts. Now you have to figure out 
> > which packets belong together to be able to locate the alerting
> > parts.
> >  
> The major case for stream generated tagged packets VS using a pseudo
> packet is that with the pseudo packet you cannot inspect all headers,
> overlaps, gaps, payloads... as they appear in native form and with the
> tagged packets you can.

Ah, that was the missing part. Sorry, but is this really the case?
I did not find any hint to this point in the documentation and the
source code of stream4 is not easy to read/understand.

If you would get the original TCP and IP header with every packet
then it really makes sense. But then this should be documented...

Although, I think if there is anything in any header that would
trigger an alert would it not be done either way? Or are there 
any keywords which I miss where I can state to filter only on
maybe the second or third IP or TCP header?

> > So why is this done? And why this way? It is a minium of effort to
> > add an option key to let the user decide which variant they prefer...
> >  
> I personally would like to see all pseudo packet logging removed and
> have all of the output methods only ever log the member packets with an
> event.

Yes, but maybe there are people out there which prefer the other 
behaviour? Some people may like to see the offending parts in one
packet instead of gathering first all tagged packets. The first
packet carries the alert information, but then you do not know if
there already exist tagged packets which would belong to this alert.

And yes, you are right if you would say that ACID/Base should be
extended to count for this. But actually they do not.

It would be nice if e.g. Base would say that alert no. x consists
of several packets which are all available. This is a general problem
of ACID/Base even with the tag keyword in the rule.
> Is dirk at lug-erding.de the same as dirk at geschke-online.de?
> Apologies for the three copies of the mail if they are.

Yes, it's the same address. Interestingly, this address should not
have appeared as this is not a subscribed one. I should rethink my
usage of the generics file in sendmail....

Best regards

Dirk


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users