North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: Is it time to abandon bogon prefix filters?
On Fri, 15 Aug 2008 09:49:38 -0400 (EDT) Sean Donelan <sean@xxxxxxxxxxx> 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