[Snort-users] Load of source quench

Scott Johnson sjohn at ...1493...
Thu Apr 5 17:02:48 EDT 2001

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

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

More information about the Snort-users mailing list