[…] fast flux. It allows decentralized networks operated by threat actors to hide their infrastructure and survive takedown attempts that would otherwise succeed. Fast flux works by cycling through a range of IP addresses and domain names that these botnets use to connect to the Internet. In some cases, IPs and domain names change every day or two; in other cases, they change almost hourly. The constant flux complicates the task of isolating the true origin of the infrastructure. It also provides redundancy. By the time defenders block one address or domain, new ones have already been assigned.
[…]
A key means for achieving this is the use of Wildcard DNS records. These records define zones within the Domain Name System, which map domains to IP addresses. The wildcards cause DNS lookups for subdomains that do not exist, specifically by tying MX (mail exchange) records used to designate mail servers. The result is the assignment of an attacker IP to a subdomain such as malicious.example.com, even though it doesn’t exist.
Fast flux comes in two variations. Single flux creates DNS A records or AAAA records to map a single domain to many IPv4 or IPv6 addresses, respectively. Here’s a diagram illustrating the structure.
Double flux provides an additional layer of obfuscation and resiliency by, in addition to changing IP addresses, cycling through the DNS name servers used in domain lookups. Defenders have observed double flux using both Name Server (NS) and Canonical Name (CNAME) DNS records. Here’s an illustration of the technique.
“Both techniques leverage a large number of compromised hosts, usually as a botnet from across the Internet that acts as proxies or relay points, making it difficult for network defenders to identify the malicious traffic and block or perform legal enforcement takedowns of the malicious infrastructure,”
Yes.. And there’s a solution for this one too. Use DNS Pinning on your local DNS resolvers.
Web browsers themselves had to look at this a number of decades ago due to DNS Rebinding Attacks [wikipedia.org]. And the answer I’m pretty sure was to Pin DNS records whose TTL was less than 10 minutes or so to make sure DNS records will be cached for a minimum length of time, even if the TTL has been configured less.
You can handle this on your organization’s DNS servers as well:
For example; if your DNS resolver is Unbound, then set the cache-min-ttl to 24 hours.
cache-min-ttl: seconds Time to live minimum for RRsets and messages in the cache. If the minimum kicks in, the data is cached for longer than the domain owner intended, and thus less queries are made to look up the data. Zero makes sure the data in the cache is as the domain owner intended, higher values, especially more than an hour or so, can lead to trouble as the data in the cache does not match up with the actual data any more.
Then the “fast flux” attackers can’t be so effective against your infrastructure. Because the DNS records are pinned upon the first lookup. At least they won’t be able to use DNS for their fast flux network in this case – if your DNS resolvers’ policy prevents fast flux.
