Re: no ip forged-source-address
At 10:44 AM 10/30/2002, variable@ednet.co.uk wrote:
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.
BCP 38 is quite explicit in the need for all networks to do their part. The document is quite effective provided there's cooperation.
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").
So you're suggesting the router vendors provide default configurations which the ISPs will overwrite with their current configurations anyway? Which interface would you filter on? If we're talking about a router at the customer premesis, the filters should be on the link to the ISP (the customer may well have more subnets internally). At the ISP end, doing the filtering you suggest would not work, since it'd permit only the IP addresses of the link between the customer and user. For dialups, such filtering can and should be done, and should be automatic in the NAS boxes. But the #1 question I have to ask you is, how are you going to have any more luck enforcing ingress filtering with what you propose, than what we have in the BCP on the subject? If the government or other large buyers require network-wide ingress filtering in any supplier they buy from (something I suggested to the folks at eBay, Schwab, etc. in our phone calls after the attacks a few years ago), or if there were legal incentive, there might be a chance ISPs would find a financial motive to implement BCP 38. As it is, there's no incentive, so the path of least resistance is to do nothing.
On Wed, 30 Oct 2002, Daniel Senie wrote:
BCP 38 is quite explicit in the need for all networks to do their part. The document is quite effective provided there's cooperation.
Doesn't seem to be working.
Which interface would you filter on?
Customer ingress ports on the ISP side, which I suspect are the majority of ports in ISP networks. Hopefully engineers on the backbone will be clueful enough to turn it off.
If we're talking about a router at the customer premesis, the filters should be on the link to the ISP (the customer may well have more subnets internally). At the ISP end, doing the filtering you suggest would not work, since it'd permit only the IP addresses of the link between the customer and user.
The routing table of the router should be used to build up a list of prefixes that you should see through the interface. In this way, you could apply it to BGP customers too without having to create filters by hand. Regards, Rich
To reiterate the comment I made during the session yesterday, the places where strict rpf will be most effective are at the very edge interfaces without explicit management (SOHO). This also tends to be the place where there is insufficient clue to turn it on. One hopes that in the nanog community there is sufficient clue to recognize the case where having it on will create a problem and turn it off. This has been a case where money has been talking, and those with enough clue to comment on it are saying they don't want it, while those that really need it are not asking. If the community believes this technique is the best tool for regaining visibility into where attacks are coming from, there are two explicit steps to making it happen. First, demand that all vendors make it the default. Second, be willing to turn it off rather than simply complain that it doesn't work in the ISP network. Tony
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of variable@ednet.co.uk Sent: Wednesday, October 30, 2002 8:21 AM To: nanog@nanog.org Subject: Re: no ip forged-source-address
On Wed, 30 Oct 2002, Daniel Senie wrote:
BCP 38 is quite explicit in the need for all networks to do their part. The document is quite effective provided there's cooperation.
Doesn't seem to be working.
Which interface would you filter on?
Customer ingress ports on the ISP side, which I suspect are the majority of ports in ISP networks. Hopefully engineers on the backbone will be clueful enough to turn it off.
If we're talking about a router at the customer premesis, the filters should be on the link to the ISP (the customer may well have more subnets internally). At the ISP end, doing the filtering you suggest would not work, since it'd permit only the IP addresses of the link between the customer and user.
The routing table of the router should be used to build up a list of prefixes that you should see through the interface. In this way, you could apply it to BGP customers too without having to create filters by hand.
Regards,
Rich
At 12:29 PM 10/30/2002, Tony Hain wrote:
To reiterate the comment I made during the session yesterday, the places where strict rpf will be most effective are at the very edge interfaces without explicit management (SOHO). This also tends to be the place where there is insufficient clue to turn it on.
This is also an area where NAT boxes are prevalent. One would HOPE the NAT boxes would take care of rejecting bogus source addresses sinec they do have to do translation on whatever comes in. So encouraging NAT boxes in the SOHO world is perhaps not so bad... For the SOHO cases without NAT boxes, cable, dsl and dialup from a single computer, it would make a great deal of sense for the ISP to take care of this issue (in the cable head-end router, DSLAM, or NAS).
If anyone has contact information for someone with the security dept. of the Army Corps of Engineers network, could they please contact me offlist? I have tried to contact the webmster from the contact list on http://www.usace.army.mil but all I get is someone's voicemail. The other number listed is disconnected. Randy
participants (4)
-
Daniel Senie
-
Randy Rostie
-
Tony Hain
-
variableļ¼ ednet.co.uk