Linux, FreeBSD, Juniper, Cisco / Network security articles and troubleshooting guides

BGP Blackhole (RTBH) with Juniper SRX firewall

How to use your Juniper SRX firewall and BGP RTBH to fight some of the spam/bad traffic

I own a small (free) web/mail hosting solution for personal and close friends' websites. It is unbelievable how much junk even hosting ~10 domains can attract... about 2000 spam emails / week.

Up until recently, big IP blocks (/24) that were used to deliver spam were added to firewall's blacklist security policy. Due to big amount of spam and new IPs, the configuration started to grow and this method passed the scallability point.

Luckily latest version of SpamAssassin with a few tweaks, ClamAV with Sanesecurity Spam signatures + few custom Clamav signatures filter ~99% of the spam for all domains. Based on this result, Dovecot IMAP server will copy them to the administrator (me ) in one big and welcoming mail directory (like a quarantine).

I still believe that most inteligent and expensive method is to allow all traffic and perform layer 7 inspection ( Intrussion prevention, anti-virus scanning, NG firewalls and so on), but SA/ClamAV/SaneSecurity are very efficient (and free) guards.

But what if you think this way: "Most of the IP addresses / subnets that are used to deliver spam are also probably used to flood, scan (VoIP, SSH, Web, ftp) vulnerabilities, bruteforcing, host phishing (fishing) domains and other types of malware traffic ? What if I want to block them dynamically from reaching my network altogether ?"

Since my network is single homed and no BGP peering is required with my ISP, the BGP blackhole community and FlowSpec solutions to stop the traffic in the ISP network is not something that I am looking for.

Blackhole communities are used to export a /32 route (an IP inside your network that is under attack) to the ISP via eBGP with the ISP's blackhole community to avoid paying for DDoS traffic and to decongestion the line. This does not block based on source IP/subnets, but rather on destination.

Flowspec is newer technology. Juniper and other vendors have been supporting it for some time (folks at CloudFlare use it very efficiently) but still is not scalable enough for my needs.

A hybrid BGP Remote Triggered Blackhole solution between the above two is something that I need. RTBH on my network's edge - bad traffic still reaches my network, but I can inject dynamicallly tens of thousands of offending IPs and block them.

This example is based on RFC5635 (http://tools.ietf.org/html/rfc5635#appendix-B), but uses slightly different approach than Unicast Reverse Path Filtering as the SRX firewall has anti-spoofing IP screening feature that can be enabled in a security zone (Checkout "Understanding Juniper SRX security zones": https://www.juniper.net/techpubs/software/junos-security/junos-security10.2/junos-security-swconfig-security/topic-41185.html).

Using IP Spoofing screen over Unicast Reverse Path Filtering has the advantage that it is easier to syslog the offending IPs and see details of the blocked traffic (timestamp, destination IP, source IP). This can also be achieved with uRPF using fail policy, but it is just a little more complex.

Hoow does it work ?
- Extract IP addresses used to deliver spam, sort and prepare.
- Edge SRX firewall is configured for a BGP peering connection not to the ISP, but to an internal PERL script. The SRX firewall is configured to set the next hop of all routes to a Reject (send ICMP Dest NET unreachable) or Discard (drop) next hop. It is also configured to reject internal RFC1918 prefixes and to accept only prefix lengths in the range between /24 and /32.
- The perl script uses Perl's NET::BGP::Update module to inject routes into the SRX. Based on bgpsimple, but altered to inject prefixes dynamically (on reciving SIGINT signal). It is also configured to daemonize.
- When new prefixes are added, they are added into a file and a SIGINT signal is sent to the script's daemon PID (kill -2 <PID of script child/daemon).


This guide starts of with extracting the IP addresses used to deliver spam to the network.

In the Maildir (IMAP mail directory format that, contrary to MBOX, keeps each individual email in a separate file. Advantages and disadvantages...), it is easy to extract the offending IPs using a simple command line (works on Linux and BSD).


Output is masked (last octet removed).

This can be very well altered for different analysis of the offending IPaddresses.

Next part: BGP configuration on edge SRX firewall to peer with the perl script.


Some failsafe measures in the srx firewall:
- accepts only prefix ranges between /24 and /32
- accepts a maximum of 10k prefixes and tears down the BGP session with the script in case this limit is reached ( in Junos this limit is applied to received prefixes, not accepted prefixes)
- authentication would also be good.

The perl script is structured this way:
- trap SIGINT signal and execute a subroutine named "check". When this subroutine is executed it triggers a chain reaction that involves checking a file on disk for new IPs, constructs the BGP update object, moves these new IP addresses to another file (that is loaded at execute time) and empties the old one.

The script is very basic, without prefix validation - which is probably done in Net::BGP::Update module of perl - and it's intended for proof of concept. It is not supported by me, nor my employer.

Defining some of the interesting variables...

Some interesting subroutines


Now, the daemonizing part (it has to run in background)


The script uses fork() to create a child process that does all the work. The parent dies and child is adopted by INIT (basic Unix).

Next, it opens up the BGP connection to the peer (SRX edge firewall) and creates two callback methods that are executed inside the bgp event loop.

First callback, "load_on_execute" injects all the routes from the "bad_routes.txt" file into BGP when the script is initialized (not covered).

The second callback, "on_the_fly", is executed only when $check variable is 1. This variable is enabled when the "check" subroutine is called. The "check" subroutine is called when SIGINT is received.

Next, the callback method checks if the "bad_ips.txt" file size is not zero ( no point in going further, right ?).

It opens the "bad_ips.txt" file for reading, strips new line characters and if the line starts with a dash, it creates a withdraw event. Otherwise, it creates an update one.

At the end, it creates the bgp update object cleans the input file, remembers all new IPs and disables the $check variable. All these are done inside the bgp event loop.

Once the script has been started, let's do some Verification:



Good. I inject another prefix:


Route was added 38 seconds ago.



So for packets coming from the internet, packet is dropped by the anti-spoofing feature. Packets coming from the LAN side towards the blocked IP, are rejected (ICMP type 3) as spoofing is not performed on this side.

Here is a screen syslog message generated by the srx:


On Juniper routing platforms without multi services cards, the anti-spoof feature is not present (it's a firewall feature), but instead the uRPF feature can be used (described in RFC 5635).

Note: Both anti-spoof and unicast Reverse Path Filtering features work on the same routing table as the ingress interface and, to my knowledge, it cannot be changed.

There are beter tools out there (like exaBGP) that are ready to do this job much easier, but for me, this is better learning experience.