Hi,
I've been following the discussion on DDoS attacks over the last few weeks
and our network has also recently been the target of a sustained DDoS
attack. I'm not alone in believing that source address filters are the
simplest way to prevent the types of DDoS traffic that we have all been
seeing with increasing regularity. Reading the comments on this list have
lead me to believe that there is a lot of inertia involved in applying
what appears to me as very simple filters.
As with the smurf attacks a few years ago, best practice documents and
RFC's don't appear to be effective. I realise that configuring and
applying a source address filter is trivial, but not enough network admins
seem to be taking the time to lock this down. If the equipment had
sensible defaults (with the option to bypass them if required), then
perhaps this would be less of an issue.
Therefore, would it be a reasonable suggestion to ask router vendors to
source address filtering in as an option[1] on the interface and then move
it to being the default setting[2] after a period of time? This appeared
to have some success with reducing the number of networks that forwarded
broadcast packets (as with "no ip directed-broadcast").
Just my $0.02,
Richard Morrell
edNET
[1] For example, an IOS config might be:
interface fastethernet 1/0
no ip forged-source-address
[2] Network admins would still have the option of turning it off, but this
would have to be explicitly configured.
Cannot be done, I certainly doesn't want RPF check to be default enabled
on all interfaces on my routers, think for a second about asymmetric
routing WITHIN the ISP network.
/Jesper
Turn it off for backbone interfaces.
Regards,
Rich
What's the difference then, the person who doesn't understand what it's
about will then just disable it throughout ...
The current solution about enabling it manually works fine.
/Jesper
Therefore, would it be a reasonable suggestion to ask router vendors to
source address filtering in as an option[1] on the interface and then move
it to being the default setting[2] after a period of time? This appeared
to have some success with reducing the number of networks that forwarded
broadcast packets (as with "no ip directed-broadcast").
[snip]
[1] For example, an IOS config might be:
interface fastethernet 1/0
no ip forged-source-address
Well, this already exists, doesn't it? Try the following on your
customer-facing interface:
ip verify unicast source reachable-via rx
[2] Network admins would still have the option of turning it off, but this
would have to be explicitly configured.
I have a feeling that having strict uRPF as the default setting on an
interface would be very badly received by a lot of ISP's. I know I
certainly wouldn't like it very much.
Is it really the job of router vendors to protect the net from
lazy/incompetent/ignorant network admins?
/leg
No, but I can't enable these features on all
my router interfaces without causing delays/drops due to poor
inital design quality and lack of long-term vision for linecards
manufactured.
The rush for time-to-market can cause you to lose in
the long-term due to lack of features.
- jared
If every router in the world did this I could still use spoofed IP
addresses and DDOS someone. My little program could determine what subnet
I am on, check what other hosts are alive on the subnet and then when it
decides to attack, it would use some neighbor's IP. The subnet I am on is
a /24 and there very well may be a few dozen hosts. I could be real
sneaky and alter my IP randomly to be any of my neighbors for every packet
I send out.
Traceback would get me instantly back to the offending subnet but then it
would take a bit of digging on the network admin to track me down and
applying RPF checking won't help.
RPF checking can only go so far. You would need RPF checking down to the
host level and I haven't heard anyone discuss that yet.
-Hank
Sure. But do you really want to give up a 95% solution just because
it doesn't get you the last inch? We have no solution that will do
that. Being able instantly to identify the subnets from which DDoS
traffic is coming would make shutting off those subnets during the
attack possible*, and that in turn would motivate the subnet owners
to clean up their hosts.
* I suspect that an attack that actually comes from 1000 compromised
hosts does not come from nearly that many subnets. Is there any data?
As a historical note, I put SAA in the filters for the ATT Worldnet
dialup network from its very start in 1995. Work by smb on the
dangers of spoofed source addresses was already public then. It's
long past time for the rest of the world to catch up.
==>Traceback would get me instantly back to the offending subnet but then it
==>would take a bit of digging on the network admin to track me down and
==>applying RPF checking won't help.
I think the issue we need to tackle is ensuring that packets originate,
at minimum, from the organization who holds the address space in the
source address.
I'm happy getting it down to the organizational level (note that in a
larger enterprise organization it may not even be to subnet level). At
least then we have an accountable party.
/cah
If every router in the world did this I could still use spoofed IP
addresses and DDOS someone. My little program could determine what subnet
I am on, check what other hosts are alive on the subnet and then when it
decides to attack, it would use some neighbor's IP. The subnet I am on is
a /24 and there very well may be a few dozen hosts. I could be real
sneaky and alter my IP randomly to be any of my neighbors for every packet
I send out.
And the company being attacked would be able to find out what network you are on.
Traceback would get me instantly back to the offending subnet but then it
would take a bit of digging on the network admin to track me down and
applying RPF checking won't help.
While that traceback is happening, your upstream ISP would be quite able to cut connectivity to your /24 while investigating which machine was causing the problem. It's a question of accountability. If that /24 is used by one company, it's now possible to know that company is your target when you file your court papers.
RPF checking can only go so far. You would need RPF checking down to the
host level and I haven't heard anyone discuss that yet.
Getting to the subnet is sufficient bring the problem to the local entity involved. I think that's quite reasonable. If the /24 is a cable network, a packet analyzer in use by the local cable ISP will find the culprit.
decides to attack, it would use some neighbor's IP. The subnet I am on is
a /24 and there very well may be a few dozen hosts. I could be real
sneaky and alter my IP randomly to be any of my neighbors for every packet
I send out.
This gets a lot sneakier when you got your /64 on the subnet. Specially
if people start to build significantly larger subnets by default.
Pete
Petri Helenius wrote:
> decides to attack, it would use some neighbor's IP. The
subnet I am
> on is a /24 and there very well may be a few dozen hosts.
I could be
> real sneaky and alter my IP randomly to be any of my neighbors for
> every packet I send out.
>
This gets a lot sneakier when you got your /64 on the subnet.
Specially
if people start to build significantly larger subnets by default.
Just stop. This nonsense about spoofing is easier because the IPv6
address space is bigger is bogus and wasting everyone's time. When each
customer is assigned a unique /48-/64 they are traceable to the
accountable entity no matter what low order bits they use. If they are
assigned something longer than a /64, they are likely to keep using
tunneling technologies like 6to4 until they can dump the provider that
is cluelessly hoarding a resource that is not scarce.
Tony
==>Traceback would get me instantly back to the offending subnet but then it
==>would take a bit of digging on the network admin to track me down and
==>applying RPF checking won't help.
I think the issue we need to tackle is ensuring that packets originate,
at minimum, from the organization who holds the address space in the
source address.
And i wish all telemarketers generated caller-id. But the
lack of it doesn't mean i won't answer the phone.
I'm happy getting it down to the organizational level (note that in a
larger enterprise organization it may not even be to subnet level). At
least then we have an accountable party.
Exactly. This isn't in attempt to stop all DoS attacks, just
help validate that when someone is attacking from the ip of www.example.com,
there will be a good chance that www.example.com is 0wned.
- jared
That's what we can do on our DOCSIS CMTS -- verify that the source IP
address is that which was issued with DHCP over the same DOCSIS SID. It's
not possible to spoof using your neighbor's PC, even if they're on the same
subnet, as their CM has a different DOCSIS SID. Otherwise the typical RPF
checking would be pretty ineffective, with up to a 1000 or even 2000 CM's on
a single interface/subnet.
So if the operator had this feature turned on your little program would not
succeed on PC's behind cable modems.
-- Jim