Re: no ip forged-source-address
On Thu, 31 Oct 2002, Christopher L. Morrow wrote: > I think the spoofed source filtering is more a red-herring than anything > else. Its not the fix for anything related to this problem of attacks on > the internet. Spoofed or non, I can forward 1,000,000pps at your network and > it will die (most times). I agree, but > This is like trying to fix a rotten decayed tooth with trident. Wouldn't you rather the dentist know which tooth to drill, instead of randomly drilling all of of your teeth hoping to get the cavity? I can pretty much predict, after source address validation becomes widely used someone will come up with the idea of blackholing attacking hosts. Of course, since many of these systems use DHCP, the zombies will just release and get new addresses.
Re: no ip forged-source-address
On 10/30/02 11:26 AM, "Hank Nussbacher" <[EMAIL PROTECTED]> 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. 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
RE: no ip forged-source-address
On Wed, 30 Oct 2002, Charles D Hammonds wrote: > analogy games are fun, but it boils down to this... If I know the real > source of an attack, I can stop it within minutes. I'm sure that my > customers appreciate that fact. Noone will ever completely stop attacks, the > point is to minimize their impact. that is my concern as a service provider. > also, from the victim's perspective, you have someone to hold accountable. again, spoofed or non, at the egress to the customer you just need to make the traffic stop. Whether they are spoofed isn't an issue. > > Charles > > -Original Message- > From: [EMAIL PROTECTED] [mailto:owner-nanog@;merit.edu]On Behalf Of > Christopher L. Morrow > Sent: Wednesday, October 30, 2002 10:47 PM > To: [EMAIL PROTECTED] > Cc: Christopher L. Morrow; [EMAIL PROTECTED] > Subject: Re: no ip forged-source-address > > > > > > On Thu, 31 Oct 2002 [EMAIL PROTECTED] wrote: > > > On Thu, 31 Oct 2002 06:21:00 GMT, "Christopher L. Morrow" said: > > > > > I'm confused.. its still a DoS attack, eh?? > > > > It's the difference between: > > > > A) Going out to your car at the end of a too-long day and finding a > > broken taillight. > > > > B) Going out to your car at the end of a too-long day and finding a > > broken taillight and a business card under the windshield wiper that > > has "Sorry - call me and I'll pay for it" written on the back. > > > > I think the spoofed source filtering is more a red-herring than anything > else. Its not the fix for anything related to this problem of attacks on > the internet. Spoofed or non, I can forward 1,000,000pps at your network and > it will die (most times). > > This is like trying to fix a rotten decayed tooth with trident. > >
RE: no ip forged-source-address
analogy games are fun, but it boils down to this... If I know the real source of an attack, I can stop it within minutes. I'm sure that my customers appreciate that fact. Noone will ever completely stop attacks, the point is to minimize their impact. that is my concern as a service provider. also, from the victim's perspective, you have someone to hold accountable. Charles -Original Message- From: [EMAIL PROTECTED] [mailto:owner-nanog@;merit.edu]On Behalf Of Christopher L. Morrow Sent: Wednesday, October 30, 2002 10:47 PM To: [EMAIL PROTECTED] Cc: Christopher L. Morrow; [EMAIL PROTECTED] Subject: Re: no ip forged-source-address On Thu, 31 Oct 2002 [EMAIL PROTECTED] wrote: > On Thu, 31 Oct 2002 06:21:00 GMT, "Christopher L. Morrow" said: > > > I'm confused.. its still a DoS attack, eh?? > > It's the difference between: > > A) Going out to your car at the end of a too-long day and finding a > broken taillight. > > B) Going out to your car at the end of a too-long day and finding a > broken taillight and a business card under the windshield wiper that > has "Sorry - call me and I'll pay for it" written on the back. > I think the spoofed source filtering is more a red-herring than anything else. Its not the fix for anything related to this problem of attacks on the internet. Spoofed or non, I can forward 1,000,000pps at your network and it will die (most times). This is like trying to fix a rotten decayed tooth with trident.
Re: no ip forged-source-address
At 01:36 AM 31-10-02 -0500, [EMAIL PROTECTED] wrote: It's the difference between: A) Going out to your car at the end of a too-long day and finding a broken taillight. B) Going out to your car at the end of a too-long day and finding a broken taillight and a business card under the windshield wiper that has "Sorry - call me and I'll pay for it" written on the back. It is better than not having it but we should not get our hopes up that DOS attacks would stop. Remember when 60% of the Internet mail servers were open mail relays? We all thought closing them up would stop spam. Today it is less than 1% but I would say that the amount of spam has not dropped proportionality. See: http://www.nwfusion.com/columnists/2002/1014buzz.html for reference. -Hank
Re: no ip forged-source-address
On Thu, 31 Oct 2002 [EMAIL PROTECTED] wrote: > On Thu, 31 Oct 2002 06:21:00 GMT, "Christopher L. Morrow" said: > > > I'm confused.. its still a DoS attack, eh?? > > It's the difference between: > > A) Going out to your car at the end of a too-long day and finding a > broken taillight. > > B) Going out to your car at the end of a too-long day and finding a > broken taillight and a business card under the windshield wiper that > has "Sorry - call me and I'll pay for it" written on the back. > I think the spoofed source filtering is more a red-herring than anything else. Its not the fix for anything related to this problem of attacks on the internet. Spoofed or non, I can forward 1,000,000pps at your network and it will die (most times). This is like trying to fix a rotten decayed tooth with trident.
Re: no ip forged-source-address
On Thu, 31 Oct 2002 06:21:00 GMT, "Christopher L. Morrow" said: > I'm confused.. its still a DoS attack, eh?? It's the difference between: A) Going out to your car at the end of a too-long day and finding a broken taillight. B) Going out to your car at the end of a too-long day and finding a broken taillight and a business card under the windshield wiper that has "Sorry - call me and I'll pay for it" written on the back. msg06365/pgp0.pgp Description: PGP signature
RE: no ip forged-source-address
If you go back to the thread, you'll see that I was responding to the idea that using src-addr verification would not prevent someone from spoofing addresses on his/own own subnet. Others pointed out that while this might hide the true offender, it would still make the DoS attack easier to mitigate because the src addresses would indicate the network from which the attack originated (if not the actual hosts). Some folks didn't seem to appreciate the value here, therefore I asserted that there is a specific difference between packets with virtually random src addrs, and packets that passed through src-addr filters. The first set are not traceable and src addresses generally useless, while the 2nd set have src addresses that can be used to trace to at least the attack's source network. As for your confusion, I am not sure that I can help with that. :-) -Original Message- From: Christopher L. Morrow [mailto:chris@;UU.NET] Sent: Thursday, October 31, 2002 1:21 AM To: H. Michael Smith, Jr. Cc: 'Hank Nussbacher'; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: no ip forged-source-address On Wed, 30 Oct 2002, H. Michael Smith, Jr. wrote: > > A fundamental effect of spoofing addresses from your local subnet is > that when the packets reach their target, the source addresses are > meaningful. I realize that the traceability of these packets has > already been mentioned, but I want to point out the profound difference > between a DDoS attack with meaningful vs. meaningless source addresses. > I'm confused.. its still a DoS attack, eh??
RE: no ip forged-source-address
On Wed, 30 Oct 2002, H. Michael Smith, Jr. wrote: > > A fundamental effect of spoofing addresses from your local subnet is > that when the packets reach their target, the source addresses are > meaningful. I realize that the traceability of these packets has > already been mentioned, but I want to point out the profound difference > between a DDoS attack with meaningful vs. meaningless source addresses. > I'm confused.. its still a DoS attack, eh??
Re: no ip forged-source-address
I was trying to keep my mouth shut... but alas that was too tough ;( First, the ip addresses used in the attack are completely disconnected from the problem of the attack. If you get attacked, its really not relevant what ips are used, spoofed or not someone needs to stop it for you. The real problem that needs to be addressed is 'how to make the attacks stop' in the first place. Anyway, on to the comments :) On Wed, 30 Oct 2002, Daniel Senie wrote: > > At 12:09 PM 10/30/2002, you wrote: > > "daniel" == Daniel Senie <[EMAIL PROTECTED]> writes: > > > >daniel> If the government or other large buyers require network-wide > >daniel> ingress filtering in any supplier they buy from (something I > >daniel> suggested to the folks at eBay, Schwab, etc. in our phone > >daniel> calls after the attacks a few years ago), or if there were > >daniel> legal incentive, there might be a chance ISPs would find a > >daniel> financial motive to implement BCP 38. As it is, there's no > >daniel> incentive, so the path of least resistance is to do nothing. > > > >I find it interesting that you suggest that the legal incentive should > >be toward having the ISPs come up with a magic solution and not toward > >having the customers do egress filtering at the edge(s) of their > >network and actually perform something resembling security on the > >hosts on their networks. > > What I suggested was a financial OR legal incentive. > > > >After all, it is not usually a security failing of the ISP that causes > >a DoS or DDoS attack, but utter incompetence or neglect by someone at > >the edge of the network. > > That's a question of perspective. Arguably both the ISP and the end user > are responsible. The ISP is often in the role of managing the CPE router, > and thereby has control over the router where ingress/egress filtering is > most easily implemented with simple access control lists. > Wow, this is an overreaching assumption you are making. There are quite a few ISP's that manage a small minority of their customers. I'd think that number at UUNET, for example, manages less than 1% of its customer CPE. Sprint is apparently managing a bit more, given that almost all sprintlink customers I talked to have managed cpe... ATT I don't know about for this argument. The point here is that assuming that "all isps manage their customer's cpe" isn't safe. > > >I'm not saying I don't think ISPs should filter where feasible, I'm > >just saying that if we're going to hold someone responsible, it should > >be the people who are responsible, not the people who are convenient. > > I find it interesting that some ISPs have no trouble taking care of ingress > filtering, while others bellyache about how hard and expensive it is. > Another nanog participant commented ATT implemented this starting in 1995. > A UUNet person was the most vocal opponent to the draft that became RFC > 2267 (over concern that the Cisco 7000's in use then would not handle the > load). Six years later, ATT's network seems to do OK. Did UUNet ever do > anything about it? Buy gear sized properly to do it? UUNet gives away > 2610's with leased lines. Do they come pre-configured to do ingress > filtering even? Yes, this has been part of the standard customer router config for sometime now... Technically its 'egress' not 'ingress' filters, but the same effect is in place. > > The question for the ISP is how it will defend itself when summoned to > court. The ISP had the tools to ensure spoof attacks could not come from > its network, yet chose not to. The customer likely would also face the This is entirely NOT the case. The 'tools' being 'urpf' works in limited cases, there are some spectacular failures though. Access-lists on INGRESS at the ISP, except in small ISP examples are a massive scale problem.. not to mention the functionality issues :)
Re: Active measurements BCP Internet Draft (fwd)
On Thu, 31 Oct 2002, Henk Uijterwaal (RIPE-NCC) wrote: > Folks, > > I've put the latest version of the Active Measurements BCP Internet > Draft, that I mentioned during yesterday's Measurements panel, > online at: > > http://www.ripe.net/home/henk/draft-ietf-ippm-owmetric-as-01.txt I think this draft makes considerable sense and addresses some of the measurements which might be used to characterize performance (as the title of the WG says) which is good. I'm also interested in provoking dicussion about the active measurement requirements for the other purposes which were touched on by the panel. Primarily, collecting traffic information for purposes of deriving traffic matrices, capacity projection, traffic engineering and attack profiling and detection. To put a fine point on it as I tried to on the panel: Can we come up with some best current practices for addressing these needs and deliver them as a clear set of requirements, both high- and low-level to equipment vendors? In addition to the very specific stuff of how to sample traffic or how not to, I'm thinking a framework document, applicability statement, or the like which lays out the big picture of how the protocols are envisioned to be used; what real-world problem(s) they solve. I chatted with Jen Rexford briefly afterward and she said that the PSAMP WG has a draft framework doc which appears to be this: http://ietf.org/internet-drafts/draft-ietf-psamp-framework-00.txt The IPPM has a few including some which have become RFCs. What do people think about how well they meet the needs they have at hand? Would some even higher-level description of an activity such as capacity planning be useful where we could then crystalize some tools we need to get that job done? What about laying out exactly how we think they need to be used so that if some part of the requirement changes down the road, the relevant adaptations can be made? Talk amongst yourselves. Tony
Re: ICANN Targets DDoS Attacks
On Wed, 30 Oct 2002 13:35:38 PST, "Crist J. Clark" said: (OK.. *technically*, Christ is correct.. you can't tell.. but still) > On the classless Internet, how does any router know what is or is not > a broadcast address when the final destination is not local? Bitch bitch whine whine. Why is it that the people who *RUN* the network have so much difficulty identifying such things, when a bunch of script kiddies(*) can put up a web site with a nice list, sorted by number of generated packets per ping packet? If all other creativity fails, visit the website, see if any of the addresses fall into your customer's space, and call them if you find any. Let's face it - this wouldn't be an issue if it wasn't well within the ability of the average 15-year-old pimply-faced script kiddie to figure out. OK. Sorry. It's been waaay too long a day, I'm done venting now. ;) On a more practical note, you don't really care *that* much about an ICMP Echo Request coming out of one of your customers (at least as long as the address is in their space, but that's just ingress/egress filtering ;) heading to some address at an ISP in some Third World country. And as noted, there isn't much you can do about it. What you *do* care about is a packet coming in and headed to one of your customer's broadcast addresses. You care because if they're a smurf amp, you're about to get hit by a packet flurry, and because you're close enough to be able to *do* something about it. And let's face it - if you've sold them a /24(**), then the .255 address is quite likely a broadcast packet (even if they have subnetted the /24 - think about it). The only other option is if they've use a /31 to number a router link at the very top of their space - and in that case, re-read RFC3021, section 2.2.1 ;) OK.. Now where did I leave my asbestos underwear? ;) -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech (*) And yes, I know that the *famous* list isn't done by script kiddies, but it's not the only one. ;) (**) And don't whine about if you sold them something other than a /24 - there's enough /24's to make it worthwhile msg06360/pgp0.pgp Description: PGP signature
Re: no ip forged-source-address
On Wed, Oct 30, 2002 at 03:34:40PM -0600, Craig A. Huegen wrote: > > 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. 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 -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
OT: Fast.net NOC contact
OK, I normally try to avoid doing this, but could someone in Fast.net's NOC please drop me an email about a job you guys have posted there? Or just plain have a contact there they would be willing to set me up with? :) Thanks if you can help! Jamie
Active measurements BCP Internet Draft (fwd)
Folks, I've put the latest version of the Active Measurements BCP Internet Draft, that I mentioned during yesterday's Measurements panel, online at: http://www.ripe.net/home/henk/draft-ietf-ippm-owmetric-as-01.txt The draft is still very rough, comments, to the [EMAIL PROTECTED] list, are welcome, Henk -- Henk UijterwaalEmail: [EMAIL PROTECTED] RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.5354414 1016 AB AmsterdamFax: +31.20.5354445 The Netherlands Mobile: +31.6.55861746 -- That problem that we weren't having yesterday, is it better? (Big ISP NOC)
RE: no ip forged-source-address
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
RE: no ip forged-source-address
A fundamental effect of spoofing addresses from your local subnet is that when the packets reach their target, the source addresses are meaningful. I realize that the traceability of these packets has already been mentioned, but I want to point out the profound difference between a DDoS attack with meaningful vs. meaningless source addresses. -Original Message- From: [EMAIL PROTECTED] [mailto:owner-nanog@;merit.edu] On Behalf Of Hank Nussbacher Sent: Wednesday, October 30, 2002 2:27 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: no ip forged-source-address On Wed, 30 Oct 2002 [EMAIL PROTECTED] 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 > > 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. > > >
Re: no ip forged-source-address
At 12:09 PM 10/30/2002, you wrote: "daniel" == Daniel Senie <[EMAIL PROTECTED]> writes: daniel> If the government or other large buyers require network-wide daniel> ingress filtering in any supplier they buy from (something I daniel> suggested to the folks at eBay, Schwab, etc. in our phone daniel> calls after the attacks a few years ago), or if there were daniel> legal incentive, there might be a chance ISPs would find a daniel> financial motive to implement BCP 38. As it is, there's no daniel> incentive, so the path of least resistance is to do nothing. I find it interesting that you suggest that the legal incentive should be toward having the ISPs come up with a magic solution and not toward having the customers do egress filtering at the edge(s) of their network and actually perform something resembling security on the hosts on their networks. What I suggested was a financial OR legal incentive. After all, it is not usually a security failing of the ISP that causes a DoS or DDoS attack, but utter incompetence or neglect by someone at the edge of the network. That's a question of perspective. Arguably both the ISP and the end user are responsible. The ISP is often in the role of managing the CPE router, and thereby has control over the router where ingress/egress filtering is most easily implemented with simple access control lists. The problem is that it's those same people who have the money needed to keep the ISPs in business. Unless all ISPs decided to hold the customers responsible, they'd just move to another ISP. Or unless customers refuse to buy from anyone who doesn't do ingress filtering, resulting in a financial incentive for the ISP. I'm not saying I don't think ISPs should filter where feasible, I'm just saying that if we're going to hold someone responsible, it should be the people who are responsible, not the people who are convenient. I find it interesting that some ISPs have no trouble taking care of ingress filtering, while others bellyache about how hard and expensive it is. Another nanog participant commented ATT implemented this starting in 1995. A UUNet person was the most vocal opponent to the draft that became RFC 2267 (over concern that the Cisco 7000's in use then would not handle the load). Six years later, ATT's network seems to do OK. Did UUNet ever do anything about it? Buy gear sized properly to do it? UUNet gives away 2610's with leased lines. Do they come pre-configured to do ingress filtering even? The question for the ISP is how it will defend itself when summoned to court. The ISP had the tools to ensure spoof attacks could not come from its network, yet chose not to. The customer likely would also face the negligence charge. The plaintiff would be the customer of another ISP whose business was severely injured. The question is whether you want to, in court, tell the judge "my customer was an idiot. Blame them, it's not my fault." You might even get away with it, but I suspect you would lose your customer base pretty quickly thereafter. The S in ISP stands for SERVICE. You're providing a service to your customers. Helping those customers stay out of trouble, whether it's by selling them a firewall service, or managing their CPE router, or just providing ingress filtering, is part of what service is about. I'm not surprised that major backbone providers still complain about ingress filtering. I am a bit surprised no lawsuits have get cited BCP 38.
Re: no ip forged-source-address
> 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
Re: no ip forged-source-address
At 02:26 PM 10/30/2002, you wrote: On Wed, 30 Oct 2002 [EMAIL PROTECTED] 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. 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. -Hank > > 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. > > >
RE: no ip forged-source-address
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).
Re: ICANN Targets DDoS Attacks
On Tue, 29 Oct 2002 16:00:06 -0500, [EMAIL PROTECTED] wrote, > On Tue, 29 Oct 2002 12:48:39 PST, Jeff Shultz said: > > > >Smurf. > > > Okay. What will this do to my user's ping and traceroute times, if > > anything? I've got users who tend to panic if their latency hits 250ms > > between here and the moon (slight exaggeration, but only slight). > > > > I just love it when I've got people blaming me because the 20th hop on > > a traceroute starts returning * * * instead of times. > > So you rate limit it to several/second or something appropriate for the normal > traffic levels. You don't allow ping/traceroute to broadcast addresses. On the classless Internet, how does any router know what is or is not a broadcast address when the final destination is not local? -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
Re: no ip forged-source-address
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
Re: no ip forged-source-address
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. 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.
NMS/OSS commercial software : short summary from NANOG replies - here itis
Sorry for my previous mail that was sent empty, due to a mouse clicking bug ;-) So, at last, here is the summary of the answers, plus additional information resulting from meetings I had with some vendors in the last days : First of all, one contributor emphazises on the fact that focusing on people and process is at least as important as on the tools used for NMS. Now the products : - Infovista : According to someone (Hi Mike,see you on rs-sp ;-) ), the product is considered to be flexible to build SLA reporting package, and very customizable to specific needs. According to another one: "Our NOC uses it and it just is not useful in any way, it usually is not common sense, the implementation is not straight- forward, it is awkward, and makes shortcuts that shall not be made". no comments >From a meeting I had with Infovista recently, my personal feelings are a mix of both opinions : It is surely a powerful tool, very customizable and scalable, but quite complex and heavy to deploy, and it costs a fortune (multiple hundreds of K$, not to say more). - Concord : >From one contributor :"horrible in multi-vendor environments" I have briefly met a Concord integrator, the product seems quite straight and simple to deploy, but very limited in terms of customization (all changes require C developpment). - Proviso : I have met the people from Quallaby today, the product looks both simple to install and powerful in terms flexibility and scalability. It might be a good product for perfs monitoring and customer SLA reports, but I had some rumors of possible bankrupcy of Quallaby ... I need to check more about it. - Netcool : seems to be quite a reference on the market, I only had good but not detailed opinions on it. - Cisco Works: not recommended by some people, or to be used for Natkit, which requires the NSA (Network supported account) level of support from Cisco (which is not cheap at all ;-). Quite an interesting doc recommended on NOC topics in general : http://www.cisco.com/networkers/nw02/presos/pws/docs/PS-510.pdf Other products that have been recommended by people on the list : - Smarts : http://www.smarts.com/ . The product looks interesting, and it was recommended by several persons on the list. Regarding my personal needs, I am not sure how well it is supported in Europe, and especially in France - LINMOR : www.linmor.com : a Canadian product. >From the contributor :"They are the prefered vendor for both Cisco & Micromuse when it comes to performance management" I might have the same problem that with Smarts in terms of finding here a reseller and appropriate support ... - SpiderMon, from Pathway Communication (a Canadian ISP reselling its in house NM tool) : It seems to be an all-in-1 product covering the whole FCAPS range. I can give more details on the product for person requesting it. An interesting article comparing Spectrum, Patrol, Netcool, and Smarts : http://www.networkcomputing.com/1316/1316f2.html All comments welcomed. Marc Rapoport Architecture Dpt Completel tel : +33 1 72 92 25 38 fax: +33 6 09 76 56 79 [EMAIL PROTECTED]
Re: no ip forged-source-address
On Wed, 30 Oct 2002 [EMAIL PROTECTED] 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 > > 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. > > >
Re: no ip forged-source-address
On Wed, Oct 30, 2002 at 08:02:13PM +0100, Lars Erik Gullerud wrote: > > On Wed, 2002-10-30 at 16:44, [EMAIL PROTECTED] wrote: > > > 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? 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 [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: no ip forged-source-address
On Wed, 2002-10-30 at 16:44, [EMAIL PROTECTED] wrote: > 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
Re: no ip forged-source-address
On Wed, Oct 30, 2002 at 06:02:44PM +, [EMAIL PROTECTED] wrote: > On Wed, 30 Oct 2002, Jesper Skriver 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. > > Turn it off for backbone interfaces. 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.
tiscali please:)
Can someone with Tiscali write to me off list concerning as9105.net Thanks Scott
Re: no ip forged-source-address
On Wed, 30 Oct 2002, Jesper Skriver 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. Turn it off for backbone interfaces. Regards, Rich
RE: no ip forged-source-address
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: [EMAIL PROTECTED] [mailto:owner-nanog@;merit.edu] On > Behalf Of [EMAIL PROTECTED] > Sent: Wednesday, October 30, 2002 8:21 AM > To: [EMAIL PROTECTED] > 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 >
Re: no ip forged-source-address
"daniel" == Daniel Senie <[EMAIL PROTECTED]> writes: daniel> If the government or other large buyers require network-wide daniel> ingress filtering in any supplier they buy from (something I daniel> suggested to the folks at eBay, Schwab, etc. in our phone daniel> calls after the attacks a few years ago), or if there were daniel> legal incentive, there might be a chance ISPs would find a daniel> financial motive to implement BCP 38. As it is, there's no daniel> incentive, so the path of least resistance is to do nothing. I find it interesting that you suggest that the legal incentive should be toward having the ISPs come up with a magic solution and not toward having the customers do egress filtering at the edge(s) of their network and actually perform something resembling security on the hosts on their networks. After all, it is not usually a security failing of the ISP that causes a DoS or DDoS attack, but utter incompetence or neglect by someone at the edge of the network. The problem is that it's those same people who have the money needed to keep the ISPs in business. Unless all ISPs decided to hold the customers responsible, they'd just move to another ISP. I'm not saying I don't think ISPs should filter where feasible, I'm just saying that if we're going to hold someone responsible, it should be the people who are responsible, not the people who are convenient. but my opinions are probably worthless, Michael
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
Re: no ip forged-source-address
On Wed, Oct 30, 2002 at 03:44:12PM +, [EMAIL PROTECTED] wrote: > 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? 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.
Re: no ip forged-source-address
At 10:44 AM 10/30/2002, [EMAIL PROTECTED] 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.
Lame reports - thanks!
Hi, NANOGers. My thanks to the increasing number of you who submit lame delegation logs to me. This helps to increase the reach and usefulness of the Weekly Lame Name Server Report page: http://www.cymru.com/DNS/lame.html If you have logs you can share, anonymously or with full credit, feel free to send them to [EMAIL PROTECTED] Be the first on your block to fill my lamer file system. :) Thanks! Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
IANA IPv4 allocation list format change
Hi, NANOGers. For those of you who don't know, the format of the IANA IPv4 allocation list has changed. It now lists each prefix as a distinct /8, instead of hyphenated ranges of prefixes. This change took place on 25 October. If you are parsing this file automagically, you may wish to modify your scripts. My own script claimed that several new allocations had been made. It's fixed now. :) http://www.iana.org/assignments/ipv4-address-space My thanks to the IANA folks for this change! Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
no ip forged-source-address
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.
Re: ICMP filtering, was Re: ICANN Targets DDoS Attacks
Hi, Rafi! How's things? ] I find it hard to believe You have no thoughts about: Oh, you know me; I have a thought about everything. :) ] 1) rate-limiting ICMP This is covered in the Secure IOS Template, though it likely should be added to the ICMP filtering list as well. I very much like the example posted by Jared, so I may steal that as well (*waves to Jared*). :) ] 2) passing ICMP "statefully" ] (that is for example ICMP echo reply only accepted in reply to an ICMP echo) Ah, yeah... I've seen a lot of problems with stateful inspection of ICMP flows. In short, I've not seen it work consistently. Enlightenment is welcome. :) ] 3) DoS problems related to ICMP unreachables This is also covered in the Secure IOS Template; I recommend disabling them. Barry has already given me the syntax to rate limit them, which is something I need to add to the Secure IOS Template. I need more time and more coffee. :) http://www.cymru.com/Documents/secure-ios-template.html Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
