[Snort-devel] Snort Detection (Stream4 and Flow)

Eric Lauzon eric.lauzon at ...1967...
Tue Feb 7 11:51:00 EST 2006


Ok tcpreplay will kind-of break everything ...
i was assuming tcpreplay in one of the reply.
 
use ./snort -z -r file.pcap. you should have better results.
 
if you need to have some kind of testbed and mabey the addresses in the pcap file does not match your
snort configuration , i suggest you change the snort configuration rather then relying on tcpreplay to rewrite packets for you.
 
 
-elz


________________________________

	From: Joel Ebrahimi [mailto:jebrahimi at ...2857...] 
	Sent: 7 février 2006 14:42
	To: Eric Lauzon
	Cc: snort-devel at lists.sourceforge.net
	Subject: RE: [Snort-devel] Snort Detection (Stream4 and Flow)
	
	
	Im actaully replaying the pcap file on the network , Snort does not read in the pcap file.
	 
	But why would states not exist when reading in the file? Its still a full packet being analyed.
	 
	If this is the case than I could easily make a Snort dos tool and just replay mangled pcaps on the network. 
	 
	// Joel
	
	
________________________________

	From: Eric Lauzon [mailto:eric.lauzon at ...1967...] 
	Sent: Tuesday, February 07, 2006 11:35 AM
	To: Joel Ebrahimi
	Subject: RE: [Snort-devel] Snort Detection (Stream4 and Flow)
	
	
	thats normal
	because when reading pcap files , states does not exist. ;)
	 
	try on the wire.
	 
	-elz
	 


________________________________

		From: Joel Ebrahimi [mailto:jebrahimi at ...2857...] 
		Sent: 7 février 2006 14:35
		To: Eric Lauzon
		Cc: snort-devel at lists.sourceforge.net
		Subject: RE: [Snort-devel] Snort Detection (Stream4 and Flow)
		
		
		Ok well then here is the other thing I am seeing. If I remove enforce_state and use only the -z (or config stateful), I am trigger on a pcap where I removed the syn and syn ack out of the 3 way handshake. When enforce_state is in there it does not trigger.
		 
		 

________________________________

		From: Eric Lauzon [mailto:eric.lauzon at ...1967...] 
		Sent: Tuesday, February 07, 2006 11:17 AM
		To: Joel Ebrahimi
		Subject: RE: [Snort-devel] Snort Detection (Stream4 and Flow)
		
		
		Sure will . dont worry about depricated options as of now it still work well and has been since 2.0.
		 
		But be sure that all your other settings are good two.
		 
		Getting the sensor up is one thing , getting what you expect is an other one.
		 
		-elz
		 


________________________________

			From: Joel Ebrahimi [mailto:jebrahimi at ...2857...] 
			Sent: 7 février 2006 14:17
			To: Eric Lauzon
			Subject: RE: [Snort-devel] Snort Detection (Stream4 and Flow)
			
			
			Well since the -z option is about to become depriciated I use config stateful. 
			 
			So would this change anything though with the below scenario? Meaning will this prevent stick/snot attacks and allow me to still trigger on stateless scan rules?
			 
			// Joel
			 
			
			Joel Ebrahimi
			jebrahimi at ...2857...
			 
			 

________________________________

			From: Eric Lauzon [mailto:eric.lauzon at ...1967...] 
			Sent: Tuesday, February 07, 2006 11:09 AM
			To: Joel Ebrahimi
			Cc: snort-devel at lists.sourceforge.net
			Subject: RE: [Snort-devel] Snort Detection (Stream4 and Flow)
			
			
			Actualy if you want to be full stream4 compatible
			 
			where_ever_path/snort -z ...... 
			 
			should get you on track
			 
			-elz
			 
			 
			
			

________________________________

				From: snort-devel-admin at lists.sourceforge.net [mailto:snort-devel-admin at lists.sourceforge.net] On Behalf Of Joel Ebrahimi
				Sent: 7 février 2006 14:04
				To: snort-devel at lists.sourceforge.net
				Subject: [Snort-devel] Snort Detection (Stream4 and Flow)
				
				
				Hi,
				 
				I've been trying to research some of the stream4 preprocessor and rule options. Basically I  noticed a number of scan rules were not triggering and I looked into it further. For example here is a simplified NULL scan rule  :
				 
				alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"SCAN NULL no seq"; flow:stateless; ack:0; flags:0; reference:arachnids,4; classtype:attempted-recon; )
				 
				This was not triggering when I was running 'nmap -sN' , even though I could see on the wire it should be. I then removed the enforce_state from the stream4 preprocessor and the rule fired off just like it should. Now my part of my confusion comes from the current docs. Here is what is said about flow: stateless
				 
				'stateless	 Trigger regardless of the state of the stream processor (useful for packets that are designed to cause machines to crash)'
				 
				So to me it would seem that even if enforce_state is set in stream4 these rules should trigger. If that is not the case what is the point of even adding flow: stateless to a rule?
				 
				I traced what was happening through the code (I am not a Snort detection expert so forgive any misconceptions I have). So in the Preprocess function do_detect will be set in this loop to 0 in this case
				 
				while(idx != NULL)
				 {
				         assert(idx->func != NULL);
				         idx->func(p, idx->context);
				         idx = idx->next;
				 }
				 
				when it is evaluating the stream4 preprocessor settings and goes into ReassembleStream4 function in spp_stream4.c . In ReassembleStream4 (around line 2100), this would be what is setting do_detect to 0 here 
				 
				 if(!InlineMode())
				 {
				             if((p->tcph->th_flags & (TH_SYN|TH_RST)) != TH_SYN)
				             {
				                 do_detect = 0;
				                 p->preprocessors = 0;
				 
				                 return;
				             }
				}
				 
				So really what this means is every single TCP rule will need to have flow with it in order to enforce state and prevent stick/snot attacks and to also be able to detect stateless scan attacks at the same time . Which seems to go against what the original design of stream4 was about, explained here: http://www.snort.org/docs/faq.html#3.14
				 
				Like I said I'm no detection expert, but I was also curious if do_detect that can be set to 0 depending on criteria in the loop from the Preprocess function above, can then be set back to 1. If not it would seem like you could gain some valuable cpu cycles by changing
				 
				while(idx != NULL)
				 
				to 
				 
				while(idx != NULL && do_detect != 0)
				 
				 
				 
				 
				Thanks,
				 
				// Joel
				 
				Joel Ebrahimi
				jebrahimi at ...2857...


				--
				No virus found in this outgoing message.
				Checked by AVG Free Edition.
				Version: 7.1.375 / Virus Database: 267.15.2/252 - Release Date: 2/6/2006
				

			AVERTISSEMENT CONCERNANT LA CONFIDENTIALITÉ 
			
			Le présent message est à l'usage exclusif du ou des destinataires mentionnés ci-dessus. Son contenu est confidentiel et peut être assujetti au secret professionnel. Si vous avez reçu le présent message par erreur, veuillez nous en aviser immédiatement et le détruire en vous abstenant d'en faire une copie, d'en divulguer le contenu ou d'y donner suite.
			
			CONFIDENTIALITY NOTICE
			
			This communication is intended for the exclusive use of the addressee identified above. Its content is confidential and may contain privileged information. If you have received this communication by error, please notify the sender and delete the message without copying or disclosing it.
			
			


			--
			No virus found in this incoming message.
			Checked by AVG Free Edition.
			Version: 7.1.375 / Virus Database: 267.15.2/252 - Release Date: 2/6/2006
			


			--
			No virus found in this outgoing message.
			Checked by AVG Free Edition.
			Version: 7.1.375 / Virus Database: 267.15.2/252 - Release Date: 2/6/2006
			

		AVERTISSEMENT CONCERNANT LA CONFIDENTIALITÉ 
		
		Le présent message est à l'usage exclusif du ou des destinataires mentionnés ci-dessus. Son contenu est confidentiel et peut être assujetti au secret professionnel. Si vous avez reçu le présent message par erreur, veuillez nous en aviser immédiatement et le détruire en vous abstenant d'en faire une copie, d'en divulguer le contenu ou d'y donner suite.
		
		CONFIDENTIALITY NOTICE
		
		This communication is intended for the exclusive use of the addressee identified above. Its content is confidential and may contain privileged information. If you have received this communication by error, please notify the sender and delete the message without copying or disclosing it.
		
		


		--
		No virus found in this incoming message.
		Checked by AVG Free Edition.
		Version: 7.1.375 / Virus Database: 267.15.2/252 - Release Date: 2/6/2006
		


		--
		No virus found in this outgoing message.
		Checked by AVG Free Edition.
		Version: 7.1.375 / Virus Database: 267.15.2/252 - Release Date: 2/6/2006
		

	AVERTISSEMENT CONCERNANT LA CONFIDENTIALITÉ 
	
	Le présent message est à l'usage exclusif du ou des destinataires mentionnés ci-dessus. Son contenu est confidentiel et peut être assujetti au secret professionnel. Si vous avez reçu le présent message par erreur, veuillez nous en aviser immédiatement et le détruire en vous abstenant d'en faire une copie, d'en divulguer le contenu ou d'y donner suite.
	
	CONFIDENTIALITY NOTICE
	
	This communication is intended for the exclusive use of the addressee identified above. Its content is confidential and may contain privileged information. If you have received this communication by error, please notify the sender and delete the message without copying or disclosing it.
	
	


	--
	No virus found in this incoming message.
	Checked by AVG Free Edition.
	Version: 7.1.375 / Virus Database: 267.15.2/252 - Release Date: 2/6/2006
	


	--
	No virus found in this outgoing message.
	Checked by AVG Free Edition.
	Version: 7.1.375 / Virus Database: 267.15.2/252 - Release Date: 2/6/2006
AVERTISSEMENT CONCERNANT LA CONFIDENTIALITÉ 

Le présent message est à l'usage exclusif du ou des destinataires mentionnés ci-dessus. Son contenu est confidentiel et peut être assujetti au secret professionnel. Si vous avez reçu le présent message par erreur, veuillez nous en aviser immédiatement et le détruire en vous abstenant d'en faire une copie, d'en divulguer le contenu ou d'y donner suite.

CONFIDENTIALITY NOTICE

This communication is intended for the exclusive use of the addressee identified above. Its content is confidential and may contain privileged information. If you have received this communication by error, please notify the sender and delete the message without copying or disclosing it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20060207/f94bc1c8/attachment.html>


More information about the Snort-devel mailing list