Sammanfattning
Abstract
Den 19 maj 2020 gav Microsoft ut säkerhets rådgivning ADV200009. I den här rekommendationen beskrivs en DNS-attack som identifieras av israeliska forskare. Attacken, som kallas NXNSAttack, kan rikta sig till alla DNS-servrar, inklusive Microsoft DNS-och BIND-servrar som är auktoritära för en DNS-zon.
För DNS-servrar som finns på företagets intranät kan Microsoft få en risk för att den här risken blir för liten. Men DNS-servrar som bor i Edge-nätverk är utsatta för NXNSAttack. Windows Server 2016 DNS-servrar som befinner sig i Edge-nätverk ska uppgraderas till Windows Server 2016 eller senare versioner som stöder svars frekvens gränsen (RRL). RRL minskar förstärknings effekten när en riktad DNS-matchare frågar dina DNS-servrar.
Symptom
När en server för DNS-förstärkning görs kan något av följande inträffa:
-
CPU-användning för DNS är förhöjd.
-
DNS-svar Times ökning och svar kan sluta.
-
Ett oväntat antal NXDOMAIN-svar skapas av din autentiseringsserver.
Angrepps översikt
DNS-servrar har alltid varit utsatta för en matris med attacker. Av den här anledningen placeras DNS-servrar normalt bakom belastningsutjämnare och brand väggar i en DMZ.
För att utnyttja detta problem måste en angripare ha flera DNS-klienter. Vanligt vis inkluderar detta en botnet, till gång till dussin tals eller hundratals DNS-matchare som kan visa upp angreppet och en specialiserad DNS server-tjänst.
Den främsta angriparen är den som är auktoritär för en domän som angriparen äger. För att angreppet ska lyckas måste DNS-matcharna veta hur de kan nå angriparens domän och DNS-server. Den här kombinationen kan generera massor av kommunikation mellan de rekursiva matcharna och den skadelidandes auktoritära DNS-server. Resultatet är en DDoS-attack.
Säkerhets problem för MS DNS i företagets intranät
Interna, privata domäner går inte att matcha genom rottips och DNS-servrarna på toppnivå domänen. När du följer bästa praxis kan DNS-servrar som är auktoritära för privata, interna domäner, till exempel Active Directory-domäner, inte nås från Internet.
Även om det är tekniskt möjligt med en NXNSAttack av en intern domän från det interna nätverket krävs en illvillig användare i det interna nätverket som har åtkomst på administratörs nivå för att konfigurera interna DNS-servrar så att de pekar på DNS-servrar i angriparens domän. Denna användare måste också kunna skapa en skadlig zon i nätverket och lägga till en speciell DNS-server som kan köra NXNSAttack i företags nätverket. En användare som har den här åtkomst nivån prioriterar vanligt vis dold om han eller hon har upplyser en mycket synlig DNS DDoS-attack.
Säkerhets problem för MS DNS i Edge
En DNS-matchare på Internet använder rottips och servrar på toppnivå domänen för att lösa okända DNS-domäner. En angripare kan använda detta offentliga DNS-system för att använda valfri DNS-matchare med Internet för att pröva NXNSAttack förstärkning. När en förstärknings vektor upptäcks kan den användas som en del av en denial of service (DDoS)-attack mot alla DNS-servrar som är värdar för en offentlig DNS-domän (den skadelidande).
En Edge-DNS-server som fungerar som en matchare eller vidarebefordrare kan användas som en förstärknings vektor för angreppet om obeställda inkommande DNS-frågor som kommer från Internet tillåts. Med offentlig åtkomst kan en illvillig DNS-klient använda den som en del av den allmänna förstärknings attacken.
Auktoritära DNS-servrar för offentliga domäner måste tillåta oombedd inkommande DNS-trafik från matchare som gör rekursiva sökningar från DNS-infrastrukturen rot tips och topp domänen. Annars går det inte att komma åt domänen. Detta gör att alla auktoritära DNS-servrar kan vara möjliga offer för en NXNSAttack. Fristående Microsoft DNS-servrar bör köra Windows Server 2016 eller en senare version för att få RRL-support.
Lösning
Lös problemet genom att använda följande metod för lämplig server typ.
För intranät-motstående MS DNS-servrar
Risken för denna sårbarhet är för dålig. Övervaka interna DNS-servrar för ovanlig trafik. Inaktivera interna NXNSAttackers som finns i företagets intranät medan de upptäcks.
För fristående auktoritära DNS-servrar
Aktivera RRL som stöds i Windows Server 2016 och senare versioner av Microsoft DNS. Om du använder RRL på DNS-matchare minimerar den första attack förstärkningen. Om du använder RRL på en offentlig domän auktoritär DNS-Server minskar eventuell förstärkning som återspeglas från DNS-matcharen. Som standardRRL är inaktiverat. Mer information om RRL finns i följande artiklar:
|
Kör PowerShell SetDNSServerResponseRateLimiting- cmdleten SetDNSServerResponseRateLimiting för att aktivera RRL genom att använda standardvärden. Om det inte går att aktivera RRL till att tillåta legitima DNS-frågor eftersom de begränsar sig för att de begränsas för tätt kan värdena för parametrarna svar/SEKoch fel/SEK ökas tills DNS-servern svarar på tidigare misslyckade frågor. Andra parametrar kan också hjälpa administratörer att hantera RRL-inställningar bättre. De här inställningarna inkluderar RRL-undantag.
Mer information finns i följande Microsoft-dokument-artikel:
Vanliga frågor och svar
Q1: den åtgärd som sammanfattas här gäller för alla versioner av Windows Server?
A1: Nej. Den här informationen gäller inte för Windows Server 2012 eller 2012 R2. De här äldre versionerna av Windows Server stöder inte RRL-funktionen som minskar förstärknings effekten när en riktad DNS-matchare frågar dina DNS-servrar.
K2: Vad ska kunder göra om de har DNS-servrar som bor i Edge-nätverk som kör antingen Windows Server 2012 eller Windows Server 2012 R2?
A2: DNS-servrar som bor i Edge-nätverk med antingen Windows Server 2012 eller Windows Server 2012 R2 bör uppgraderas till Windows Server 2016 eller senare versioner som stöder RRL. RRL minskar förstärknings effekten när en riktad DNS-matchare frågar dina DNS-servrar.
Q3: Hur kan jag avgöra om RRL orsakar legitima DNS-frågor?
A3: Om RRL är inställt på inloggnings läget utför DNS-servern alla RRL-beräkningar. I stället för att förhindra förebyggande åtgärder (som att släppa eller trunkera svar) loggar servern i stället de potentiella åtgärderna som om RRL var aktive rad och fortsätter sedan med de vanliga svaren.