On Thu, 2 Nov 2000, John Fraizer wrote:
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.
My war is to increase Internet security. It's generally impossible with the current implementation, and I'm not exactly sure how much better IPv6 is going to be if we ever get around to deploying it Internet-wide.
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.
Actually, that's not a bad idea in and of itself if you have the ability to do so. But people generally filter at /19 or /20 advertisements, and what happens when it's more than just some moron taking down an IRC server? What happens when it's a customer doing business that someone has decided to take issue with? What happens when it's a political web site being attacked by someone who does not agree with that point of view? What happens when it's some bored kid who's rooted a couple hundred Solaris or Linux boxes and is using them to take businesses off the net for no particular reason. Retracting routes is a band-aid solution, and in some instances it's certanly workable. But you're entirely fixated on IRC and 'making yourself a target,' which still doesn't fix the problem as a whole. More importantly, having to remove advertised routes for the service effectively accomplishes what the DoS set out to do. The solution is making it virtually impossible for the offensive acts to be carried out.
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?
This is a poor analogy. In Texas, I'm able to carry a concealed weapon because I've got no criminal history, can pass a test that shows I know the state laws concerning concealed carry and gun laws, and can pass another test that shows I can shoot accurately. Furthermore, in your analogy, I would be quite aware of who was attacking me, it would be matter of life and death and not network resources or money, and there would be certain steps I could take to actively defend myself, my family, and anyone else who might be around if the police were not there to handle the situation because of the information in the previous paragraph. I'm not advocating net vigilantism, or vigilantism of any kind for that matter.
Sir, if you're going to curse at me, at least spell the foul language correctly.
Sigh... I can spell. It was intentional. I trust no 'Head Geek' that does not get the reference.
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?
Any Internet connected server can be subjected to DoS attacks. Think E-bay, buy.com, and all the others that were taken down this last February by the new DDoS attacks. Most of those businesses were solely based upon web traffic. I'll admit your argument holds water if we're only talking about IRC servers. But it stops making sense when you refer to any other service.
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.
You don't have to explain money to me. I work for a multi-billion dollar corporation in the top half of the Fortune 50. The bottom line is generally always their primary concern, and for good reason. But, they also take the security of their network and it's resources very seriously. Even with no Return On Investment, they're still willing to spend large sums on security software and hardware.
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.
Me too, actually. If only I could gracefully transition those pesky cardboard cases into them. However, this has absolutely nothing to do with the topic of this discussion.
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?
That would never be asked in a US court of law by a judge, regardless of the fact if it were a mail, web, or any other type of server. Here is why. "Your { web | news | SMTP | POP3 | <INSERT SERVICE HERE>} server was under attack? Why didn't you take it down?" "Because doing so would be a more effective and pervasive denial of service attack than the actual attack they were performing by flooding."
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!"
Why is it more acceptable if they attack an IRC server than if they attack a webserver of a web retailer? So far, your only reasoning has been solely based around money. That's sad, because if it's only money that's driving the ".com economy," then we're all going to be screwed when it's not in anyone's best interest to deal with any other entity unless there's some monetary gain or loss involved.
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?
There isn't one, except the last time I looked, the classic martian filters had nothing to do with customer space. They were strictly blocking 'odd' things to from RFC1918 space, packets with a source or destination of 255.255.255.255 or 0.0.0.0, 127.0.0.1 of improperly configured UNIX hosts, etc. How many of them are actually doing more than this was the question. Furthermore, how many of them are doing it at all? The big guys certainly don't seem to be interested in answering, even though we know they are on the list.
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.
And eventually, someone will take this matter to court. Then we'll see how things play out and if the clue disabled can be forced to act properly if negligence can be proven.
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.)
You are correct, though I wonder what your wife has to do with this. My apologies for using the incorrect term. My intention was not to be vague or misleading, but it was late.
routing being desired, in many cased, it IS desired.
I'm looking for actual examples. If you have some, I'd love to here them. There has only been one time in the past where I actually wanted asymetrical routing, and it certainly took some work to make traffic flow that way. I'm not saying don't allow it to happen, just make it the default not to allow traffic you're not specifically routing.
There are also cases where you are providing transit to a customer who, for whatever reason, is NOT announcing routes to you.
How can you possibly have transit customers who you are not announcing any type of routes for? Has the meaning of a transit network, which transit customers generally buy access to for connectivity, changed? Transit networks used to mean networks used to transit traffic between two other different networks, generally a Tier 2 ISP/NSP. Is this not the case anymore? This would include things like address space that you are advertising as part of a larger aggregate.
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.
If you're a Tier 1, and bandwidth costs you little or nothing, then I certainly do. In your case, I'd expect you to do the same thing with your upstream Tier-1 providers if it were causing a problem with you. In my years or working with various upstreams, some of whom have been swallowed by the Worldcom communications giant or sold off so that Worldcom could buy other parts of the companies, no Tier1 provider I've bought access from has ever had a problem with not charging me for flood traffic. Maybe as a Tier 2 your budget is a bit tighter and your bottom line a bit lower, but unless your upstream is charging you for the bandwidth, and in my experience with what used to be the big 3 (UUNet, MCI, and Sprint) as well as C&W and Savvis, they never did when it was obvious it was a DoS attack, then you shouldn't be charge and you shouldn't charge the victim.
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.
Opinions do vary. While I consider v4 to be functional, I do not consider it adequate, especially when it comes to security. It was not designed with security/accountability in mind. It was designed to be functional first. If it were secure, we wouldn't have many of the problems we're facing today. There are certainly pockets of v6 speakers tunneling over v4, but until v6 is widely deployed and spoken by everyone, it's really not even a concern. But, seeing how most people can't even take basic security measures, moving to an entirely new version of IP could be asking too much.
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.
It's just as easy to protect against letting DoS/spoofing attacks occur. We rate-limit ICMP and certain types of UDP, enable TCP-intercept, utilize process scheduling, apply both egress and ingress compiled ACL's, disable TCP and UDP small-servers, turn off source routing, disable IP directed broadcasts, and other proven methods to pro-actively keep bad things from happening. You know, an ounce of prevention is worth a pound of cure and all that stuff. All this, on top of 24x7x365 manned monitoring of the routers, as well as firewalls and strategically placed network IDS devices. Our abuse notifications are even answered by real people in times of minutes or hours, not days, which so far has been better than any other organization I've had to deal with in hunting down abuse from other networks. If a security notification goes more than a few hours before we investigate it, then managment starts getting notified that we're not doing our job. So far, that's never happened. What's it going to take to get people to cooperate in an effective manner? Even with what some might perceive as rancor or disagreement between you and I, I would certainly handle any security issues from my network with the same urgency as I do with any of the other people or entities I deal with, becuase it's the right thing to do as a responsible Internet entity. You certanly won't get the "Please learn how to read your BlackIce firewall output and understand that 5 UDP packets from a server does not constitute an attack, neither does traceroute" letter, unless that's the information you send me. -- 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.