|
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, dies wrote: Still, the basic rules of connecting to a network provider should be implemented correctly (if you can come close to eliminating spoofed attacks - identifying where an attack comes from becomes alot easier, don't you agree ?). My goal was not just to mutter. I thank UUnet for providing the details, and I will make sure these phone numbers are properly used. My goal was to create a framework that will define how to properly define your networking equipment when you connect to a NSP, and what the NSPs should do in order to protect themselves and their customers. As I said, there are experienced and knowledgeable people on this list. I am anticipating your responses, and insights. thanks, --Ariel > > > I agree that getting help from Tier1/2 NSPs is not a outlandish > request/idea.However, in my personal experience UUNet has been the most > responsive out of all the Tier-1 NSPs (Assuming they are contacted > correctly).Tracking the attack, however, is not always a trivial > task.If you are a large NSP like UUNet, Sprint, and C&W, where your > backbone spans multiple POPs or even countries with their own POPs it is > time consuming and you run a real risk of crashing transit routers if the > flood isheavy (read high packets per second).At that point the question > becomes, "Is it worth tracing an attack on a shell server/irc > server?"I'm not trying to say running an IRC server or shell server is > wrong, however, some (if not most) NSPs/ISPs consider them attractive > nuisances. > > This topic is continously covered (as you can tell) so I'm not > sure where to go from here.I've been looking into starting a BGP speaker > that announces the top 4000 smurf amplifiers from my list and the top 2000 > from netscan, which in turn can be pushed to null0 or discard.This would > prevent one from actually attacking from a network participating in this > BGP session.I've tested it and it's working on a couple smaller ISPs as > we speak.My major problem is getting some Tier-1's to go for > it...Anyways I guess larger attacks than last Feb. will have to happen to > get something done?Let's hope not... > > > On Fri, 3 Nov 2000, Ariel Biener wrote: > > > On Thu, 2 Nov 2000, dies wrote: > > > > > > > > Actually, I was thinking of taking a slightly different path. > > > > > > 1). ISPs (downstreams) responsibilities: > > > > 1a). Active and clueful NOC. > > 1b). Proper implementation of Internet RFCs (private networks and > > spoofing). > > 1c). Proper BGP filtering towards upstream. > > 1d). Running routing software adequate to today's challenges (for example, > > something that can deal properly with small fragments...). > > > > 2). NSPs (upstreams, tier1/2) responsibilities: > > > > 2a). Active and clueful abuse department. > > 2b). Monitoring tools that will allow tracking down a stream throghout > > their own backbone, and cooperation with their peers to get to the > > source. With a handful of cluefull people, and a set of autmatic > > tools, this IMHO is something at hand. > > 2c). Proper BGP filtering of their customers, to not allow their customers > > to fuck-up Internet routing (Sprintlink incidents...). > > > > > > The main idea is that downstreams make sure they are not very susceptable > > to abuse. Then, if attacked, the upstream provider should cooperate in > > detecting the source, by monitoring their own network, and cooperating > > with it's peers. If for any reason, it takes more than X hours, the > > upstream provider should try toprotect it's customers. Usually, it wont, > > and the attacker will be indentified, and shut down at it's source. > > > > There is no requirement that tier1/2 NSPs tie up their equipment into an > > ACL monster. What is needed is cooperation. With proper cooperation, > > identifying a stream's source is much easier that you may think. > > > > Do you find the above so hard to do ?All it requires is some > > professional attitude, and a bit more cooperation and consideration from > > NSPs and ISPs as one, what happens to someone you don't know today may > > happen to you tomorrow ! > > > > > > Thoughts ? > > > > --Ariel > > > > > Well since everyone else is stating their opinions, I'll join in > > > as well.First off I think pulling the plug is a great idea ( =] ). > > > Anyways the point comes down to this.Who should be doing the ingress > > > filtering?Tier-2's, Tier-1's, the actual customer?I know this whole > > > idea sounds very pretty and nice, however, when it comes down to it there > > > are many real problems with this idea.One, the hardware on most ISP's > > > backbones cannot realistically do ingress filtering.I'm sorry to say but > > > a GSR is not able to do ingress filtering on 5 Channelized OC-12's that > > > hold 400+ Customers a piece.It just does not work, I don't care what > > > Cisco claims, it just does not work.What about other vendors?I have no > > > experience with Bay or Lucent, however, Juniper (which I do have > > > experience with) has the ability due to the hardware based filtering > > > available but that brings up a whole set of other questions.How will > > > ingress filtering from an ISP level effect downstream customers that do > > > asymmetrical routing?How about the management overhead that comes into > > > play when you are a Tier-1 or a large Tier-2 with tens of thousands of > > > customers?What is comes down to is that customers need to be doing > > > egress filtering, it's the only scalable solution, however this just is > > > not happening.Don't blame the ISPs only, it's their customers that are > > > really the problem.Lack of security/knowledge on the customer's end > > > leads to hacked boxes, which in turn lead to DoS attacks.It really comes > > > down to not the responsibility of the ISP, but in fact the responsibility > > > of the customers!Maybe we all should thinkg about that before we point > > > fingers. > > > > > > > > > > > > On Thu, 2 Nov 2000 [email protected] wrote: > > > > > > > On Thu, 02 Nov 2000 09:59:04 EST, MarkMentovai <[email protected]>said: > > > > > This can'tgo on forever.I'd like to spread the clue about ingress > > > > > filtering, and am willing to commit time to the cause.Is anyone with me? > > > > > > > > The problem is that for many ISPs, I fear the only way to get them to > > > > implement 2827-style filtering is for their upstreams to implement a > > > > policy of fascist-mode ingress filtering - "We see a bogon packet that > > > > your site should have filtered, we pull the plug on your link till you > > > > fix it". > > > > > > > > Time alone won't be enough.Bring a baseball bat.And a spare bat. > > > > > > > > -- > > > > Valdis Kletnieks > > > > Operating Systems Analyst > > > > Virginia Tech > > > > > > > > > > > > > > > > > > > > > > -- > > Ariel Biener > > e-mail: [email protected] Work phone: 03-6406086 > > fingerprint = 07 D1 E5 3E EF 6D E5 82 0B E9 21 D4 3C 7D 8B BC > > > > > > -- Ariel Biener e-mail: [email protected] Work phone: 03-6406086 fingerprint = 07 D1 E5 3E EF 6D E5 82 0B E9 21 D4 3C 7D 8B BC
|