Government scrutiny is headed our way

Wed Jun 17 13:58:37 UTC 1998

On Wed, Jun 17, 1998 at 12:45:07AM -0400, Jon Lewis wrote:
> On Tue, 16 Jun 1998, Karl Denninger wrote:
> 
> > We're looking into implementing filtering on ALL ingress paths, including
> > dedicated line, as soon as we can come up with a tool to manage it
> > automatically.  The dial side is trivial and as such I can't understand
> > how ANYONE can have an excuse for not doing that - at this point.
> 
> For those who don't bother filtering "because it's too hard or too
> complicated", if you don't want or can't afford to put the work into tight
> ingress filtering on all interfaces, it's really easy to just say "our IP
> blocks are A, B, and C.  Allow input with source addresses in A, B, or C,
> deny everything else."  That will at least protect the rest of the
> internet from your lusers.

Right.  That's what we do on the dial plant today, because there isn't a
syntax available on our RAS hardware which says "allow anything with this
RADIUS assigned or dynamic address block (depending on the account) and deny
everything else".  So we have to relax the filters to be "allow anything from
netblocks A, B, and C, block everything else" since the syntax we really
want isn't available.  

We do that for all dial and ISDN inbound connections today, and have been 
for a long time.

Still, that's good enough.  You can't launch a DOS attack against ANOTHER
provider from our plant this way.  We also have directed broadcasts shut
off network-wide, so attempts to bounce pingstorms off our internal plant 
(even to internal targets) don't work either.

That's the 95th percentile solution, and is a hell of a lot more than most
other ISPs do.  Most don't do ANY filtering of any kind.  I've tested this
against accounts on other providers, and most will happily forward packets
with ANY source address from dial customers.

Add throw-away accounts to that and you've just created the existing monster
called "The Smurf".  Wow, I wonder how that happened?

> On IOS, aren't packets going through ip access-group filters (that don't
> do logging) fast switched as of some point in 11.2?  If ingress filtering
> no longer has to put a huge burdon on router CPUs, it would be nice to see
> ingress filtering on the routers backbone providers talk to customers
> with.  Don't tell me it's too much of an administrative problem.  None of
> my current backbone providers will listen to BGP advertisements that
> haven't been arranged in advance (either by email or phone).  If I can't
> advertise the space, why should I be allowed to spoof source addresses
> from it?

We've yet to have trouble traced to any of our dedicated line customers. If
we had, we'd have implemented the filtering a LONG time ago, administrative
pain in the ass or not!

We HAVE had the alarms go off for packets which were spoofed from dial
customers (and were blocked by the filters).  That's a great way to get 
your account whacked around here (get caught attempting to launch a DOS
attack at someone)

Our approach on the dial plant is simple - if its not from one of our
netblocks, it doesn't go out - period.  Now you can still spoof, but
only an address that is local to us (and thus can be traced completely
on a local basis)

If your dial plant is all dynamic address (ours is mixed) then the filters 
can be a lot tighter - if its not in the pool for that RAS device, it gets 
bounced.

ALL RAS devices in common use today (ie: Lucent, ASCEND, CISCO, etc) have
this capability, and virtually all previous-generation ones (ie: Netblazers)
can do this as well.  And if you're unlucky enough to have something that
can't, you can STILL do the same filtering at the boundary between the RAS 
and the rest of your network (like the CISCO that feeds the plant that your
RAS boxes sit on).

There simply is no excuse for not doing ingres filtering for dial customers
in today's environment.  The bitrates are low enough and the RAS boxes good
enough that claims that "I don't have the CPU for it" are plain bullshit,
even on last-generation hardware (ie: Netblazers).

I understand the CPU problems filtering ingress on a DS-3 to a customer, 
for example, if the box has a bunch of other interfaces.  But in that case 
you should insist (contractually) that the *CUSTOMER* router have the 
filters on ITS interface which talks to you, and TEST it from time to time.

--
-- 
Karl Denninger (karl at MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin
http://www.mcs.net/          | T1's from $600 monthly / All Lines K56Flex/DOV
			     | NEW! Corporate ISDN Prices dropped by up to 50%!
Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS
Fax:   [+1 312 803-4929]     | *SPAMBLOCK* Technology now included at no cost