Valdis.Kletnieks@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