|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: DoS attacks, NSPs unresponsiveness
On Thu, 2 Nov 2000, Joe Shaw wrote: > > On Wed, 1 Nov 2000, John Fraizer wrote: > > Where should they put them? You also have to take into account, a large IMHO, in a museum. > portion of crippling attacks aren't directed at the servers themselves, > but at the actual users. This makes the problem a bit larger than just > one of those that should only concern owners of IRC servers. OK. I will grant you that there are attacks aimed at individuals. And I will also grant you that some of these script kiddies like to "kill a fly with a hammer" IE; 100Mb/s attack launched against some poor schmuck on a 28.8 modem. The script kiddies aren't terribly stupid though. They don't generally continue to attack once their objective has been achieved. To do so increases the chances that the source of the attack will be identified. One of the keys to winning a war is to choose your battles wisely and attempt to limit casualties in the battles you do fight.. Don't throw 1Gb/s of capacity to a server that is only going to use 20Mb/s but is highly likely to attract 600Mb/s of "hate" from the script kiddies. Go find someone with a legacy /24 they're not using (there are TONS of them) and convince them to sell it to you. Put the "target" on that /24. If you're under attack, retract the announcement. Now, the "hate" stays on the originating network. I know you're probably going to say "You expect them to disconnect just because some punk downloaded the latest attack script?" I'll answer that with a question for you. Some idiot is shooting a shotgun at you and your family. Do you just stand there hoping that the police will arrest the idiot for violating the law or do you try to limit your exposure to this attack? > > While I agree that it is unprofessional for your contact at a provider to > > ignore or be disrespectful of you regarding a DoS against an IRC server, > > it is just a fact of life that attacks against commercial entities will be > > treated with much higher priority than attacks against a non-revenue > > producing "service." Quite frankly, the pizza man comes in WAY above an > > IRC server in my book. > > That's the biggest fscking cop-out I've seen recently. Is profit or > profit-capability the new litmus test for whether or not attacks should be > dealt with or rectified? Let's take efnet as an example. Most of the > efnet servers are hosted by commercial entities. Does it matter less that > the attack is against their IRC server than it would if it were against > their web server? Both are certainly a theft of resources, and you can > certainly put a price on bandwidth consumption. Sir, if you're going to curse at me, at least spell the foul language correctly. As for my opinion being a cop-out, I suppose you're entitled to your opinion. I'll take your EFnet example. Is it a responsible action for these "commercial entities" to exponentially increase the chances of being attacked by hosting an EFnet server? As you have stated, these attacks often cripple their entire network. Is this benefitial to their stockholders? How about to their customers? You see, the vast majority of us are in business to make money. When something that does NOT generate revenue impacts your revenue generating services, it's not a good thing. If running an IRC server was a multi-billion dollar revenue producing venture, you could argue "the lesser of two evils." It is doubtful that you will ever convince me that the PROs of running an IRC service outweigh the CONs. > IRC servers are a benefit of services. If they weren't, then AOL wouldn't > have one. Don't even remind me that aol.com is currently k-lined off most > of efnet, as well as most of the other IRC networks. You picked the wrong company to cite to try to convince me that running an IRC server is wise business practice. I really appreciate all of the "replacement DVD cases" they send me. I enjoy the laughter they bring me when there is a power outage at their Columbus POP. It's cool to see row after row after row of cabinets filles with Total Controls go DARK because they aren't on UPS or 48V DC. You answered your own question as to why they have an IRC server. > I'd love to see someone take this type of case to civil court. I'd be > very interested to see how hard it would be to prove negligence, though I > could imagine it could get complicated if it's a matter of international > law. Give me a break. "Yes your honor. We incurred $200K of extra bandwidth costs as a result of this attack. What? Why didn't we retract the network announcement and try to limit our liability? Duh.... That never occured to us! Um, yes. This is the third time this year that this has happened to us. Why do we still host a server that only generates revenue for the entity who sells us bandwidth? We think it's cool to be able to say that we host one. I suppose it is stupid now that we think about it. Is it possible for us to plead to a lesser charge? Felony Stupidity carries such stiff minimum sentences!" > How many ISP/NSP's do ingress filtering beyond anything other than routing > announcements from their customers/peers and the standard RFC1918 space > and Martian filters? I bet you it's a lot less than those who don't, Um, lets see. If they're filtering out martians and bogons, and only accepting traffic from their customers assigned space, what seems to be the problem? > customers, who's to say they don't just dump traffic on you? I've never > tried it personally, but it seems possible. Really, large NSP's which > should be clue enabled should be the least of our worries. Clueless ISPs/NSPs will continue to be abused in this manner. As for lerge NSPs being the least of your worries, I disagree. Sure, they "should" be clue enabled. The last time I checked, noone was enforcing the "minumum" clue standard though and there are pleanty of entities with big pipe and little clue. > How hard would it be to have a router automatically filter IP packets > heading out an interface if they aren't being advertised via a routing > protocol across that interface or statically routed to the connected > interface? I'm trying to think of an instance where it's desired to not > announce a network, but still forward traffic for it, and I haven't come > up with one yet unless there are specific reasons why asynchronous > routing is desired. It certainly would seem more secure than the way > routers handle traffic now. It is possible to do this now. As for asymetric (I believe that's the word you were grasping for. Don't worry about it. My wife would have made the same mistake.) being routing being desired, in many cased, it IS desired. There are also cases where you are providing transit to a customer who, for whatever reason, is NOT announcing routes to you. > > > > Quite frankly, unless the source of the attack lives on their network, > > they bear no responsibility, period, the end. They're providing > > transit. It's 1's and 0's with no discrimination. > > Please clarify what you mean by 'their network.' It seems that you're > suggesting that if an NSP's customers are spoofing traffic it's not the > NSP's responsibility to do any sort of validation or filtering, since it's > transit of "1's and 0's with no discrimination." That goes against what > you said earlier about ingress filtering, but it's what I'm gathering in > the context of that paragraph. It's late, so I may be misunderstanding > what you're trying to say. > As a NSP, tier 1, whatever you want to call it, many of us sell transit to other transit providers. Filtering based on source/dest IP address does not scale well for either router CPU, config size, or management. You filter end users, not the middlemen. IE; tier 2's filter tier 3's, etc based on source address. Don't get me wrong. We do prefix-list and as-path filter our BGP speaking customers and set up source address filters on static customers border routers. > If you are just talking about Company A's upstream provider not helping > them during an attack, I think it should definitely be a concern if the > victim is a metered service customer. How hard is it for an NSP to route > attack traffic to Null0 on the router they connect to? I'd certailny > stay away from any NSP that chose to ignore me while I'm under attack, but > I find myself auditing large networks these days instead of running them, > so that's probably a non-issue. OK. So, you expect me to accept and possibly pay for traffic that is destined for your network but, instead of passing it to you and billing you for it, I should route it to Null0 and just eat the cost? Sounds like a great deal for you. Not so good a deal for me. > The real problem is that the IPv4 protocol suite as a whole is really, > really, really insecure in a lot of ways, and has outlived it's > usefulness. Even with the security features of IPv6 retrofitted to it, > IPv4 still has lots of issues. It amazes me that companies are actually > relying on public IP services for critical business systems and revenue > generation. If we had packet accountability from end to end then most, if I don't agree that v4 has outlived it's usefullness. v6 has nice features and we do speak v6. v4 still has a lot of kick left in it though. > not all of the network-based DoS attacks of the last 5 years would have > been a non-issue. And tracking down the DDoS kiddies would have been > relatively simple and easy. I'm all for privacy and a certain amount of Is it just me or is it not pretty simple to set up monitoring on your network that would squeal real loud when your bandwidth usage goes outside of it's expected "profile?" We do it. It works very well. When the source of the traffic knows immediately about it, the nasty traffic goes away quicker. > anonymity, but total anonymity seems to turn normal people into crazed > morons who will do things they would not think of doing in the physical > world. I think that's human nature. > > -- > Joseph W. Shaw > Sr. Network Security Specialist for Big Company not to be named because I > don't speak for them here. I have public opinions, and they don't. > --- John Fraizer Head Nerd in Charge EnterZone, Inc And I *do* speak for my company.
|