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@1480) 23:30:52.398484 130.89.29.52 > 206.66.5.134: icmp: echo request (frag
35153:1480@0+)
23:30:52.399460 130.89.29.52 > 206.66.5.134: (frag 35153:576@1480) 23:30:52.402386 130.89.29.52 > 206.66.5.134: icmp: echo request (frag 35154:1480@0+) 23:30:52.404337 130.89.29.52 > 206.66.5.134: icmp: echo request (frag 35155:1480@0+) 23:30:52.404337 130.89.29.52 > 206.66.5.134: (frag 35155:576@1480) 23:30:52.408240 130.89.29.52 > 206.66.5.134: icmp: echo request (frag 35156:1480@0+) 23:30:52.408240 130.89.29.52 > 206.66.5.134: (frag 35156:576@1480) 23:30:52.411166 130.89.29.52 > 206.66.5.134: icmp: echo request (frag 35157:1480@0+) 23:30:52.411166 130.89.29.52 > 206.66.5.134: (frag 35157:576@1480) 23:30:52.413118 130.89.29.52 > 206.66.5.134: icmp: echo request (frag 35158:1480@0+) 23:30:52.413118 130.89.29.52 > 206.66.5.134: (frag 35158:576@1480) 23:30:52.415069 130.89.29.52 > 206.66.5.134: icmp: echo request (frag 35159:1480@0+) 23:30:52.416044 130.89.29.52 > 206.66.5.134: (frag 35159:576@1480) 23:30:52.418971 130.89.29.52 > 206.66.5.134: icmp: echo request (frag 35160:1480@0+) 23:30:52.419946 130.89.29.52 > 206.66.5.134: (frag 35160:576@1480) 23:30:52.420922 130.89.29.52 > 206.66.5.134: icmp: echo request (frag 35161:1480@0+) 23:30:52.420922 130.89.29.52 > 206.66.5.134: (frag 35161:576@1480) 23:30:52.425800 130.89.29.52 > 206.66.5.134: icmp: echo request (frag 35163:1480@0+) 23:30:52.425800 130.89.29.52 > 206.66.5.134: (frag 35163:576@1480) 23:30:52.428727 130.89.29.52 > 206.66.5.134: icmp: echo request (frag 35165:1480@0+) 23:30:52.428727 130.89.29.52 > 206.66.5.134: (frag 35165:576@1480) 23:30:52.431653 130.89.29.52 > 206.66.5.134: icmp: echo request (frag 35167:1480@0+) 23:30:52.431653 130.89.29.52 > 206.66.5.134: (frag 35167:576@1480) 23:30:52.434580 130.89.29.52 > 206.66.5.134: icmp: echo request (frag 35168:1480@0+) 23:30:52.434580 130.89.29.52 > 206.66.5.134: (frag 35168:576@1480) 23:30:52.436531 130.89.29.52 > 206.66.5.134: icmp: echo request (frag 35169:1480@0+) 23:30:52.436531 130.89.29.52 > 206.66.5.134: (frag 35169:576@1480) 23:30:52.439458 130.89.29.52 > 206.66.5.134: icmp: echo request (frag 35170:1480@0+) 23:30:52.439458 130.89.29.52 > 206.66.5.134: (frag 35170:576@1480) 23:30:52.445311 130.89.29.52 > 206.66.5.134: icmp: echo request (frag 35173:1480@0+) 23:30:52.446287 130.89.29.52 > 206.66.5.134: (frag 35173:576@1480) 23:30:52.449213 130.89.29.52 > 206.66.5.134: icmp: echo request (frag 35174:1480@0+) 23:30:52.449213 130.89.29.52 > 206.66.5.134: (frag 35174:576@1480) 23:30:52.451164 130.89.29.52 > 206.66.5.134: icmp: echo request (frag 35175:1480@0+) 23:30:52.451164 130.89.29.52 > 206.66.5.134: (frag 35175:576@1480) 23:30:52.453116 130.89.29.52 > 206.66.5.134: icmp: echo request (frag 35177:1480@0+) 23:30:52.453116 130.89.29.52 > 206.66.5.134: (frag 35177:576@1480) 23:30:52.456042 130.89.29.52 > 206.66.5.134: icmp: echo request (frag 35178:1480@0+) 23:30:52.457993 130.89.29.52 > 206.66.5.134: icmp: echo request (frag 35179:1480@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@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 ----------------------------------------------------------------------