Worst Offenders/Active Attackers blacklists

Patrick W. Gilmore patrick at ianai.net
Tue Jan 29 15:02:20 UTC 2008


On Jan 29, 2008, at 9:43 AM, Jim Popovitch wrote:
> On Jan 29, 2008 12:58 AM, Patrick W. Gilmore <patrick at ianai.net>  
> wrote:
>> 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.
>
> Andrew, IIUC, suggested that the default would be to allow while the
> check was performed.

I read that, but discounted it.  There has been more than one single- 
packet compromise in the past.  Not really a good idea to let packets  
through for a while, _then_ decide to stop them.  Kinda closing the  
bard door after yada yada yada.

Perhaps combine the two?  Have a stateful firewall which also checks  
DNSBLs?  I can see why that would be attractive to someone, but still  
not a good idea.  Not to mention no DNSBL operator would let any  
reasonably sized network query them for every new source address - the  
load would squash the name servers.

As I mentioned, zone transfer the DNSBL and check against that might  
add a modicum of usefulness, but still has lots of bad side effects.

Then again, what do I know?  Please implement this in production and  
show me I'm wrong.  I smell a huge business opportunity if you can get  
it to work!

-- 
TTFN,
patrick




More information about the NANOG mailing list