|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: FW: Re: Is there a line of defense against Distributed Reflectiveattacks?
On Sat, 18 Jan 2003, Daniel Senie wrote: > At 09:29 PM 1/17/2003, Christopher L. Morrow wrote: > >On Fri, 17 Jan 2003, Stewart, William C (Bill), RTLSL wrote: > > > > > > > > > > > > > > -----Original Message----- > > > From: Stewart, William C (Bill), RTLSL > > > Sent: Friday, January 17, 2003 5:35 PM > > > To: '[email protected]' > > > Subject: Re: Is there a line of defense against Distributed Reflective > > > attacks? > > > > > > > > > Many of these attacks can be mitigated by ISPs that do > > > anti-spoofing filtering on input - only accepting packets from user ports > > > >Sure, but this is a proven non-scalable solution. HOWEVER, filtering as > >close to the end host is scalable and feasible... do it there, it makes > >MUCH more sense to do it there. > > Well, let's see... on dialup circuits it should be done and should be a > no-brainer. After all, ISPs are required (by UUNet at least) to push in > filters to ensure dialup users can only reach port 25 of that ISPs mail > servers and be blocked from all other spots. How hard is it to push in one > more filter that checks the source IP address of the dialup user to ensure > the address coming from the user is the one assigned? Sure, dialups are a fixable problem, and mostly they are fixed... and.... most dialups are platforms that can't readily spoof so the threat level is low. I'd point out one thing though, for larger dial platform providers the decision to put filters on the radius users isn't under their direct control... They may mandate to the people that lease the service from them the requirement for radius profile filters, but the implementation is solely up to the leasee. Most times its also not implemented until the next contract cycle ;( Anyway, you are correct, this is a fairly easy win, provided the dial platform can support the filtering on hundreds of ppp connections. (I don't have any good or bad data on this so I know not the scaling issues here) > > Sure, dialups are not the only problem, but it's an example of blocking > close (very close) to the edge. > > Each time an ISP sells a T1 with a router and assigns a block of addresses, > there's an opportunity to configure that router with filters > (ingress/egress depending on which side you look at it from) and at least > simple firewalling rules. Is this an expense to the installing ISP, or a > cost savings in not having to deal with attacks that came from that network This is certainly true, UUNET has been doing this for some time now... (+1.5 years I believe?) Unfortunately, many of the larger providers only manage a small number of their customer's CPE, this means the config is subject to change immediately on arrival at customer site :( I'd note that UUNET also went through some pain to push CPE configs with 'good' passwds for telnet and enable, now there are tens (perhaps hundreds) of CPE routers with 'cisco' as the vty passwd... Don't customers' care about security? This is the issue, there aren't enough people with 'constant vigilance' about security, Convenience is always more important :( Never mind that their CPE device is now being used to DoS several hosts on the internet and their link charges are showing that each month... that cost isn't enough for them to change their ways. > later? Even when a customer provides the CPE, providing sample > configurations really costs little and would help. In many cases, the > vendor supplying that T1 is one of the same companies which also handles > the "core" so it's REALLY in their best interest to take little steps to > protect their edges (hard to point fingers from the core and say "it's the > edge vendor's problem" when you're also the edge vendor in some cases). > Ok, so here we get to the meat of my arguement. The end user needs to filter, they know best what/where/how their network is used. The 'core' provider simply knows that there are 6 /24's and a /23 routed to the T1 in question. The filtering can be MUCH more effective at the end user site, where each ether interface can include a simple 1 line acl that fixes the problems of spoofing. There was some chatter at NANOG in Oregon last October about some 'default' settings on interfaces for 'small' routers that would accomplish this task. I believe it was 'turn on uRPF strict for all small platform routers' and make it a simple 'no uRPF' to turn it off. Barry Greene or the other Cisco fellow in the back of the room should recall more precisely, eh? This seems like a great first step, keeping in mind that its a year or more to roll that out, atleast its a start :) > While it's nice that router vendors implemented unicast RPF to make > configuration in some cases easier, using simple ACLs isn't necessarily > hard at the edges either. This completely depends on the part of the edge you run... ask Ebay how it is to filter on their Gig ports facing their servers, or Microsoft on their 10Gig interfaces... acls suck when packet rates increase, uRPF is a win here since it is just a FIB lookup, not a acl processing task. (Yes, 10Gig ints likely have acls in asics, but point is fib lookups win.) > > The stumbling block for ingress filtering has always been pretty simple: By > implementing ingress, the network you save will be someone else's. You have > to trust that other network operators will implement ingress filtering and > in so doing save your network. Sadly, folks tend to avoid doing things that > might help others, and so I continue to wait for a negligence lawsuit to > wake folks up on this issue. > Actually, the stumbling block has been getting end users to do it... the core is just not the place to do this, too complex to do and not enough granularity at that level. > Eliminating spoofed addresses from the backbone, even if it were possible > to do 100%, would not eliminate denial of service attacks. The DDoS attacks This was precisely the point of Mr. Gill from AOL at the aforementioned NANOG meeting, I believe his quote goes something like: "The ip address used for the attack is orthogonal to the problem..." To me this makes perfect sense... People really do get stuck on the red herring of 'stopping all spoofing'. That isn't the problem, as you say below here its trivial to use owned hosts by the thousands to attack with unspoofed addresses... Rob Thomas has some good data on attacks against IRC servers and other hosts on the internet, his data last I recall was something like 80% of attacks use spoofed addresses, though more and more his tracked attacks are showing from non-spoofed hosts. He can certainly jump in and correct me though :) I can speak authoritatively from the network I work on's perspective on this issue, more and more we have seen non-spoofed attacks. There are still plenty of spoofed attacks, but frankly we prefer that as its MUCH easier to track and stop. For those that wonder 'how would you track that? It's spoofed!' please visit: http://www.secsup.org and read the provided links... its simple, free, proven, tested and used everyday by atleast UUNET and I believe Sprint? If you have an upstream you should push them to implement these things also so you can be protected and get resolution faster... or like I said, switch to a provider that DOES these things and HAS a security crew on staff 24/7. Its in your best interest if you think you might be a target. > using coordinated "owned" machines demonstrates this. As spoofing becomes > more difficult, tracing back the source of attacks becomes easier. Network > operators will still find machines on their networks performing attacks, > but when that phone call comes from another network with attack details, > the chances of finding the offending host are much greater. >
|