Do you use let's encrypt?





9561 votes ~ 32 comments

 

Preventing SPAM connections with bird.

Posted by Steve on Fri 22 May 2015 at 07:25

Bird is an Internet routing daemon with full support for all the major routing protocols. It allows you to configure hosts to share routing information, via protocols such as BGP, OSPF, or even statically. Here we're going to look at using it to automatically blacklist traffic from SPAM-sources.

There are many online SPAM-blacklists, and most of them are distributed as DNS-blacklists (DNSBL), such as Spamhaus, allowing your mailserver to answer questions such as the following with a DNS-lookup:

  • Is the IP Address 1.2.3.4 a known-spam source?

Instead of using those we're going to look at using the bgp-spamd.net list. The difference here is that we're being premptive: Hosts on the list will not be able to connect to our server at all - instead of having them connect and start sending SPAM, which we might detect mid-transmission, they'll will never reach us.

To get started you need to install the package:

# apt-get install bird

Depending on your distribution you might find that the configuration file location changes - for wheezy hosts you'll configure the software via /etc/bird.conf, for jessie hosts you'll use /etc/bird/bird.conf.

In either case you can create the following configuration file to test thigns out:

router id 192.168.1.1;      # Change this to your public IP, ideally.

protocol kernel {
    learn;                  # Learn all alien routes from the kernel
    scan time 60;           # Scan kernel routing table every minute
    export all;             # Default is export none
}

# Explicitly blacklisted routes
protocol static {
         route 1.0.1.0/24 drop;
}

With this configuration in place you've defined a static route which will kill traffic to the IP address 1.0.1.0. Specifically this IP is blacklisted because:

  • Traffic from that IP will reach your server.
  • But traffic which should be sent back in reply will never made it, because there is no return-route.
  • This effectively kills the connection.

Now you can (re)start the service:

# service bird stop
# service bird start

And you should see the reoute:

# ip -4 route list
..
blackhole 1.0.1.0/24  proto bird

And attempts to contact that IP address will fail:

# ping 1.0.1.0
connect: Network is unreachable

Using bird like this you can easily blacklist hundreds, or even thousands, of distinct IPs, or netblocks (e.g. 1.2.3.0/24) and startup/load will be low.

What we want to do is to dynamically blacklist IP addresses though, via the BGP feed. If you're not familiar with BGP then you might enjoy reading about it - but for the purposes of this discussion you don't need to understand the detail.

In short Border Gateway Protocol allows routers to share routes with each other, and announce changes as new routes are added/removed. It is a perfect way of configuring dynamic routing between servers, or routers. (For example we've used it in the past to announce where virtual machines are running in a shared environment.)

Update your bird.conf to read like so:

router id 192.168.1.1;      # Change this to your public IP, ideally.

protocol kernel {
    learn;                  # Learn all alien routes from the kernel
    scan time 60;           # Scan kernel routing table every minute
    export all;             # Default is export none
}

filter route_import {
    dest = RTD_BLACKHOLE;
    accept;
}

filter route_export {
    reject;
}

protocol bgp {
    description "bgp-spamd.net - blacklist";
    local as 65332;
    multihop 64;

    # eu.bgp-spamd.net
    neighbor 217.31.80.170 as 65066;

    import filter route_import;
    export filter route_export;
}

Now restarte the service:

# service bird restart

Less than a minute later you should start to see routes:

# ip -4 route list | head -n 10
default via 80.68.84.97 dev eth0
blackhole 1.0.1.0/24  proto bird
blackhole 1.0.2.0/23  proto bird
blackhole 1.0.8.0/21  proto bird
blackhole 1.0.32.0/19  proto bird
blackhole 1.0.128.0/17  proto bird
blackhole 1.1.0.0/24  proto bird
blackhole 1.1.2.0/23  proto bird
blackhole 1.1.4.0/22  proto bird
blackhole 1.1.8.0/21  proto bird

At the moment I'm seeing about 60,000 routes:

# ip -4 route list | wc -l
62199

If you're familiar with BGP you can tweak the configuration to your liking, but the above settings should be robust and reliable. Just remember that now IPs which are listed in the black list cannot :

  • Send you email, if it is hosted on this machine.
  • Access your websites.
  • Access other things on your server.

One neat thing about this approach is that it can be used to protect whole network segments. In my case I run this on a virtual machine host - which means that the virtual machines it launches are protected, since the server is their gateway.

 

 


Re: Preventing SPAM connections with bird.
Posted by tpreissler (82.9.xx.xx) on Sat 23 May 2015 at 19:12
Brilliant. Many thanks for this article. Finally a reason to learn more about BGP... hehe.

This only works with latest "bird" from Jessie, or alternatively with wheezy backports version 1.4.5-1~bpo70+1.
Or it will complain about the line:

dest = RTD_BLACKHOLE;

I am having a minor issue with this setup in general:

May 23 19:10:33 preisaa1 bird: KRT: Received route 0.0.0.0/0 with unknown ifindex 3
May 23 19:10:33 preisaa1 bird: KRT: Received route $DEFGW/32 with unknown ifindex 3

Any ideas?


Cheers

Thomas

[ Parent | Reply to this comment ]

Re: Preventing SPAM connections with bird.
Posted by Steve (90.201.xx.xx) on Mon 25 May 2015 at 06:51
[ View Steve's Scratchpad | View Weblogs ]

I'm afraid I have nothing useful to add, I've not seen those kind of warnings in my own setup. I know that you can lines such as these to log more:

# Configure logging
log syslog { debug, trace, info, remote, warning, error, auth, fatal, bug };
log stderr all;
log "/var/log/bird.log" all;

That said I have a sneaking suspicion what you're seeing logged is the routes that are already present when you launch - i.e. your default route not added by bird, or the BGP setup. If that is the case then the error/warning can be ignored. --
Steve

[ Parent | Reply to this comment ]

Re: Preventing SPAM connections with bird.
Posted by ajt (79.77.xx.xx) on Fri 5 Jun 2015 at 19:56
[ View Weblogs ]

Wow, that looks really clever and dead simple. I'll have to give that a try when I upgrade my server next - I'll wait until it's running Jessie first.

--
"It's Not Magic, It's Work"
Adam

[ Parent | Reply to this comment ]

Re: Preventing SPAM connections with bird.
Posted by Steve (90.201.xx.xx) on Fri 5 Jun 2015 at 20:56
[ View Steve's Scratchpad | View Weblogs ]

I guess the risk is always, like all blacklists, that you get cut off from folk you don't expect. Specifically I've seen that @orange.net, and @gmx.net are now unreachable email domains for me.

In practice not a concern, but ..

--
Steve

[ Parent | Reply to this comment ]

Re: Preventing SPAM connections with bird.
Posted by ajt (79.77.xx.xx) on Fri 5 Jun 2015 at 21:10
[ View Weblogs ]

I know what you mean, I've blocked friends & family who use very spammy web mail in the past. They insist on using Hotmail or Yahoo! and wonder why people don't respond no matter how many times I've advised them not to send spammy emails...!

--
"It's Not Magic, It's Work"
Adam

[ Parent | Reply to this comment ]

Re: Preventing SPAM connections with bird.
Posted by Anonymous (85.93.xx.xx) on Thu 30 Jul 2015 at 23:03

It’s a pity that 1.0.1.0/24 is an actual, real prefix that’s been assigned to China Telecom. We’d be better off using an RFC 1918 subnet here.

[ Parent | Reply to this comment ]

Re: Preventing SPAM connections with bird.
Posted by Anonymous (77.12.xx.xx) on Thu 5 Jan 2017 at 18:10
Hi, I'm the author and maintainer of bgp-spamd.

There is a major problem with the recipe that is provided for users. You are blackholing all IPs listed, but I provide both a whitelist *and* a blacklist in the feed. You'll need to check for community 65066:666 for blacklisted entries. Obviously, blackholing the semi-trusted email servers isn't what you want to do.

Additionally, I strongly recommend NOT blackholing IPs on the blacklist. You prevent admins from being able to detect failures, and falsely present to them that you are offline. This is important when the sending system is a normal email server, their marketing department gets some shady list of "customers" to email, and then their CEO wants to email your CEO. Just imagine the conversations that can happen at that point :).

Thanks for the recommendations for the project!

-peter

[ Parent | Reply to this comment ]