Re: Tagged Packet

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

Hi Jason,

> > > The recommendation to disable stream4 is very bad :)
> >
> >
> > jipp, this is really a bad solution. But this will definitively
> > remove the tagged packets...
>
> Not necessarily. Tag is also a rule keyword option and can still produce
> tagged packets. There are currently two rules that ship by default in
> the VRT set that use tag. 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.

I am aware of this keyword. But if you would have read the whole
thread than it would be clear that this was not causing the tagged
packets ;-)

> > > Stream4 is not in charge of fragmentation, frag3 is.  Stream4 does  
> > > tcp conversation reconstruction.  If you disable Stream4 you will  
> > > render ALOT of rules totally null and void.
> >
> >
> > You can fragment IP packets on Layer 3, this is reassembled by frag3.
> > But you can also fragment on Layer 4, this is reassembled by stream4
> > by recreating the full session.
>
> What you say is materially correct but it is not fragmentation.
> Interchanging the terms tends to confuse people. What is really
> happening is TCP segmentation and it naturally occurs in certain
> situations. Most major operating systems and network cards support
> offloading of the handling of TCP segmentation.

Ok, I will quote "dict":

  fragmentation
    
         1. <networking> {segmentation}.
           
The idea was to use this term to show the similarity to IP 
fragmentation because this is what seems to be more intuitive
to understand. Segmentation may be the better technical word
but I think this will be more irritating...
> Disabling tagged packets would make analysis useless in most cases where
> those tagged packets appear. You will not have enough data to
> effectively determine the type and scope of an attack.

Yes, but the question was how to disable tagged packets. And 
disabling stream4 is one - although bad - solution. If you 
would have read the whole thread...

> > Think of telnet, is is not unlikely that every byte is sent by an
> > individual packet. (Before people ask, the "normal" telnet client
> > uses line buffering only on ports unequal to 23.)
>
> This is not really segmentation in that the client is sending data one
> byte at a time by design and not because the payload would exceed the
> MSS. In classic segmentation the client sends data, the stack decides if
> it will pass through unmolested using MSS, and then splits the amount of
> data into chunks of an appropriate size. One can segment all TCP into
> 200 byte chunks simply by setting an MTU of 200 for the interface
> involved. It is important to not confuse MTU and MSS though. MTU is for
> the local link layer segment and MSS is between the endpoints for all
> networks a packet traverses. UDP does not have MSS so it is often
> fragmented at the IP layer by intermediary devices.

Come on, this was an example how you could be blind due to splitting
the payload over several packets. If the application splits it in 
several parts or the kernel decides to split is was not the question.

Usually all data for an action are part of one packeet, think of
http, or are in line mode like smtp. In this cases you will see
the whole request in one packet not in several ones. But with
telnet it is done byte per byte. And again, this was simply to
demonstrate that stream4 is important for this case.

It is not uncommon to split an attack over several packets, this
can be done on layer 3 aka IP or with TCP on layer 4. Ok, you 
can call this segmentation but this is even not the correct 
behaviour.

(Although, I even would not call this segmentation at all if
you think on telnet. The packets are far beyond the MSS and
several packets would build the real content for a request.
That is the reason why the linemode was introduced to save
the overhead of sending each byte individually instead of
using the overhead of IP/TCP for each byte.)

BTW: An MTU of 200 is impossible if you want to use IP, the minimum
is 576 bytes...

> > To call this fragmentation or to reserve this to IP packets which 
> > got fragmented is another question...
>
> Fragmentation only deals with IP packets and can encapsulate any higher
> level protocol. Segmentation deals with TCP packets and the ability to
> split a normally larger request into smaller TCP segments to obtain
> maximum MSS efficiency. All of these things can be abused in security so
> disabling frag or stream handling would be far less than ideal.

Hey, this was not the matter of this mail thread. The question was
how to disable tagged packets in alerts. And, yes, read the thread,
disabling stream4 was only one option labled as a bad idea...

If you already think you have to jump in then why are you not
explaining why this packets were stored as tagged ones?

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.

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...

> A decent overview of this process is available here
>
> http://www.citap.com/documents/tcp-ip/tcpip012.htm
>
> please excuse all just woke up and have had no coffee moments in the
> reading of this mail.

Ok, then drink a further cup and read the whole thread ;-)

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