Worst Offenders/Active Attackers blacklists

Andrew D Kirch trelane at trelane.net
Tue Jan 29 06:40:30 UTC 2008


Valdis.Kletnieks at vt.edu wrote:
> On Sun, 27 Jan 2008 12:21:27 PST, "Tomas L. Byrnes" said:
>   
>> I'm the CTO and founder of ThreatSTOP (www.threatstop.com), and we're
>> currently propagating the DShield, and some other, block lists for use
>> in firewalls. I'm interested in gathering additional threat information,
>> and serving additional communities.
>>
>> Is there any interest in a collaborative platform where anonymized
>> candidates for blocking would be submitted by a trusted group, and then
>> propagated out to the whole group?
>>     
>
> http://www.ranum.com/security/computer_security/editorials/dumb/
>
> This illustrates dumb idea #2.  Explain to me how you intend to enumerate
> enough of the "bad" hosts out there that such a blocklist would help, while
> still having it small enough that you don't blow out the RAM on whatever
> device you're installing it on.  Have you *tested* whatever iptables/ipf/ACL
> for proper operation with 10 million entries?
>
>   

Why would you need to do this?  There's already proven technology out
there.  Simply write a DNSBL module for iptables. 

1. packet arrives and is forwarded (packets continue to arrive are
forwarded in a default-allow security posture)
2. dnsbl checks are sent, and replies received
3. a entry is added to iptables/acl/ipf and removed based on the DNS
zone's TTL

points against:
yes this generates extra traffic
yes this could be used to make a DDoS attack worse , so I don't think
anyone would argue that this is a good utility to run on a core/edge
router on a large pipe
yes the usual admonitions about dns security apply
yes this creates a race condition to infect machines or do other dirty
deeds before the dnsbl reply comes back, or were you wanting a perfect
solution?

In reality the DNSBL security model has been shown to work in practice
with mail servers around the world.  It's used for billions of e-mail
transactions every day.  Most major e-mail abuse prevention software
that I'm aware of relies to some extent on DNSBL technology, and other
than writing a software package to do it, there's no reason why it
couldn't be done with $FIREWALL_OF_CHOICE.  Further we use a
default-allow security posture to ensure data flow, as this is an
addition to other security measures taken on a given system as part of
best practices.
Also with this method and packages such as cfengine and rsync, updated
lists of questionable hosts connecting to a network can be rapidly
propagated to hosts which have not yet been attacked minimizing the
effect of remote scans/infection attempts against netblocks.


Regardless of the inefficiency, and the fact that there is a race to get
the data back from the DNS server, it's better than what we have now,
which is nothing at all like this.

Andrew



More information about the NANOG mailing list