ICANN ICANN Email List Archives

[gnso-ff-pdp-may08]


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

Re: [gnso-ff-pdp-may08] Fast Flux Definition - V4.1

  • To: Kal Feher <kalman.feher@xxxxxxxxxxxxxxxxxx>, fast Flux Workgroup <gnso-ff-pdp-May08@xxxxxxxxx>
  • Subject: Re: [gnso-ff-pdp-may08] Fast Flux Definition - V4.1
  • From: Dave Piscitello <dave.piscitello@xxxxxxxxx>
  • Date: Tue, 29 Jul 2008 05:31:02 -0700

One alternate scenario I can think of is where bulletproof hosting is used for 
the illegal web sites. But these hosts only account for a small number of the 
actual hosts involved in the network. I can't think of a FF scenario where the 
majority of hosts are not running on compromised systems since using someone 
else's assets is one of the economic drivers for these 
attackers/micreants/criminals.

Can you give me an real world example where the majority of systems used in a 
FF network are not compromised hosts?


On 7/28/08 11:55 PM, "Kal Feher" <kalman.feher@xxxxxxxxxxxxxxxxxx> wrote:

A thought regarding the first point.

Does the network need to be made up of compromised systems?

Obviously it is the most common scenario, but I can imagine quite a few 
alternate scenarios where the hosting software is "legitimately" installed on a 
large base of systems, both knowingly and unknowingly. We should not digress 
into the legality of "click wrap agreements" but merely acknowledge that 
legitimately installed and operated software could still be used to deliver 
illegitimate content in a manner that would mirror FF behaviour with regards 
misdirection and obfuscation of the operators identity.


On 29/7/08 12:47 AM, "Greg Aaron" <gaaron@xxxxxxxxxxxx> wrote:

I think what Dave says names sense.  And "difficult or impossible to contact" 
seems unnecessary.


________________________________

From: owner-gnso-ff-pdp-may08@xxxxxxxxx 
[mailto:owner-gnso-ff-pdp-may08@xxxxxxxxx] On Behalf Of Dave Piscitello
Sent: Monday, July 28, 2008 9:16 AM
To: Mike O'Connor; fast Flux Workgroup
Subject: Re: [gnso-ff-pdp-may08] Fast Flux Definition - V4.1

While Randy's definitions are accurate and extremely helpful and important for 
this WG's work, I think they are too dense for counsel members and the ICANN 
community at large. I would prefer that we use short bullet items that 
enumerate the characteristics rather than use "inherited definitions".

I am also uncomfortable to paint a blue haze over the characteristics that 
clearly distinguish unauthorized and potentially criminal behavior by saying 
"difficult or impossible to contact".

The characteristics I believe best describe flux networks in general:

 *   operated on compromised systems
 *   operated for the purpose of hosting unauthorized, malicious or criminal 
content
 *   operated using software that was installed without notice or consent to 
the system operator/owner
 *   "volatile" in the sense that the network changes its topology for the 
specific purpose of sustaining the lifetime of the network and the attack(s) 
the network supports, using
    *   (rapid) modification of TTLs for name servers and malicious content 
hosts
    *   monitoring to determine/conclude that a host has been identified and 
shut down
    *   time- or other metric-based topology change (in theory, I could choose 
to move a web host simply because I've reached some "max" number of visitors 
that I judge to be sufficient to put that host on someone's radar)

For me, this definition paints a very different kind of network than one that 
is used for any commercial or other non-criminal activity. And it's the kind of 
network I am very eager to put out of business.


On 7/26/08 1:13 PM, "Mike O'Connor" <mike@xxxxxxxxxx> wrote:


Hi all,

Here's what I wind up with:

FastFlux -- for purposes of our working group;

"A volatile compromised host service network, the operators of which
are difficult or impossible to contact."

The "longer version" can be found in the notes from yesterday's call
in the Definition of Fastflux part of the Discussion Topics;

  https://st.icann.org/pdp-wg-ff/index.cgi?july_25_call

Two questions --

1) Does this do it?

2) Can we identify these in the data we collect?

m


voice: 651-647-6109
fax: 866-280-2356

web: www.haven2.com












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

Privacy Policy | Terms of Service | Cookies Policy