Worst Offenders/Active Attackers blacklists

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


On Jan 29, 2008, at 3:28 PM, Andrew D Kirch wrote:
> Patrick W. Gilmore wrote:
>> 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.
>>
> I don't disagree with this, but I'm also noting that this is not the  
> universal fix to everything wrong with the internet.  I'll also note  
> that there is in fact no such thing.  You also don't get to  
> discount, and then assault my position without a reasonable position  
> for discounting it.  One packet exploits will compromise the host  
> whether this system is running or not.  This is the case with any  
> security system, as there is no "one size fits all" solution.  So  
> one might say that this system is not intended to deal with such an  
> event, and that there are already methods out there for doing so.   
> Such services should be firewalled off from a majority of the  
> internet (MSSQL, SSH, RPC anyone?).  If you aren't firewalling those  
> services which are notoriously  vulnerable to a one packet  
> compromise, maybe I should suggest that this is the problem, and not  
> the DNSBL based trust system that wasn't designed to stop the  
> attack?   Network security is, as always a practice of defense in  
> depth.

Of course there is no One Final Solution.  However, each solution  
necessarily must be more good than bad.  This solution has _many_ bad  
things, each of which are more bad than the solution is good.

For instance, this creates and instant and trivial vector to DDoS the  
name servers doing the DNSBL hosting.


>> 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.
>>
> I don't have a disagreement here, but zone transfers are easy to set  
> up.

Sure they are, but zone transfers, while not as bad as individual  
lookups, are still a bad idea IMHO.  For instance, are you sure you  
want your dynamic filters 30 or 60 minutes out of date?

BGP was discussed, but such feeds already exist and do not require a  
firewall.


Anyway, as I have said multiple times now, you don't have to believe  
me.  Please, set this up and tell us how it works.  Your real-world  
experience will beat my mailing list post every time.

-- 
TTFN,
patrick



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




More information about the NANOG mailing list