North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Worst Offenders/Active Attackers blacklists
[email protected] 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
|