Internet DRAFT - draft-bambenek-doubleflux
draft-bambenek-doubleflux
Network Working Group J. Bambenek
Internet-Draft: Double Flux Defense in DNS Univ. of Illinois
Updates: 1123, 1912, 2181, 2535 (if approved) May 21, 2008
Intended status: Standard
Expires: November 21, 2008
Double Flux Defense in the DNS Protocol
draft-bambenek-doubleflux-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 20, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
The memo provides information and suggests processes for developers
of applications based on the DNS protocol and for administrators
of servers and networks. It suggests new procedures for DNS and
DNSSEC implementations that would prevent abuse of the DNS
Bambenek Expires November 21, 2008 [Page 1]
Internet-Draft Double Flux Defense in DNS May 2008
protocol such as those seen by "Double Flux" service networks.
Specifically, this document recommends that all resource records for
NS records with Time-To-Live (TTL) settings under 24 hours be
dropped as potentially malicious records designed to attack users.
This document would update RFCs 1123, 1912, 2181 and 2535.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [KWORDS].
Table of Contents
1. Introduction ............................................... 2
2. Overview of Fast Flux Service Networks ..................... 3
2.1 Single Flux ............................................ 3
2.2 Double Flux ............................................ 3
3. Recommend Changes .......................................... 4
3.1 Changes to Registrars .................................. 4
3.2 Changes to Authoritative DNS Services .................. 4
3.3 Changes to DNS Resolving Services ...................... 4
3.4 Changes to DNS Clients ................................. 4
4. Security Considerations .................................... 5
5. IANA Considerations ........................................ 5
6. Conclusion ................................................. 5
7. Acknowledgments ............................................ 5
8. Feedback ................................................... 5
9. References ................................................. 6
Author's Address .............................................. 6
Senseless Legalese ............................................ 6
1. Introduction
Traditionally, malware repositories and malicious websites were easy
to locate and take down. They were either registered in DNS or used
their IP address. A call or e-mail to the abuse department and the
relevant ISP is (usually) all that was needed. With the advent of
botnets, this all changed.
Botnet technology changed the paradigm for hacking. Instead of
controlling only a few machines and using those machines as
launching pads for attacks, malicious individuals could control
hundreds, thousands, or even more machines that they could then use
to initiate more attacks. Identifying all the botnet "drones"
became difficult simply by the shear volume. Even after machines
Bambenek Expires November 21, 2008 [Page 2]
Internet-Draft Double Flux Defense in DNS May 2008
were identified, they frequently would just get reinfected. The
attention then turned to botnet command and control structures.
This lead to the development of fast flux networks which allow
leverging the shear numbers of infected machines and DNS to quickly
point and repoint victims to malicious websites and command and
control mechanisms.
2. Overview of Fast Flux Service Networks
Fast flux service networks work by using a combination of short
Time-To-Live (TTL) values and round-robin IP address assignments
in DNS records for a given domain. This leads to DNS resource
records having IP address that are changing quickly which make
takedowns difficult. Fast flux networks come in two varieties:
single flux which only rotate A records for web services and
double flux which rotate DNS records as well as A records for
web services. [1]
Fast flux networks rely on many machines that have been
compromised that can be used as "throwaway" hosts for further
exploitation or launching pads for their own attacks.
2.1. Single Flux
In a single flux network, there are up to thousands of IP
addresses that can coorespond to a single A record. For instace,
at any given moment, a round-robin list of IP address can be
returned for a query of host.malicioushost.com. However, those
values will have low TTLs assigned to them (as low as 3 minutes).
A future query will then return different IP addresses. This
allows malicious individuals to use DNS to point victims to
malware and command & control systems without having to worry
about the IP address being identified and taken offline. With
thousands of IPs to choose from, taking down the individual
hosts becomes quickly impractical. The one weak point in this
network is the nameservers that are authoritative for the
domain are static and they can be taken down which would,
in turn, disable the fast flux network.
2.2. Double Flux
The weak point in single flux networks is addressed in double
flux networks. In this case, double flux also use low TTLs
to quickly cycle the authoritative nameservers as well so
take downs of the nameserver also become difficult. They can
accomplish this by using low TTLs for the NS records
themselves, or using a fully-qualified domain name in the NS
Bambenek Expires November 21, 2008 [Page 3]
Internet-Draft Double Flux Defense in DNS May 2008
record with has a cooresponding A record with a low TTL. This
allows malicious users to cycle in owned machines as both
webservers and nameservers.
3. Recommended Changes
In order to mitigate the threat of double flux service networks
a variety of changes to the standard are proposed. The changes
will affect a variety of levels so that if some of the changes
are not implemented at certain levels, some protection will be
afforded to consumers through the other levels.
3.1. Changes to Registrars
Domain registrars SHALL limit the rate at which changes can be
made to authoritative DNS servers for domains within their control
to one set of changes per 72 hours. They SHOULD also allow for a
"backout" to the previous settings in the event of errors. This
backout will move the settings back to the previous nameserver
settings and reset the clock for 72 hours. This will prevent
malicious individuals from constantly changing their DNS records
to avoid takedowns.
3.2. Changes to Authoritative DNS Services
During startup, DNS services SHALL check both the TTL for NS
records and check the TTL for the A records associated with the
NS record. If the TTL is set to a value below 86400 (24 hours) it
SHALL override the setting to 259200 (72 hours) and record an
entry in the system logs to that affect. A value MAY be specified
within 24-72 hours that will work, but values under 24 hours
will default to 72 hours.
3.3. Changes to DNS Resolving Services
DNS servers that are non-authoritative but performing queries on
behalf of local clients SHALL examine the TTL of the NS record and
if applicable, the A record for the cooresponding nameserver.
If either non-cached TTL comes back with a value of less than
12 hours, it SHALL be discarded and return an error giving no
information to the requesting client.
3.4. Changes to DNS Clients
DNS clients SHALL examine returned values for all nameserver
Bambenek Expires November 21, 2008 [Page 4]
Internet-Draft Double Flux Defense in DNS May 2008
lookups for NS records (and cooresponding A records for those
NS records) for TTLs less than 12 hours. If a non-cached result
of a query comes back with a low TTL, it SHALL be discarded with
no IP address returned to the requesting application.
4. Security Considerations
This document proposes changes to the DNS protocol to improve
security in the existing system. It will not prevent misuse, but it
will help slow down the propogation of malicious DNS changes to
allow for the information security community to take appropriate
corrective action. This should theoretically enhance the security
of DNS services.
5. IANA Consdierations
This document has no actions for IANA.
6. Conclusion
The changes to the standards proposed in this document allow for
the information security field to slow down the movement of double
flux networs so that takedowns become more possible. It will not
fix the problem, nor does it intend to. The objective is to raise
the bar and prevent the malicious use of features within the DNS
protocol that are no longer relevant to modern usage.
Additionally, this author encourages the development of a
real-time DNS Blacklist of known fast-flux domain names to provide
an additional layer of protection that service providers can use
to protect their consumers.
7. Acknowledgments
This document acknowledges Captain John Smith who introduced coffee
to the New World in 1607. Without this, the practice of information
technology would not be possible.
8. Feedback
Feedback on this document is requested and interested parties can
contact that author at the address and e-mail listed below under
"Author's Address".
Bambenek Expires November 21, 2008 [Page 5]
Internet-Draft Double Flux Defense in DNS May 2008
9. References
[1] Honeynet Project & Research Alliance, "Know Your Enemy:
Fast-Flux Service Networks" http://www.honeynet.org/papers/
ff/fast-flux.html (13 July 2007)
Author's Address
John Bambenek
University of Illinois
1308 W. Main St
Urbana, IL 61801
United States of America
EMail: bambenek@uiuc.edu
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Bambenek Expires November 21, 2008 [Page 6]
Internet-Draft Double Flux Defense in DNS May 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
