Snort mailing list archives
Re: Tagged Packet
From: Dirk Geschke <dirk () geschke-online de>
Date: Mon, 23 Jan 2006 10:02:07 +0100
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
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)