From: Andrew D Kirch (no email)
Date: Tue Jan 29 2008 - 01:40:30 EST
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
|
|
|