Overheid VS: 'fast flux' vormt nationale bedreiging voor cyberveiligheid

Verschillende Amerikaanse overheidsinstanties en internationale partners waarschuwen voor fast flux. Dat is een techniek die cybercriminelen inzetten om ongedetecteerd te werk te kunnen gaan. De partijen noemen het een aanzienlijke bedreiging voor de nationale veiligheid.

Fast flux houdt in dat cybercriminelen de locatie van hun infrastructuur verbergen door snel van DNS-record te veranderen. Hierdoor wordt het lastig om activiteiten zoals command-and-control, phishing en het verspreiden van ransomware of malware te detecteren en te voorkomen. De techniek is relatief oud, maar is recent in opkomst door hackers.

De Amerikaanse Cybersecurity and Infrastructure Agency waarschuwt samen met de NSA, FBI en cybersecurityinstanties uit Australië, Canada en Nieuw-Zeeland in een advies voor twee variaties van fast flux. Bij single flux roteren verschillende IP-adressen die gelinkt zijn aan een bepaalde domeinnaam. In het geval van double flux wordt ook het IP-adres van de DNS-nameserver met een hoge snelheid verwisseld. Beide versies maken vaak gebruik van een botnet, waardoor het moeilijk is om het netwerkverkeer te identificeren en te blokkeren.

De autoriteiten raden verschillende maatregelen aan om fast flux tegen te gaan. Zo kunnen onder meer telecombedrijven volgens het advies IP-adressen verzamelen die gelinkt zijn aan fast flux. Het zeer snel wisselen tussen IP-adressen zorgt ervoor dat deze extra opvallen, zeker wanneer de gekoppelde geolocaties niet consistent zijn.

Fast Flux Single DoubleFast Flux Single Double

Door Idriz Velghe

Redacteur

04-04-2025 • 15:24

26

Submitter: Anonymoussaurus

Reacties (26)

26
26
9
2
0
11
Wijzig sortering
Eerlijk gezegd zie ik niet waarom flux van IP's zo opmerkelijk is. Het enige "nieuwe" is dat het preventief en aan een hoog tempo gebeurd, ipv wanneer de intermediaries getackled zijn.

Met een snel IP based reactiesysteem ga je vroeg of laat onschuldige DNS-servers tackelen.

De C&C domeinen blokkeren lijkt me het enige wat echt kan helpen, en ook dat is niet nieuw.
Waarom wordt iets gepresenteerd als nieuw?

Het is bijna 20 jaar oud.
Er zal ook heus wel iets meer achter zitten.
Dit soort waarschuwingen zijn vaak opstapjes naar de implementatie van iets "nieuws" wat de gebruiksvrijheid van de consument verder inperkt.

Het blijft natuurlijk wel een vervelend iets, en zoals met alles zullen de goeden onder de kwaden moeten lijden.
Jemig want een aluhoedje reactie zeg.

Dit is iets wat eigenlijk vrij makkelijk te detecteren en is waar je dan maatregelen tegen kunt nemen. Zonder dat de goeden onder de kwaden moeten lijden.

Als jij wel een aanleiding ziet om dat bij dit bericht te denken, licht dat dan verder toe.
Dus jij denkt dat iets wat al jaren bekend is, en waar volgens jou maatregelen tegen genomen kunnen worden, ineens in het nieuws moet... omdat? ...het leuk staat? ...er geen beter nieuws is?

Is het toevallig dat (in ieder geval) vier van de vijf "Five Eyes" landen dit naar buiten brengen?
De autoriteiten raden verschillende maatregelen aan om fast flux tegen te gaan. Zo kunnen onder meer telecombedrijven volgens het advies IP-adressen verzamelen die gelinkt zijn aan fast flux. Het zeer snel wisselen tussen IP-adressen zorgt ervoor dat deze extra opvallen, zeker wanneer de gekoppelde geolocaties niet consistent zijn.
Hoe gaat het verzamelen van IP-adressen door telecombedrijven dit dan precies stoppen én hoe voorkomt dit dat het de"...aanzienlijke bedreiging voor de nationale veiligheid" teniet gaat doen?

Dit heeft niets met aan alu-hoedje te maken, maar is simpel een reactie op (alweer) een artikel wat meer vragen oproept dan dat het antwoorden geeft.

Als jij meer of betere informatie hebt dan doe je er beter aan om die met anderen te delen dan om een afgezaagde reactie te plaatsen omdat jij niet verder wil kijken dan dat je neus lang is.
Je wilt dingen zien of je wilt ze niet zien. Heel veel mensen kiezen ervoor om dingen niet te (willen) zien. Dan kun je blijven roepen, maar krijg je het "alu-hoedje" label.

Overigens, niets mis met een alu-hoedje als dat betekend dat je wel je ogen open wilt houden voor wat er (mogelijkerwijs - we weten het nog niet zeker) gaat komen.
Daar gaat het nu net om: DNS-beheerders moeten sneller in actie schieten, maar dan nog gaat het denk ik niet zo veel helpen, want eens je malware de reguliere infrastructuur gaat bypassen kan je er nog weinig tegen doen.
Ja, maar 20 jaar geleden had je nog geen linux containers. Toen moest je nog aardig programmeren met chrootjail. (Er werd toen al voor gewaarschuwd dat Linux containers wel eens een vloek konden zijn)

Snap ook niet waarom je hier een botnet voor nodig hebt? Als je beetje met containers kunt programmeren kun je hetzelfde.
Jij kunt met je containers 1000 verschillende internet IP's emuleren welke *NIET* terug te herleiden zijn naar jouw machine?

Je gebruikt een botnet om zelf zo min mogelijk zichtbaar te zijn. Echter de bots moeten zich wel bij de C&C server kunnen registeren. Met fast flux roteert men bijvoorbeeld via Cloudflare DNS elke minuut of zelfs elke 15/20 seconden het IP van de DNS record en wijst elke keer naar een andere bot. Die bot heeft even daardoor instructies gekregen wat deze moet doen met het verkeer dat deze dan ontvangt. De techniek welke hiervoor wordt ingezet verschilt niet heel erg veel van onion routing.

Een container is slechts een isolatie techniek op een enkele server zodat meerdere componenten naast elkaar kunnen draaien met verschillenden dependencies. Chroot heeft niets met programmeren te maken, maar puur met het opzetten van een virtual filesystem welke als 'root filesystem' voor een process wordt gepresenteerd. Een bug in bijvoorbeeld bind zorgt er niet voor dat je geen remote shell kunt openen (bijv. netcat terug naar hacker), maar alleen dat bind bijvoorbeeld niet /etc/password of /etc/shadow kan uitlezen, maar alleen de bestanden welke in /var/chroot/bind/ te vinden zijn. Het lastigste can chroot was altijd om ervoor te zorgen dat je alles wat een process nodig heeft aan files, utilities en libraries beschikbaar is. Echter bind draait nog steeds als root en heeft daardoor ook nog steeds alle rechten welke root heeft. Daarom waren wij in '99 al overgestapt naar djbdns (aka tinydns) omdat deze niet als root hoefde te draaien. Grotendeels dezelfde reden waarom wij waren overgestapt naar qmail, maar dat had ook te maken met de oneindige stroom met mbox file issues, welke niet aanwezig waren in maildir.

In een testlab kun je prima met containers een klein leger van bots emuleren om bijvoorbeeld een API te stress testen, maar dat heeft niets met maken met zo min mogelijk sporen van jezelf achterlaten op het internet zodat de autoriteiten je niet kunnen opsporen...

Ik las een tijd geleden overigens dat deze fast flux techniek alweer ingehaald is. Er zijn inmiddels botnets welke een soort van OTP code genereren om hiermee een hostname samen te stellen. Je gaat hierdoor dus niet elke keer naar ccserver.example.net, maar naar cc073524.example.net en een minuut later naar cc182624.example.net. Hierdoor doet men niet op hoge snelheid de IP's van een hostname veranderen, maar roteert men op een voorspelbare manier door een grote lijst van dynamische hostnames.

Overigens kunnen containers ook prima als botnet misbruikt worden, niet alleen via docket/podman, maar ook via k3s/k8s. In enterprise productie systemen draaien met van componenten van een specifieke versie van een component, bijvoorbeeld mysql. Je wilt niet ongetest van versie veranderen op een productie systeem, dus ':latest' wordt vrijwel nooit toegepast. Zodra men vanuit een test/acceptatie/qa environment naar productie gaat, dan neemt met deze specifieke versies over omdat ze weten dat die combinatie werkt. Als je blijkt dat er een bug in haproxy zit, dan duurt het vaak dagen, soms weken voordat men een nieuwere versie heeft draaien. Teveel afdelingen zijn betrokken bij deze processen, waardoor besluitvorming en uiteindelijk toestemming vaak (te) lang op zicht laat wachten. Echter voor korte tijd is de omgeving dan vatbaar voor exploits van (semi) staats hackers. Zij creeren vervolgens een remote shell (firewall punching) waardoor de c&c server instructies naar de nieuwe bot kan sturen. Het 'script' kan bijvoorbeeld kijken welke listening porten open staan, het oorspronkelijke process zelf stoppen, rebinden aan deze port en dan bijvoorbeeld haproxy rebinden op poort 880 en al het verkeer niet voor de bot doorstuurt, zodat de bot langere tijd onopgemerkt blijft...
Uhm ja maar je geeft aan chroot. Ik heb het over chrootjails dat is wel een verschil. Vroeger bonden ze IP's en Mac adressen daaraan en aan proxy dns en IP server. Clonen en klaar. Daarvoor moest je aardig programmeren.

Tegenwoordig heb je linux containers. Als je die script met een Lifetime van een aantal seconden of minuten en ze killed met IP en alles erop en eraan. Ben je sneller dan zombie netwerk. Desnoods gooi ze scripted via proxyservers wat ook weer scripted containers kunnen zijn naar onionservers.

Vroeger om een chrootjail fatsoenlijk veilig op te zetten met een Hardened kernel onder Unix vereist best wat kennis vooral als je de Linux tools ook nog moet programmeren. Met de LX containers is het een fluitje van een cent bijna.
Fluitje van een cent voor een DOGE hacker, natuurlijk. Gewoon AI toepassen, en klaar.

Daarom hebben ze ook net de directeur en onderdirecteur van de NSA ontslagen uiteraard.
https://edition.cnn.com/2...ecurity-agency/index.html
Sommige appreciëren jouw sarcasme niet.

Komt waarschijnlijk omdat we al een geruime tijd leven in een realiteit waar zelfs The Onion niet tegenop kan verzinnen.
Wacht, als de request naar het botnet vervolgens via het botnet geforward worden naar command and control, dan moet het botnet weten wat de c&c server is. Is het dan niet gewoon de malware installeren, wachten tot jij de forwarder bent, en kijken waar je heen forward? Dan heb je alsnog de c&c server te pakken ook al heb je geen directe dns resolve. Duurt misschien even, maar hoe faster de flux is, hoe minder tijd dat duurt.
Ja en nee, niet iedereen in het botnet krijgt dezelfde instructies. Dus jouw installatie kan een verwijzing naar A krijgen, terwijl de rest van het botnet instructies krijgt voor ontelbaar andere locaties.
Als het een beetje slim is ingericht forwarden alle forwarders een X aantal nodes verder a la Tor (of zelfs via Tor). Dan ben je niets wijzer, tenzij je een groot deel van het botnet beheert.
Het is zeker niet nieuw. Ruim 20 jaar geleden was dit regelmatig al een serieus probleem. En al bijna net zo lang is er dus aandacht de problemen te verminderen.

Het lijkt me dus vooral de vraag waarom het nu (nog) nodig is om te waarschuwen maatregelen te nemen. Er staat namelijk niet vermeld dat het eerder geen probleem was. En het is zelden het geval dat als een kans bekend is de criminelen die niet blijven proberen te nemen. Natuurlijk soms wat minder en soms wat meer, maar je kunt er nmm maar beter rekening mee houden dan negeren tot een ander er voor gaat waarschuwen dat het nu echt erg is.
Lijkt me dat Rusland hier goed gebruik van kan maken. Gezien de VS de Russische hackers niet meer monitort en zich er niet meer tegen wapent. Vrij spel dus voor Poetin.
Super interessant dit. Al vraag ik me wel af of telecombedrijven wereldwijd hieraan zouden willen meewerken.
Off-topic: "Cybersecurity and Infrastructure Agency" kreeg geen afkorting zoals de NSA & FBI want die van hun was al bezet.
Off-topic: "Cybersecurity and Infrastructure Agency" kreeg geen afkorting zoals de NSA & FBI want die van hun was al bezet.
Hadden ze daar geen 'CSIA' voor kunnen kiezen oid, CyberSecurity and Infrastructur Agency ?
Das natuurlijk geen TLA
Cyber Defense Agency?
Pretty good!
Laat die Amerikanen maar niet horen dat wij dit probleem opgelost hebben, kunnen ze niet goed tegen ;)
Waarom zouden telecombedrijven hier niet aan willen meewerken? Het levert voor hun servers immers onnodige extra load op. En het lijkt vrij simpel te detecteren, dus dan zal het ook niet zo kostbaar zijn.
Dus eigenlijk hebben cybercriminelen IaC (infrastruture as code) ondekt :P ?
Volgens mij is het probleem (de uitdaging) dat de dns-records snel en automatisch worden geregistreerd en vooral net zo snel weer worden ge-de-registreerd. En dat niet alleen voor de dns-records, maar ook voor de registering dns servers. Die registering dns servers zijn dan de snel startende containers die ook weer snel zijn opgeruimd...

Mijn eerste workaround om hier toch iets van te kunnen traceren is een algemeen decreet dat een dns-registratie minimaal een bepaalde tijd moet blijven bestaan, bijvoorbeeld 24-uur of zo iets. Dat de time-to-live (ttl) dus ongeacht de instelling minimaal een dag is.
Maar aan de andere kant is het een creatieve geest die daar dan ook weer gepast misbruik van kan maken.


Om te kunnen reageren moet je ingelogd zijn