Consolidated Blackhole BGP Communities
Prefixes listed by 65532:666
What is the CBBC ?
The CBBC is a BGP Real-Time, source address based, Black Hole feed (RTBH). I started this project in 2010.
Historically, the feed blacklists 30,000 to 50,000 prefixes at any given time, with occasional peaks over 100,000.
I have subscribers in the US, France, Israel, and India.
What is BGP ?
If you don't know, you are not ready for this page.
Who can use the CBBC ?
Anyone with a BGP-capable router. Tested successfully so far : Cisco,VyOS, Palo Alto, Bird, Mikrotik. Expected to be compatible : Juniper, FRR, Force10.
Who else provides BGP RTBH feeds ?
I receive the fullbogons: https://team-cymru.com/community-services/bogon-reference/bogon-reference-bgp/
I receive the BCL : https://www.spamhaus.org/bgpf/
Based on destination IP address :
https://team-cymru.com/community-services/utrs/
Note that these are NOT directly redistributed in the CBBC; their prefixes are no-export, if you want their feeds you need to peer with these organizations.
Prefixes listed by 65532:666
Prefixes blocked by list fetching
uRPF drops in 5 minutes, single IP, Xfinity residential
uRPF drops in 5 minutes, single IP, Comcast Business.
Who wrote the CBBC ?
Michel Py wrote the original implementation. The code currently running was written by Jeremy Beker : https://github.com/jbeker/blocklist
Another major component of the CBBC is Thomas Mangin's Exabgp : https://github.com/Exa-Networks/exabgp
Do I need a big, beefy router ?
No, you do not need a BFR. I feed the CBBC to my home router, a Cisco 1841 with 384 Megs of RAM. 50,000 prefixes take about 80 MBytes of RAM on that platform, not much these days. Older BFRs with limited TCAM may be more problematic than software-based routers. That being said, if you receive full-feeds and your router is limited to 1 million routes, CBBC may become the straw that will break the camel's back soon.
Do I need a public ASN ?
No. If you already are using a private ASN and it is not in use already by any of the CBBC participants, you can keep using it to peer. If you don't have an ASN, I will assign a private one to you.
Do I need to be multi-homed ?
No. I do however recommend that, if you are multi-homed, you do not accept the default route from transit providers. If you get a full-feed, my recommendation is ip route 0.0.0.0 0.0.0.0 null0. Rationale : if a prefix does not come into your feed and if it is indeed legitimate, it will be fixed quickly. In the rare cases of single-homed with a full-feed, I recommend the same. If you get a full-feed, do run in the real DFZ mode : no default route. There has been a recent twist with this : I am about to replace the faithful Cisco ISR 1841 with a newer ISR 4321, that comes with 8GB and can easily handle a full BGP feed. I am now running one of the home sites in real DFZ mode : no default route.
Is the CBBC a read-only feed, or can I inject my prefixes in it, too ?
It depends on the story you tell me. The very nature of this is that I am interested in getting and redistributing someone else's blackhole, if I trust it; there are no set rules so far. Anyone gets the read-only feed for free (as of it does not turn into a full-time job); anyone with a good story gets the read-write feed for free, but he story has to be good.
Are 32-bit ASNs supported ?
Yes, both private and public. However, 32-bit ASN holders who would request a read-write feed have to understand that the BGP communities in the generally accepted new format have remained a 32-bit number, therefore the old ways of ASN:666 are not available to them.
What are the CBBC design goals ?
-Increase distribution speed my moving from a pull mechanism to a real-time peering mechanism.
- Reduce firewall log volume by blocking the traffic before it hits the firewall (especially with uRPF).
- Increase network security by blocking all traffic to blackholed prefixes, and possibly from blackholed prefixes. Read the uRPF section.
What are the differences between the CBBC feed and firewall rules ?
- Speed. The CBBC feed is a real-time feed. As soon as a change is known, it will be propagated to the peers within seconds.
- Brutality : unlike firewall rules, the CBBC feed does not discriminate and/or block based on content / ports / etc. Logic : if a botnet host is compromised with malware, the attack pattern will change at the will of the C&C master much faster than the host's IP address changes (and therefore firewall rules are updated). Erring on the side of safety, it is prudent to blackhole the IP address itself, versus being finicky about the specifics of the attack it's going to play next.
How do I get the CBBC feed ?
email michel at arneill-py dot sacramento dot ca dot us
Who should use the CBBC feed ?
As originally designed, end-networks, as opposed to transit providers. Lately though, some mid-size ISPs have starting to use the CBBC. It is up to the network administrators who have final decision on who to block to make the call. It works good for my users and my customers. The CBBC is designed to be used at the edge between a private network (possibly a multihomed one) and their ISP(s), although recent developments have shown that ISPs who implement it have not suffered consequences from doing so.
Do I need to implement uRPF ?
No, but you might as well. Read the section about DDOS below, too.
Here his my personal opinion: if you are peering in an IX, uRPF (BCP38) can be a pain. Been there done that, the CBBC is not a debate about why or not BCP38 is or is not being implemented. If you are a transit provider peering in an IX, the CBBC is probably not for you and I understand why you would not implement uRPF too.
If you are an end-network, implementing uRPF can be good. An end-network multihomed to a small number of upstreams is a good candidate to implement uRPF in loose mode. On a single-homed network, uRPF is a no-brainer. I have uRPF on my home aDSL.
Is the CBBC useful even if I don't implement uRPF ?
Yes it is. With or without uRPF, the hosts on your network will not be able to talk to the blacklisted prefixes, because the egress trafic will die in the blackhole in your router.
What uRPF brings you on top of blackholing is : if the malicious trafic originated from the outside, it will not even reach your inside host. Without uRPF, your host may receive the original packet/datagram, and attempt to reply to it.
Routing to a blackhole blocks traffic to the blackholed prefixes. Using uRPF blocks traffic from the blackholed prefixes.
How does one's IP address get on the CBBC feed ?
- More than 80% of the CBBC feed is based on publicly available blacklists.
- Another 20% comes from trusted peers.
- A few come from automated syslog events.
- The hand-picked ones that we as humans manually label as a nuisance are on the feed, too.
- I do understand the concept of a joe-job; in theory, it is possible than a crafted attack on one of my probes could lead to me manually blacklisting the IP. In practice, it still has to be seen.
How do I know if my IP address is listed in the CBBC ?
If you can read this, your address is not listed. A lookup tool is on my to-do list. There's a catch : you won't be able to access it if you are blacklisted.
Where is the CBBC getting its data from ?
About 20% of the CBBC comes from direct, selected participants who share their honeypots and sensors.
About 80% of the CBBC comes from these lists:
[This list is not final]
http://hosts-file.net/rss.asp
https://sslbl.abuse.ch/blacklist/sslipblacklist.csv
http://www.openbl.org/lists/base_1days.txt
http://cinsscore.com/list/ci-badguys.txt
http://www.autoshun.org/files/shunlist.csv
https://www.myip.ms/files/blacklist/csf/latest_blacklist.txt
http://www.spamhaus.org/drop/drop.lasso
http://www.spamhaus.org/drop/edrop.lasso
http://danger.rulez.sk/projects/bruteforceblocker/blist.php
http://rules.emergingthreats.net/blockrules/compromised-ips.txt
http://rules.emergingthreats.net/blockrules/emerging-botcc.excluded
http://rules.emergingthreats.net/blockrules/emerging-botcc.portgrouped.rules
http://rules.emergingthreats.net/blockrules/emerging-botcc.rules
http://rules.emergingthreats.net/blockrules/emerging-ciarmy.rules
http://rules.emergingthreats.net/blockrules/emerging-compromised-BLOCK.rules
http://rules.emergingthreats.net/blockrules/emerging-compromised.rules
http://rules.emergingthreats.net/blockrules/emerging-drop-BLOCK.rules
http://rules.emergingthreats.net/blockrules/emerging-drop.rules
http://rules.emergingthreats.net/blockrules/emerging-dshield-BLOCK.rules
http://rules.emergingthreats.net/blockrules/emerging-dshield.rules
http://rules.emergingthreats.net/blockrules/emerging-rbn-BLOCK.rules
http://rules.emergingthreats.net/blockrules/emerging-rbn-malvertisers-BLOCK.rules
http://rules.emergingthreats.net/blockrules/emerging-rbn-malvertisers.rules
http://rules.emergingthreats.net/blockrules/emerging-rbn.rules
http://rules.emergingthreats.net/blockrules/emerging-tor-BLOCK.rules
http://rules.emergingthreats.net/blockrules/emerging-tor.rules
http://lists.blocklist.de/lists/all.txt
Can I use only parts of the CBBC ?
Yes, when the feature is ready (it's not yet). You can choose to receive only a subset of the CBBC by accepting only certain communities. The part of the CBBC that comes from connected participants comes with an additional community in addition to 65532:666.
Can I whilelist some IP addresses ?
Yes and it is prudent to do so. This is done entirely in your router, though. If more than the basic setup is required, CBBC peers are required to have understanding on how BGP works and how to configure route-maps and prefix-lists. Whitelisting your routing core and your upstreams is a good idea ;-) It has happened a few times in the 10 years that I have been operating the CBBC that a single /32 address has been blacklisted, mostly for good reasons, but nevertheless being the dynamic IP of a big cheese customer, so DO get ready to implement whitelists in your setup. On a Cisco platform, that would be a low-number deny in the route-map. See sample config.
Is the CBBC feeding single IP (/32) or entire blocks ?
Both. Here is a sample distribution of the feed : (sample taken January 18, 2022)
Total prefixes blocked : 50852
Number of /8 : 1
Number of /9 : 0
Number of /10 : 1
Number of /11 : 0
Number of /12 : 5
Number of /13 : 2
Number of /14 : 10
Number of /15 : 17
Number of /16 : 200
Number of /17 : 17
Number of /18 : 118
Number of /19 : 102
Number of /20 : 144
Number of /21 : 118
Number of /22 : 945
Number of /23 : 351
Number of /24 : 793
Number of /25 : 0
Number of /26 : 2
Number of /27 : 8
Number of /28 : 21
Number of /29 : 37
Number of /30 : 112
Number of /31 : 608
Number of /32 : 47240
+-------+----------------+
| Pref | Country |
+-------+----------------+
| 20838 | United States |
| 19120 | China |
| 4946 | Russia |
| 3618 | Germany |
| 3268 | Brazil |
| 2942 | India |
| 2940 | United Kingdom |
| 2890 | South Korea |
| 2844 | France |
| 2674 | Netherlands |
+-------+----------------+
+------+---------------------------------------------------+
| Pref | ASN |
+------+---------------------------------------------------+
| 4805 | DIGITALOCEAN-ASN |
| 2449 | Shenzhen Tencent Computer Systems Company Limited |
| 2265 | Unknown |
| 2018 | Hangzhou Alibaba Advertising Co.,Ltd. |
| 1707 | Chinanet |
| 1133 | COMCAST-7922 |
| 1040 | OVH SAS |
| 960 | CHINA UNICOM China169 Backbone |
| 874 | Tencent Building, Kejizhongyi Avenue |
| 759 | MICROSOFT-CORP-MSN-AS-BLOCK |
+------+---------------------------------------------------+
It is up to you to filter or not prefixes shorter than /32
Some disclaimer
Please note : what is just above is one sample taken one day; it is not statiscally significant. That being said, the top of the offending ASNs does not change that much. I have a day job working for one of the biggest cloud services providers; interesting enough, I am more involved in the core routing and switching datacenter ops rather than the peering / backbone ops, so as of today (February 2022) the CBBC still remains a completely independant operation from my big employer.
My ISP accepts a Black Hole BGP community; can redistribute the CBBC for that purpose ?
No. Although it is not technically forbidden to redistribute the CBBC feed, feeding it back to your ISPs as RTBH is not a good idea until I get to talk to their lead BGP / Peering engineer. There are plenty of valid reasons your ISPs will not take the raw CBBC feed as a Black Hole feed. If you do not add the no-export community to the CBBC feed, and / or you do modify the CBBC communities and leak them to match your upstream's BH requirements, and if by doing do your upstream de-peers you, you have been warned.
We had a (brief) BGP leak of the CBBC already. To protect the guilty I will not provide details (it was not me :P) but I can tell this much : the volume of hate email was high.
I have to withstand DDOS attacks all the time, can the CBBC feed help ?
It depends on the type of attack; the CBBC feed is not designed as DDOS mitigation tool. There is no such thing as a free lunch : your ISP will not take the full CBBC feed for free when they can make you pay big bucks for their own one or the one they resell. The CBBC does not prevent the DDOS attack to get to you, it may help with attacks that are based on PPS, not raw bandwidth. What the CBBC does is to block the offending traffic at the router level, so it is blocked before it even reaches your server / firewall. However, the CBBC does not prevent the DDOS traffic from coming to you, so if you have a slow connection to the Internet and the DDOS sends more bandwidth than you have, you still are down. However, if the DDOS is based not on bandwidth but on a higher-level protocol such as DNS or HTTPS or NTP, it may help by taking the load off the servers, especially if you implement uRPF.
On a side note : what about attacks based on spoofed IP addresses ?
The CBBC by itself will not do much about these. It is much better to have a good bogon feed and not to have a default route.
Does the CBBC list spam-sending prefixes ?
Not on purpose; some may be listed because they otherwise partake in malicious activity. The CBBC will not do much to curb spam; it is not part of the design. I have not observed significant spam decrease.
The CBBC feed is blocking me, how so ?
I am not blocking you. If you are being blocked by the CBBC feed, it's because either your network administrator or the network administrator of the host you are trying to communicate with or someone else in the middle has made the deliberate decision of peering to get the CBBC feed. This is not an automated process : someone has to email me, we have to chit-chat. I don't control who in the path of the Internet blocks you, I don't know why, and I don't care either. More than 80% of the CBBC feed is a consolidation of other blacklists publicly available on the Internet.
# CBBC Cisco template
# Replace the following strings with appropriate info.
# <Your_AS>
# <YourRouterIP>
# <BGP_Password>
# <YourSubnetMask>
# <YourDefaultGateway>
router bgp <Your_AS>
bgp router-id <YourRouterIP>
bgp log-neighbor-changes
neighbor 173.166.233.21 remote-as 65532
neighbor 173.166.233.21 description CBBC
neighbor 173.166.233.21 ebgp-multihop 255
neighbor 173.166.233.21 password <BGP_Password>
address-family ipv4
neighbor 173.166.233.21 activate
neighbor 173.166.233.21 prefix-list PL-NONE out
neighbor 173.166.233.21 prefix-list PL-GE10 in
neighbor 173.166.233.21 route-map RM-CBBC-IN in
neighbor 173.166.233.21 maximum-prefix 200000
ip bgp-community new-format
ip community-list standard COMM-CBBC permit 65532:666
ip prefix-list PL-GE10 description longer or equal to 10 and whitelist
ip prefix-list PL-GE10 seq 5 deny 8.8.8.8/32
ip prefix-list PL-GE10 seq 10 deny 8.8.4.4/32
ip prefix-list PL-GE10 seq 15 deny 208.67.222.222/32
ip prefix-list PL-GE10 seq 20 deny 208.67.220.220/32
ip prefix-list PL-GE10 seq 9999 permit 0.0.0.0/0 ge 10
ip prefix-list PL-NONE seq 5 deny 0.0.0.0/0 le 32
route-map RM-CBBC-IN permit 10
description Blackhole list learned from CBBC route-servers
match community COMM-CBBC
set community no-export additive
set ip next-hop 192.0.2.1
ip route 192.0.2.1 255.255.255.255 Null0 name BLACKHOLE
# If not getting full feed (typical of single-home with default route).
# Sometimes eBGP session will not come up without it.
ip route 173.166.233.21 255.255.255.255 <YourDefaultGateway> name CBBC
ip access-list extended OUTSIDE-IN
remark +------------------------------------------------+
remark | Ingress access-list for the outside interface. |
remark +=-----------------------------------------------+
remark your stuff
remark +----------------+
remark | eBGP for CBBC. |
remark +=---------------+
permit tcp host <YourRouterIP> host 173.166.233.21 eq bgp
permit tcp host <YourRouterIP> eq bgp host 173.166.233.21
remark
# Tested
# URPF, if not getting full feed (typical of single-homed with default route). Strict with allow-default.
# interface TerabitEthernet 0/0/0
# description to the Internet
# ip address <YourRouterIP> <YourSubnetMask>
ip verify unicast source reachable-via rx allow-default
# TESTED
# URPF, full feed with default route (typical of multi-homed). Loose with allow-default.
# interface TerabitEthernet 0/0/0
# description to the Internet
# ip address <YourRouterIP> <YourSubnetMask>
ip verify unicast source reachable-via any allow-default
# TESTED
# URPF, full feed with no default (typical of tier-1 or tier-2). Loose.
# interface TerabitEthernet 0/0/0
# description to the Internet
# ip address <YourRouterIP> <YourSubnetMask>
ip verify unicast source reachable-via any
# CBBC VYOS template
# Provided by David Ponzone
# Replace the following strings with appropriate info.
# <Your_AS>
# <YourRouterIP>
set protocols bgp <Your_AS> neighbor 173.166.233.21 description 'michel@arneill-py.sacramento.ca.us'
set protocols bgp <Your_AS> neighbor 173.166.233.21 ebgp-multihop '255'
set protocols bgp <Your_AS> neighbor 173.166.233.21 maximum-prefix '160000'
set protocols bgp <Your_AS> neighbor 173.166.233.21 prefix-list export 'EXPORT-NONE'
set protocols bgp <Your_AS> neighbor 173.166.233.21 prefix-list import 'NO-BLACKHOLE'
set protocols bgp <Your_AS> neighbor 173.166.233.21 remote-as '65532'
set protocols bgp <Your_AS> neighbor 173.166.233.21 route-map import 'BLACKHOLE'
set protocols bgp <Your_AS> neighbor 173.166.233.21 soft-reconfiguration 'inbound'
set protocols bgp <Your_AS> neighbor 173.166.233.21 update-source '<YourRouterIP>'
set policy prefix-list EXPORT-NONE rule 1 action 'deny'
set policy prefix-list EXPORT-NONE rule 1 prefix '0.0.0.0/0'
set policy prefix-list NO-BLACKHOLE description 'No blackhole on prefixes larger than /12'
set policy prefix-list NO-BLACKHOLE rule 100 action 'permit'
set policy prefix-list NO-BLACKHOLE rule 100 ge '12'
set policy prefix-list NO-BLACKHOLE rule 100 prefix '0.0.0.0/0'
set policy route-map BLACKHOLE description 'IPv4 filter crap learned from eBGP peers'
set policy route-map BLACKHOLE rule 1 action 'permit'
set policy route-map BLACKHOLE rule 1 match community community-list '1'
set policy route-map BLACKHOLE rule 1 set ip-next-hop '192.0.2.1'
set policy route-map BLACKHOLE rule 1 set local-preference '200'
set policy route-map BLACKHOLE rule 1 set tag '65535'
set policy community-list 1 rule 1 action 'permit'
set policy community-list 1 rule 1 regex '65532:666'