nanog mailing list archives
Re: Access Lists
From: Phil Howard <phil () charon milepost com>
Date: Thu, 26 Mar 1998 08:46:20 -0600 (CST)
Dan Boehlke writes:
By looking at netflow stats or ip accounting I can usually find the host being attacked by sorting the list by destination. The source will point to hosts on a net being used as a smurf packet replicator, giving a hint who might need to be contacted to shut off directed broadcasts. Netflow stats even show it as being ICMP ECHO traffic if you look at the numeric codes in the flow export. Once you know who is being attacked, you can call your upstream providers or peers and have it traced, but if you want the traffic stopped and the attack is flooding your pipe, about all you can do it stop the traffic from getting to you, so if you are BGP peering with your neighbors, withdraw the network annoucement for the victim and the rest of your customers can continue to get their trafic. This doesn't help trace in, although give how older cisco IOS code reacts to tossing out unroutable packets, the intermediate hosts may find they have a problem when their router CPU use hits 100%. I too would rather have a good quick way to nail the people initiating this sort of attack. However I have also found that my customers who are victims are seldom random and are usually doing something to attract the attack, like running IRC bots or running a sendmail capable of being a SPAM relay. However I don't approve of vigilantism. This stuff can be taken care of in other ways.
I've always held that one thing routers should do is apply the routing logic to the source address of each packet, and verify that the interface it came in on was one of the valid interfaces a reply could return through. It might not be the best route (e.g. asymmetric), but it would at least have to be one of the possible routes. This would break thoses cases where the network would break anyway if that was the only interface to reach the source as a destination (for valid sources). This would at worst case double the CPU usage (if the CPU was doing nothing but route logic). This doesn't affect the scalability formula since with this, tripling the bandwidth still means increasing the performance of the router in the same ratio as it would have been anyway (after it has already been doubled). The cost of this has to be weighed against the cost of the impact of spoofed sources and the manual resources used to track them down. That may not justify the feature. Another possible approach is a tracking protocol. One possible way is for a message to be sent to the router to watch for packets with a specific host or network destination, and send a report to the requester indicating where that packet is coming from, and pass the request on to that same interface. A flag would indicate if the actual packet should be dropped or not for the duration of the tracking (perhaps up to 200 seconds). This logic itself would be subject to abuse, so it would have to have strong security designed into it, such as the verification that it did come from a valid interface as per the logic I described in a previous paragraph. With more and more of these attacks happening, and more and more clueless untrained or improperly trained people being hired to answer the phones at many (or most) of the major backbones, something else is clearly needed. But I do think a smarter router could help. But just how smart is a good question. The most efficient and secure method is desired. -- Phil Howard | no4spam7 () lame1ads net end6ads4 () dumb0ads edu a7b6c3d3 () anywhere com phil | no6spam4 () no6place org eat74me7 () nowhere6 com eat7this () nowhere8 com at | no9way37 () lame7ads org stop9752 () dumbads2 com crash530 () dumbads8 org milepost | ads5suck () dumbads1 edu crash979 () anyplace com stop2208 () anywhere com dot | stop7941 () nowhere8 com die3spam () no0where org stop9114 () anywhere net com | a7b0c5d3 () anyplace net w5x1y1z5 () dumb7ads com blow2me2 () lame7ads org
Current thread:
- Access Lists Martin, Christian (Mar 25)
- Re: Access Lists Dan Boehlke (Mar 25)
- Re: Access Lists Phil Howard (Mar 25)
- Re: Access Lists Dan Boehlke (Mar 26)
- Re: Access Lists Phil Howard (Mar 26)
- Re: Access Lists Phil Howard (Mar 25)
- Re: Access Lists Dan Boehlke (Mar 25)
- <Possible follow-ups>
- RE: Access Lists Martin, Christian (Mar 25)
- Re: Access Lists Steve Sobol (Mar 26)
- RE: Access Lists Martin, Christian (Mar 25)
- RE: Access Lists Rich Sena (Mar 26)
- Re: Access Lists Steve Sobol (Mar 26)
- RE: Access Lists Martin, Christian (Mar 26)
- Re: Access Lists John Navitsky (Mar 27)