<<<
Chronological Index
>>> <<<
Thread Index
>>>
[gnso-ff-pdp-may08] Section 5.10 Text
- To: Fast Flux Workgroup <gnso-ff-pdp-May08@xxxxxxxxx>
- Subject: [gnso-ff-pdp-may08] Section 5.10 Text
- From: Rod Rasmussen <rod.rasmussen@xxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 13 Nov 2008 14:03:34 -0800
Hi folks,
Sending this around to everyone as I don't think we made the cut on
getting it in Marika's latest draft.
This text is meant for section 5.10 that asks, "What are some of the
best practices available with regard to protection from fast flux?"
All that was done here was to add and explain references to two
different documents that cover some possible best practices that could
be brought to bear: the APWG Registrars Best Practices and the SSAC
paper on Fast Flux hosting. Some of the pertinent points were brought
out to show their relevance, but the point here is to get references
to relevant documents included here.
We should probably discuss any changes/additions/etc. to this along
with our other work for tomorrow's call.
Thanks!
Rod
=====================
One source of best practices for protection from fast flux can be
found in the phishing world. The Anti-Phishing Working Group has
recently released a best practices document for domain registrars in
dealing with domain names registered by phishers ("Anti-Phishing Best
Practices Recommendations for Registrars" http://www.apwg.org/reports/APWG_RegistrarBestPractices.pdf)
. Several of the practices outlined in that document apply directly
or indirectly to dealing with fast flux domain names. While the
audience for this particular document is the domain registrar
community so some particular recommendations may not translate to
other entities within the domain registration space, the same general
principles can apply to domain registries, domain resellers, and other
providers of domain registration or support services.
The following is a paraphrased sampling of some of the applicable
practices mentioned in this document:
- Track the IP address, date, time, frequency and action of all
account changes such as updating DNS or WHOIS information
- Limit the ability of registrants to repeatedly change their name
servers via a programmatic interface to reduce or eliminate automated
name server hopping.
- Proactively use available data to identify and/or shut-down
malicious domains: There are numerous data sources that can provide
information that may help in identifying malicious activity. Lists
such as theSORBS Dynamic User and Host List can provide networks
associated to dial-up, DSL, and cable networks that are more likely to
be abused. The Composite Block List (XBL) may indicate fraud.
Optimally a registrar would check against this information at DNS set-
up or modification time, however periodic scanning should see good
results.
- Use a "Registrar Lock" on registrations that are deemed to be
suspicious enough to warrant further investigation.
Another source for suggested practices to mitigate the use of domain
names in the "double flux" variant of fast flux attacks is SAC 025,
Fast Flux Hosting and DNS (http://www.icann.org/committees/security/sac025.pdf
).
SAC 035 identifies mitigations methods certain registrars practice
today in cases where the registrar provides DNS for the customer's
domains:
- Authenticate contacts before permitting changes to name server
configurations.
- Implement measures to prevent automated (scripted) changes to name
server configurations.
- Set a minimum allowed TTL (e.g., 30 minutes) that is long enough to
thwart the double flux element of fast flux hosting. [The WG notes
that this method could interfere with customers (registrants) who use
low TTLs for legitimate uses, without harm to others. In such cases,
the DNS provider might provide exception case processing or white
listing.]
- Implement or expand abuse monitoring systems to report excessive DNS
configuration changes.
- Publish and enforce a Universal Terms of Service agreement that
prohibits the use of a registered domain and hosting services (DNS,
web, mail) to abet illegal or objectionable activities (as enumerated
in the agreement).
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|