Az értékhiányos DNS-bejegyzések megelőzése és az altartomány-átvétel elkerülése

Ez a cikk ismerteti az altartományok átvételének gyakori biztonsági fenyegetését, valamint azokat a lépéseket, amelyek elhárítására van lehetőség.

Mi az az altartomány-átvétel?

Az altartomány-átvételek gyakori, nagy súlyosságú fenyegetést jelentenek az olyan szervezetek számára, amelyek rendszeresen létrehoznak és törölnek számos erőforrást. Altartomány-átvétel akkor fordulhat elő, ha olyan DNS-rekordtal rendelkezik, amely egy elavult Azure-erőforrásra mutat. Az ilyen DNS-rekordok „lógó DNS-bejegyzés” néven is ismertek. A CNAME-rekordok különösen sebezhetőek ezzel a fenyegetéssel szemben. Az altartomány-átvételek lehetővé teszik a rosszindulatú aktoroknak a szervezet egyik tartományának szánt forgalom átirányítását egy rosszindulatú tevékenységet végző webhelyre.

Az altartományok átvételének gyakori forgatókönyve:

1. ALKOTÁS:

   1. Egy Azure-erőforrást teljes tartománynévvel (FQDN) kell kiépíteni app-contogreat-dev-001.azurewebsites.net.

   2. A DNS-zónában egy CNAME rekordot rendelhet hozzá azzal az altartománysal greatapp.contoso.com , amely a forgalmat az Azure-erőforráshoz irányítja.

2. LEÉPÍTÉS:

   1. Miután már nincs rá szükség, az Azure-erőforrás le lesz bontva vagy törölve lesz.

      Ekkor a CNAME rekordot greatapp.contoso.com el kell távolítani a DNS-zónából. Ha a CNAME rekordot nem távolítja el, akkor aktív tartományként van meghirdetve, de nem irányítja a forgalmat aktív Azure-erőforráshoz. Most már rendelkezik egy "dangling" DNS-rekorddal.

   2. A dangling subdomain mostantól greatapp.contoso.comsebezhető, és átvehető egy másik Azure-előfizetés erőforrásához rendelve.

3. ÁTVÉTEL:

   1. A gyakran elérhető módszerek és eszközök használatával a fenyegetést jelző szereplő felderíti a dangling altartományt.

   2. A fenyegetéselktor kiépít egy Azure-erőforrást a korábban felügyelt erőforrás teljes tartománynevével. Ebben a példában. app-contogreat-dev-001.azurewebsites.net

   3. Az altartományba greatapp.contoso.com küldött forgalmat a rendszer átirányítja a rosszindulatú szereplő erőforrásához, ahol ők irányítják a tartalmat.

Az altartományok átvételének kockázatai

Ha egy DNS-rekord egy nem elérhető erőforrásra mutat, magát a rekordot el kell távolítani a DNS-zónából. Ha nem törlik, az egy "dangling DNS" rekord, és lehetőséget teremt az altartomány átvételére.

A Dangling DNS-bejegyzések lehetővé teszik, hogy a fenyegetést figyelő szereplők átvegye az irányítást a társított DNS-név felett egy rosszindulatú webhely vagy szolgáltatás üzemeltetéséhez. A szervezet altartományában található rosszindulatú lapok és szolgáltatások a következőt eredményezhetik:

• Az altartomány tartalmának szabályozásának elvesztése – Negatív sajtó arról, hogy a szervezet nem tud biztonságossá tenni a tartalmát, a márka sérülését és a bizalom elvesztését.

• Cookie-k begyűjtése gyanútlan látogatóktól – A webalkalmazások gyakran teszik elérhetővé a munkamenet-cookie-kat az altartományokban (*.contoso.com). Bármely altartomány hozzáférhet hozzájuk. A fenyegetést figyelő szereplők altartomány-átvételt használhatnak egy hiteles megjelenésű oldal létrehozásához, a gyanútlan felhasználók megcsalásához, és a cookie-k begyűjtéséhez (még a biztonságos cookie-khoz is). Gyakori tévhit, hogy az SSL-tanúsítványok használata védi a webhelyet és a felhasználók cookie-jait az átvételtől. A fenyegetéselosztó azonban használhatja az eltérített altartományt érvényes SSL-tanúsítvány igénylésére és fogadására. Az érvényes SSL-tanúsítványok hozzáférést biztosítanak a biztonságos cookie-khoz, és tovább növelhetik a rosszindulatú webhely vélt legitimitását.

• Adathalászati kampányok – A rosszindulatú szereplők gyakran kihasználják a hitelesnek látszó altartományokat az adathalász kampányokban. A kockázat a rosszindulatú webhelyekre és az MX-rekordokra is kiterjed, amelyek lehetővé tehetik, hogy a fenyegetést okozó szereplők megbízható márkákhoz társított megbízható altartományokra irányuló e-maileket kapjanak.

• További kockázatok – Rosszindulatú webhelyek használatával eszkalálható más klasszikus támadások, például XSS, CSRF, CORS-megkerülés stb.

A dangling DNS-bejegyzések azonosítása

A szervezeten belüli, esetleg dangoló DNS-bejegyzések azonosításához használja a Microsoft GitHub által üzemeltetett PowerShell-eszközeit (Get-DanglingDnsRecords).

Ezzel az eszközzel az Azure-ügyfelek listázhatják az előfizetéseiken vagy bérlőikben létrehozott, meglévő Azure-erőforrásokhoz társított CNAME-mel rendelkező tartományokat.

Ha a CNAME-k más DNS-szolgáltatásokban találhatók, és Azure-erőforrásokra mutatnak, a CNAME-eket egy bemeneti fájlban adja meg az eszköznek.

Az eszköz az alábbi táblázatban felsorolt Azure-erőforrásokat támogatja. Az eszköz kinyeri vagy bemenetként veszi fel a bérlő összes CNAM-ját.

Előfeltételek

Futtassa a lekérdezést olyan felhasználóként, aki rendelkezik a következővel:

• legalább olvasói szintű hozzáférés az Azure-előfizetésekhez
• az Azure Resource Graphhoz való hozzáférés olvasása

Ha Ön a szervezet bérlőjének globális rendszergazdája, kövesse az Elevate access (Hozzáférés emelése) című útmutatót az összes Azure-előfizetés és felügyeleti csoport kezeléséhez, hogy hozzáférjen a szervezet összes előfizetéséhez

A szkript futtatása

További információ a Get-DanglingDnsRecords.ps1 PowerShell-szkriptről, és töltse le a GitHubról: https://aka.ms/Get-DanglingDnsRecords.

A lógó DNS-bejegyzések szervizelése

Tekintse át a DNS-zónákat, és azonosítsa az átvett vagy átvett CNAME rekordokat. Ha azt észleli, hogy vannak lógó vagy átvett altartományok, távolítsa el a sebezhető altartományokat, és hárítsa el a kockázatokat az alábbi lépésekkel:

1. A DNS-zónából távolítsa el az összes olyan CNAME-rekordot, amelyek már nem üzemelő erőforrások teljes tartománynevére mutatnak.

2. Ha engedélyezni szeretné, hogy a forgalom a vezérlő erőforrásaihoz legyen irányítva, további erőforrásokat építhet ki a csonkoló altartományok CNAME rekordjaiban megadott teljes tartománynevekkel.

3. Tekintse át az alkalmazáskódot az adott altartományokra mutató hivatkozásokat keresve, és frissítse a helytelen vagy elavult altartomány-hivatkozásokat.

4. Vizsgálja meg, hogy történt-e biztonsági rés, és tegyen lépéseket a szervezet incidenskezelési eljárásai szerint. Tippek és ajánlott eljárások a vizsgálathoz:

   Ha az alkalmazáslogika titkos kulcsokat( például OAuth-hitelesítő adatokat) eredményez, amelyeket a rendszer a dangling altartományokra küld, vagy bizalmas adatokat továbbít az altartományoknak, lehetséges, hogy ezek az adatok harmadik felek számára is elérhetők lesznek.

5. Ismerje meg, hogy miért nem távolították el a CNAME rekordot a DNS-zónából az erőforrás megszüntetésekor, és tegyen lépéseket annak biztosítására, hogy a DNS-rekordok megfelelően frissüljenek az Azure-erőforrások jövőbeli leépítésekor.

Dangling DNS-bejegyzések megakadályozása

A biztonsági program fontos része annak biztosítása, hogy a szervezet olyan folyamatokat implementáljon, amelyek megakadályozzák a dns-bejegyzések és az ebből eredő altartomány-átvételek használatát.

Egyes Azure-szolgáltatások olyan funkciókat kínálnak, amelyek segítséget nyújtanak a megelőző intézkedések létrehozásához, és az alábbiakban részletezzük. A probléma megelőzésére szolgáló egyéb módszereket a szervezet ajánlott eljárásain vagy szabványos üzemeltetési eljárásain keresztül kell létrehozni.

A Microsoft Defender for App Service engedélyezése

Felhőhöz készült Microsoft Defender integrált felhőbeli számítási feladatvédelmi platformja (CWPP) számos tervet kínál az Azure-beli, hibrid és többfelhős erőforrások és számítási feladatok védelmére.

Az App Service-hez készült Microsoft Defender csomag tartalmazza a dangling DNS-észlelést. Ha ez a csomag engedélyezve van, biztonsági riasztásokat kap, ha leszerel egy App Service-webhelyet, de nem távolítja el az egyéni tartományát a DNS-regisztrálótól.

Felhőhöz készült Microsoft Defender dangling DNS-védelme elérhető, függetlenül attól, hogy tartományait az Azure DNS-sel vagy egy külső tartományregisztrálóval kezelik, és windowsos és linuxos App Service-re is vonatkozik.

Erről és a Microsoft Defender-csomagok egyéb előnyeiről a Microsoft Defender for App Service bemutatása című témakörben olvashat bővebben.

Azure DNS-aliasrekordok használata

Az Azure DNS aliasrekordjai megakadályozhatják a referenciák keveredését, ha egy DNS-rekord életciklusát egy Azure-erőforrással kapcsolják össze. Vegyük például egy aliasrekordként minősített DNS-rekordot, amely nyilvános IP-címre vagy Traffic Manager-profilra mutat. Ha törli az alapul szolgáló erőforrásokat, a DNS-aliasrekord üres rekordhalmazsá válik. Már nem hivatkozik a törölt erőforrásra. Fontos megjegyezni, hogy az aliasrekordok védelmének korlátai vannak. A lista jelenleg a következőkre korlátozódik:

• Azure Front Door
• Traffic Manager-profilok
• Az Azure Content Delivery Network (CDN) végpontjai
• Nyilvános IP-címek

A jelenleg korlátozott szolgáltatásajánlatok ellenére javasoljuk, hogy az altartomány-átvétel elleni védelemhez használjon aliasrekordokat, amikor csak lehetséges.

További információ az Azure DNS aliasrekordjainak képességeiről.

A Azure-alkalmazás szolgáltatás egyéni tartományellenőrzésének használata

Amikor DNS-bejegyzéseket hoz létre Azure-alkalmazás szolgáltatáshoz, hozzon létre egy asuidot.{ subdomain} TXT rekord tartomány-ellenőrzési azonosítóval. Ha ilyen TXT rekord létezik, egyetlen másik Azure-előfizetés sem tudja érvényesíteni az egyéni tartományt, azaz átveheti azt.

Ezek a rekordok nem akadályozzák meg, hogy valaki a CNAME bejegyzésben szereplő névvel hozza létre a Azure-alkalmazás szolgáltatást. A tartománynév tulajdonjogának igazolása nélkül a fenyegetést teremtő szereplők nem fogadhatnak forgalmat, és nem irányíthatják a tartalmat.

További információ arról, hogyan képezhet le meglévő egyéni DNS-nevet Azure-alkalmazás szolgáltatásra.

Folyamatok létrehozása és automatizálása a fenyegetés mérséklése érdekében

Gyakran a fejlesztők és az üzemeltetési csapatokon múlik, hogy karbantartási folyamatokat futtasson a DNS-fenyegetések keveredésének elkerülése érdekében. Az alábbi gyakorlatok segítenek abban, hogy szervezete ne szenvedjen ilyen fenyegetéstől.

• Megelőzési eljárások létrehozása:

  • Tájékoztassa az alkalmazásfejlesztőt, hogy mindig irányítsa át a címeket, amikor törlik az erőforrásokat.

  • Helyezze a "DNS-bejegyzés eltávolítása" elemet a szolgáltatás leszerelésekor szükséges ellenőrzések listájára.

  • Törölje a zárolásokat minden olyan erőforráson, amely egyéni DNS-bejegyzéssel rendelkezik. A törlési zárolás azt jelzi, hogy a leképezést el kell távolítani az erőforrás kivonása előtt. Az ehhez hasonló mértékek csak belső oktatási programokkal kombinálva működnek.

• Felderítési eljárások létrehozása:

  • Rendszeresen tekintse át a DNS-rekordokat, és győződjön meg arról, hogy az altartományok mind olyan Azure-erőforrásokra vannak leképezve, amelyek:

    • Létező – A DNS-zónák lekérdezése azure-altartományokra, például *.azurewebsites.net vagy *.cloudapp.azure.com mutató erőforrásokhoz (lásd az Azure-tartományok referencialistáját).
    • Saját tulajdonú – Győződjön meg arról, hogy ön az összes olyan erőforrás tulajdonosa, amelyet a DNS-altartományok céloznak.

  • Az Azure teljes tartománynevű végpontjainak és az alkalmazástulajdonosoknak a szolgáltatáskatalógusának karbantartása. A szolgáltatáskatalógus létrehozásához futtassa az alábbi Azure Resource Graph-lekérdezési szkriptet. Ez a szkript azoknak az erőforrásoknak a teljes tartománynév-végpontadatait ismerteti, amelyekhez hozzáféréssel rendelkezik, és egy CSV-fájlban adja ki őket. Ha rendelkezik hozzáféréssel a bérlő összes előfizetéséhez, a szkript az összes előfizetést az alábbi példaszkriptben látható módon veszi figyelembe. Ha az eredményeket egy adott előfizetésre szeretné korlátozni, szerkessze a szkriptet az ábrán látható módon.

• Szervizelési eljárások létrehozása:

  • Ha a rendszer dns-bejegyzéseket talál, a csapatnak meg kell vizsgálnia, hogy történt-e valamilyen kompromisszum.
  • Vizsgálja meg, hogy miért nem lett átirányítva a cím az erőforrás leszerelésekor.
  • Törölje a DNS-rekordot, ha már nincs használatban, vagy mutasson a szervezet tulajdonában lévő megfelelő Azure-erőforrásra (FQDN).

DNS-mutatók törlése vagy a DNS ismételt igénylése

A klasszikus felhőszolgáltatás-erőforrás törlésekor a megfelelő DNS az Azure DNS-szabályzatok szerint van fenntartva. A foglalási időszak alatt a DNS ismételt használata tilos lesz, kivéve azokat az előfizetéseket, amely eredetileg a DNS-t birtokolja, a Microsoft Entra-bérlőhöz tartozó előfizetések esetében. A foglalás lejárta után a DNS-t bármely előfizetés ingyenesen igényelheti. A DNS-foglalások használatával az ügyfélnek van némi ideje arra, hogy 1) törölje a társításokat/mutatókat az említett DNS-re, vagy 2) igényelje újra a DNS-t az Azure-ban. A javaslat az lenne, hogy a nem kívánt DNS-bejegyzéseket minél hamarabb törölje. A fenntartott DNS-név úgy származtatható, hogy hozzáfűzi a felhőszolgáltatás nevét az adott felhő DNS-zónához.

• Nyilvános – cloudapp.net
• Mooncake - chinacloudapp.cn
• Fairfax - usgovcloudapp.net
• BlackForest - azurecloudapp.de

Például a nyilvános "teszt" nevű üzemeltetett szolgáltatás dns-sel rendelkezik : "test.cloudapp.net"

Példa: Az "A" előfizetés és a "B" előfizetés az "AB" Microsoft Entra-bérlő egyetlen előfizetése. Az "A" előfizetés egy klasszikus felhőalapú szolgáltatást tartalmaz ,,teszt" DNS-névvel ,test.cloudapp.net'. A felhőszolgáltatás törlése után a rendszer a "test.cloudapp.net" DNS-névre foglal foglalást. A foglalási időszak alatt csak az "A" vagy a "B" előfizetés igényelheti a "test.cloudapp.net" DNS-nevet egy klasszikus, "teszt" nevű felhőszolgáltatás létrehozásával. Más előfizetések nem igényelhetik. A foglalási időszak után az Azure-beli előfizetések mostantól "test.cloudapp.net" jogcímet igényelhetnek.

Következő lépések

Az altartomány-átvétel elleni védelemhez használható kapcsolódó szolgáltatásokról és Azure-funkciókról az alábbi oldalakon olvashat bővebben.

• A Microsoft Defender for App Service engedélyezése – riasztások fogadása a DNS-bejegyzések észlelésekor

• A DNS-rekordok azure DNS-sel való keveredésének megakadályozása

• Tartomány-ellenőrzési azonosító használata egyéni tartományok hozzáadásakor Azure-alkalmazás szolgáltatásban

• Rövid útmutató: Az első Resource Graph-lekérdezés futtatása az Azure PowerShell használatával