Exporteren (0) Afdrukken
Alles uitvouwen
Expand Minimize

RPC-interfacebeperkingen

Hoe werken RPC-interfacebeperkingen?

In de RPC-service (Remote Procedure Call) voor Windows Server 2003 met Service Pack 1 zijn verschillende wijzigingen aangebracht die RPC-interfaces standaard veiliger maken en het aanvalsrisico in Windows Server 2003 verkleinen. De belangrijkste wijziging is de toevoeging van de registersleutel RestrictRemoteClients. Met deze sleutel kunt u het gedrag van alle RPC-interfaces in het systeem wijzigen en kunt u bovendien voorkomen dat van buitenaf anoniem toegang kan worden verkregen tot RPC-interfaces in het systeem, enkele uitzonderingen daargelaten. Andere wijzigingen betreffen onder andere de registersleutel EnableAuthEpResolution en drie nieuwe interfaceregistratievlaggen.

Voor wie is deze voorziening van belang?

Deze voorziening is van belang voor ontwikkelaars van RPC-toepassingen. Ook systeembeheerders moeten bekend zijn met deze wijziging in RPC.

Welke nieuwe functionaliteit is aan deze voorziening toegevoegd in Windows Server 2003 Service Pack 1?

De registersleutel RestrictRemoteClients

Gedetailleerde beschrijving

Wanneer een interface wordt geregistreerd via RpcServerRegisterIf, kan de servertoepassing er met behulp van RPC voor zorgen dat de toegang tot de interface wordt beperkt, gewoonlijk door middel van een beveiligingscallback. De registersleutel RestrictRemoteClients dwingt RPC aanvullende beveiligingscontroles uit te voeren voor alle interfaces, ook als de interface geen geregistreerde beveiligingscallback heeft.

Op RPC-clients die de named pipe-protocolreeks (ncacn_np) gebruiken, zijn geen van de beperkingen die in deze sectie aan bod komen, van toepassing. Voor de named pipe-protocolreeks kunnen geen beperkingen worden ingesteld vanwege verschillende compatibiliteitsproblemen met eerdere versies.

De registersleutel RestrictRemoteClients kan een van drie DWORD-waarden hebben die ook kunnen worden bestuurd via rpcdce.h. Als de sleutel niet aanwezig is, heeft dit hetzelfde effect als wanneer de waarde DWORD=0 (RPC_RESTRICT_REMOTE_CLIENT_NONE) voor serverproducten en de waarde DWORD=1 (RPC_RESTRICT_REMOTE_CLIENT_AUTH) voor client-serverproducten is ingesteld.

De volgende tabel bevat een overzicht van de registersleutel RestrictRemoteClients:

 

Type Beschrijving

Sleutelnaam

RestrictRemoteClients

Type

DWORD

Kan worden ingesteld via gebruikersinterface

Ja. Deze sleutel kan worden ingesteld met de Groepsbeleidsobjecteditor.

Sleutelwaarden

0 (Standaardwaarde voor serverproducten)

Dit is in Windows Server 2003 Service Pack 1 de standaardwaarde voor serverproducten. Bij deze instelling wordt de RPC-interfacebeperking genegeerd. Deze instelling komt overeen met de waarde RPC_RESTRICT_REMOTE_CLIENT_NONE in rpcdce.h. De verantwoordelijkheid voor het toepassen van geschikte RPC-beperkingen ligt bij de servertoepassing. Deze instelling is gelijk aan de werking in vorige versies van Windows.

1

Dit is de standaardwaarde in Windows XP Service Pack 2 en client-serverproducten die zijn samengesteld op basis van de SRSP1-code. Bij deze instelling wordt de toegang tot alle RPC-interfaces beperkt. Alle externe anonieme oproepen worden afgewezen, behalve oproepen die via named pipes binnenkomen (ncacn_np). Deze instelling komt overeen met de waarde RPC_RESTRICT_REMOTE_CLIENT_DEFAULT in rpcdce.h. Als een interface een beveiligingscallback registreert en de vlag RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH doorgeeft, is deze beperking niet van toepassing op die interface.

2

Alle externe anonieme oproepen worden zonder uitzondering afgewezen door RPC. Deze instelling komt overeen met de waarde RPC_RESTRICT_REMOTE_CLIENT_HIGH in rpcdce.h. Wanneer deze waarde is ingesteld, kunnen er via RPC geen externe anonieme oproepen worden ontvangen in een systeem.

Wat is het belang van deze wijziging? Welke risico's worden hierdoor mede beperkt?

Het is veel moeilijker om een interface aan te vallen als voor oproepen verificatie moet worden uitgevoerd, zelfs als het een relatief laag niveau van verificatie betreft. Het inschakelen van RestrictRemoteClients kan een uitermate nuttige beveiliging vormen tegen wormen die misbruik maken van bufferoverschrijdingen die van buitenaf kunnen worden veroorzaakt via anonieme verbindingen.

Wat werkt er anders?

Als uw RPC-toepassing oproepen verwacht van externe anonieme RPC-clients, kan uw toepassing mogelijk niet goed worden uitgevoerd als u deze voorziening gebruikt. Dit heeft tot gevolg dat toepassingen die DCOM gebruiken, mogelijk niet goed werken als deze waarde is ingesteld.

Aangezien beveiligde RPC-oproepen via verbindingsloze protocollen zoals UDP (User Datagram Protocol) en IPX (Internetwork Packet Exchange) (ncadq_ip_udp en ncadg_ipx) een lager beveiligingsniveau gebruiken dan oproepen via verbindingsgeoriënteerde protocollen, worden deze oproepen voor dit beleid altijd beschouwd als onveilig. Daarom mislukken RPC-oproepen via verbindingsloze protocollen als deze sleutel is ingeschakeld in Windows Server 2003 met Service Pack 1.

Als u RPC-clientoproepen via verbindingsloze protocollen wilt toestaan, moet u de waarde RestrictRemoteClients instellen op 0 (RPC_RESTRICT_REMOTE_CLIENT_NONE), de standaardinstelling voor Windows Server 2003 met Service Pack 1.

Hoe los ik dit op?

U beschikt over de volgende opties om RestrictRemoteClients te gebruiken op uw server:

  • Alleen RPC-clients die RPC-beveiliging gebruiken, contact laten maken met uw servertoepassing. Dit is de beste methode om beveiligingsrisico's te beperken.
  • Uw interface vrijstellen van verificatie door de vlag RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH in te stellen tijdens interfaceregistratie. RPC wordt dan zodanig ingesteld dat alleen anonieme verbindingen met de interface van uw toepassing zijn toegestaan.

De registersleutel EnableAuthEpResolution

Gedetailleerde beschrijving

Een RPC-interface die van buitenaf en anoniem toegankelijk is en standaard is geregistreerd in Windows Server 2003, vormt een belangrijk aanvalsrisico. RPC zelf moet een dergelijke interface registreren om eindpuntomzetting mogelijk te maken voor oproepen die dynamische eindpunten gebruiken.

Als u de vlag RestrictRemoteClients inschakelt, is de interface van de RPC-eindpunttoewijzing niet anoniem toegankelijk. Dit is een belangrijke verbetering van de beveiliging, maar hierbij verandert de manier waarop eindpunten worden omgezet. Momenteel voert een RPC-client die probeert een oproep te plaatsen met een dynamisch eindpunt, eerst een query uit in de RPC-eindpunttoewijzing op de server om te bepalen met welk eindpunt verbinding moet worden gemaakt. Deze query wordt anoniem uitgevoerd, zelfs als de RPC-clientoproep zelf wordt uitgevoerd met RPC-beveiliging. Anonieme oproepen naar de interface van de RPC-eindpunttoewijzer mislukken in Windows Server 2003 met Service Pack 1 als de sleutel RestrictRemoteClients is ingesteld op 1 of hoger. Hierdoor is het noodzakelijk om de RPC-client een geverifieerde query te laten uitvoeren in de eindpunttoewijzing. Als de sleutel EnableAuthEpResolution is ingesteld, maakt de RPC-client gebruik van NTLM voor verificatie bij de eindpunttoewijzing. Deze geverifieerde query wordt alleen uitgevoerd als voor de daadwerkelijke RPC-clientoproep RPC-verificatie wordt gebruikt.

Wat is het belang van deze wijziging?

Door deze wijziging is het voor een RPC-client mogelijk een oproep te plaatsen bij een RPC-server waarvoor een dynamisch eindpunt is geregistreerd op een systeem waarop Windows Server 2003 met Service Pack 1 wordt uitgevoerd met RestrictRemoteClients ingeschakeld. De clientcomputer moet deze registersleutel instellen, zodat een geverifieerde query wordt uitgevoerd in de RPC-eindpunttoewijzing.

Wat werkt er anders?

Deze registersleutel wordt gebruikt om het specifieke scenario in te schakelen dat in de vorige sectie is beschreven. Wanneer deze sleutel is ingeschakeld, wordt NTLM-verificatie gebruikt voor alle query's in de RPC-eindpunttoewijzing die namens geverifieerde oproepen worden uitgevoerd.

Deze instelling kan ook worden opgegeven via de Groepsbeleidsobjecteditor om het groepsbeleidsobject in te stellen dat zich bevindt in Computerconfiguratie\Beheersjablonen\Systeem\Externe procedureaanroep\RPC-clientverificatie door Endpoint Mapper.

Nieuwe vlaggen voor RPC-interfaceregistratie

Gedetailleerde beschrijving

Er zijn drie nieuwe vlaggen gemaakt voor interfaceregistratie om het voor ontwikkelaars van toepassingen gemakkelijker te maken om een RPC-interface te beveiligen.

  • RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH
    Wanneer deze vlag is geregistreerd, roept RPC de geregistreerde beveiligingscallback op voor alle oproepen, ongeacht de beveiligingsinstellingen van de oproep. Zonder deze vlag wijst RPC alle niet-geverifieerde oproepen af voordat ze de beveiligingscallback bereiken. Deze vlag werkt alleen wanneer een beveiligingscallback is geregistreerd.
  • RPC_IF_SEC_NO_CACHE
    Er wordt een beveiligingscallback geregistreerd voor een interface om de toegang tot die interface te beperken. Bij een beveiligingscallback wordt gewoonlijk de client geïmiteerd om vast te stellen of de client over voldoende rechten beschikt om een oproep bij de interface te plaatsen. Als een bepaalde clientidentiteit eenmaal een beveiligingscallback heeft doorstaan, wordt dezelfde beveiligingscallback gewoonlijk ook de volgende keren doorstaan.
    RPC maakt gebruik van dit patroon door te onthouden wanneer een afzonderlijke clientidentiteit een beveiligingscallback heeft doorstaan, waarna de beveiligingscallback wordt overgeslagen voor opeenvolgende oproepen van dezelfde client bij dezelfde interface. Deze procedure komt neer op het in de cache plaatsen van beveiligingscallbacks, een voorziening die bestaat sinds de besturingssystemen van Microsoft Windows 2000. Voor Windows Server 2003 met Service Pack 1 kunt u de vlag RPC_IF_SEC_NO_CACHE gebruiken om het in de cache plaatsen van beveiligingscallbacks uit te schakelen voor een bepaalde interface. Dit is nuttig als de beveiligingscontrole kan veranderen, waardoor een clientidentiteit die voorheen toegang kreeg, later toch kan worden geweigerd.
  • RPC_IF_LOCAL_ONLY
    Wanneer een interface is geregistreerd met deze vlag, wijst RPC oproepen af die door externe RPC-clients zijn geplaatst. Bovendien worden ook lokale oproepen met de protocolreeks ncadg_* en ncacn_* (behalve named pipes, met ncacn_np) afgewezen. Als een oproep wordt geplaatst bij ncacn_np, is de oproep alleen toegestaan als deze niet afkomstig is van SRV, waarmee alle externe oproepen worden weggefilterd. Ncalrpc-oproepen worden altijd doorgelaten.

Wat is het belang van deze wijziging?

Door deze wijziging beschikken ontwikkelaars van RPC-toepassingen over extra beveiligingsvoorzieningen voor de beveiliging van hun RPC-interface.

Wat werkt er anders?

Deze vlaggen veranderen niets aan de werking van bestaande toepassingen op basis van Windows Server 2003. Toepassingsontwikkelaars bepalen zelf of zij deze vlaggen willen gebruiken.

Welke instellingen zijn toegevoegd of gewijzigd in Windows Server 2003 Service Pack 1?

RPC-instellingen

Naam instelling Locatie Standaardwaarde Mogelijke waarden

RestrictRemoteClients

HKEY_LOCAL_MACHINE\ SOFTWARE\Policies\ Microsoft\Windows NT\RPC

-of-

(Groepsbeleidsobject)

Computerconfiguratie\ Beheersjablonen\Systeem\Externe procedureaanroep\Beperkingen voor niet-geverifieerde RPC-clients

0

0 - Geen

1 – Standaardwaarde van XP SP2- en SRSP1-client-serverproducten

2 – Hoog

EnableAuthEpResolution

HKEY_LOCAL_MACHINE\ SOFTWARE\Policies\ Microsoft\Windows NT\RPC

-of-

(Groepsbeleidsobject)

Computerconfiguratie\ Beheersjablonen\Systeem\Externe procedureaanroepRPC-clientverificatie door Endpoint Mapper

0

0 – Uitgeschakeld

1 - Ingeschakeld

Moet ik mijn code wijzigen zodat deze werkt in Windows Server 2003 Service Pack 1?

Mogelijk moet u de code wijzigen zodat deze werkt in Windows Server 2003 Service Pack 1 als u RestrictRemoteClients inschakelt. Zie de vorige secties over RestrictRemoteClients en EnableAuthEpResolution voor meer informatie over mogelijk vereiste wijzigingen in toepassingen.

Vindt u dit nuttig?
(1500 tekens resterend)
Bedankt voor uw feedback

Community-inhoud

Toevoegen
Weergeven:
© 2014 Microsoft