<<<
Chronological Index
>>> <<<
Thread Index
>>>
Re: [gnso-ff-pdp-may08] Crafting a solution for fast flux
- To: marc@xxxxxxxxxx
- Subject: Re: [gnso-ff-pdp-may08] Crafting a solution for fast flux
- From: Joe St Sauver <joe@xxxxxxxxxxxxxxxxxx>
- Date: Wed, 16 Jul 2008 17:09:01 -0700
Marc asked:
#If I'm not jumping into the solution side to fast, what do you think is
#the best solution?
I don't think any single thing will eliminate fastflux, I think a
multipronged strategy will be needed (including improved information
sharing, as you've suggested). A short/very incomplete list:
-- Publicly encourage service providers to have abuse reporting addresses,
and current domain/IP/ASN whois point of contact data (including an
explicit abuse contact in those whois records). Flag those who elect
NOT to do so.
-- Name servers in domain registrations should be identified as static or
dynamic by the registrant. If static name servers, the IP's used for
those name servers should be provided. If dynamic, that's fine, but
sites electing to use dynamic name servers should expect that their
choice will be taken into account when other sites assess their
reputation and decide what (if anything) they want to do
with their traffic. Charge a premium for dynamic name server domains.
-- Changes to static name server IPs should also incur a nominal fee, split
between ICANN and the Registry, with the funds received from that fee
should be dedicated to abuse handling/security-related purposes at
ICANN and each Registry.
-- Encourage ISPs to document IP address ranges which should NOT be
hosting web pages or DNS servers, much as the PBL is used to document
IP address ranges which should not be emitting email.
-- Fix the WDPRS process, so that fastflux domains with bogus contact
information can be efficiently reported.
What would such a "fix" entail? Well, I'd start with:
1) If one domain with a given bit of bad information is reported,
make it possible for submitters to request equivalent treatment
for ALL domains that share that same specific information defect.
Thus, for example, if someone registers 150 domains that all
have the hypothetical and obviously bogus address:
blah blah blah
you can't catch me
north, pole 99999
do NOT require someone reporting those addresses to report all
(or some fraction of all) 150 domains one-by-one.
2) Publish monthly summaries of unique complaint volumes by registrar,
by TLD, and by name server. Also provide a report by privacy
protection service associated with complained-of domains.
3) FOLLOW UP on WDPRS complaints and make sure that something is DONE
about the issues which get identified.
4) Provide a channel for Internet users to report illegal domain use
(currently it is rather ironic that ICANN will let me report a
domain for having the wrong zip code, but not for hosting a
phishing site or child pr0n -- something's wrong there, I think).
5) Allow users to flag domains that appear to be fastfluxing.
-- Encourage the creation of national cleanup resources for those whose
systems have been infected by bots. These resources may vary from country
to country, but should include technical experts who can help clean
and harden infected systems (along the lines of what I proposed in
http://www.uoregon.edu/~joe/ecrime-summit/ecrime-summit.pdf )
-- Encourage ISPs to instrument their own networks, so they have
visibility into what's being done *with* their resources, and *to*
their customers. Fastflux can only survive if networks are blind to
upstream hosts.
Regards,
Joe
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|