Is it time to abandon bogon prefix filters?
Steven M. Bellovin
smb at cs.columbia.edu
Fri Aug 15 14:41:22 UTC 2008
On Fri, 15 Aug 2008 09:49:38 -0400 (EDT)
Sean Donelan <sean at donelan.com> wrote:
> On Fri, 15 Aug 2008, Randy Bush wrote:
> > my read is that the 60% was an alleged 60% of attacks came from
> > *all* bogon space. this now seems in the low single digit
> > percentge. of that, the majority is from 1918 space.
>
> Although I've disagreed with Rob about the configuration of bogon
> filters, especially on unmanaged (or semi-managed) routers, it is
> important to remember attacks and bogus packets are not naturally
> occuring phenomenon. The attacker chooses the attack vector and
> target, usually based on effectiveness and vulnerability but often on
> ease for the attacker.
>
> Packet and especially source address hygiene can be very useful for
> highly managed equipement. However, bogon filters have often become
> more a source of recurring security consultant maintenance revenue
> than effective packet controls. Understanding the operational
> maintenance demands is also an important part of implementing good
> security controls.
>
> For unmanaged and semi-managed routers, I'd suggest strict out-bound
> packet controls (i.e. be conservative in what you send) because you
> already need to make operational updates when they change. But
> consider using inbound controls that require less extensive recurring
> maintenance, e.g. only filtering martians (i.e. 0/8, 127/8,
> 255.255.255.255/32, etc) instead of updating bogons (i.e. changing
> reserved and unallocated) every few months.
>
Martians plus 1918 space, I'd say, though that requires knowing which
are border interfaces.
Other than that, I agree 100% -- bogon filters have little security
relevance for most sites. Furthermore, as the allocated address space
increases, the percentage of actual bogon space decreases and the rate
of false positives -- packets that are rejected that shouldn't be --
will increase. Security? Remember that availability is a security
issue, too.
--Steve Bellovin, http://www.cs.columbia.edu/~smb
More information about the NANOG
mailing list