Assuming you’ve followed my spam-fighting adventures, you’ll know that I have a fairly successful installation of Neal Horman’s spamilter running in a FreeBSD jail, and his ipfwmtad daemon running on the jail’s host. Meaning the ipfw rules being added by ipfwmtad are done on a server different from where spamilter is running.
Along with all of that, you’ll recall that I finally moved my router to FreeBSD. It turns out, I had an eeeevil plan in mind when I was doing all of that work. This blog entry won’t be terribly long because it should hopefully be an easy leap to make for the reader.
Remote IPFWMTAD
Now that my router is running FreeBSD, why not move the ipfwmtad process to it? There’s really no down side to it at all. I followed the exact process that I had on joker and riddler when I moved spamilter to the jail. I snagged a copy of Neal’s code, then built it and installed it on the router. Once done, I added a new file on the router called /usr/local/etc/spamilter/ipfwmtad.acl:
allow | 127.0.0.1/32 |
allow | ::1/128 |
allow | [riddler's IPv4]/32 |
allow | [riddler's IPv6]/128 |
That will allow riddler‘s spamilter to talk to ipfwmtad on the router. I then copied the same /usr/local/etc/rc.d/ipfwmtad rc script that I wrote from joker over to the router.
Finally, in the router’s /etc/rc.conf:
# Firewall ... ipfw for use with spamilter
firewall_enable="YES"
firewall_type="open"
# Spamilter - specifically the ipfwmtad part
spamilter_enable="NO"
ipfwmtad_enable="YES"
ipfwmtad_flags="-I [router's IPv4]"
By default, ipfwmtad wants to listen on 127.0.0.1. The -I flag tells it which IP to use instead. Once that was done, from the router’s CLI:
service ipfw start
service ipfwmtad start
At this point, I had an open IPFW running on the router, and the ipfwmtad daemon waiting for spamilter to contact it to start feeding it bad IPs to block. However, like with joker, I had to add a new user to the router’s /etc/passwd file. This user just needs a password to authenticate with. A nonexistent home directory and shell are recommended as it will never actually be logged in. I won’t document how I did that, as adding new users to /etc/passwd should be something any systems administrator can do in his or her sleep. Right?
Right.
Aiming Spamilter at the Router
The last change was just as simple. Since I used the same username and password for ipfwmtad’s authentication, all I needed to do was change the IpfwHost line in riddler‘s /usr/local/etc/spamilter/spamilter.conf:
IpfwHost = [router's IPv4]
And from riddler‘s CLI:
service spamilter stop ; service spamilter start
And from that point on, riddler was feeding the router IP addresses of bad MTAs which needed to be blocked:
lateapex-gw# ipfw list 90 | wc -l
325
How Useful is This?
It’s fair to ask, “How useful is this?” Arguably, in my small 1-MTA setup, it’s probably not that useful. There’s no real reason why the router needs to block incoming port 25 connections from spammers for 1 single MTA. The MTA can do that itself.
What about a network of MTAs? Or several networks of MTAs? If those networks all used the same FreeBSD (or Linux) router as their gateway, then you could imagine spamilter running on each of them, and they all report back to the router’s centralized ipfwmtad to block bad MTAs. In other words: distribute the data collection (your MTAs) but centralize the management point (the router).
Good idea?
