Consolidated  Blackhole  BGP  Communities

Prefixes listed by 65532:666


What is the CBBC ?
The CBBC is a BGP Real-Time Black Hole feed (RTBH).

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 and VyOS. Expected to be compatible : Juniper, Quagga, BIRD, Mikrotik, Force10.

Who else provides BGP RTBH feeds ?
I receive the fullbogons: http://www.team-cymru.org/bogon-reference-bgp.html
I receive the BCL : https://www.spamhaus.org/bgpf/
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.

Who wrote the  CBBC ?
Michel Py wrote the original implementation. The code currently running was written by Jeremy Beker : https://github.com/jbeker/blocklist

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. 50K 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.

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. Actually, being multi-homed and adding CBBC to your setup is something not to be taken lightly, just because of the sheer volume of the feed and its lack of technical maturity. Being able to handle 50K extra prefixes flapping twice a day on top of having multiple full-feeds is a technical requirement. If you are currently multi-homed and do not understand the ramifications of what 50K flapping prefixes can do to your routers and your TCAM, do not put it in production. Being multi-homed is both a curse and a blessing at the same time. The CBBC still is in the experimental stage; I will gladly enternain feed requests for experimental purposes, if I can learn something about the experiment.

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 peering mechanism.
- Reduce firewall log volume by blocking the traffic before it hits the firewall.
- 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 ?
End-networks, as opposed to transit providers. 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).

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 99% of the CBBC feed is based on publicly available blacklists.
- 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 ?
[This list is not final - March 2016]
More than 99% of the CBBC comes from these lists:
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.

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 ;-)

Is the CBBC feeding single IP (/32) or entire blocks ?
Both. Here is a sample distribution of the feed :
/10: 1
/12: 3
/14: 10
/15: 13
/16: 178
/17: 24
/18: 52
/19: 80
/20: 94
/21: 59
/22: 117
/23: 47
/24: 317
/32: 45546
Prefixes : 46,541. Total IP count : 26,401,002.
It is up to you to filter or not prefixes shorter than /32

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. 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, it helps by taking the load off the server.

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 99% 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 64.113.127.228 remote-as 65532
neighbor 64.113.127.228 description CBBC
neighbor 64.113.127.228 ebgp-multihop 255
neighbor 64.113.127.228 password <BGP_Password>

address-family ipv4
neighbor 64.113.127.228 activate
neighbor 64.113.127.228 prefix-list PL-NONE out
neighbor 64.113.127.228 prefix-list PL-GE10 in
neighbor 64.113.127.228 route-map RM-CBBC-IN in
neighbor 64.113.127.228 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 64.113.127.228 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 64.113.127.228 eq bgp
permit tcp host <YourRouterIP> eq bgp host 64.113.127.228
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 access-group OUTSIDE-IN in
ip verify unicast source reachable-via rx allow-default

# NOT 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 access-group OUTSIDE-IN in
ip verify unicast source reachable-via any allow-default

# NOT 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 access-group OUTSIDE-IN in
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 64.113.127.228 description 'michel@arneill-py.sacramento.ca.us'
set protocols bgp <Your_AS> neighbor 64.113.127.228 ebgp-multihop '255'
set protocols bgp <Your_AS> neighbor 64.113.127.228 maximum-prefix '160000'
set protocols bgp <Your_AS> neighbor 64.113.127.228 prefix-list export 'EXPORT-NONE'
set protocols bgp <Your_AS> neighbor 64.113.127.228 prefix-list import 'NO-BLACKHOLE'
set protocols bgp <Your_AS> neighbor 64.113.127.228 remote-as '65532'
set protocols bgp <Your_AS> neighbor 64.113.127.228 route-map import 'BLACKHOLE'
set protocols bgp <Your_AS> neighbor 64.113.127.228 soft-reconfiguration 'inbound'
set protocols bgp <Your_AS> neighbor 64.113.127.228 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'