Click here for blacklist information.
A bogon prefix is a route that should never appear in the Internet routing table. A packet routed over the public Internet (not including over VPNs or other tunnels) should never have a source address in a bogon range. These are commonly found as the source addresses of DDoS attacks.
Bogons are defined as Martians (private and reserved addresses defined by RFC 1918, RFC 5735, and RFC 6598) and netblocks that have not been allocated to a regional internet registry (RIR) by the Internet Assigned Numbers Authority.
Fullbogons are a larger set which also includes IP space that has been allocated to an RIR, but not assigned by that RIR to an actual ISP or other end-user. IANA maintains a convenient IPv4 summary page listing allocated and reserved netblocks, and each RIR maintains a list of all prefixes that they have assigned to end-users. Our bogon reference pages include additional links and resources to assist those who wish to properly filter bogon prefixes within their networks.
It is important to realize that the bogon and fullbogon lists are NOT static lists.
IP ranges are regularly added to, and more importantly, removed from the bogon lists. If you filter bogons, please try to make sure that you have a plan for keeping your filters up-to-date, or within a short space of time you will be filtering legitimate traffic and creating work for network administrators everywhere. This is especially true for the fullbogons list, which has significant changes every day.
We have attempted to make the task of maintaining bogon filters simpler for network operators by providing a wide range of formats and methods through which you can receive this data, which are all updated on the same interval, and based on the authoritative sources of the data (the relevant RFCs, the IANA IPv4 allocation list, and RIR data). Changes in all of these sources are constantly monitored and quickly reflected within the documents we provide.
How much does it help to filter the bogons? In one study conducted by Rob Thomas of a frequently attacked site, fully 60% of the naughty packets were obvious bogons (e.g. 127.1.2.3, 0.5.4.3, etc.). A presentation based on that study, entitled "60 Days of Basic Naughtiness," can be viewed here. Your mileage may vary, and you may opt to filter more conservatively or more liberally. As always, you must KNOW YOUR NETWORK to understand the effects of such filtering.
Aggressive ingress and egress filtering is good and wise, but must be maintained. We provide a variety of means to make this maintenance as painless as possible. Please do keep your bogon filters current. The fine folks at the RIPE NCC have a project underway to debogonise new allocations. You can read more about it at http://www.ris.ripe.net/debogon/.
While not all DDoS uses bogons, every little bit helps. Please note that bogon filtering is a component of anti-spoofing filtering, which is also very important. Internet security is all about "the other guy." If one sizeable network is insecure, it WILL be used to abuse other networks. Please help us to secure the edge.
For many years Team Cymru has offered the bogon reference project. This was a list of IPv4 space that is either explicitly reserved by various RFCs for special purposes (the martians) or that has not been allocated by IANA to any of the Regional Internet Registries (RIRs).
With the continued depletion of IPv4 space and the continuing growth of IPv6, we determined that something more enumerative was required. The traditional Team Cymru bogon feed isn't granular enough for the current IPv4 environment, and doesn't have coverage for IPv6.
Enter the fullbogons! Fullbogons begins with the traditional bogon prefixes. We then add the IP space allocated to the RIRs, but not yet assigned by them to ISPs or other end-users. This provides a much more granular and enumerative view of IP space that should not appear on the Internet.
Fullbogons are available for both IPv4 and IPv6. Due to the fragmented nature of IP allocations and assignments, the fullbogons feed is much larger than the traditional bogon feed.
We intend to continue offering both flavors of bogons for the forseeable future - you can choose which is more useful to you and your networks, or perhaps even use both for different purposes - it's up to you! It is important to note that fullbogons change every day, and absolutely must be kept up-to-date, because prefixes are being distributed all the time. If you just download a fullbogons list once and use it to block access to systems, it WILL become out of date very quickly, and you WILL wind up blocking legitimate traffic.
So how does one use the community 65333:888 or 65332:888 prefixes to generate a bogon filter? There are myriad methods, of course. One possible method is to use a route-map and a route with a next-hop of the null0 (Cisco) interface. We have collected examples below from our own experience and from several helpful contributors, which you may view by following the links below.
If none of these methods will work for you then please contact us for assistance. We are also eager to hear your suggestions on other filtering methods!
To peer with the bogon route servers, contact firstname.lastname@example.org. When requesting a peering session, please include the following information in your e-mail:
We will typically provide multiple peering sessions (at least 2) per remote peer for redundancy. If you would like more or less than 2 sessions please note that in your request. We try to respond to new peering requests within one to two business days, but, again, can provide no guarantees for this free service.
Remember that you must be able to accommodate up to 100 prefixes for traditional bogons, and up to 50,000 prefixes for fullbogons, and be capable of multihop peering with a private ASN. If you improperly configure your peering and route all packets destined for bogon addresses to the bogon route-servers, your peering session will be dropped.