Worst Offenders/Active Attackers blacklists

Mailman List Mirror (Read Only)
1

There are a number of public network attacker threat feeds available, the most well know of which, AFAIK, is the Internet Storm Center’s DShield system. I know a few network operators, including at least one on this list, also run private versions of the DShield system.

Are there many others?

Do any or most network operators have some sort of private current block list that gets pushed out to routers and or firewalls/traffic shapers in real time?

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?

I’d be happy to collect responses anonymously and submit a summary back to the list, if people don’t want to open this up on the list.

2

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?

3

My suggestion would be not even to try iptables. It'll take hours just
to load 10 million entries. There's no efficient mass loading interface.

-J

From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf

Of

Valdis.Kletnieks@vt.edu
Sent: Monday, January 28, 2008 4:23 PM
To: Tomas L. Byrnes
Cc: nanog@nanog.org
Subject: Re: Worst Offenders/Active Attackers blacklists

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

4

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

5

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.

No, it is not.

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.

6

Andrew, IIUC, suggested that the default would be to allow while the
check was performed.

-Jim P.

7

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!

8

Hi,

Is not the other danger that any anti Dos measure is likely to fail
unless unified over a significant % of the Internet / AS numbers to
block to the BotNet client machines at source within their home AS.

Once the army has been amassed and escaped their home ASes they can
launch an attack against any target or bit of infrastructure that is
proving effective or annoying in the disruption of the cyber criminal's
commercial activities.

Or, to ask the question another way, would the low % of infrastructure
backbone attacks increase if the infrastructure started blocking
effectively attacks rather than completing them through null routing the
target. If the commercial $ are being paid to the ISP to prevent DoS
surely the ISP then becomes an extortion target as well rather than just
the end customer site.

In a way its a bit similar to a protection racket in that as long as the
ISP completes attacks rather than blocks them it is in the attackers
interests to leave the infrastructure alone to a large degree.

Anything less than a solution that sorts the BotNet problem at source AS
will end up being like King Canute against a monster Hawaiian style wave
of vengeful packets. And consequently the ISPs are faced with little
alternative than to go along with the status quo than stick their head
above the parapet and end up on the receiving end.

Black hole routing easy & effective, source identification / traffic
scrubbing expensive.

Thoughts?

Ben

9

Patrick W. Gilmore wrote:

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.

If you want the sort of performance you expect from your firewall now
your going to have to evaluate the source on the basis of locally
available information.

bgp based blocklist would be a more sensible approach than an dnsbl.
Then it's a question of how many blackhole prefixs you're willing to
carry in your firewall's table...

10

Date: Tue, 29 Jan 2008 10:02:20 -0500
From: Patrick W. Gilmore

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.

(Apologies for straying from ops into R&D-ish stuff.)

True. IMNSHO, lookups would need to be instantaneous. Kind of like...
routing. The RIB presumably is a very sparse array. What's needed is a
FIB capable of approximately 2^24 routes, yet with only two
destinations: "pass" and "drop".

A naive approach would be a simple sorted array of 2^24 entries.
Assuming IPv4, that's a 64 MB lookup table that can be searched using
good old binary search. Take this as a starting point for something
that definitely is possible.

Said sorted array contains much redundancy. One can do _much_ better
than a primitive sorted array. Uh, the more back-of-the-envelope
calculations I run, the more I believe this is entirely doable.

I'd need to dust off some code I wrote a while back, but I consider
150-clock IPv4 lookups reasonable. IPv6 would be slower by a factor of
four. (Predictions based on profiling performed on Pentium4-targetted
assembly code custom-written for a similar purpose.)

Note that the above is slightly optimistic. It does not account for
blowing out the TLB on every lookup. I'd need to review/profile that
penalty.

RAM use would be the biggest obstacle.

Eddy

11

Or, to ask the question another way, would the low % of infrastructure
backbone attacks increase if the infrastructure started blocking
effectively attacks rather than completing them through null routing the
target. If the commercial $ are being paid to the ISP to prevent DoS

So first off you might consider where the 'null route' is applied, in
which cases it's used vs other sorts of techniques. There are many,
many cases everyday of things that get null routed due to them being a
destination of a DoS/DDoS attack. In those cases almost always it's a
completely useless thing that the end user doesn't even care about, so
just stopping the flood is more important than any other solution.

The cases of larger/more-important things being attacked get handled
in other, more complex, ways. (acls, mitigation
platforms/scrubbers/etc)

surely the ISP then becomes an extortion target as well rather than just
the end customer site.

no, not really, sometimes the upstream devices get packet-love, but
that's not difficult to fix either... who needs their internal
infrastructure reachable by the external world?

See work on infrastructure acls by: james gill @vzb + darrel lewis @
cisco + paul quinn @ cisco + barry greene @ cisco +.... new book by
Greg Schudel @ cisco ->

<http://www.ciscopress.com/bookstore/product.asp?isbn=1587053365>

note that I haven't looked at the book but it seems to cover some of this.

In a way its a bit similar to a protection racket in that as long as the
ISP completes attacks rather than blocks them it is in the attackers
interests to leave the infrastructure alone to a large degree.

or it's in their interest because their monetary flow comes across
those same pipes.... so turning off the intertubes is contrary to
their goals. (see presentations by Team Cymru on this topic actually)

Black hole routing easy & effective, source identification / traffic
scrubbing expensive.

The distinction between blackhole-routing and scrubbing that you draw
is overly simplistic, if you are a UUNET/VerizonBusiness customer (or
sprint or ATT though I can't easily find their links...)

<http://www.verizonbusiness.com/products/security/managed/#services-dos>

yours for the low-low price of 3250/month... which is well worth it if
you have an ecommerce site that of any decent revenue draw... The
folks at UUNET/VZB will even do things aside from NullRoute if you
have issues and are their customer, all you have to do is call and ask
them for assistance when problems arise, some of that is described at:

<http://www.verizonbusiness.com/terms/us/products/internet/sla/>

(I had to google search this, vz's website isn't so helpful on finding
information....)

-Chris

12

Patrick W. Gilmore 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.

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.

13

Patrick W. Gilmore 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.

14

Date: Tue, 29 Jan 2008 15:50:50 -0500
From: Patrick W. Gilmore

[Z]one 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?

As opposed to infinitely out-of-date (i.e., no filters)? Don't get me
wrong; I'm none too keen on using DNS to distribute IP ACLs. I just am
nitpicking that one particular point.

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

IMHO, this is better than anything DNS-based. Using zone transfers is
like using RIP. *shudder*

Eddy

15

Frequently, yes. FPs can be more dangerous than FNs. Depends on your network, clients, etc.

And that's just the first reason that came to mind. There are plenty of others.

Or maybe not. Prove me wrong!

16

Date: Tue, 29 Jan 2008 16:39:14 -0500
From: Patrick W. Gilmore

[A]re you sure you want your dynamic filters 30 or 60 minutes out
of date?

As opposed to infinitely out-of-date (i.e., no filters)?

Frequently, yes. FPs can be more dangerous than FNs.

We're dealing with more than one issue, here:

* How to disseminate information (DNSLLs, AXFR, BGP, etc.)
* How to act on it.

I'm curious what filtering method you use that never passes a packet
from a "bad" host, yet never has an outdated ACL entry that blocks a
recently-cleaned host. If you present your arguments to state "don't
run ACLs", fine. Your case is a wholly valid one for not filtering.

If you contend that your position supports static ACLs versus dynamic --
forget it. Static filters are even more prone to bitrot. (69/8,
anyone?) Why? Because static \(.*\) requires more effort than dynamic
\1.

Despite dynamic routing's non-instantaneous convergence, I doubt anyone
here uses much static routing. Do packets ever get misdirected due to
dynamic routing protocol failure? You bet. Do we poo-poo dynamic
routing? Maybe, but we still decide it's the best overall approach.

Once one has the information, the question is how to act on it.
Proposition: Make the "Evil Bit" for real. (Hear me out...)

How do people deal with spam? Some block it outright. Others tag,
allowing users to decide based on a numeric score. Sometimes based on
ACL (DNSBL being just one way of communicating an ACL), sometimes based
on inspection.

Maybe one firewall drops blacklisted traffic. Another might set the
"Evil Bit". Perhaps inserting a new IP option would be useful. Or map
"badness" to something like, oh... say... 802.1p priority.

Depends on your network, clients, etc.

Exactly.

Some people use default-only routing. Others use static. People here
run dynamic. All have their places.

Anyone using dynamic _anything_ accepts, explicitly or implicitly, that
the information may be outdated or wrong. This does not mean dynamic is
invalid across the board.

Ehhhh.... did I just chase a red herring? I thought we were discusing
RIB/FIB methods, not whether or not anyone would want to run dynamic
firewall rules.

Eddy