För mig blir DNS-tunnling värdefullt först när resultatet går att testa med både positiva och negativa kontrollfall. DNS-tunnling utnyttjar det faktum att DNS ofta tillåts ut från många nät och kan bära data i långa eller frekventa namnuppslag.
DNS-tunnling i praktiken
Första byggstenen: Ovanligt långa labels kan indikera kodad data men förekommer även legitimt. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
En annan viktig del: Hög entropi och många unika subdomäner kan vara signal. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det tekniska ankaret: Regelbundna queries till samma parentdomän kan visa beaconliknande beteende. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det som ofta avgör kvaliteten: NXDOMAIN-rate och query types kan ge ytterligare kontext. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Arbetsgång utan genvägar
- Bygg en baslinje för vanliga klienter och resolvers.
- Gruppera queries per host och parentdomän.
- Mät längd, entropi, frekvens och unika labels.
- Kontrollera processen på endpointen som genererar trafiken.
- Blockera eller sinkhola först när legitim användning har bedömts.
För DNS-tunnling håller jag därför införandet i små steg. Då går det att skilja ett säkerhetsproblem från ett rent driftfel och att rulla tillbaka just den ändring som gav ett oväntat resultat.
Ett testbart exempel
En klient som skickar hundratals unika, långa subdomäner till samma ovanliga domän är mer intressant än en enstaka lång query. Mönstret över tid är ofta starkare än en regex på ett paket.
När en bra idé blir fel i drift
- Att larma på varje lång DNS-fråga.
- Att analysera bara resolverns IP och förlora ursprunglig klientidentitet.
- Att glömma legitima CDN-, telemetry- och securityprodukter med maskinlika subdomäner.
Efterkontroll
För DNS-tunnling vill jag avsluta med mätbara efterkontroller i stället för att nöja mig med att en statusruta visar ”enabled”. De viktigaste kontrollerna här är:
- Misstänkt klient kan kopplas till process eller användare.
- Parentdomänens beteende skiljer sig från normal baslinje.
- Blockering stoppar tunneln utan bred DNS-störning.
Ett negativt test hör också till DNS-tunnling: den väg, identitet eller operation som inte ska vara tillåten ska misslyckas på ett förutsägbart sätt. Då kan nästa tekniker upprepa kontrollen och förstå både avsikten och gränsen.
Slutsats
DNS-tunnling – känna igen data som gömmer sig i namnuppslag handlar därför inte om att samla fler säkerhetsinställningar. Det handlar om att minska en konkret risk med en kontroll som har tydligt scope, tydlig ägare och ett verifierbart resultat. När före-läge, förändring och eftertest dokumenteras blir säkerhetsarbetet både säkrare och lättare att förvalta.