On Thu, Mar 29, 2001 at 06:40:03PM -0800, David Schwartz wrote:
But the *unspoofed* packets are traceable. The victim can pick up the phone and call your operations and alert them.
If they were spoofed, they wouldn't have to because we'd already be investigating. And even if they're not spoofed, you can't know they're not spoofed, so there's no way to know you got the right person.
So you automatically know about every single spoofed packet your customers send? If they're not spoofed, then the operations folk that I would be speaking to could verify that they're not spoofed by looking at their customer's traffic.
Odds are, an attacker will used spoofed packets if he can. potentially spoofed packets will trigger an investigation on my network. An unspoofed UDP flood probably won't (especially if it hops from victim to victim).
Some of us that have been flooded don't appreciate playing the odds that the provider of the flooder will notice.
Right, that's why every provider has to come up with some reasonable way to deal with this problem. Filtering is one, but it doesn't solve the whole problem. Monitoring is one, but it doesn't solve the whole problem either.
Filtering removes the "is this spoofed or not?" problem. We wouldn't be flooded with packets with sources in unallocated space. Oh, and smurf would disappear completely. Monitoring is reactive. Filtering is proactive. Filtering means I won't be flooded by spoofed packets coming from your customers. Filtering means I won't be smurfed by your customers. (Sure, they could still act as smurf amps, but they couldn't originate a smurf attack). Monitoring means I could still be flooded with spoofed packets, and you might notice and switch it off.
So if the attacker uses spoofed packets, he may get cut off at the source (and the problem actually solved) sooner. On the other hand, unspoofed packets will probably trigger a call to the administration of the source network faster. Of course, you don't know that attack is unspoofed, so you really can't be sure what the source is.
No, but it gives a good indication. And your NOC can find out if the packets are actually coming from your customer (unspoofed) or not (spoofed). If its unspoofed then we're on the phone to the right people. If its spoofed, we're SOL.
Well that's the real problem. Every attack is potentially spoofed and there are no good tools for dealing with spoofed attacks. Filtering doesn't solve either of those two problems.
If everyone filtered, it would solve the problem. If most people filter, it reduces the problem. If nobody filters it does nothing to address the problem. Do you want to help, or do you want to do as little as possible?
The important thing to realize is that neither of these situations is ideal. That is, filters don't solve the problem. We need to acknowledge that we have a problem and don't have a solution to it. Only then will the problem be analyzed, solutions proposed, and implemented.
Filters mean "least damage".
Again, no. A unicast UDP flood can do just as much damage. So filters do not reduce the damage.
If you're ingress filtering, when I pick up the phone I can call your operations folk and they can verify that your customer is flooding me, and stop the flood *quickly*. Speed means a reduction in damage. Sure, someone else could be spoofing your customers addresses, but your operations folk would be able to verify that your customer is not flooding me... so I'm back to square one. *but* even in this case, I'm no worse off than I am today... so putting filters in either means that attacks get shut down more quickly, or they get treated the same as today. It does not make things worse.
I don't know, I'm not smart enough to solve the problem by myself. All I can do is keep yelling as loudly as I can that there is a problem and that we do need a really good solution.
And until we get a really good solution, a really good workaround is not letting spoofed packets into your network from your customers.
Exactly -- the problem is there's no good way to tell a spoofed packet from an unspoofed packet. Some form of source authentication would solve that.
Or you could make sure you're not part of the problem by putting source address filters on your ingress. -- John Payne http://www.sackheads.org/jpayne/ john@sackheads.org http://www.sackheads.org/uce/ Fax: +44 870 0547954 To send me mail, use the address in the From: header