Snort mailing list archives

Previous By Date Next
Previous By Thread Next

Re: Tagged Packet

From: Jason Brvenik <jasonb () sourcefire com>
Date: Sun, 22 Jan 2006 21:51:41 -0500
Dirk Geschke wrote:


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 ;-)
 



Yes, and in that thread you say "oh, there are many options (I think you
have no rules with the tag keyword)"

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.

Your initial reply in the thread also jumps to this potentially
incorrect conclusion as evidenced by this statement.

"I guess you are running barnyard..."

I was not addressing the specific recommendations you made in the thread
and perhaps I should have. I was clarifying statements made later WRT to
tagged packets and stream and the initial question itself. I am sorry if
take offense at having clarity added to statements made in the course of
a conversation.

[..]


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


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.

Try this and fire up your favorite sniffer ( substitute en1 for the
appropriate interface )

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

EG:

01/22-14:47:23.238173 0:11:24:8E:FE:F8 -> 0:F:66:1A:C7:A4 type:0x800
len:0x4A
192.168.1.100:57354 -> 66.27.58.123:80 TCP TTL:64 TOS:0x0 ID:59394
IpLen:20 DgmLen:60 DF
******S* Seq: 0x437F4731  Ack: 0x0  Win: 0xFFFF  TcpLen: 40
TCP Options (6) => MSS: 160 NOP WS: 0 NOP NOP TS: 485693125 0

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

01/22-14:47:23.331818 0:F:66:1A:C7:A4 -> 0:11:24:8E:FE:F8 type:0x800
len:0x4A
66.27.58.123:80 -> 192.168.1.100:57354 TCP TTL:102 TOS:0x0 ID:22678
IpLen:20 DgmLen:60 DF
***A**S* Seq: 0x4F51F3D0  Ack: 0x437F4732  Win: 0x4060  TcpLen: 40
TCP Options (6) => MSS: 536 NOP WS: 0 NOP NOP TS: 0 0

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

01/22-14:47:23.331942 0:11:24:8E:FE:F8 -> 0:F:66:1A:C7:A4 type:0x800
len:0x42
192.168.1.100:57354 -> 66.27.58.123:80 TCP TTL:64 TOS:0x0 ID:59395
IpLen:20 DgmLen:52 DF
***A**** Seq: 0x437F4732  Ack: 0x4F51F3D1  Win: 0xFFFF  TcpLen: 32
TCP Options (3) => NOP NOP TS: 485693125 0

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

01/22-14:47:23.332228 0:11:24:8E:FE:F8 -> 0:F:66:1A:C7:A4 type:0x800
len:0xD6
192.168.1.100:57354 -> 66.27.58.123:80 TCP TTL:64 TOS:0x0 ID:59397
IpLen:20 DgmLen:200 DF
***A**** Seq: 0x437F4732  Ack: 0x4F51F3D1  Win: 0xFFFF  TcpLen: 32
TCP Options (3) => NOP NOP TS: 485693125 0
47 45 54 20 2F 65 6E 70 2F 72 66 63 2F 72 66 63  GET /enp/rfc/rfc
31 31 39 31 2E 74 78 74 20 48 54 54 50 2F 31 2E  1191.txt HTTP/1.
31 0D 0A 48 6F 73 74 3A 20 77 77 77 2E 6E 65 74  1..Host: www.net
77 6F 72 6B 73 6F 72 63 65 72 79 2E 63 6F 6D 0D  worksorcery.com.
0A 55 73 65 72 2D 41 67 65 6E 74 3A 20 4D 6F 7A  .User-Agent: Moz
69 6C 6C 61 2F 35 2E 30 20 28 4D 61 63 69 6E 74  illa/5.0 (Macint
6F 73 68 3B 20 55 3B 20 50 50 43 20 4D 61 63 20  osh; U; PPC Mac
4F 53 20 58 20 4D 61 63 68 2D 4F 3B 20 65 6E 2D  OS X Mach-O; en-
55 53 3B 20 72 76 3A 31 2E 38 29 20 47 65 63 6B  US; rv:1.8) Geck
6F 2F 32 30                                      o/20

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

01/22-14:47:23.332252 0:11:24:8E:FE:F8 -> 0:F:66:1A:C7:A4 type:0x800
len:0xD6
192.168.1.100:57354 -> 66.27.58.123:80 TCP TTL:64 TOS:0x0 ID:59398
IpLen:20 DgmLen:200 DF
***A**** Seq: 0x437F47C6  Ack: 0x4F51F3D1  Win: 0xFFFF  TcpLen: 32
TCP Options (3) => NOP NOP TS: 485693125 0
30 35 31 31 31 31 20 46 69 72 65 66 6F 78 2F 31  051111 Firefox/1
2E 35 0D 0A 41 63 63 65 70 74 3A 20 74 65 78 74  .5..Accept: text
2F 78 6D 6C 2C 61 70 70 6C 69 63 61 74 69 6F 6E  /xml,application
2F 78 6D 6C 2C 61 70 70 6C 69 63 61 74 69 6F 6E  /xml,application
2F 78 68 74 6D 6C 2B 78 6D 6C 2C 74 65 78 74 2F  /xhtml+xml,text/
68 74 6D 6C 3B 71 3D 30 2E 39 2C 74 65 78 74 2F  html;q=0.9,text/
70 6C 61 69 6E 3B 71 3D 30 2E 38 2C 69 6D 61 67  plain;q=0.8,imag
65 2F 70 6E 67 2C 2A 2F 2A 3B 71 3D 30 2E 35 0D  e/png,*/*;q=0.5.
0A 41 63 63 65 70 74 2D 4C 61 6E 67 75 61 67 65  .Accept-Language
3A 20 65 6E                                      : en

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

01/22-14:47:23.332264 0:11:24:8E:FE:F8 -> 0:F:66:1A:C7:A4 type:0x800
len:0xD6
192.168.1.100:57354 -> 66.27.58.123:80 TCP TTL:64 TOS:0x0 ID:59399
IpLen:20 DgmLen:200 DF
***A**** Seq: 0x437F485A  Ack: 0x4F51F3D1  Win: 0xFFFF  TcpLen: 32
TCP Options (3) => NOP NOP TS: 485693125 0
2D 75 73 2C 65 6E 3B 71 3D 30 2E 35 0D 0A 41 63  -us,en;q=0.5..Ac
63 65 70 74 2D 45 6E 63 6F 64 69 6E 67 3A 20 67  cept-Encoding: g
7A 69 70 2C 64 65 66 6C 61 74 65 0D 0A 41 63 63  zip,deflate..Acc
65 70 74 2D 43 68 61 72 73 65 74 3A 20 49 53 4F  ept-Charset: ISO
2D 38 38 35 39 2D 31 2C 75 74 66 2D 38 3B 71 3D  -8859-1,utf-8;q=
30 2E 37 2C 2A 3B 71 3D 30 2E 37 0D 0A 4B 65 65  0.7,*;q=0.7..Kee
70 2D 41 6C 69 76 65 3A 20 33 30 30 0D 0A 43 6F  p-Alive: 300..Co
6E 6E 65 63 74 69 6F 6E 3A 20 6B 65 65 70 2D 61  nnection: keep-a
6C 69 76 65 0D 0A 50 72 61 67 6D 61 3A 20 6E 6F  live..Pragma: no
2D 63 61 63                                      -cac

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

01/22-14:47:23.332276 0:11:24:8E:FE:F8 -> 0:F:66:1A:C7:A4 type:0x800
len:0x61
192.168.1.100:57354 -> 66.27.58.123:80 TCP TTL:64 TOS:0x0 ID:59400
IpLen:20 DgmLen:83 DF
***AP*** Seq: 0x437F48EE  Ack: 0x4F51F3D1  Win: 0xFFFF  TcpLen: 32
TCP Options (3) => NOP NOP TS: 485693125 0
68 65 0D 0A 43 61 63 68 65 2D 43 6F 6E 74 72 6F  he..Cache-Contro
6C 3A 20 6E 6F 2D 63 61 63 68 65 0D 0A 0D 0A     l: no-cache....

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

01/22-14:47:23.456537 0:F:66:1A:C7:A4 -> 0:11:24:8E:FE:F8 type:0x800
len:0x42
66.27.58.123:80 -> 192.168.1.100:57354 TCP TTL:102 TOS:0x0 ID:22679
IpLen:20 DgmLen:52 DF
***A**** Seq: 0x4F51F3D1  Ack: 0x437F485A  Win: 0x4060  TcpLen: 32
TCP Options (3) => NOP NOP TS: 3436067 485693125


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


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.


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.

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.


-------------------------------------------------------
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
Previous By Date Next
Previous By Thread Next

Current thread: