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.