Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

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?

  • From: Christopher L. Morrow
  • Date: Sat Jan 18 15:53:15 2003

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: ''
> > > 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

> 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: 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

> 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.

Discussion Communities

About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home

Merit Network, Inc.