North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Government scrutiny is headed our way
> > 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. > I believe RADIUS has a facility for setting ifilt and ofilt based on the particular user based on the Framed-Filter-ID. So, for dynamic users, you could set a filter that allows the Dynamic IP range of that NAS for single-host users. For network users, you could either use blocks like are listed now, or you could set up a filter per user through the choicenet features (Livingston). At the very least, with a rational allocation policy, it should be possible to limit the filters to some subset of Every IP we own. > We do that for all dial and ISDN inbound connections today, and have been > for a long time. > Some people don't. That's the problem. > 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. > Exactly. > 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. > Actually, with Cisco's running the newer Fast Drop code, filtering on a DS-3 is not that big a deal. Especially when you consider that this can be done with a simple access-list. Owen
|