[Dshield] Revoking CIDRs (forked from the NR Fightback black-list discusion).
Tomas L. Byrnes
tomb at byrneit.net
Sat Aug 26 17:55:49 GMT 2006
One thing I didn't respond to in my other post because it was not on the
topic of IP block lists:
It looks like, in your discussion of Net Block revocation below, you are
talking about cases where the responsible party for the IP range @
ARIN/RIPE/APNIC is valid and responsive, but a user of the Netblock is
abusive, and the RP won't do anything about it, so there is an effort to
revoke it according to the terms of service of the ISP that is thwarted
by TRO and the practicality of revoking a /8 for the actions of a /24
(or less). That is definitely an issue, but it is not one that I think
can be solved technologically, nor is it relevant to the subject of the
idea of publishing a list of CIDRs that bounce or don't respond to
Fightback messages. In your example below, the Abuse Alias (Verizon) is
monitored and responsive. The blocking would have to take place due to
another mechanism (DSHIELD attacker list, or SPAM RBL).
It is definitely a matter of Internet Governance that needs to be
addressed, as are many items that bear on security, but it's not
something my idea can deal with (revoking the CIDR).
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