Fast Flux Detection was added in IPFire 2.27 - Core Update 161.
Weaponising IPFire Location to proactively detect Fast Flux setups
Thanks to libloc, the free & open source location database, IPFire comes with an accurate, trustworthy database for mapping IP addresses to countries and Autonomous Systems, and vice versa. This allows us to introduce a new feature: Proactive detection of Fast Flux setups, which are commonly used by ne'er-do-wells for hosting questionable and malicious content on compromised machines around the world, switching from one infected PC, IoT device, or router to another within minutes.
To the best of our knowledge, this is a unique feature. Contrary to other security mechanisms such as AV scanners, which are often lagging behind, it detects malware, phishing, C&C servers and other nefarious things proactively - before any threat intelligence source in the world even knows about them. Even better, measurements done so far indicate it comes with a near-zero false positive rate in productive environments. 1
If you are using IPFire's built-in web proxy, all you need to do is to tick a checkbox, hit the "save and reload" button at the end of that page, and you're done.
To compensate the rather simple looking screenshot, this explains what Fast Flux hosting looks like, how it is used by cyber criminals, and how IPFire detects it. If you are in need of some tea or coffee, it is now time to make it. Ready? Here we go...
What is Fast Flux hosting?
Fast Flux is a way of hosting content on a highly volatile network of usually compromised machines across the globe. Instead of returning one or two relatively static IP addresses for a FQDN, as it is commonly done, a FQDN being in use for Fast Flux hosting returns a bunch of IP addresses, pointing into different countries and Autonomous Systems.
Replies to a DNS query come with a Time to Live (TTL), telling a DNS resolver how long it should cache them. While legitimate services often have a TTL within the range of hours or a day, Fast Flux FQDNs come with a significantly smaller one: Some of them propagate a TTL of half an hour, while others shuffle the IP addresses returned back every minute. Therefore, you'll end up talking to a different machine every time.
In theory, there are few legitimate use-cases for this. The author, however, never observed a Fast Flux hosting setup that had even a patina of legitimacy. In fact, they are an important utility for cyber criminals, especially because they are very resilient against take-down attempts. With ten new IP addresses coming in every few minutes, even most sophisticated and capable anti-abuse actors have to give up.
Most Fast Flux setups serve malicious content, ranging from malware distribution via phishing sites to C&C servers. Being exposed to detection and shutdown, infected systems often do not host valuable data such as collected login credentials themselves, but serve as proxies for connecting to the cyber criminals' backend infrastructure - which is often hidden behind another Fast Flux network, located at bulletproof ISPs or operating out of stolen IP space.
Although they are not suitable for applications requiring persistent, low-latency connections, some Fast Flux networks serve non-technical threats as well, such as marketplaces for stolen credit card data, fake pharmacy shops, warez download portals, or CSAM.
How does IPFire detect Fast Flux setups?
Having only a FQDN, a bunch of IP addresses resolved and perhaps a few metadata at hand, it is pretty hard to spot a Fast Flux network with a sufficient level of confidence. Very low TTLs are used for legitimate purposes as well (take a look at www.youtube.com
, for example), and IP addresses obviously not being part of the same /24 or /16 chunk is not a very reliable criterion either.
Querying IP reputation services or RBLs might catch some incidents, but relies on information on infected machines being available in near-realtime. Given the volatility of such setups, false negatives are highly likely.
But Fast Flux hosting comes with one characteristic sticking out like a sore thumb: It has an extremely high ASN diversity, since IP addresses are most likely to trace back to many different ISPs, hence ending up in different Autonomous Systems - which have different Autonomous System Numbers (ASNs).
To be fair: High-availability services might be hosted in two different data centers behind two distinct ASNs. People might have a backup DC - but not four or five of them. It simply does not make sense.
In terms of proactive detection, this is a Fast Flux network's undoing. And this is what we are able to measure in IPFire as well, since IPFire comes with our location database, already having all network data needed at hand, queried within nanoseconds. We just need to make use of it.
Below is a snapshot of the DNS replies of two FQDNs hosted on Fast Flux setups, dated around 9 pm (UTC) on July 14th, 2021. Their anatomy, spreading across several different ASNs in several different parts of the world, is striking.
IP Address | Country | ASN | AS Name |
---|---|---|---|
1.247.35[.]250 |
KR | 9318 | SK Broadband Co Ltd |
88.158.247[.]38 |
RO | 15471 | S.N. Radiocomunicatii S.A. |
109.102.255[.]230 |
RO | 9050 | TELEKOM ROMANIA COMMUNICATION S.A |
110.14.121[.]125 |
KR | 9318 | SK Broadband Co Ltd |
175.117.131[.]127 |
KR | 9318 | SK Broadband Co Ltd |
180.69.193[.]102 |
KR | 9318 | SK Broadband Co Ltd |
181.57.221[.]246 |
CO | 14080 | Telmex Colombia S.A. |
189.238.217[.]39 |
MX | 8151 | Uninet S.A. de C.V. |
190.218.32[.]60 |
PA | 18809 | Cable Onda |
213.231.134[.]136 |
BG | 38932 | Rimex Ltd. |
IP Address | Country | ASN | AS Name |
---|---|---|---|
1.247.35[.]250 |
KR | 9318 | SK Broadband Co Ltd |
37.75.44[.]24 |
MT | 33874 | Epic Communications Limited |
84.40.106[.]91 |
BG | 43561 | NET1 Ltd. |
106.241.4[.]103 |
KR | 3786 | LG DACOM Corporation |
116.126.116[.]6 |
KR | 9318 | SK Broadband Co Ltd |
175.117.131[.]127 |
KR | 9318 | SK Broadband Co Ltd |
186.6.236[.]46 |
DO | 6400 | Compañía Dominicana de Teléfonos S. A. |
211.244.109[.]130 |
KR | 9318 | SK Broadband Co Ltd |
218.232.207[.]201 |
KR | 9318 | SK Broadband Co Ltd |
218.233.73[.]201 |
KR | 9318 | SK Broadband Co Ltd |
One might get curious over the geographic distribution of these two examples. This is because a countries density of compromised machines is often related to different factors, including socioeconomic ones. However, South Korean ISP "SK Broadband" clearly has a problem with tackling abusive activities originating from their networks.
Seeing the bigger picture: Can we get rid of Fast Flux networks altogether?
Most probably, the short-term answer to this is "no": As explained by Brian Krebs multiple times, miscreants are both very tenacious in compromising machines and creative in abusing them afterwards. Owners of IT equipment, however, often say something like: "There is no valuable data on this PC, why should I bother securing it?" As long as they do not see the threats of an infection that emerge to the internet community, we will most likely continue to observe Fast Flux setups in the future.
As always, having both a good firewall ruleset and IPS configuration in place is vitally important to keep your clients behind IPFire secure. Using the web proxy, you do not have to worry about Fast Flux setups anymore, either.
Want an extra benefit? How about detection of selectively announced networks?
Especially in the spamming business, miscreants sometimes do not announce their networks globally, but only to a few ESPs (e-mail service providers) they aim at. That way, security vendors are less likely to notice, hence reducing the risk of disruption to the planned spam campaign.
In addition to deny access to a FQDN having an abnormally high AS diversity, you can also prevent your clients from reaching a website that is not hosted on a globally announced IP network - there simply is no legitimate reason for this.
This also applies to BGP announcements being very new: Would you like to visit a website being hosted on a network that just bursted into life a few hours ago? Why can't its operator wait a few days to ensure the network is known globally?
The author once observed such a setup (phishing mail containing a link to an AS not announced globally, but only to the victim's organisation) in conjunction with industrial espionage. Even if this is not a threat your network is exposed to, blocking access to destinations without a global BGP announcement might shield some dirt from it.
View Log
A detection will cause this message to appear in the /var/log/squid/cache.log
file:
[root@ipfire ~] # grep squid-asnbl-helper /var/log/squid/cache.log
Dec 16 14:19:00 squid-asnbl-helper[26233] WARN: Destination 'www.foke.es' resolves to IP addresses 'fe80::ccde:4cff:fea2:57ae' without corresponding ASN, probably selectively announced
Dec 16 14:19:00 squid-asnbl-helper[26233] INFO: Denying access to destination 'www.foke.es' due to suspected selective announcements
Note: For some reason, the folks at www.foke.es decided to put an IPv6 address into the DNS pointing to a non-routable IPv6 range - similar to 127.0.0.0/8 for IPv4. This triggers the anomaly detection.
Links
-
If populated, the list of allowed domains configured in the URL filter section will be used to bypass detection hits for these FQDNs. Should you encounter a false positive, just add the domain to the list, and reload the web proxy. ↩ ↩
-
Source of the image above: Brian Krebs: The Scrap Value of a Hacked PC, Revisited ↩