|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: SMURF amplifier block list
On Sat, 18 Apr 1998, Alex P. Rudnev wrote: > > What about people who didn't subnet their class B on the eight bit > > boundry, but made larger subnets instead? What about the class B that > > doesn't appear to be subnetted at all? What about supernetted class C > > networks? A trailing .255 can be a valid host. > And what's worng? If they di nit subnet their B network, the tail of > address should be .255 too. > > If someone have particular .255 host - OK, you should not be able to ping > it, not more. The small fee for the free-of-smurfing-from-your-network. > > > > Why don't use the filter > > > > > > deny icmp any 0.0.0.255 255.255.255.0 echo-request > Just now, USA's ISP seems to be absolutely helpless facing SMURF. A lot > of networks do not block aroadcast echo-request's; no one even know how > to trace thos 'echo-request' packets by their network... may be I am > wrong, and it's because there is _a lot of ISP_ there, and even a few af > them who do not know how to fight against SMURF compose a good backet - I > do not know. > > Really; does anyone know any sucsessfull attempts to search for the > smurfer? What penalty was provided for this hackers? Does exist some > legitimate way to establish a lawsuite against them (when they'll be > located - last is the only matter of qualification for their nearest ISP, > not more). I agree that ISPs are at the mercy of the smurfers. At MRNet we have been fighting an internal battle to get our customers to do the right things to block their ability to be used as a multiplier. Its not just ignorance that keeps our customers from acting, it in some cases is their equipment. We have written SMURF detection software that uses cisco netflow exports to let us know when a SMURF is going on, either inbound or outbound. Before we had this, we didn't know how bad it was, we never saw the majority of the attacks or where our customer nets were being used as a multiplier. We hope to automate a block. Cisco is working on features to help with this problem. They need to be given time to do it right. We have implimented a filter that blocks broadcasts on our NSP border routers. However this list only blocks the broadcast addresses in our CIDR blocks and on assigment boundries. It has helped alot. We can, as network administrators, clamp down this net so hard only the hackers would be able to use it. Blocking all .255 traffic even just ICMP is a step too close to that. Remember the distain for routers and hosts that made classfull assumptions when they were given an address? -- Dan Boehlke, Senior Network Engineer M R N e t Internet: [email protected] A MEANS Telcom Company Phone: 612-362-5814 2829 SE University Ave. Suite 200 WWW: http://www.mr.net/~dboehlke/ Minneapolis, MN 55414
|