Overname van subdomeinen voorkomen in Azure App Service

Overnames van subdomeinen vormen een veelvoorkomende bedreiging voor organisaties die regelmatig veel resources maken en verwijderen. Een subdomeinovername kan optreden wanneer u een DNS-record hebt die verwijst naar een niet-ingerichte Azure-resource. Dergelijke DNS-records worden ook wel 'zwevende DNS-vermeldingen' genoemd. Met overnames van subdomeinen kunnen kwaadwillende actoren verkeer omleiden dat is bedoeld voor het domein van een organisatie naar een site die schadelijke activiteiten uitvoert.

De risico's van overname van subdomeinen zijn onder andere:

  • Verlies van controle over de inhoud van het subdomein
  • Cookies verzamelen bij nietsvermoedende bezoekers
  • Phishingcampagnes
  • Verdere risico's van klassieke aanvallen, zoals XSS, CSRF of CORS bypass

Voor meer informatie over het overnemen van subdomeinen, zie het voorkomen van loshangende DNS-vermeldingen en subdomeinovername.

Azure App Service biedt naamreservering, domeinverificatietokens en onveilige unieke standaardhostnamen om overname van subdomeinen te voorkomen.

De meest effectieve manier om uw App Service-resources te beschermen tegen overname van subdomeinen is door veilige unieke standaardhostnamen te gebruiken. Deze functie is algemeen beschikbaar voor Web Apps, Functie-apps en Logic Apps (Standard).

Wanneer u beveiligde unieke standaardhostnamen inschakelt, ontvangt uw app een standaardhostnaam die een gerandomiseerde hash en een regio-id bevat, waardoor deze uniek is voor uw organisatie. Deze indeling zorgt ervoor dat niemand buiten uw organisatie een resource kan maken met dezelfde standaardhostnaam, waardoor het risico van overname van subdomeinen via zwevende DNS-vermeldingen wordt geëlimineerd.

Hoe werkt het?

Traditionele App Service-resources gebruiken een standaardhostnaamindeling die globaal voorspelbaar is:

Algemeen (origineel) Uniek (nieuw)
Standaardhostnaam <AppName>.azurewebsites.net <AppName>-<Hash>.<Region>.azurewebsites.net
SCM-eindpunt <AppName>.scm.azurewebsites.net <AppName>-<Hash>.scm.<Region>.azurewebsites.net

Een web-app met de naam contoso, die is geïmplementeerd in East US, kan bijvoorbeeld het volgende ontvangen:

contoso-a6gqaeashthkhkeu.eastus-01.azurewebsites.net

De hash van 16 tekens is deterministisch binnen een configureerbaar bereik, zodat u consistente hostnamen in omgevingen kunt garanderen wanneer dat nodig is.

Hashbereikopties

Wanneer u een resource maakt met een unieke standaardhostnaam, kiest u een bereik dat bepaalt hoe de hash wordt gegenereerd:

Scope Description
Tenant opnieuw gebruiken Dezelfde hash voor dezelfde app-naam voor alle abonnementen in uw Microsoft Entra tenant.
Abonnement opnieuw gebruiken Dezelfde hash voor dezelfde app-naam binnen hetzelfde abonnement.
Resourcegroep opnieuw gebruiken Dezelfde hash voor dezelfde app-naam binnen dezelfde resourcegroep.
Geen hergebruik Telkens een unieke hash. Maximale isolatie.

Tip

Als u resources regelmatig opnieuw implementeert in omgevingen (bijvoorbeeld van een testabonnement naar een productieabonnement onder dezelfde tenant), gebruikt u Tenant hergebruik om ervoor te zorgen dat uw hostnamen consistent blijven tussen abonnementen.

Implementatiesites

Implementatiesites volgen dezelfde indeling als de productiesite, maar elke site ontvangt een eigen afzonderlijke hash:

Standaardhostnaam Hostnaam van slot
Formatteren <AppName>-<Hash>.<Region>.azurewebsites.net <AppName>-<SlotName>-<Hash>.<Region>.azurewebsites.net

Slots worden altijd gemaakt met dezelfde scope als de productiesite.

Hoe u dit kunt inschakelen

Je configureert veilige, unieke standaard hostnamen wanneer je de resource aanmaakt. Je kunt ze niet achteraf toepassen op bestaande bronnen. De manier waarop je ze inschakelt hangt af van de client die je gebruikt:

  • Azure-portaal: Nieuwe Web Apps, Function Apps en Logic Apps (Standard) die in het Azure-portaal zijn gemaakt, gebruiken automatisch veilige, unieke standaard hostnamen op alle ondersteunde SKU's. Er is geen extra configuratie vereist.
  • Azure CLI, ARM-templates en REST API: Je moet je expliciet aanmelden door de hostnaamscope in te stellen op het aanmaakverzoek. Stel deze waarde in voor elke nieuwe implementatie zodat resources die buiten het portaal zijn aangemaakt hetzelfde standaard hostnaamformaat gebruiken als resources die in het portaal worden gemaakt.

Gebruik de parameter bij het --domain-name-scope maken van een nieuwe resource om beveiligde unieke standaardhostnamen in te schakelen.

Hulpmiddelsoort Opdracht Reference
Web Apps- az webapp create --name <AppName> --resource-group <ResourceGroup> --plan <AppServicePlan> --domain-name-scope TenantReuse Gebruik de opdracht az webapp create om een webapp te maken.
Functie-apps az functionapp create --name <AppName> --resource-group <ResourceGroup> --storage-account <StorageAccount> --consumption-plan-location <Region> --domain-name-scope TenantReuse az FunctionApp Create
Logic Apps (Standaard) az logicapp create --name <AppName> --resource-group <ResourceGroup> --storage-account <StorageAccount> --domain-name-scope TenantReuse az logicapp create

De --domain-name-scope parameter accepteert de volgende waarden: NoReuse, ResourceGroupReuse, SubscriptionReuse, . TenantReuse

Bestaande bronnen migreren

Omdat deze functie alleen kan worden ingeschakeld tijdens het maken, hebt u twee opties voor bestaande resources:

  • Kopieer een bestaande app naar een nieuwe app waarbij beveiligde, unieke standaardhostnamen zijn ingeschakeld.
  • Herstel vanuit een back-up naar een nieuwe app met beveiligde unieke standaardhostnamen ingeschakeld.

Beide opties zijn beschikbaar in de Azure-portal.

Waarom dit nu aannemen

Beveiligde unieke standaardhostnamen bieden standaard beveiliging. In tegenstelling tot andere risicobeperkingsstrategieën die doorlopende DNS-hygiëne en handmatige interventie vereisen, bouwt deze benadering de beveiliging rechtstreeks in de hostnaamstructuur. Wanneer deze functie is ingeschakeld:

  • Er kan geen externe actor uw standaardhostnaam opnieuw maken.
  • Zwevende DNS-vermeldingen kunnen niet worden misbruikt voor overname van subdomeinen.
  • Er zijn geen extra configuratiestappen nodig, behalve het inschakelen van de functie tijdens het maken.

Gebruik veilige, unieke standaard hostnamen voor elke nieuwe App Service-implementatie. Het Azure-portaal past deze configuratie al automatisch toe voor nieuwe resources op ondersteunde SKU's. Door je Azure CLI, ARM-template en REST API-implementaties uit te lijnen met hetzelfde standaard hostnaamformaat blijft je provisioning consistent met de aanbevolen App Service-configuratie.

Opmerking

De regio-id in de hostnaam (bijvoorbeeld eastus-01) kan verschillende numerieke achtervoegsels gebruiken voor toekomstige implementaties. Zorg dat u niet strikt afhankelijk bent van de exacte combinatie van regio en nummer.

Verwante inhoud

Hoe App Service overnames van subdomeinen voorkomt

Na het verwijderen van een App Service-app of App Service Environment (ASE) mag de bijbehorende DNS niet opnieuw worden gebruikt, behalve door abonnementen die deel uitmaken van de tenant van het abonnement dat oorspronkelijk eigendom is van de DNS. De klant heeft dus enige tijd om koppelingen of aanwijzers naar de genoemde DNS op te schonen of de DNS in Azure vrij te maken door de resource opnieuw te maken met dezelfde naam. Dit gedrag is standaard ingeschakeld in Azure App Service voor *.azurewebsites.net en *.appserviceenvironment.net resources, zodat er geen klantconfiguratie is vereist.

Voorbeeldscenario

Abonnement A en abonnement B zijn de enige abonnementen die deel uitmaken van tenant AB. Abonnement A bevat een App Service-webapp test met DNS-naam test.azurewebsites.net. Na het verwijderen van de app kunnen alleen abonnementen A of B de DNS-naam test.azurewebsites.net onmiddellijk opnieuw gebruiken door een web-app met de naam test te maken. Geen andere abonnementen mogen direct na het verwijderen van de resource de naam claimen.

Hoe u overnames van subdomeinen kunt voorkomen

Wanneer u DNS-vermeldingen voor Azure App Service maakt, maakt u een asuid.{ subdomein} TXT-record met de domeinverificatie-id. Wanneer een dergelijke TXT-record bestaat, kan geen ander Azure-abonnement het aangepaste domein valideren of overnemen, tenzij ze hun tokenverificatie-id toevoegen aan de DNS-vermeldingen.

Deze records voorkomen dat u een andere App Service-app maakt met dezelfde naam uit uw CNAME-vermelding. Zonder de mogelijkheid om het eigendom van de domeinnaam te bewijzen, kunnen bedreigingsactoren geen verkeer ontvangen of de inhoud beheren.

DNS-records moeten worden bijgewerkt voordat de site wordt verwijderd om ervoor te zorgen dat slechte actoren het domein niet kunnen overnemen tussen de periode van verwijdering en het opnieuw maken.

Zie Een bestaand aangepast domein instellen in Azure App Service om een domeinverificatie-id op te halen.

  • Last updated on