Worst Offenders/Active Attackers blacklists

Patrick W. Gilmore patrick at ianai.net
Tue Jan 29 06:58:49 UTC 2008


> 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.

No, it is not.

A general purpose host or firewall is NOTHING like a mail server.   
There is no race condition in a mail server, because the server simply  
waits until the DNS query is returned.  No user is watching the mail  
queue, if mail is delayed by 1/10 of a second, or even many seconds,  
nothing happens.

Now magine every web page you visit is suddenly paused by 100ms, or  
1000ms, or multiple seconds?  Imagine that times 100s or 1000s of  
users.  Imagine what your call center would look like the day after  
you implemented it.  (Hint: Something like a smoking crater.)

There might be ways around this (e.g. zone transfer / bulk load), but  
it is still not a good idea.

Of course I could be wrong.  You shouldn't trust me on this, you  
should try it in production.  Let us know how it works out.

-- 
TTFN,
patrick


On Jan 29, 2008, at 1:40 AM, Andrew D Kirch wrote:

>
> 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