Szinte minden hálózati kapcsolat névfeloldással kezdődik. Mielőtt a böngésző, a levelezőkliens vagy egy frissítést kereső szolgáltatás kapcsolódna egy szerverhez, megkérdezi a DNS-t (Domain Name System), hogy a névhez melyik IP-cím tartozik. A kérdés és a válasz többnyire titkosítatlanul, kis UDP-csomagokban utazik, és sok hálózatban a tűzfal különösebb vizsgálat nélkül átengedi.
Ezért van a DNS-nek kettős szerepe a biztonságban. Jó megfigyelési pont, mert a lekérdezésekből egy fertőzés sokszor már akkor látszik, amikor más jel még nincs. A támadók viszont éppen azért használják, mert egy mindenhol átengedett csatornán vezérlést és adatot is lehet csempészni. Érdemes mindkét oldalt megnézni, a titkosított DNS-sel és a DNSSEC-kel együtt, amelyekről gyakran többet feltételeznek, mint amit valójában adnak.
Mit csinál a DNS, és miért érdekes a támadóknak
A DNS-t az IETF RFC 1034 és RFC 1035 (1987) írja le. A névtér hierarchikus: a gyökér alatt a legfelső szintű tartományok (.hu, .com) állnak, ezek alatt a szervezetek zónái. A feloldásban két szereplő különül el. Az autoritatív (mérvadó) névszerver egy zóna hiteles adatait tárolja. A rekurzív feloldó (resolver) a kliens helyett végigkérdezi a hierarchiát a gyökértől lefelé, a választ pedig a rekordhoz tartozó élettartamig (TTL) a gyorsítótárában tartja. Vállalati hálózatban a kliensek jellemzően a belső DNS-szervert kérdezik, amely maga is feloldhat rekurzívan, vagy továbbadja a kérdést egy külső feloldónak.
Mit árul el a DNS-forgalom
Egy fertőzött gép a kártevő telepítése után kapcsolatot keres a támadó vezérlőszerverével (command and control, C2). Ehhez legtöbbször egy nevet old fel, így a lekérdezés megjelenik a belső DNS-szerver naplójában, akkor is, ha maga a későbbi kapcsolat titkosított. Gyanús jelek lehetnek:
- ismert kártevő-, adathalász- vagy vezérlőtartomány lekérdezése;
- frissen regisztrált tartományok, amelyeket a cégnél korábban egyetlen gép sem kérdezett;
- sok sikertelen (NXDOMAIN) válasz egyetlen gépről, véletlenszerűnek látszó nevekre;
- szokatlanul hosszú, kódolt adatnak látszó altartományok (subdomainek), nagy lekérdezésszám egyetlen tartomány felé;
- olyan gép, amely a belső DNS-szervert megkerülve közvetlenül egy külső feloldóhoz fordul.
A MITRE ATT&CK tudásbázis a DNS vezérlőcsatornaként való használatát külön technikaként tartja nyilván (T1071.004, Application Layer Protocol: DNS).
A névfeloldás befolyásolásával a forgalom is irányítható. Egy meghamisított válasz a felhasználót hamis bejelentkezőoldalra viheti, miközben a címsorban a megszokott név áll. HTTPS-oldalnál a böngésző a hamis szerver tanúsítványát többnyire elutasítja, egy titkosítatlan szolgáltatásnál vagy egy a tanúsítványt nem ellenőrző alkalmazásnál viszont semmi nem jelez.
DNS-szűrés: kategóriák, fenyegetéslisták, saját szabályok
A DNS-szűrés a feloldónál dönt. Ha a kért név tiltott, a feloldó nem a valódi címet adja vissza, hanem hibaválaszt (NXDOMAIN vagy REFUSED), vagy egy figyelmeztető oldal címét. A kapcsolat így létre sem jön. Mivel a döntés a névfeloldáskor születik, a szűrés protokolltól függetlenül hat: a webes forgalomra, a levelezőkliensre és arra a kártevőre is, amely saját protokollon próbálna kapcsolódni. Az amerikai NSA és CISA közös útmutatója (Selecting a Protective DNS Service, 2021) az ilyen szűrő feloldót „protective DNS” néven tárgyalja.
A szabályok forrásai
- Fenyegetéslisták. Kártevő-, adathalász- és vezérlőtartományok listái, amelyeket a szűrőszolgáltatás vagy a tűzfal gyártója folyamatosan frissít. A védelem nagy része ebből jön, és a minősége azon múlik, milyen gyorsan kerül fel egy új kampány tartománya.
- Kategóriák. A tartományok tartalom szerinti besorolása, például szerencsejáték, fájlmegosztás, újonnan regisztrált vagy még be nem sorolt tartomány. Az újonnan regisztrált tartományok tiltása vagy figyelése gyakori beállítás, mert az adathalász- és kártevőkampányok sokszor néhány napos neveket használnak. Hátránya, hogy egy jogszerű új szolgáltatás is fennakadhat, amíg a besorolása meg nem történik.
- Saját szabályok. A szervezet saját tiltó és engedélyező listája. A tiltólistára kerülhetnek egy incidens során talált tartományok, az engedélyezőlistára azok a partneroldalak, amelyeket a kategóriaszűrő tévesen fog meg.
Sok DNS-szerver a külső tiltólistákat Response Policy Zone (RPZ) formában fogadja. A lista ilyenkor egy különleges zóna, amelyet a feloldó a szokásos zónaátvitellel tölt le a kiadótól, így a frissítéshez nem kell külön mechanizmus.
Korlátok
A DNS-szűrés csak akkor hat, ha a kliens a szűrő feloldót kérdezi. Egy kézzel beállított külső DNS-szerver, egy saját feloldót használó alkalmazás vagy a titkosított DNS megkerüli. A név nélkül, közvetlenül IP-címre induló kapcsolatokat sem látja. Egy tartományon belül pedig nem tud különbséget tenni: ha a kártékony fájl egy jogszerű tárhely- vagy fájlmegosztó szolgáltatás tartományán van, a név tiltása mindenkit kizár, az engedése pedig a kártevőt is átengedi. Ilyenkor a tűzfal URL- és tartalomszűrése dönthet finomabban, erről az új generációs tűzfalakról szóló cikk ír.
A blokkolt lekérdezés riasztásnak is jó. Ha egy gép rendszeresen vezérlőtartományt kérdez, akkor valószínűleg fertőzött, akkor is, ha a kapcsolat a szűrés miatt nem jött létre. A szűrő naplóját ezért a többi biztonsági naplóval együtt érdemes gyűjteni és figyelni, nem csak a blokkolások számát nézni.
DNS-alagút és generált tartománynevek felismerése
A DNS-alagút (DNS tunneling) a lekérdezéseket adatszállításra használja. A kliens az elküldendő adatot kódolja, és egy a támadó által üzemeltetett tartomány altartományába írja, egy hosszú, véletlennek látszó karaktersorként a név elején. A kérdés a belső DNS-szerveren és a külső feloldókon át eljut a támadó autoritatív névszerveréhez, amely a választ szintén kódolva küldi vissza, jellemzően TXT, NULL vagy CNAME rekordban. A fertőzött gépnek ehhez nem kell közvetlenül kijutnia az internetre, elég, ha a belső DNS-szerver kifelé rekurzívan felold.
Az RFC 1035 egy címke hosszát 63, egy teljes névét 255 oktetre korlátozza, ezért egy lekérdezés kevés adatot visz. Az alagút emiatt sok, gyors egymásutánban küldött kérdésből áll, és éppen erről ismerhető fel.
Ismertetőjelek
- hosszú, nagy entrópiájú, véletlenszerű betű- és számsorozatnak látszó altartományok, sokszor a megengedett címkehossz közelében;
- egyetlen tartomány alatt nagyon sok, egymástól mind különböző altartomány;
- szokatlan rekordtípusok: sok TXT- vagy NULL-lekérdezés olyan gépről, amely egyébként csak címet kérdez;
- egyenletes ritmusú lekérdezések, vagy munkaidőn kívüli csúcsok;
- egy tartomány felé lekérdezett nagy összes adatmennyiség.
Egyik jel sem bizonyít önmagában. Jogszerű szolgáltatások is használnak hosszú, kódolt altartományokat, például egyes vírusvédelmi felhőlekérdezések, tiltólista- (DNSBL) és telemetria-lekérdezések. Az észlelés ezért a jelek együttesére és egy kivétellistára épül, amely az ismert, jóindulatú forrásokat kiveszi a vizsgálatból.
Generált tartománynevek (DGA)
A domain generation algorithm (DGA) a kártevőbe épített eljárás, amely például a dátumból rendszeresen nagy számú lehetséges nevet állít elő. A támadó ezek közül csak néhányat regisztrál, a kártevő pedig végigpróbálja a listát, amíg egy élő nevet el nem ér. Egyetlen név tiltása így nem szakítja meg a kapcsolatot. A hálózaton úgy látszik, hogy egy gép rövid idő alatt sok értelmetlen nevet kérdez, és ezek többségére NXDOMAIN válasz jön, mert a nevek nincsenek regisztrálva. A MITRE ATT&CK ezt a technikát T1568.002 azonosítóval írja le.
Rokon módszer a fast flux (T1568.001): ugyanaz a név nagyon rövid TTL-lel, gyakran változó IP-címekre mutat, így a mögötte álló szervereket nehezebb egyenként lekapcsolni vagy címre tiltani.
Mit lehet tenni ellene
Az alagút feltétele, hogy a belső gépek DNS-forgalma szabadon kijusson, vagy a belső szerver bármilyen külső nevet kérdés nélkül feloldjon. Ha a tűzfal a kifelé menő 53-as portot (UDP és TCP) csak a belső DNS-szervereknek engedi, minden lekérdezés egy helyen halad át, ott naplózható és vizsgálható. A belső szervereken vagy a tűzfal DNS-vizsgálatában ezután a fenti jelekre épülő szabályok állíthatók be, a DGA- és alagútfelismerést pedig sok DNS-szűrő szolgáltatás is tartalmazza. A gyűjtendő naplókról és a megőrzésről a naplózásról szóló cikk szól részletesebben.
Titkosított DNS: DoH és DoT a vállalati hálózatban
A hagyományos DNS-lekérdezés titkosítatlan, az út mentén bárki láthatja, és egy támadó módosíthatja is. Erre két szabványos válasz van. A DNS over TLS (DoT, IETF RFC 7858, 2016) a lekérdezéseket TLS-kapcsolatban, a dedikált 853-as TCP-porton küldi. A DNS over HTTPS (DoH, IETF RFC 8484, 2018) HTTPS-kérésekbe csomagolja őket, és a 443-as porton fut, ugyanott, ahol a webes forgalom.
Nyilvános wifin vagy otthoni hálózaton ez valódi védelem, mert a hálózat üzemeltetője vagy egy támadó nem látja és nem hamisítja a lekérdezéseket. A vállalati hálózatban kétélű. Ha egy böngésző vagy alkalmazás a saját beépített DoH-feloldóját használja, a lekérdezések megkerülik a belső DNS-szervert: a DNS-szűrés nem hat rájuk, a belső nevek nem oldódnak fel, és a lekérdezésnaplóból is hiányoznak. Ugyanezt a kártevők is kihasználhatják, mert a DoH-forgalom a hálózaton közönséges HTTPS-nek látszik.
Hogyan lehet kézben tartani
- A titkosítás megmaradhat, de a belső feloldóig. Ha a belső szerver támogatja, a kliensek DoT-tal vagy DoH-val kapcsolódhatnak hozzá, és onnan megy tovább a kérdés.
- A böngészők és operációs rendszerek többségében a beépített DoH központi házirenddel kikapcsolható, vagy egy megadott feloldóhoz köthető. A felügyelt gépeken ez a legmegbízhatóbb megoldás.
- A 853-as port kifelé a belső feloldók kivételével tiltható, így a DoT nem jut ki a hálózatból.
- A DoH a portja alapján nem szűrhető. A tűzfalak az ismert nyilvános DoH-feloldók címlistájával vagy alkalmazásfelismeréssel blokkolják. Ez a nagy, ismert szolgáltatóknál működik, egy támadó saját DoH-szerverénél nem.
A nem felügyelt eszközöknél és a kártevőknél tehát a tiltás nem ad teljes megoldást. Ezeknél a belső DNS-en kívüli névfeloldást a hálózat gyanúsnak kezeli, és ha egy gép a belső feloldó helyett feltűnően sokat beszél egy ismeretlen HTTPS-végponttal, az vizsgálatot érdemel.
DNSSEC: mit hitelesít és mit nem
A DNSSEC (DNS Security Extensions, IETF RFC 4033, 4034 és 4035, 2005) digitális aláírással igazolja, hogy egy DNS-válasz a zóna gazdájától származik, és útközben nem módosult. A zóna üzemeltetője aláírja a rekordjait. Az aláírás RRSIG rekordként kerül a zónába, a nyilvános kulcs DNSKEY rekordként. A szülőzóna egy DS rekordban a gyerekzóna kulcsának lenyomatát tárolja, így a bizalmi lánc a gyökérzónáig vezethető vissza, amely 2010 óta aláírt. Az ellenőrző (validáló) feloldó ezt a láncot követi végig, és ha egy aláírás nem egyezik, a választ elveti, a kliensnek pedig SERVFAIL hibát ad.
Ami ellen véd
A DNSSEC a hamisított válaszok ellen véd, akár gyorsítótár-mérgezésről, akár az út mentén átírt csomagról van szó. Gyorsítótár-mérgezésnél a támadó a valódi válasz előtt próbál egy hamisat eljuttatni a feloldóhoz, és ha ez sikerül, a feloldó a hamis címet a TTL lejártáig minden kliensnek kiosztja. Az RFC 1035 szerinti 16 bites tranzakcióazonosító mellé az IETF RFC 5452 (2009) a forrásport véletlenszerűsítését is ajánlja, ami a találgatást jelentősen megnehezíti, de lehetetlenné nem teszi. A DNSSEC-kel a hamis válasz már kriptográfiailag kimutatható. Az aláírt nemlétezés-igazolás (NSEC, illetve NSEC3, IETF RFC 5155, 2008) azt is igazolja, hogy egy név valóban nem létezik, így a támadó a „nincs ilyen név” választ sem tudja hamisítani.
Ami ellen nem
- Nem titkosít. A lekérdezés és a válasz ugyanúgy olvasható, a lekérdezések bizalmasságát a DoT és a DoH védi.
- Nem mondja meg, hogy egy tartomány jóindulatú-e. Egy adathalász tartomány is lehet hibátlanul aláírva, a DNSSEC csak azt igazolja, hogy a válasz a zóna gazdájától jön.
- Csak ott hat, ahol a zónát aláírták és a feloldó ellenőriz. A kliens jellemzően nem maga validál, hanem a feloldó „ellenőrizve” jelzésében (AD bit) bízik. Ha a kliens és a feloldó közötti szakasz védtelen, ez a jelzés is hamisítható.
- Nem véd egy feltört regisztrátori fiók ellen. Aki a tartomány névszervereit vagy DS rekordját átírhatja, az a saját kulcsával érvényes aláírást is készíthet.
Üzemeltetési kockázat
Az aláírt zóna karbantartást igényel. Az aláírások lejárnak, a kulcsokat időnként cserélni kell, és a DS rekordot a regisztrátornál a kulcscserével összehangolva kell frissíteni. Ha ez elcsúszik, a validáló feloldók az egész tartományt elérhetetlennek látják, miközben a szerverek hibátlanul működnek. Saját zóna aláírása előtt ezért a kulcscsere folyamatát és a lejáratok figyelését érdemes kidolgozni. A belső feloldón a validálás bekapcsolása kisebb kockázattal jár, és az aláírt külső nevekre azonnal védelmet ad.
A belső DNS-szerverek védelme
A belső DNS-szerver sok hálózatban a címtárszolgáltatás része. Ha leáll vagy hamis adatot ad, vele együtt áll le a bejelentkezés, a fájlmegosztás és szinte minden belső alkalmazás. A védelme ezért nem csak szűrési kérdés.
Szerepek és elérés
- A rekurzív feloldás csak a belső hálózatnak legyen elérhető. Az internet felől bárkinek válaszoló nyílt feloldót a támadók erősítéses túlterheléses támadásra használják: a megtámadott címet hamisított forráscímként megadva kis kérdést küldenek, a feloldó pedig sokkal nagyobb választ küld a célpontnak. A túlterheléses támadásokról a DDoS-ról szóló cikk ír.
- Az internet felé hirdetett, autoritatív zónát lehetőleg külön szerver vagy szolgáltató szolgálja ki, ne az a belső szerver, amely a belső neveket is tárolja. A belső és a külső nézet szétválasztása (split-horizon DNS) azt is biztosítja, hogy a belső nevek és címek kívülről ne legyenek lekérdezhetők.
- A zónaátvitel (AXFR, IETF RFC 5936, 2010) csak a megnevezett másodlagos szerverek felé legyen engedélyezve, lehetőleg TSIG-gel hitelesítve (IETF RFC 8945, 2020). Egy szabadon letölthető belső zóna a támadónak kész hálózati térképet ad.
- A dinamikus frissítés, amellyel a kliensek a saját rekordjukat bejegyzik, csak hitelesítve legyen engedélyezve, különben egy belső gép más gépek nevét is átírhatja.
Kifelé menő forgalom
A kliensek csak a belső DNS-szervereket érjék el, az 53-as és a 853-as port kifelé csak a feloldókról legyen nyitva. A belső feloldó továbbíthatja a kérdéseket egy szűrő feloldónak, így a szűrés minden gépre hat, a lekérdezésnapló pedig egy helyen keletkezik.
Üzemeltetés
- Legalább két szerver, eltérő hardveren vagy helyen, mert a DNS kiesése az egész hálózatot megállítja.
- A DNS-szoftver frissítése a gyártói biztonsági közlemények szerint. A feloldók kívülről érkező válaszokat dolgoznak fel, a sebezhetőségeik ezért távolról is kihasználhatók.
- A lekérdezésnapló gyűjtése és megőrzése, hogy egy incidensnél visszakereshető legyen, melyik gép mikor kérdezett egy gyanús nevet.
- Adminisztratív hozzáférés név szerinti fiókkal, többfaktoros hitelesítéssel, a felhasználói hálózattól elkülönített felügyeleti hálózatból.
- A rekordváltozások figyelése, mert egy belső név váratlan átírása egy támadás része is lehet.
Kapcsolódó szolgáltatás: Tűzfal és VPN →
