<<<
Chronological Index
>>> <<<
Thread Index
>>>
RE: [gnso-ff-pdp-may08] Update on outstanding sections in draft Initial Report
- To: "'Fast Flux Workgroup'" <gnso-ff-pdp-May08@xxxxxxxxx>
- Subject: RE: [gnso-ff-pdp-may08] Update on outstanding sections in draft Initial Report
- From: "Greg Aaron" <gaaron@xxxxxxxxxxxx>
- Date: Thu, 13 Nov 2008 16:18:50 -0500
Dear Marika and friends:
I suggest the following edits for consideration:
Replace:
"registration abuse (and abuse of registered domain names)"
with
"domain name abuse"
RATIONALE: registration of a domain name is different from use of a domain
name. Whether a domain name is abusive or not cannot be determined at time
of registration (unless it's made via stolen credit card, and that's not a
matter under ICANN's purview). Also, ICANN has drawn the distinction
between "registration abuse" and "domain use" or abuse in a recent issues
paper.
Replace:
"In some cases, i.e., when the registrar provides name service for the
customer, the registrar allows the customer to set the TTL parameter for
name server records to arbitrarily small values."
With:
"In some cases, i.e., when the registrar provides relevant hosting or DNS
services service for the customer, the registrar allows the customer to set
the TTL parameter for name server records to arbitrarily small values."
RATIONALE: it could be argued that all registrars provide "name service"
for any domain name they register. What we are trying to explain here is
that some registrars offer ancillary DNS or hosting services that allow
registrants to set TTLs.
Replace:
"abuse IP, brands, copyrights and trademarks"
with
"abuse intellectual property, brands, copyrights and trademarks"
RATIONALE: distinguish intellectual property from "IP" as in "Internet
Protocol"
All best,
--Greg
_____
From: Greg Aaron [mailto:gaaron@xxxxxxxxxxxx]
Sent: Monday, November 10, 2008 4:43 PM
To: gaaron@xxxxxxxxxxxx
Subject: FW: [gnso-ff-pdp-may08] Update on outstanding sections in draft
Initial Report
_____
From: owner-gnso-ff-pdp-may08@xxxxxxxxx
[mailto:owner-gnso-ff-pdp-may08@xxxxxxxxx] On Behalf Of Marika Konings
Sent: Thursday, November 06, 2008 4:50 AM
To: Fast Flux Workgroup
Subject: [gnso-ff-pdp-may08] Update on outstanding sections in draft Initial
Report
Dear All,
Please find below an overview of the sections that have been / are being
discussed on the list and which were not included in the latest version of
the report yet. I would like to include these in the next update of the
initial report, so I would like to invite you to review the proposed
additions and continue any further discussion if needed on the working group
mailing list and/or be prepared to indicate your support or disagreement on
the next call so the appropriate label can be included in the report
(agreement / support / alternative view). Please note that there are some
sections for which I have not received any input yet (apologies if I missed
your e-mail) such as 5.10, so please (re)send it to the list.
With best regards,
Marika
=================================
Proposed text for Section 5.4
------------------ begin --------------
The WG has no hard evidence that any registrar intentionally facilitates
fast flux hosting attacks. However, registrars become targets for
registration abuse (and abuse of registered domain names) when attackers
discover they can exploit weaknesses in the registrar's registration
services and internal processes. The attackers' objectives are in most cases
to gain control of a customer's domain account so that he can use the domain
names and name servers as resources for a subsequent attack, i.e., by
modifying or adding name servers that host zone files of domain names used
in phishing and other forms of attack that employ domain names.
Some of the known attack vectors are mentioned below:
- attackers scan registrar web sites to identify web application
vulnerabilities. They exploit vulnerabilities in registration web pages to
gain unauthorized access to existing customer accounts.
- attackers impersonate registrars using phishing techniques. A
registrar-impersonating phisher tries to lure a registrar's customer to a
bogus copy of the registrar's customer login page, where the customer may
unwittingly disclose account credentials to the attacker who can then modify
or assume ownership of the customer's domain names (See SAC 028 at
http://www.icann.org/committees/security/sac028.pdf).
- Attackers will brute force customer account credentials when they detect
that no countermeasures are implemented to block account access after
repeated attempts to login have failed.
- Attackers may attempt to coerce or socially engineer help desk and support
staff into making changes to customer accounts, or to grant access without
proper identification and credentials.
- Attackers may create customer accounts using false credentials and stolen
credit cards. They register domain names under this account and submit
incomplete, inaccurate and intentionally fraudulent registration contact
information. Attackers target registrars whom they have determined have
insufficient measures when he completes a registration information form. In
certain cases,
attackers will initially submit superficially valid whois (e.g., the
information may correspond to the credit card holder). Once the domains are
created, the attacker returns to falsify contact information so that the
contact information is not obviously linked to the credit card holder in
displayed WHOIS information.
This list is representative but not exhaustive. The above mentioned attacks
are also used to gain administrative control over domain names for purposes
other than fast flux attacks. For example, any attack that allows an
attacker to control a domain name can be used to facilitate a web defacement
attack or other forms of denial of service attack involving domain names and
DNS.
Registrars are directly involved in assisting customers who use certain fast
flux hosting techniques in production networks for self-beneficial purposes
(and without harmful impact on others). In most cases, the registrar
provides such customers with the ability to identify name servers and
addresses for name servers. In some cases, i.e., when the registrar provides
name service for the customer, the registrar allows the customer to set the
TTL parameter for name server records to arbitrarily small values.
Some registrars are aware of the range of attacks that can be perpetrated
against registrars and customers, and take proactive measures to protect
themselves and their customers from attacks of the nature described above.
Some of these are done as part of a general abuse prevention service while
others are premium services that pay particular attention to customers that
have high profile or high value domain name portfolios. Examples of such
measures are mentioned below:
- certain registrars provide a brand equity protection service. They
proactively study domain name registrations to to identify and block
attempts to mimic or abuse IP, brands, copyrights and trademarks.
- certain registrars monitor and limit DNS configuration changes for name
servers that are to be included in TLD zone files. They may limit frequency
of change, minimum TTL parameter values, number of DNS changes in a given
time period, and total number of name servers that can be created for a
given domain name.
- abuse and brand protection staff of certain registrars work in cooperation
with contracted parties and self-help groups to identify domain names and IP
addresses of systems that appear to be participants in fast flux attacks.
They correlate the IP addresses with routing information (ASNs), domains and
hyperlinks found in blacklisted phish email messages and work cooperatively
with registries to suspend or delete domains used in harmful attacks. Some
registrars work with ISPs, hosting service providers, system administrators
whose systems have been compromised and used to host fraudulent web sites to
mitigate the effects of the attacks.
- certain registrars offer customized domain name administration services to
protect registrants from unauthorized access and misuse of that registrant's
domains. Such services prevent fast flux attackers from using domains that
are perceived as legitimate by black listing services and consumers for
harmful purposes.
The above mentioned protection services do not focus specifically on
mitigating fast flux attacks, but more broadly on protection from domain
hijacking, malicious configuration of DNS, and brand protection.
-------------------------
Proposed text for section 5.5
Registrants are targets for fast flux attackers who seek domain names they
can use to facilitate double flux attacks. Attackers often gain
administrative control over a registrant's portfolio of domain names using
some of the methods described in Section 5.4. The attacker uses domains he
controls via compromised accounts in fast flux attacks by modifying or
adding to DNS configuration information via the registrant's domain
administration account.
Attackers are attracted to existing domains that have a positive reputation
(i.e., are not blacklisted) over newly registered domains. This attraction
has increased because domain name (registration) age and history have become
factors investigators consider as they attempt to determine whether a domain
is associated with phishing, spam, and fast flux attacks. Attackers are also
aware that registrars and registries often require stronger evidence of
abuse and typically proceed more cautiously take down requests are submitted
against "established" domains.
The impact to a registrant in such circumstances can be severe, ranging from
service disruption to domain blacklisting or suspension. Service disruption
can cause loss of revenue, service, advertising or business opportunities.
Blackisting or suspension can cause considerable reputational harm to a
registrant's brands and trademarks.
-------------------
Proposed addition to section 5.7
In 5.7 of the document, for "active engagement" ideas (starting at
line 926), I'd propose adding the following point, say between line
930 and line 931 of the current document or at line 947:
- stronger registrant verification procedures
Note, this can be accomplished without affecting the display of public
WHOIS (i.e. verification takes place by registrar or registry, but
WHOIS display is unaffected, in particular they can continue to use
privacy services).
[Note, there was further discussion on this proposal on the list. George,
please let the group now if you want to update your proposal following the
feedback received]
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|