On Wed, 1 Nov 2000, John Fraizer wrote:
On Thu, 2 Nov 2000, Ariel Biener wrote:
As most of you know, some ISPs run irc servers, and provide an IRC service to the community. The service is free, and maintenance and cost of networking/hardware/human hours is on the ISPs expense.
This begs to question: Why do they still do it? (Put the targets....er IRC servers on their networks?)
Where should they put them? You also have to take into account, a large 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.
The problem is that when trying to get help from the upstream provider (UUnet in this example), you either receive a negative answer, or you're just ignored completely. Thus, by terrorism, people get what they want, and hold you at a threat of force, without any ability to defend yourself.
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. 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. 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.
Smurfing, icmp attacks, udp attacks, tcp synflooding (spoofed sources) are just a number of these weapons. The problem with alot of networking entities, be it ISPs, enterprises, and such, is that they allow spoofed packets to leave their network (i.e. do not check if the packets originate from within their netblocks before letting them leave their routers).
Filtering scales best to ingress vs egress. I agree that filtering should be in place. "Sanity checking" traffic from your downstream customers is a lot smarter than simply hoping they're cluefull enough to block bogons leaving their network though.
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, considering the amount of clue available to the internet connected companies. Furthermore, if you don't specifically ingress filter your 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. 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.
The question is, how can we defend ourselves, and why do the large NSPs turn a blind eye, and act as if it's not their concern ?
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. 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.
Now, in specific response to your question about eliminating electronic terrorism, it is doubtful. Doubtful that you'll ever: #1 spread enough clue around. #2 get everyone to cooperate.
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 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 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. -- 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.