Re: [gnso-ff-pdp-may08] Crafting a solution for fast flux

[Marc Perkel <marc@xxxxxxxxxx>]

Now to address Joe's ideas individually.

Joe St Sauver wrote:
> 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. 
>   
I agree in general but we also need to migrate or mirror whois data to a 
DNS based system so that it can be queried through automation rather 
than manually. Whois is a manual protocol and not suitable for real time 
queries by spam filtering systems. Thus the information in Whois is 
useless to me unless I'm doing it by hand.
> -- 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.
>   
I'm generally opposed to using fees as an anti-spam solution. The reason 
to me is somewhat obvious. Spammers have/make a lot of money and can 
afford it. Fees tend to discourage use by poor people. A small fee to us 
is a day's wages in parts of Africa. Alternatively we should require 
capcha to eliminate automation, and if automation is required by legit 
services then charge a fee for automation access.
> -- 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.
>   
I'm totally with you on this. I think there are a lot of things the ISPs 
can do to eliminate spambots. I think consumer modems should, be 
default, provide NAT or the ISP should just give consumers fake net 
addresses (10.x.x.x) so that the web can't surf them. The idea being 
that the average person is not a technical wizard and needs to be 
protected from the internet. Thus if they got hacked and became a web 
server or DNS server no one could reach it.
In such a sustem the more advanced user could turn off the NAT and get a 
real IP to do what they do now. The threshold being that they go to the 
trouble to turn NAT off and have the minimal skills to do that. Thus 
freedom is protected and consumers are protected from the web surfing them.
Also - ISPs by default should block port 25 and outgoing email should 
use 587 to talk to outgoing SMTP servers. Port 25 should be a server to 
server port only. Again - the user would be allowed to open port 25 
manually to run a legitimate email server. But by default viruses would 
be isolated.
I could go on forever about ISP policy but I'll say one more thing. If 
there were an open source project to create tools for ISPs to manage 
spambots I think ISPs would use them. So if such a project were created 
then I think it would take a big bite out of the spambot world.
> -- Fix the WDPRS process, so that fastflux domains with bogus contact
>    information can be efficiently reported.
>   
I agree that reporting is key. Especially automated reporting so that if 
an ISP gets reports from several sources about one customer then by 
using automation that IP could be closed on the offending port. I think 
this can be solved with an open source project to provide ISPs with tools.
>    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.
>   
Yes - even fake domain owners can be classified by being the same fake 
owner. Thus if someone had 150 domains and multiple domains were 
receiving complaints action can be taken against all of them.
>    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. 
>   
I don't quite understand this. Joe - you could build a wiki outlining 
all these ideas.
>    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. 
>   
These suggestion require 2 things that I'm asking for. Whois information 
through DNS and an automated way to send the message to the correct 
abuse address.
Suppose such information existed. Then the user can click on the "this 
is spam" button and the message is sent to the abuse department that 
handles the source where it came from. Thus the ISP would know instantly 
where the problems are.
> -- 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 )
>   
Require Microsoft to make security patches available to the public to be 
used even on pirated copies of Windows.
> -- 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.
>   
To me the word "encourage" is the same as providing ISPs with free 
tools. I'm sure 99% of ISPs are in total agreement but like the how-to 
ability to make it happen. I think if they had the tools available they 
would use them.
Maybe it's a matter of funding it. Suppose we raised a few million bucks 
and funded an open source project to create tools for ISPs to clean 
spambots from their networks? Maybe that's the solution?