On Aug 23, Paul Vixie <paul@vix.com> wrote:

...

Does anyone use spamhaus drop list ? http://www.spamhaus.org/drop/index.lasso i do. Me too, since a couple of years. I do not have any negative issues to report and I encourage everybody who cares about their customers to filter the routes listed in DROP.

...

I'm glad to listen opinions or experience. no false positives yet. mostly seems to drop inbound tcp/53. I know that DROP blocks some name servers used by pharming gangs. E.g.: http://isc.sans.org/diary.html?storyid=1872 http://isc.sans.org/diary.html?storyid=997

A customer of mine found out that he was infected by this malware when he noticed that he could not resolve anymore his web sites hosted on my network. My authoritative name servers are protected by DROP and the recursive name servers configured by the malware (85.255.116.20 and others in that /20) were not able to reach them. -- ciao, Marco

I hope this mail does not go out twice. Accidently used the wrong mailer. Sean Donelan wrote:

On Thu, 23 Aug 2007, Paul Vixie wrote:

...

...

Does anyone use spamhaus drop list ? http://www.spamhaus.org/drop/index.lasso

i do.

...

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.

Is it a placebo or does it actually have an effect?

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.

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.

I had to get rid of some people who notoriously brought my exim down. Here is my personal list: 212.22.0.0 * 255.255.255.0 U 0 0 0 eth0 218.174.212.0 * 255.255.255.0 U 0 0 0 eth0 218.167.73.0 * 255.255.255.0 U 0 0 0 eth0 62.227.222.0 * 255.255.255.0 U 0 0 0 eth0 219.91.64.0 * 255.255.255.0 U 0 0 0 eth0 219.91.92.0 * 255.255.255.0 U 0 0 0 eth0 122.116.17.0 * 255.255.255.0 U 0 0 0 eth0 Dont copy it without knowing what you are doing. I did not mind losing something. I lost all spammers using my system as a relay. I did not find any of my routes in the DROP list. No good for me. I remember friends telling me they got rid of SpamHaus because it killed too many legal emails - but that was not the DROP list. My router keeps telling me - the more routes, the slower it gets. I guess with 120 routes it gets slowly enough for all spammers to time out :) Remember the US is a republic. The UK is an old-fashioned monarchy and their legal system might not be compatible with what you expect :) Kind regards Peter and Karin -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Rimbacher Strasse 16 D-69509 Moerlenbach-Bonsweiher +49(6209)795-816 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: peter@echnaton.serveftp.com mail: peter@peter-dambier.de http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ http://www.cesidianroot.com/

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

sean@donelan.com (Sean Donelan) writes:

Unfortunately, on today's Internet if you randomly picked a couple of hundred network blocks of the same size you would see the same thing.

no. really. just not. you'd have to search nonrandomly among thousands or tens of thousands of netblocks to equal the russian business network.

Lame delegations and brokeness is well distributed across the Internet.

that's not the kind of maliciousness i'm interested in avoiding.

Unfortunately again, if you use your favorite search engine you will find several instances that read something like "we also have the DROP list in an ACL on our router, but we don't monitor it." I have found two year old copies of the DROP list in networks.

that's an argument for not statically importing policy.

Network blocks are regularly added *AND REMOVED* from the Spamhaus DROP list.

and that's another. nobody here is claiming that external policy should be "fired and forgot." in fact, cymru's BOGON list comes with lots of disclaimers about how much pain your successors will be in if you import these things and forget them.

It can be useful if used correctly, it can be harmful if used incorrectly.

like anything else. remember, all power tools can kill. that's an argument for using them correctly, more than it's an argument for living without them. -- Paul Vixie

On 24 Aug 2007, at 01:49, Derek wrote:

hjan wrote:

...

Does anyone use spamhaus drop list ? http://www.spamhaus.org/drop/index.lasso

I'm glad to listen opinions or experience.

Regards, Gianluca

My experience is not specific to the DROP list but regarding the RBL/Zen service I have found the 'moderators' of the lists can abuse their power and unable to provide any proof to their entries.

A quick search in our removals archive brings up the particular listing Derek's experience relates to: SBL53319 In April Derek was hosted on Intercage (aka Atrivo, aka US-based home of malware, DNS exploits, malware C&Cs and botnet spam cannons). Intercage/Atrivo is a /20 used predominantly by serious crime gangs from the Ukraine and Russia, the /20 is firewalled to hell and back by those who know about it. Amongst all the East European cyber-crime gangs stuffed into that /20 there's the rare legitimate customer like Derek dotted about here and there, they can be counted literally on one hand. In contacting our team about the SBL listing, Derek googled a bit for "Spamhaus" and read a posting by a ROKSO spammer claiming we were child molesters, nazis and members of the KKK, and unfortunately Derek fully believed it, so he contacted our removals team from that perspective... Advisably not the best way to have a constructive dialogue with our team. SBL Removals declined to provide Derek with proof of the cyber-crimes being committed by the gangs on Intercage, since Derek did not provide his FBI badge number. With over 100 SBL listings all for malware, botnet C&Cs, phishing and carding cyber-crime, as well as being closely connected with RBN (Russian Business Network), Intercage (216.255.176.0/20) is indeed currently on the SBL and is in our DROP list: http://www.spamhaus.org/sbl/sbl.lasso?query=SBL53319

But when your on the wrong side of the fence it is very annoying, if one of the moderators has a beef with your provider - look out!

Derek

In this particular case, I think it's fair to say that Spamhaus "has a beef" with Derek's provider. So do all of the internet's security firms. Steve Linford The Spamhaus Project http://www.spamhaus.org