Snort mailing list archives
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
Current thread:
- Tagged Packet marco turr (Jan 21)
- Re: Tagged Packet Dirk Geschke (Jan 21)
- Re: Tagged Packet marco turr (Jan 21)
- Re: Tagged Packet Jason (Jan 21)
- Re: Tagged Packet Dirk Geschke (Jan 22)
- Re: Tagged Packet Joel Esler (Jan 22)
- Re: Tagged Packet Dirk Geschke (Jan 22)
- Re: Tagged Packet Jason Brvenik (Jan 22)
- Re: Tagged Packet Dirk Geschke (Jan 22)
- Re: Tagged Packet Jason Brvenik (Jan 22)
- Re: Tagged Packet Dirk Geschke (Jan 23)
- Re: Tagged Packet marco turr (Jan 21)
- Re: Tagged Packet Dirk Geschke (Jan 21)