[Dshield] Idea for dealing with ISPs that ignoreabusenotificatons was RE: The Art/Tao/Zen of Abuse e-mails(Was:[Fwd: WHY IS YOURCUSTOMER...])
Tomas L. Byrnes
tomb at byrneit.net
Sat Aug 26 17:41:18 GMT 2006
You make a lot of good points below, let me make sure I got them,
because I see several points that are not necessarily directly
1: The legal and practical concerns with actually getting IPNs with
bogus or unmaintained contact info returned to the registrars make that
whole system broken.
OK, that is the way it is now. From an Internet governance standpoint,
that should be fixed. In the meantime, it's all the more reason to block
such CIDRs, especially if you are doing it dynamically, correlated to
the current attacks reported from all over the world to DSHIELD (not
just what one network sees, but the aggregate logs). Maybe it's a good
reason to follow the SWIP tree as deep as you can (do the full NS lookup
for the IN-ADDR and then LS the resulting zone), but I don't see that as
a good reason to deprecate non-responsive or invalid abuse handles as a
criteria for "bad neighborhood" designation.
1a: Also, contacts are often not updated for a long time without
Just because a contact isn't updated, doesn't mean it's invalid or NR.
It's when its invalid because it hasn't been updated that it becomes a
problem. Do you, or someone (or a script), monitor benchoff at vt.edu? If
so, it wouldn't get listed.
2: If you are parsing your own logs, you don't know if the abuse has
stopped, or just moved on. If the place it has moved to isn't being
monitored by any threat feeds you use, then you won't see it.
True, but just because a system isn't perfect, doesn't mean it doesn't
add some additional security at a relatively low cost. I'd rather dump
the baddies at the perimeter than have to use my SPAM filters or
application security to catch their attacks. The CPU cost of making a 4
octet match is much less than that of inspecting payload. So I will
inaccurately age them out when they stop attacking the nodes that submit
to DSHIELD, that's a wide net. I'm OK with that.
3: Statically configured blacklists are a bad thing, as are dynamic ones
that don't have an automatic aging/positive purge mechanism, because the
ownership of IP address space changes.
I couldn't agree with you more. The first rule in network security
should be the same as in medicine: "First do no harm". In reality, it's
more along the lines of do less harm than you do good (we have more in
common with Chemotherapy than fixing broken bones).
That's why the system I was advocating would be dynamic, with aging.
People should no more use this statically than they should the Bogon
list @ CYMRU (which is updated fairly regularly, and which you COULD use
dynamically). Other posters have pointed out the maintenance headache of
constantly rewriting rules, I also agree. I've been fighting this battle
myself for years, and have come up with a way that works, that doesn't
require constant rewriting of firewall rules, or a special management
console, or vendors' platform specific scripts, to handle it. I'll be
making a test version of this available using the DSHIELD lists after we
have some time to work out the details with DShield, Inc.
The SORBS lists, etc. really do make it far too hard to be removed, and
paint an over-broad brush to be useful in many cases (FE, using dial-up
lists with header inspection will usually bin most e-mail, since the
dial up is usually one or two in in the relay path in legitimate mail).
I'm not advocating that sort of "once you're on the list, you have to
beg me to get off it" system, but rather one that is correlated in time
with actual attack logs and non-responsive or invalid abuse aliases.
4: Marcus Raynum's word is holy writ and we should never use allow all,
then deny baddies, for any service.
MR is a very smart guy, who has helped enormously in raising awareness
of security, and distilling it down to concepts that the average network
administrator can actually understand and act on.
That having been said, any production network must, of necessity, have a
default permit rule for the services it offers to the general public.
Many of those services are attack vectors, and thus need additional
protection. One of those methods of additional protection is to block
known bad guys or networks that have no need to access the service. You
can then use other, more sophisticated, and in most cases CPU intensive,
methods to protect against compromise from the "neutral" rated peers.
This is like mall security keeping the vandals the shift before threw
out from reentering the mall. That doesn't mean that they aren't also on
the look out for shoplifters IN the mall. In fact, it means that they
have a better chance of catching others who are IN the mall, by keeping
known troublemakers from wasting resources. Also, a few months to a year
later, the same vandal may have grown up and out of their stupid phase,
and be shopping for a new stereo. Barring them permanently, when they
haven't tried to do anything bad in a long time, loses you business
5: Managing dynamically changing firewall rules is cumbersome, so much
so as to be impractical.
I agree, except for those who have large-scale security teams, SIM/SEM,
threat feeds and the whole "best practices" infrastructure that has an
entry cost of about $250,000 and an annual maintenance cost in the same
range (and goes up rapidly as your network increases in size and
complexity, and your public access requirements increase). I have been
working on a way that DOESN'T take enormous amounts of time and effort;
investment in expensive platforms, or the hiring of full-time security
admins, and have got a first iteration working. Stay tuned.
As I said earlier, it is also about disseminating the information so
that local administrators can decide how they want to use them. You may
not want to use the NR list, that's your choice. In a University
setting, that is probably a good choice. On the other hand, the
charities I help out, Grantsmart and the California Ships to Reefs,
don't have the need to let the whole world access them, have limited
resources to deal with the consequences of a compromise, don't have a
full time security or networking staff, and don't have the $$ to buy and
maintain Web App Firewalls, deep inspection engines, IDP, host IPS,
Tripwire on everything, etc. etc. For them, blocking bad or questionable
traffic sources at the edge and doing signature based inspection is the
best defense (assuming that there are exploits available for their web
servers, which there are from time to time).
I'm advocating that the information be made available, and some ideas
about how it could be ensured to be accurate, timely, and handle the
aging issue and other weaknesses it would share with all other block
list approaches. You could make the same arguments you are making about
the NR abuse list idea regarding the existing DSHIELD lists. If you have
some ideas on how my idea could be improved, I'd love to hear them.
We all work in a dismal science. When we do our job successfully,
nothing happens, and there is always some vulnerability we can't protect
against. I'm merely offering a suggestion that I think might help in
From: list-bounces at lists.dshield.org
[mailto:list-bounces at lists.dshield.org] On Behalf Of
Valdis.Kletnieks at vt.edu
Sent: Saturday, August 26, 2006 9:10 AM
To: General DShield Discussion List
Subject: Re: [Dshield] Idea for dealing with ISPs that
ignoreabusenotificatons was RE: The Art/Tao/Zen of Abuse
e-mails(Was:[Fwd: WHY IS YOURCUSTOMER...])
On Fri, 25 Aug 2006 14:43:39 PDT, "Tomas L. Byrnes" said:
> Since Fightback is correlated to logs, the "silent fix" part is fairly
> easy to see: the attacking IP stops showing up in the submitted logs.
It's actually not as simple as that.
You don't have any real way of telling if the abuse has actually
*stopped*, or if it's merely moved on (there's been times when our
DShield sensor boxes have been hammered, then go quiet - while the same
abuse is still hitting other parts of our /16s).
> I would agree, some sort of delay would be in order, but if a
> fightback message BOUNCES, for example, then blocking and notifying
> IANA/RIPE/APNIC is in order. It is a requirement that the contact info
> for a network be accurate, monitored, and updated, otherwise the CIDR
> is subject to forfeiture and reissue.
You would think so, but in fact even the "accurate" part is a totally
broken system - even *obviously* bad data (like phone numbers +1 999
999-9999) isn't enough to cause it to be removed (at least over on the
domain registration side of the fence). "Monitored" and "updated" -
that's even *more* of a joke - take a look at AS1312:
% whois as1312
descr: Virginia Tech, Blacksburg VA
admin-c: See Maint-AS1312
tech-c: See MAINT-AS1312
notify: benchoff at vt.edu
changed: benchoff at vt.edu 19960207
Last changed over a decade ago. Abandoned, not updated, or just no
changes worth reporting? (OK, so 'whois -h whois.radb.net maint-as1312'
will show a change 5 years ago.. Point still stands).
Also, if you've ever actually *chased* the ownership of a network, it
gets murky pretty quickly. IANA assigns a block of /8s to (say) ARIN.
ARIN then assigns a /10 to Verizon. Verizon assigns a /14 to a Joe's
Bait, Tackle, and Internet, and Joe manages to sell a /20 to
Fly-By-Night-R-Us. Fly-by-nite then gives a /24 to a known spamming
organization. Now, there's things in place for IANA to take back the
/8, and ARIN to take back the /10 - but everything after that is just
business, and nobody's been able to actually enforce a requirement that
these things get SWIP'ed correctly. Now, ARIN would be on very shaky
legal ground trying to take back the /10 - it's an *obvious* candidate
for a TRO because of the damage the revocation would do to any customers
currently in the address space (has happened already - a provider tried
to take back address space, the guy got a 90-day TRO to allow customers
to renumber out). Also, ARIN can't complain that Verizon did anything
*wrong* - even if they have a clause in the Verizon-Joe contract saying
Joe can't resell to shady characters (such clauses are *very* hard to
write well, btw). So you end up having to go after the spammers and
Fly-By-Night. Now what do you actually *do* at this point? Remember
that in order to file a lawsuit, you'll need somebody with both standing
and money and desire. Fly-By-Night doesn't have an allocation of
anything that ARIN *can* revoke. Your best hope is that Joe's contract
with Fly-by-night has a clause that they can break the contract easily.
And Joe may not *want* to break the contract, especially if it's a
volume-charged circuit - there's a *real* cost to finding another
customer, and if the new customer doesn't use as much bandwidth as the
spammers did, that's more revenue lost. If Joe has any clue at all,
they do *NOT* want to peek at Fly-by-night's traffic to identify
something naughty, because doing so would
(a) likely kill any common-carrier status they had and (b) render them
also liable if any *other* customers did something naughty..
And meanwhile, as long as Joe keeps sending out BGP announcements, and
Verizon keeps broadcasting them to others, the sites are still
reachable, even if they've been officially nuked - this is why hijacked
address space is even possible. As long as the BGP announcement is
believed, the site is reachable.
> This brings up the usual issues with black lists of aging,
> verification, etc., but these are all manageable.
Anybody who got address space in 69/8, 70/8, or 71/8 would quite likely
differ with you. 69/8 got allocated several years ago, and there are
probably *still* plenty of places that list it as "bogon". It took a
2 years to wake up all the major places that were blocking 69/8. And
the lesson wasn't learned - when 70/8 and then 71/8 came into use,
places allocated in those spaces had to go get *themselves* un-bogoned
at the same sites that had blocked 69/8.
There's been more than a few cases where people have gotten address
allocations, and had to return them to ARIN or RIPE because they were
"scorched earth" - previously used by spammers, and in so many black
lists that the space was effectively unusable.
> As far as ISPs being the participants, I don't see how the service
> provider is a necessary component here. Presumably each subscriber has
> their own firewall, which they can write their own DENY rules on.
>From yesterday's weekly routing table report, as seen by a router at
BGP routing table entries examined: 195958
Prefixes after maximum aggregation: 107215
Unique aggregates announced to Internet: 95129
Total ASes present in the Internet Routing Table: 22969
Origin-only ASes present in the Internet Routing Table: 20004
Let me know how maintaining your own rules scales for you. Keep in mind
Marcus Ranum's "6 stupid security things" - the first is "Default
allow", and the second is "Enumerating Badness".
And that's what you're trying to do here. Default allow, and then try
to enumerate the badness.
More information about the list