Re: SpamHaus Drop List

23 Aug 2007

      sean@donelan.com (Sean Donelan) writes:
...
...
...
I'm glad to listen opinions or experience.
no false positives yet.  mostly seems to drop inbound tcp/53.
Waving a dead chicken over your computer will have no false positives too.
whoa -- that wasn't called for.
...
Is it a placebo or does it actually have an effect?
the inbound tcp/53 i see blocked by SH-DROP isn't the result of truncation
or any other response of mine that could reasonably trigger TCP retry.  so
on the basis that it's no longer reaching me and can't have been for my
good, SH-DROP has at least that good effect.  i also see a lot of nameserver
transaction timeouts in my own logs, and it's all (*ALL*) for garbage domains
such as much be used by phishers or spammers.  so i'm getting failures in my
SMTP logs (because i've got postfix wired up to "high paranoia" and if it
can't resolve the HELO name or if the A/PTR doesn't match, i bounce stuff.)
but even if i weren't bouncing more stuff, or bouncing it earlier (since most
of what i'm bouncing is also listed on various blackhole lists), the fact of
me not making DNS queries about these malicious domain names means i'm denying
criminals a potentially valuable (if they know how to use it) source of
telemetry about their spam runs.  so, no placebos here.
...
Although very little good or bad will come from those networks, just like
the various BOGON lists, the Spamhause DROP list does require
maintenance.  If you don't have a process in place to maintain it even
after you are gone, proceed with caution.
why would i install something that required manual maintainance or depended
on me still being present?  other than putting system level logic in my home
directory, i detect no sysadmin sin here.  take a look, tell me your thoughts.

here is the root crontab entry i'm using on my freebsd firewall:

14 * * * * /home/vixie/spamhaus-drop/cronrun.sh

here is the full text of that shell script:

#!/bin/sh -x
cd ~vixie/spamhaus-drop
rm -f drop.txt.new
fetch -o drop.txt.new http://www.spamhaus.org/drop/drop.lasso && {
        [ -r drop.txt ] || touch drop.txt
        cmp -s drop.txt drop.txt.new || {
                ./ipfw-merge.pl 29 < drop.txt.new | /sbin/ipfw /dev/stdin
                mv drop.txt.new drop.txt
        }
}
exit 0

the "ipfw-merge.pl" perl script is just:

#!/usr/bin/perl
# august 17, 2007
use strict;
use warnings;
my ($tblno) = @ARGV;
die "usage: $0 tblno" unless defined $tblno && $tblno;
# load in the existing table
my %old = ();
open("ipfw", "ipfw table $tblno list |") || die "ipfw: $!";
while (<ipfw>) {
        chop;
        my @ary = split;
        $_ = $ary[$[];
        next unless length;
        $old{$_} = '';
}
close("ipfw");
# use mark and sweep to compute differences
my $now = time;
while (<STDIN>) {
        chop;
        s/\;.*//o; s/\s+//go;
        next unless length;
        if (defined $old{$_}) {
                delete $old{$_};
        } else {
                print "table $tblno add $_ $now\n";
        }
}
my ($key, $val);
while (($key, $val) = each %old) {
        print "table $tblno delete $key\n";
}
exit 0;

(note, i've squished out vertical whitespace to make cut/paste easier, at
the expense of readability.  sorry i still write in perl3, old habits die
hard.)

here is the relevant component of my ipfw rule file.

add deny log all from table(29) to any
add deny log all from any to table(29)
...
If you do have a process in place, not only for routing but also for
your new customer order process, it is a useful source of information.
agreed.
-- 
Paul Vixie