ICANN ICANN Email List Archives


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [gnso-ff-pdp-may08] How are Internet users affected by fastflux hosting?

  • To: gnso-ff-pdp-May08@xxxxxxxxx
  • Subject: Re: [gnso-ff-pdp-may08] How are Internet users affected by fastflux hosting?
  • From: Wendy Seltzer <wendy@xxxxxxxxxxx>
  • Date: Sat, 12 Jul 2008 10:50:59 -0400

Joe St Sauver wrote:
> The Messaging Anti-Abuse Working Group, a consortium of leading 
> international ISPs, has issued recommendations for managing port 25
> traffic to defeat direct-to-MX spamming, see http://www.maawg.org/port25
> If traffic on port 25 is blocked through following those recommendations,
> as it now is at many ISPs worldwide, spam can no longer be sent directly 
> to remote mail servers from those compromised PCs (although non-spamming 
> normal mail users can still send regular mail). 
> When the ISPs control port 25, that leaves the shadowy "bot herders" with 
> millions of compromised systems which are now incapable of directly 
> spamming remote mail servers.

This step worries me.  Closing port 25 may stop some spam, temporarily,
but at the cost of depriving a whole class of Internet users of the
ability to be full peers.  Instead of getting Internet service, they
find themselves able to get only "Internet lite," or, if they're lucky,
getting to pay more for "premium tiers of service."  The ISP is making
presumptions about what "Internet" is, and those presumptions are wrong
and limiting for users who want to run their own services.

As we've seen, this does not stop the flow of spam email, although that
may slow until abusers find other routes.  It does, however, block
legitimate users from having full Internet access.

I think we have to guard against assuming that the Internet applications
and uses of today are the only ones that will be important in the future.

I'm not defending the use of compromised machines, but I'm trying to
ward off solutions to one problem that create new problems of their own.
 I appreciate your discussion of some of those difficulties.


> Blocking http traffic from consumer web pages thus often results in 
> ISPs deploying more draconian solutions, such as banning all web servers 
> from dynamic customer address space, or deploying potentially expensive
> deep packet inspection (DPI) appliances to identify fastflux or double
> flux traffic (at least until the spammers begin using SSL/TLS to defeat
> DPI.
> The problem gets even more complex when double flux is involved. When
> name servers are routinely hosted on consumer systems, controlling 
> that DNS traffic requires managing port 53 traffic, blocking external
> DNS queries coming in to the name server running on the compromised 
> customer host, and typically also managing blocking or redirecting any 
> DNS traffic coming from the local customer base, permitting it only to
> access the provider's own DNS recursive resolvers. This loss of Internet
> transparency can keep customers from readily (and intentionally!) using
> third party DNS servers (such as those offered to the Internet 
> community by OpenDNS), and may also complicate or preclude things such 
> as accessing access-limited information products delivered via DNS, such 
> as some subscription DNS block lists. 
> In conclusion, Internet users see their systems used without their
> permission by abusers who've set up fastflux nodes on them; they face
> the daunting task of cleaning up those compromised systems once they
> discover what's happened; they are the target of endless spam, spam that
> would be materially harder if fastflux hosting didn't exist; and they
> experience a loss of Internet transparency as ISPs strugle to control
> the fastflux and doubleflux problems on the network. The combination
> of those effects can result in Internet users having a pretty bad
> experience, all thanks to the choice by some to use fastflux and double 
> flux techniques.

Wendy Seltzer -- wendy@xxxxxxxxxxx
phone: +1.914.374.0613
Visiting Professor, American University Washington College of Law
Fellow, Berkman Center for Internet & Society

<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy