>> Filtering the bogons does help, and everyone should perform anti-spoofing
>> in the appropriate places. It isn't, however, a silver bullet.
> it's necessary but not sufficient.anti-spoofing is useful, but vastly insufficient, and hence not necessary
randy
anti-spoofing eliminates certain avenues of attack allowing one to focus
on remaining avenues, and hence (as Vix stated) is necessary but not
sufficient.
Filtering the bogons does help, and everyone should perform anti-spoofing
in the appropriate places. It isn't, however, a silver bullet.it's necessary but not sufficient.
anti-spoofing is useful, but vastly insufficient, and hence not necessary
anti-spoofing eliminates certain avenues of attack allowing one to focus
on remaining avenues, and hence (as Vix stated) is necessary but not
sufficient.
it turns 1% of the technical problem into a massive social business
problem which, even if it was solvable (which it practically isn't),
would also be addressed by technical solutions where no spoofing is
involved.
but it would provide a lot of fun and soapboxes for wannabe net
police and vigilantes.
randy
Randy Bush wrote:
anti-spoofing eliminates certain avenues of attack allowing one to focus
on remaining avenues, and hence (as Vix stated) is necessary but not
sufficient.it turns 1% of the technical problem into a massive social business
problem which, even if it was solvable (which it practically isn't),
would also be addressed by technical solutions where no spoofing is
involved.
Spoofed packets are harder to trace to the source than non-spoofed packets. Knowing where a malicious packet is very important to the process of trying to stop the malicious packet(s). Anyone without anti-spoof filtering has no interest in managing their network, keeping it secure, and assisting the Internet as a whole.
Without spoofing, one could take a list of 5,000 IP addresses involved in an attack and say, "These are either compromised or direct attacks," and issue reports to the correct people (with a few scripts). With spoofing, there is no reliable way of knowing if a host is compromised, the attacker, or if it's just another IP being spoofed. In such cases, on has to contact each IP owner and find out if spoof protection is enabled. If it is, then the party needs to look into the problem. If not, then it's just another waste of time.
-Jack
it's worse than that. If they have it enabled (eg: 10.0.0.0/24 has
it enabled), but nobody else does, it allows everyone else to spoof
from the 10/24 prefix causing large sets of complaints to filter into
their mailbox.
If we're able to authenticate the sources, then we can presume
abuse reports are authentic. (aside from address space hijacking issues).
it all comes down to filtering, filtering, filtering.
announcement filtering, anti-spoof filtering, peer filtering.
If you're not doing this, you *SHOULD* be. I know it's hard
to do these things in the current business environment. Those of
you that can, please take the time to do this. It will make the lives
of the rest of us much easier when tracing attacks back.
For those of you that are doing IPv6 deployments, might I suggest
you also take the time to do the same? I know that Cisco has v6 u-rpf
support already.
- Jared
Hi, NANOGers.
] For those of you that are doing IPv6 deployments, might I suggest
] you also take the time to do the same? I know that Cisco has v6 u-rpf
] support already.
It's "shameless plug and solicitation of feedback day" here at Team
Cymru. 
We have put together a very rough beta of an IPv6 bogon
page. We could really use some feedback, suggestions, and witty
comments. You will find the BETA page at the following URL:
<http://www.cymru.com/Documents/bogonv6-list.html>
The long-term goal is to provide this data in the same manner that
we provide the IPv4 data, e.g. through HTML, text, DNS, and BGP
peering.
Thanks!
Rob, for Team Cymru.
this is patently incorrect: www.secsup.org/Tracking/ has some information
you might want to review. Tracking spoofed attacks is infact EASIER than
non-spoofed attacks, especially if your network has a large 'edge'.
For those of you that are doing IPv6 deployments, might I suggest
you also take the time to do the same?I know that Cisco has v6 u-rpf
support already.
but not netflow as far as i remember. -hank
Errr... you don't need to _track_ non-spoofed attacks - you _know_ where
the source is. Instead of going box to box back to the source (most
likely across several providers) you can immediately go to _their_
provider.
--vadim
I've heard of Cisco having EFT IPv6 netflow images
available someplace.
- jared
> > Spoofed packets are harder to trace to the source than non-spoofed
> > packets. Knowing where a malicious packet is very important to the
>
> this is patently incorrect: www.secsup.org/Tracking/ has some information
> you might want to review. Tracking spoofed attacks is infact EASIER than
> non-spoofed attacks, especially if your network has a large 'edge'.Errr... you don't need to _track_ non-spoofed attacks - you _know_ where
the source is. Instead of going box to box back to the source (most
likely across several providers) you can immediately go to _their_
provider.
so long as you are sure they aren't spoofed, yes. The point I mis-made was
that tracking the spoofed attacks back to your edge is quicker since in
many cases the non-spoofed attacks come from 'everywhere' so blocking
traffic becomes a null route very quickly 
(unless the upstreams from
your edge device can absorb the load and the protocol/ports being flooded
are not critical to the business of the box being hammered.
A recent post by Rob Thomas said, "I've tracked 1787 DDoS attacks since 01 JAN 2003. Of that number, only 32 used spoofed sources. I rarely see spoofed attacks now."
Thats about 1%. Of the few attacked directed at us and originating from our customers, that generally jives. What number are you seeing ?
---Mike
More and more there is less and less spoofing, its just not required and
it causes more damage with less effort 
Why spoof when you have 1000
machines pumping 1 packet per second? (or 10)
More and more there is less and less spoofing, its just not required and
it causes more damage with less effort
machines pumping 1 packet per second? (or 10)
leaving the spoofing option open for future generations of attacks,
rather than having a witch-hunt and tracking down and upgrading every
insecure edge, is just about the worst thing we could do. because
when an attacker wants an extra edge, they'll add spoofing to their
attack profile, and the core's immune system will be totally unprepared.
knowing this, and knowing that spoofing isn't actually necessary right
now, the current generation of attackers would be well advised to stop
spoofing for a while so that nobody makes any serious attempt to plug
the hole. (and, it sounds like that strategy might already be working.)
could someone here who can write win32 apps, and someone else who can
write cocoa apps, please volunteer short executables that will try to
spoof a few packets through some well known server, and then report as
to whether the current computer/firewall/cablemodem/isp/core permitted
this or not? isc would be happy to host the server component of this,
as long as source code for the executables is available under a bsd
style copyright, and the executables are released without any fee.
this is so the community can gather compelling evidence for the witch-hunt.
(i expect we'd have to come up with a "web button" campaign to brand isp's
who dtrt. sort of like the old squid-era "cache now!" thing.)
How would the spoofing program, or its user, be able to tell if
it was successful? Unless I'm very confused, the definition of
spoofing is that the return packets aren't going to come back to you.
I can imagine a packet format where the real source address was in the
data, but with no authentication this would itself be subject to abuse.
You'd need a little protocol:
Volunteer Server
real-source-->server
<--back to real source with ip to fake, cookie
fake-source-->server with cookie
<--back to real source with result as a courtesy
Doing this from behind a NAT would be difficult.
I don't believe I ever said that the edges shouldn't filter... did I?
They have existed in the past it was how many an irc server was
hacked.. It's just not easy to accomplish but there are many hacker
tools to do this still available, some with better capabilities at this
then others.
Also you could have 2 ip addresses on the same host different
interfaces eg 10.0.0.2 and 10.0.0.3, and use 10.0.0.2 and spoof
10.0.0.3 as the source, and since you can listen to both interfaces,
you can determine if it arrived on the wrong interface.
jason
On Wed, Aug 06, 2003 at 12:58:19AM +0000, Paul Vixie quacked:
could someone here who can write win32 apps, and someone else who can
write cocoa apps, please volunteer short executables that will try to
spoof a few packets through some well known server, and then report as
to whether the current computer/firewall/cablemodem/isp/core permitted
this or not? isc would be happy to host the server component of this,
as long as source code for the executables is available under a bsd
style copyright, and the executables are released without any fee.
If anyone wants this, I have a unix client and server that does the
basics of the testing Paul's suggesting. I used it to test
for spoofability from a bunch of my nodes, I don't claim it's
something you want to open up to cable users as-is. 
The code has only been tested on FreeBSD. YMMV. BSD license.
No attempt at real accounting or security. But maybe it'll get
someone off the ground. If you have compilation problems,
try ripping out the ltconfig and using automake to install the
right version for your own computer (automake --add-missing).
http://eep.lcs.mit.edu/spooftest-dist.tar.gz
-Dave (spoof now!)
Hi, NANOGers.
] leaving the spoofing option open for future generations of attacks,
] rather than having a witch-hunt and tracking down and upgrading every
] insecure edge, is just about the worst thing we could do.
When I first looked at this problem back in March 2001, I did a
study of one often attacked web site. The data showed that 66.85%
of all the source addresses hitting the site were *obvious* bogons,
e.g. RFC1918, unallocated prefixes, etc. That is 66.85% of all
naughty packets that this site never should have received. What
was the total percentage of spoofed source packets? That was
anyone's guess.
You can see this in a presentation I did entitled "60 Days of Basic
Naughtiness":
<http://www.cymru.com/Presentations/60Days.zip>
Since then things have changed in many ways, but the mitigation of
spoofing, be it bogon or otherwise, is an improvement. It takes
another tool out of their toolbox. We win this battle by degrees.
Thanks,
Rob.
] I don't believe I ever said that the edges shouldn't filter... did I?
Nope. I've always heard you say quite the opposite - the edges
should filter.