Fast flux

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search
Robtex DNS Analysis of a fast fluxing domain.

Fast flux is a DNS evasion technique used by cyber criminals to hide phishing and malware delivery sites behind an ever-changing network of compromised hosts acting as reverse proxies to the backend botnet master—a bulletproof AS.[1] It can also refer to the combination of peer-to-peer networking, distributed command and control, web-based load balancing and proxy redirection used to make malware networks more resistant to discovery and counter-measures.

The basic idea behind Fast flux is to have numerous IP addresses associated with a single fully qualified domain name, where the IP addresses are swapped in and out with extremely high frequency, through changing DNS resource records, thus the authoritative name servers of the said fast-fluxing domain name is—in most cases—hosted by the criminal actor.[2] Depending on the configuration and complexity of the infrastructure, fast-fluxing is generally classified into single, double, and domain flux networks. Fast-fluxing remains an intricate problem in network security and current countermeasures remain inefficacious.

History[edit]

Fast-fluxing was first reported by the security researchers William Salusky and Robert Danford of The Honeynet Project in 2007; the following year, they released a systematic study of fast-flux service networks in 2008.[3] Rock Phish (2004) and Storm Worm (2007) were two of the most well known fast-flux service networks which were used for malware distribution and phishing.[4]

Fast-flux service network[edit]

A fast-flux service network (FFSN) is a network infrastructure resultant of the fast-fluxed network of compromised hosts; the technique is also used by content distribution networks (CDNs) where the dynamic IP address is converted to match the domain name of the internet host, usually for the purpose of load balancing using round-robin domain name system (RR-DNS).[5] The purpose of using FFSN infrastructure for the botnets is to relay network requests and act as a proxy to the backend bulletproof content server which function as an "origin server".[6] The frontend bots, which act as an ephemeral host affixed to a control master, are called flux-agents whose network availability is indeterminate due to the dynamic nature of fast-fluxing.[1]

Types[edit]

Single and double DNS fast-fluxing

Fast-fluxing is generally classified into two types: single fluxing and double fluxing, a build-on implementation over single fluxing. The phraseologies involved in fast-fluxing includes "flux-herder mothership nodes" and "fast-flux agent nodes", referred to the backend bulletproof botnet controller and the compromised host nodes involved in reverse proxying the traffic back-and-forth between the origin and clients respectively.[7][1] The compromised hosts used by the fast-flux herders typically includes residential broadband access circuits, such as DSL and cable modems.[8]

Single-flux network[edit]

In single-flux network, the authoritative DNS server of a fast-fluxing domain name repeatedly permutes the DNS resource records of the said domain with low time to live (TTL) values, conventionally between 180 and 600 seconds. The permuted record within the zone file includes A, AAAA and CNAME record, the disposition is usually done by means of round robin from the registry of exploited host's IP addresses and DDNS names.[9][10][11] Although the commonly proxied application protocol by the frontend flux-agent redirector nodes remains HTTP and DNS, other services such as SMTP, IMAP and POP can also be delivered through the flux-agent since the transfer between the backend flux-herder mothership node and flux-agent utilize transport layer (L4) TCP and UDP level port binding techniques.[12]

Double-flux network[edit]

A Double-flux network is an implementation complexity over single-flux, in which both the DNS A, AAAA, or CNAME and the IP addresses of the authoritative name server of the fast-fluxing domain name is reverse proxied through a fluxing-agent to the backend mothership node.[12] In this infrastructure, the authoritative name server record of the fast-fluxing domain points to a frontend redirector, which forwards the DNS datagram to the backend mothership node. The DNS resource records, including the NS record, are set with a lower TTL value, which gets permuted at the fast-flux mothership node's DNS zone file. This architecture results in an additional indirection.[13][14] The NS records in double-fluxing network usually point to a referrer host, that listens on port 53, rather than the flux-agents. The referrer hosts forward the DNS queries to a backend DNS server that hosts the zone file for the domain name, and the response message is directly sent from the backend DNS server to the querying resolver, instead of relaying the response message back through the referring name server.[15]

Domain-flux network[edit]

Domain-flux network involves keeping a fast-fluxing network operational through continuously rotating the domain name of the flux-herder mothership nodes. The domain names are dynamically generated using a selected pseudorandom domain generation algorithm (DGA), and the flux operator mass-registers the domain names. An infected host repeatedly tries to initiate a flux-agent handshake by spontaneous generating, resolving and connecting to an IP address until an acknowledgment, to register itself to the flux-herder mothership node.[13] A notable example includes Conficker, a botnet which was operational by generating 50,000 different domains in 110 top-level domains (TLDs).[16]

Security countermeasures[edit]

The detection and mitigation of fast-fluxing domain names remain an intricate problem in network security. Although fingerprinting the backend fast-flux mothership node remains increasingly difficult, service providers could detect the upstream mothership nodes through probing the frontend flux-agents in a special way by sending a crafted HTTP request that would trigger an out-of-band network request from the backend fast-flux mothership node to the client in an independent channel, such that the client could deduce the mothership node's IP address by analyzing the logs of its network traffic.[17] Various security researchers suggests that the effective measure against fast-fluxing is to take down the domain name from its use. However, the domain name registrars are reluctant in doing so, since there aren't jurisdiction independent terms of service agreements that must be observed; in most cases, fast-flux operators and cybersquatters are the main source of income to those registrars.[18]

Other countermeasures against fast-fluxing domains include deep packet inspection (DPI), host-based firewall, and IP-based access control lists (ACLs), although there are serious limitations in these approaches due to the dynamic nature of fast-fluxing.[19]

See also[edit]

References[edit]

  1. ^ a b c Li & Wang 2017, p. 3.
  2. ^ Almomani 2016, p. 483.
  3. ^ Saif Al-Marshadi; Mohamed Anbar; Shankar Karuppayah; Ahmed Al-Ani (17 May 2019). "A Review of Botnet Detection Approaches Based on DNS Traffic Analysis". Intelligent and Interactive Computing. Singapore: Springer Publishing, Universiti Sains Malaysia. 67: 308. doi:10.1007/978-981-13-6031-2_21. ISBN 978-981-13-6030-5.
  4. ^ Nazario, Josh; Holz, Thorsten (8 October 2008). As the net churns: Fast-flux botnet observations. 3rd International Conference on Malicious and Unwanted Software (MALWARE). Alexandria, Virginia: Institute of Electrical and Electronics Engineers. p. 24. doi:10.1109/MALWARE.2008.4690854. ISBN 978-1-4244-3288-2.
  5. ^ Almomani 2016, p. 483-484.
  6. ^ Almomani 2016, p. 484.
  7. ^ Salusky & Daford 2007, p. 1.
  8. ^ Konte, Feamster & Jung 2008, p. 8.
  9. ^ Salusky & Daford 2007, p. 1-2.
  10. ^ Li & Wang 2017, p. 3-4.
  11. ^ "FAQ: Fast-fluxing". Andorra: The Spamhaus Project. Archived from the original on 29 April 2021. Retrieved 12 December 2021.
  12. ^ a b Salusky & Daford 2007, p. 2.
  13. ^ a b Li & Wang 2017, p. 4.
  14. ^ Salusky & Daford 2007, p. 2-3.
  15. ^ Konte, Feamster & Jung 2008, p. 4-6.
  16. ^ Li & Wang 2017, p. 4-5.
  17. ^ Salusky & Daford 2007, p. 7.
  18. ^ Konte, Feamster & Jung 2008, p. 8-11.
  19. ^ Florian Tegeler; Xiaoming Fu; Giovanni Vigna; Christoper Kruegel (10 December 2012). "BotFinder: finding bots in network traffic without deep packet inspection". Association for Computing Machinery: 349–360. doi:10.1145/2413176.2413217. ISBN 9781450317757. Cite journal requires |journal= (help)

Bibliography[edit]