|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Smurfing
| > o Making sure source IP address spoofing isn't as easily done as | > it is now. Also an easy one, right? ;-) | | I agree, and this is what we have done. The earlier post (from someone else) | was asking about how to filter *outbound* directed broadcasts, and I didn't | understand how this could be done. A number of my NANOG colleagues have | adamantly agreed that it can't! You probably can't, however the point H�vard was making is that if you deny people the opportunity to spoof the origin of their packets, you deny people the ability to engage in long-term denials-of-service of this nature, and you increase the liklihood of catching the individual perpetrator. These two things will tend to reduce the number of Smurf and other attacks. | > o Lastly, I think that better tools are needed to track this | > sort of attacks back to their source (?). | | That would be very difficult, effectively requiring the ability to query | routers and ask if they are seeing packets bound for a specific address. I'd | love to see some tools that would help us do that, however! H�vard mentioned work going on to do RPF checking. A feature that looked for "out of profile" RPF-failed traffic but that did not drop RPF-failed traffic in general would be a useful debugging tool. Out-of-profile traffic ought to include any large amount of traffic over a sustained period. More cleverly, if the traffic is not TCP traffic or if it is TCP traffic but does not appear to react to induced early packet loss (i.e., you drop a packet deliberately and wait for the sender to react with a retransmit and a decrease in sending bandwidth) and it fails the RPF test, ring alarm bells and optionally drop the traffic altogether. RPF, btw, is "reverse path forwarding", which comes from the wonderful world of multicast lingo. Essentially when you do any type of flooding you ant to make sure you don't forward the flooded traffic back in the direction from which you heard it in the first place. In the world of unicast it is a short-hand way of saying that you check to make sure that a particular packet came from the direction in which you route traffic destined for that packet's source address. Sean.
|