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