Getting PING bombed...

Chris A. Icide chris at nap.net
Mon Oct 20 12:36:47 UTC 1997


If I remember right, and I think I do, Cisco filtes will not reconstruct a
fragment if it's not addressed to the router (why would you want to do such
a thing, especially if the rest of the path is MTU limited?).  Because of
this lack of reconstruction, the router only stops the initial fragment,
and allows the rest to pass.  A while back we did some testing on this with
some folks from abs.net (they supplied the victim), and it was still a
problem in the 11.1.8 revision of code for the 7500 series.  

Here is a response I got from a Cisco technical type a while back:


By design, non-initial fragments are not filtered as the transport layer
(TCP/UDP) information is only available in the initial fragment and
ACLs can contain entries that filter based on this. Filtering the
initial fragment provides security as the receiving station will 
time out after not receiving the initial fragment and flush the 
rest. But, it is still prone to denial of service attacks...

There is a bug CSCdi84140 open presently that would try to give the
user the option whether to filter non-initial fragments of any access
list element.

Unfortunately a search on that bug ID reveals...

Sorry -- The defect you've requested 'CSCdi84140' - cannot be displayed.

This may be due to one or more of the following:

   1.The defect number does not exist 
   2.The defect does not have a customer-visible description available yet 
   3.The defect has been marked Cisco Confidential which is usually done
for security purposes or for entries that do not have customer impact 


At 12:26 PM 10/18/97 -0400, Jamie Rishaw wrote:
>access-list 123 deny icmp host 130.89.29.52 any echo
>access-list 123 permit ip any any
>interface HSSIx/x
> ip access-group 123 in
>
>..have your upstream do the same, out.
>
>Doug Davis wrote:
>> 
>> Hello all.
>> 
>> We are getting ping bombed by the site `donantonio.wb.utwente.nl`
>> the attack is coming thru our uunet connection and is consuming
>> about 20% of our DS3.  It is directed at one of our 28.8 dialup
>> ports.
>> 
>> Email to the listed site contact fails with "Resource unavailable"
>> 
>> Does anyone have a contact address for these folks? Even though we've
>> blocked them at the router, my customers would really like them to stop
>> now so we can have the rest of the DS3.
>> 
>> 23:30:52.396533 130.89.29.52 > 206.66.5.134: (frag 35152:576 at 1480)
>> 23:30:52.398484 130.89.29.52 > 206.66.5.134: icmp: echo request (frag
35153:1480 at 0+)
>> 23:30:52.399460 130.89.29.52 > 206.66.5.134: (frag 35153:576 at 1480)
>> 23:30:52.402386 130.89.29.52 > 206.66.5.134: icmp: echo request (frag
35154:1480 at 0+)
>> 23:30:52.404337 130.89.29.52 > 206.66.5.134: icmp: echo request (frag
35155:1480 at 0+)
>> 23:30:52.404337 130.89.29.52 > 206.66.5.134: (frag 35155:576 at 1480)
>> 23:30:52.408240 130.89.29.52 > 206.66.5.134: icmp: echo request (frag
35156:1480 at 0+)
>> 23:30:52.408240 130.89.29.52 > 206.66.5.134: (frag 35156:576 at 1480)
>> 23:30:52.411166 130.89.29.52 > 206.66.5.134: icmp: echo request (frag
35157:1480 at 0+)
>> 23:30:52.411166 130.89.29.52 > 206.66.5.134: (frag 35157:576 at 1480)
>> 23:30:52.413118 130.89.29.52 > 206.66.5.134: icmp: echo request (frag
35158:1480 at 0+)
>> 23:30:52.413118 130.89.29.52 > 206.66.5.134: (frag 35158:576 at 1480)
>> 23:30:52.415069 130.89.29.52 > 206.66.5.134: icmp: echo request (frag
35159:1480 at 0+)
>> 23:30:52.416044 130.89.29.52 > 206.66.5.134: (frag 35159:576 at 1480)
>> 23:30:52.418971 130.89.29.52 > 206.66.5.134: icmp: echo request (frag
35160:1480 at 0+)
>> 23:30:52.419946 130.89.29.52 > 206.66.5.134: (frag 35160:576 at 1480)
>> 23:30:52.420922 130.89.29.52 > 206.66.5.134: icmp: echo request (frag
35161:1480 at 0+)
>> 23:30:52.420922 130.89.29.52 > 206.66.5.134: (frag 35161:576 at 1480)
>> 23:30:52.425800 130.89.29.52 > 206.66.5.134: icmp: echo request (frag
35163:1480 at 0+)
>> 23:30:52.425800 130.89.29.52 > 206.66.5.134: (frag 35163:576 at 1480)
>> 23:30:52.428727 130.89.29.52 > 206.66.5.134: icmp: echo request (frag
35165:1480 at 0+)
>> 23:30:52.428727 130.89.29.52 > 206.66.5.134: (frag 35165:576 at 1480)
>> 23:30:52.431653 130.89.29.52 > 206.66.5.134: icmp: echo request (frag
35167:1480 at 0+)
>> 23:30:52.431653 130.89.29.52 > 206.66.5.134: (frag 35167:576 at 1480)
>> 23:30:52.434580 130.89.29.52 > 206.66.5.134: icmp: echo request (frag
35168:1480 at 0+)
>> 23:30:52.434580 130.89.29.52 > 206.66.5.134: (frag 35168:576 at 1480)
>> 23:30:52.436531 130.89.29.52 > 206.66.5.134: icmp: echo request (frag
35169:1480 at 0+)
>> 23:30:52.436531 130.89.29.52 > 206.66.5.134: (frag 35169:576 at 1480)
>> 23:30:52.439458 130.89.29.52 > 206.66.5.134: icmp: echo request (frag
35170:1480 at 0+)
>> 23:30:52.439458 130.89.29.52 > 206.66.5.134: (frag 35170:576 at 1480)
>> 23:30:52.445311 130.89.29.52 > 206.66.5.134: icmp: echo request (frag
35173:1480 at 0+)
>> 23:30:52.446287 130.89.29.52 > 206.66.5.134: (frag 35173:576 at 1480)
>> 23:30:52.449213 130.89.29.52 > 206.66.5.134: icmp: echo request (frag
35174:1480 at 0+)
>> 23:30:52.449213 130.89.29.52 > 206.66.5.134: (frag 35174:576 at 1480)
>> 23:30:52.451164 130.89.29.52 > 206.66.5.134: icmp: echo request (frag
35175:1480 at 0+)
>> 23:30:52.451164 130.89.29.52 > 206.66.5.134: (frag 35175:576 at 1480)
>> 23:30:52.453116 130.89.29.52 > 206.66.5.134: icmp: echo request (frag
35177:1480 at 0+)
>> 23:30:52.453116 130.89.29.52 > 206.66.5.134: (frag 35177:576 at 1480)
>> 23:30:52.456042 130.89.29.52 > 206.66.5.134: icmp: echo request (frag
35178:1480 at 0+)
>> 23:30:52.457993 130.89.29.52 > 206.66.5.134: icmp: echo request (frag
35179:1480 at 0+)
>> [...]
>> 
>> 
>
>
>-- 
>jamie g.k. rishaw  dal/efnet:gavroche  __    IAGnet/CICNet/netILLINOIS Netops
>DID:216.902.5455 FAX:216.623.3566      \/            800.637.4IAGx5455
>"No. I'm *not* going to walk a nun through a router config." -dan at nic.net
>               Forget regret, or life is yours to miss -- RENT
>
>
----------------------------------------------------------------------
Chris A. Icide                                     Nap.Net, L.L.C.
Sr. Engineer                                       5007 S. Howell Ave.
414-747-8747                                       Milwaukee, WI 53207
-
Notice: NVRAM invalid, possibly due to write erase.
Press RETURN to get started!
-
PGP Keys located at pgpkeys.mit.edu or http://nap.net/~chris/keys.html
----------------------------------------------------------------------



More information about the NANOG mailing list