[Dshield] Idea for dealing with ISPs that ignore abusenotificatons was RE: The Art/Tao/Zen of Abuse e-mails (Was:[Fwd: WHY IS YOURCUSTOMER...])

Valdis.Kletnieks at vt.edu Valdis.Kletnieks at vt.edu
Sat Aug 26 16:10:07 GMT 2006

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
[Querying whois.radb.net]
aut-num:      AS1312
as-name:      VA-TECH-AS
descr:        Virginia Tech, Blacksburg VA
admin-c:      See Maint-AS1312
tech-c:       See MAINT-AS1312
notify:       benchoff at vt.edu
mnt-by:       MAINT-AS1312
changed:      benchoff at vt.edu 19960207
source:       SAVVIS

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 good
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 APNIC:

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.dshield.org/pipermail/list/attachments/20060826/9cc9b96b/attachment.bin 

More information about the list mailing list