ICANN ICANN Email List Archives

[gnso-ff-pdp-may08]


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

[Fwd: Re: [gnso-ff-pdp-may08] Who benefits from fast flux activities, and who is harmed?]

  • To: "gnso-ff-pdp-May08@xxxxxxxxx" <gnso-ff-pdp-May08@xxxxxxxxx>
  • Subject: [Fwd: Re: [gnso-ff-pdp-may08] Who benefits from fast flux activities, and who is harmed?]
  • From: Eric Brunner-Williams <ebw@xxxxxxxxxxxxxxxxxxxx>
  • Date: Fri, 11 Jul 2008 18:34:59 -0400

This is a resend of my comments on Dave's post-call note.
--- Begin Message ---
  • To: Dave Piscitello <dave.piscitello@xxxxxxxxx>
  • Subject: Re: [gnso-ff-pdp-may08] Who benefits from fast flux activities, and who is harmed?
  • From: Eric Brunner-Williams <ebw@xxxxxxxxxxxxxxxxxxxx>
  • Date: Fri, 11 Jul 2008 16:11:03 -0400
inline. Eric

Dave Piscitello wrote:

I previously suggested that we break it down into "Who benefits from the use
of short TTLs?" and "Who is harmed by fast flux activities?". I'm continuing
this thread using that theme.
Good.
I've tried to capture ideas from Joe, Wendy, Eric and others from prior
emails before re-posting this so it is different/longer than my original
post.

Who is neither benefited, nor harmed, by X, yet who's business model(s) enable X and similarly exploitable policy and/or best practice and/or operational abilities weaknesses?

I just happened to be thinking this morning about the present administration's nominee to the post of Assistant Secretary for Communications and Information at the Department of Commerce, that is, to head the National Telecommunications and Information Administration. He made his bones turning a blind eye to abuse reports when assistant general counsel at UUNET Technologies, and AS701 was for a long, long time, both the best connected network, and the most likely to be hosting the best (in the believed to be the most effective metric) P/P/O weakness.

We're walking around the history of ISP port 25 filtering and the profit margin made in dumping paying or non-paying customer exploits on other cost carriers.

Is it my duty <registrar_hat="on"> to ensure that an A record doesn't point to a low reputation address block, or is it the ISP's duty to policy things answering to port 80 and/or port 53, equivalent to port 25 filtering?

We're also walking around the history of address allocation, the subject of notes between Dave, Joe, and I, and the problem created by Microsoft's protection model.

Repeat (is it my duty ... ) to fingerprint the web server or dns server at each A record change, or any other mechanism that a registrar might use to acquire data about the innate vulnerability of the (virtual) server at the (virtual) ip address, or is it the ISP's duty to policy things answering to port 80 and/or port 53, equivalent to port 25 filtering?

This was the point made by John Berryhill, which I mentioned previously.


"Who is harmed by fast flux activities?"

1. Individuals whose computers are infected by attackers and subsequently
used to host name servers or web sites for a fast flux phishing attack. The
individual may have his Internet connection blocked. In the extreme, should
the computer be suspected of hosting illegal material, the computer may be
seized by law enforcement agents (LEAs) and the individual may be subjected
to a criminal investigation.

2. Businesses and organizations whose computers are infected may have
Internet connections blocked, which may result in loss of connectivity for
all users as well as the possible loss of connectivity for any Internet
services also hosted via the blocked connection (e.g., mail, web, e-merchant
or ecommerce sites). Again, in the extreme, should the computer be suspected
to host illegal material, the computer may be seized by LEAs and the
individual may be subjected to a criminal investigation. If this computer
were hosting web and other services for the business/organization, the
seizure could also result in an interruption of service, loss of income or
"web presence".

Both true. However, these assets were compromised prior to their use (to the point of re-compromise) in an X exploit, and the allocation of awkward knocking on the door by the local LEO is incidental to the asset exploitation to the point of exhaustion by the actual operator of the assets.

I don't think these "victims" should be counted, their computers are being used for one or more distributed systems, until busy, hung, or dead, and just counting the ones that get to that state due to the specific nature of the task assigned to a compromised asset misses the point that the asset was compromised and which use it was put, and how destructive to that asset that particular use is, is attacker choice. Restated, why are we not counting the vast numbers of compromised assets that are just as likely to be used as those which were detected and disabled? Where we don't want to get to is playing whack-a-mole with an effectively infinite renewable inventory of moles.

4. Internet access operators are harmed when their IP address blocks are
associated with bot nets and phishing attacks that are linked to fast flux
activities. These operators also bear the burden of switching the
unauthorized traffic that phishing attacks generate and they may also incur
the cost of diverting staff and resources to respond to abuse reports or
legal inquiries.

Rewind to UUNET. The ISP models that cut cost by cutting monitoring, help desks, ... more generally, those that ignore the BCP series (a perennial thread on NANOG) are _not_ harmed by hosting these ASP models (granted, X isn't the nicest Application for the average Service Provider), those "costs" are built into their business model.

The class of ISPs (and transit, but for other forms of BCP==cost avoidance) that don't effectively policy their assets are like dogs with fleas. Lots of fleas. They can be imagined to be flea-free, in theory, but in practice they collect fleas. Eventually the backbone cabal imposed the USENET Death Penalty (no connect) on UUNET, which momentarily got some behavior (and profit/cost) modification.

5. Registrars are harmed when their registration and DNS hosting services
are used to abet "double flux" attacks. Like Internet access providers, they
may also incur the cost of diverting staff and resources to monitor abuse,
or to respond to abuse reports or legal inquiries.

Some registrars have business models indistinguishable from UUNET.

8. Registries may incur the cost of diverting staff and resources to monitor
abuse or to respond to abuse reports or legal inquiries.

While the gTLD sample size is smaller, some registries have business models indistinguishable from UUNET.

Who benefits from the use of short TTLs?

1. Organizations that operate highly targetable networks (e.g., government
and military/tactical networks) that must adhere to very stringent
availability metrics and use short TTLs to rapidly relocate network
resources which may come under attack (Assumes the attack
targets a dotted quad and not a FQDN.

(From Joe St. Sauver: Targetting a dotted quad rather than a FQDN is
generally preferred by intelligent attackers because then you avoid creating
a "steerable death ray" which can be repointed by whomever controls the DNS
for the targeted domain name)

2. Content distribution networks such as Akamai, where "add, drop, change"
of servers are common activities to complement existing servers with
additional capacity, to load balance or location-adjust servers to meet
performance metrics (latency, for example, can be reduced by making servers
available that are fewer hops from the current most active locus of users
and by avoiding lower capacity or higher cost international/intercontinental
transmission links).

3. Organizations that provide channels for free speech, minority advocacies,
and activities, revolutionary thinking may use short TTLs and operate
fast-flux like networks to avoid detection.

4. researchers. there's always some paper that could get wrapped around temporal properties within a distributed database.



--- End Message ---


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

Privacy Policy | Terms of Service | Cookies Policy