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.
On Wed, Oct 30, 2002 at 03:44:12PM +0000, variable@ednet.co.uk wrote:
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 -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Senior network engineer @ AS3292, TDC Tele Danmark One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them.
On Wed, Oct 30, 2002 at 06:02:44PM +0000, variable@ednet.co.uk wrote:
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 -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Senior network engineer @ AS3292, TDC Tele Danmark One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them.
in cisco parlance, ip verify unicast source reachable-via any allow-default allow-self-ping would be fine in the core, and as a default setting. Would still need to enable strict settings on applicable borders, which would probably be skipped by the clue impaired, but some of the crap would be caught, which is better than none.
On Wed, 2002-10-30 at 16:44, variable@ednet.co.uk wrote:
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
On Wed, Oct 30, 2002 at 08:02:13PM +0100, Lars Erik Gullerud wrote:
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 -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
On Wed, 30 Oct 2002 variable@ednet.co.uk wrote: 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
On Wed, Oct 30, 2002 at 09:26:30PM +0200, Hank Nussbacher wrote:
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. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net.
On Wed, Oct 30, 2002 at 09:26:30PM +0200, Hank Nussbacher wrote: ==>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
On Wed, Oct 30, 2002 at 03:34:40PM -0600, Craig A. Huegen wrote:
And i wish all telemarketers generated caller-id. But the lack of it doesn't mean i won't answer the phone.
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 -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Petri Helenius wrote:
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
On 10/30/02 11:26 AM, "Hank Nussbacher" <hank@att.net.il> wrote:
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
participants (11)
-
Barney Wolff
-
bdragon@gweep.net
-
Craig A. Huegen
-
Hank Nussbacher
-
Jared Mauch
-
Jesper Skriver
-
Jim Forster
-
Lars Erik Gullerud
-
Petri Helenius
-
Tony Hain
-
variable@ednet.co.uk