ICANN ICANN Email List Archives

[gnso-ff-pdp-may08]


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

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

  • To: Wendy Seltzer <wendy@xxxxxxxxxxx>, "gnso-ff-pdp-May08@xxxxxxxxx" <gnso-ff-pdp-May08@xxxxxxxxx>
  • Subject: Re: [gnso-ff-pdp-may08] How are Internet users affected by fastflux hosting?
  • From: Dave Piscitello <dave.piscitello@xxxxxxxxx>
  • Date: Sat, 12 Jul 2008 08:14:03 -0700

Please read the MAAWG recommendation carefully.

Port 25 is not blocked unilaterally/unconditionally/autocratically, but
*conditionally*, based on whether the mail sender lies ³outside² the
administrative domain of the mail server operator. Specifically,

³Unabated transmission access (sending of email) from personal computers to
email servers not managed or monitored by the email provider exposes both
providers and their customers to a greater risk of victimization from rogue
persons and software.²

Simply put, if you aren't my client, I'm not relaying mail for you.

This is very similar to configuring a DNS server so that it is not an "open
recursive" server.

Again, simply put, if you are not my client, I'm not resolving names for
you.

It is also very similar to how firewalls - specifically, properly configured
firewalls - allow and block traffic based on whether the originating IP
address is one that is assigned from a space that the firewall recognizes as
"one of my own": again, if you are not in my address space, I'm not
forwarding packets for you.

In all cases, the ISP/netadmin is not making assumptions about what the
Internet is, but whether it chooses to *serve* a particular endpoint, for a
particular application. This is a very rudimentary form of "authorization",
and is a basic security tenet.

No conspiracy here:-)

On 7/12/08 10:50 AM, "Wendy Seltzer" <wendy@xxxxxxxxxxx> wrote:

>
>
> 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.
>
> --Wendy
>
>> 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
> http://cyber.law.harvard.edu/seltzer.html
> http://www.chillingeffects.org/
> https://www.torproject.org/
>






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

Privacy Policy | Terms of Service | Cookies Policy