[Snort-users] Load of source quench

agetchel at ...1525... agetchel at ...1525...
Thu Apr 5 22:02:29 EDT 2001


Hi Scott,
	I'm not implying that some TCP/IP stacks don't check for a valid IP
header, I'm saying that there is at least one implementation I know of which
doesn't pay attention to ICMP source quench notifications _at all_.  I
grabbed a network trace one evening where a number of ICMP source quench
messages were being sent to a proxy server from a web server which a client
was trying to transfer a large amount of data through (doing a POST).  The
source quenches sent by the web server simply weren't being honored by the
proxy server in question.  I think I still have the trace somewhere, and can
dig it out if you want to see it.  I didn't have any debugging software on
the proxy server itself, so I couldn't see what was going on behind the
scenes (whether the proxy server was simply ignoring the messages or trying
to throttle back but being somehow unable to do so), but there was no
decrease in data transfer rate what-so-ever and no errors in any log to
speak of.  Packet loss occurred at the web server.  I'd guess that the proxy
server checked to see if it had a valid IP header, but just didn't care what
the message inside was saying.  That's only a guess, but I can't be sure
without digging into it deeper which I didn't have the time or resources to
do at that point, or at this point since we are moving away from the proxy
server software I speak of.

<rant on>
	This, of course, is the same proxy server software where we were
seeing RST's not being honored.  I grabbed a number of traces where we had
two proxy servers and a client.  The client was pointing to one of the proxy
servers (proxy server A), which was pointing to another proxy (proxy server
B), which was pointing directly to the Internet.  When the client was
downloading a large file through both proxy servers from a web server on the
Internet, and clicked the 'Stop' button on the browser, a RST was sent to
the proxy server A, which in turn was sent to proxy server B.  Proxy server
B didn't honor the RST and kept sending data to proxy server A.  Proxy
server A sent a total of _five_ RST's before proxy server B finished sending
the data.  It's a matter of a one company's product not interoperating with
itself when used in a large environment.  I'm not going to name the company
or the product, but let's just say that it was a problem with a pIece of
wIdely uSed web server software which this vendors proxy server software
happened to plug into. ;-)
<rant off>

	Anywho, in terms of ICMP source quenches being used for nefarious
purposes, I suppose that an intruder could use a man-in-the-middle attack,
hijack a session, whatever, and start sending these notifications to the
target machine as a primitive DoS.  However, if someone goes through the
trouble of employing this type of impersonation, they are usually interested
in what is going on in-between these two boxes and not necessarily to
perform a DoS against one, or both, of them.  Regardless, FW admins should
block these at the firewall to keep any chance of this happening to a
minimum, in my not-so-humble opinion. =)

Thanks,
Abe

Abe L. Getchell - Security Engineer
Division of System Support Services
Kentucky Department of Education
Voice   502-564-2020x225
E-mail  agetchel at ...1525...
Web     http://www.kde.state.ky.us/



> -----Original Message-----
> From: Scott Johnson [mailto:sjohn at ...1493...]
> Sent: Thursday, April 05, 2001 5:03 PM
> To: Snort-users at lists.sourceforge.net
> Subject: Re: [Snort-users] Load of source quench
> 
> 
> Quoth agetchel at ...1525... on Thu, Apr 05, 2001 at 
> 11:32:30AM -0400:
> > Hi JB,
> > 	It's a good idea to block ICMP source quench packets at the
> > firewall, as they can be used as a somewhat effective DoS 
> attack (depending
> > on the OS of the machine being attacked and how it handles these
> > notifications).  Seeing that many of these alerts in such a 
> short amount of
> > time (all coming from one host going too one host?) would 
> definitely raise a
> > red flag.  However, we've seen a good amount these being 
> sent from remote
> > servers to our large proxy array for legitimate reasons (up 
> to about 35 per
> > minute).  Since the ICMP Source Quench notification is 
> basically a remote
> > system telling your system 'Slow down!  I can't process the 
> data as fast as
> > you're sending it!', blocking these might result in packet loss.
> > 
> 
> An ICMP source quench should be discarded by the OS unless there is a
> valid IP header included in the message. TCP does the 
> backoff, so IP has
> to know which stream to hand the ICMP message to, and TCP should be
> checking for valid sequence numbers. Now, in order for this to be an
> effective DOS, the attacker has to be able to provide this 
> information,
> which means he needs access to the traffic he plans on disrputing. So
> while source quench can be used for DoS, it can't be used thus by just
> anyone.
> 
> You said, Abe, that the effectiveness of such a DoS depends 
> on the OS and
> how it handles source quench messages. Are you implying that some
> implementations don't check the sequence numbers and act appropriately
> (like ignoring sequence numbers already acked, or those 
> invalid for the
> stream? Or that there may be some added logic in interpreting source
> quench at the TCP layer? At the IP layer, of course, there's 
> always ICMP
> bandwidth limiting...
> 
> -- 
>                                  Scott Johnson
>                           System/Network Administrator
>                                 Airlink Systems
> 
> _______________________________________________
> Snort-users mailing list
> Snort-users at lists.sourceforge.net
> Go to this URL to change user options or unsubscribe:
> http://lists.sourceforge.net/lists/listinfo/snort-users
> Snort-users list archive:
> http://www.geocrawler.com/redir-sf.php3?list=snort-users
> 




More information about the Snort-users mailing list