Rekomendacje dotyczące wdrażania protokołu RPC za pośrednictwem protokołu HTTP

Ta sekcja zawiera najlepsze rozwiązania i zalecane konfiguracje wdrażania w celu osiągnięcia maksymalnego poziomu zabezpieczeń i wydajności podczas korzystania z procedury RPC za pośrednictwem protokołu HTTP. Różne konfiguracje znalezione w niniejszym dokumencie mają zastosowanie do różnych organizacji na podstawie różnych rozmiarów, budżetu i wymagań dotyczących zabezpieczeń. Każda konfiguracja zawiera również zagadnienia dotyczące wdrażania przydatne podczas określania, co jest najlepsze dla danego scenariusza.

Aby uzyskać informacje dotyczące dużej liczby wywołań RPC za pośrednictwem scenariuszy HTTP, zobacz równoważenia obciążenia RPC firmy Microsoft.

Następujące zalecenia dotyczą wszystkich konfiguracji:

• Użyj wersji systemu Windows, które obsługują RPC za pośrednictwem protokołu HTTP w wersji 2.
• Umieść usługi IIS na maszynie z uruchomionym serwerem proxy RPC w trybie IIS 6.0.
• Nie zezwalaj na dostęp anonimowy do katalogu wirtualnego serwera proxy RPC.
• Nigdy nie włącz klucza rejestru AllowAnonymous.
• Upewnij się, że RPC za pośrednictwem klientów HTTP użyj CertificateSubjectField (zobacz RpcBindingSetAuthInfoEx, aby uzyskać więcej informacji), aby sprawdzić, czy serwer proxy RPC, z którym nawiązano połączenie, jest oczekiwanym serwerem proxy RPC.
• Skonfiguruj klucz rejestru ValidPorts zawierający tylko maszyny, z którymi będzie nawiązywać połączenie RPC za pośrednictwem klientów HTTP.
• Nie używaj symboli wieloznacznych w kluczu ValidPorts; Może to zaoszczędzić czas, ale całkowicie nieoczekiwana maszyna może również zmieścić symbol wieloznaczny.
• Użyj protokołu SSL na komputerze RPC za pośrednictwem klientów HTTP. Jeśli zostaną spełnione wytyczne opisane w tych sekcjach, RPC za pośrednictwem klienta HTTP nie będzie można nawiązać połączenia bez korzystania z protokołu SSL.
• Skonfiguruj RPC za pośrednictwem klientów HTTP, aby oprócz używania protokołu SSL używać szyfrowania RPC. Jeśli RPC za pośrednictwem klienta HTTP nie może nawiązać połączenia z centrum dystrybucji kluczy, może używać tylko negocjacja i NTLM.
• Skonfiguruj maszyny klienckie do korzystania z NTLMv2. Ustaw LMCompatibilityLevel klucz rejestru na 2 lub wyższy. Aby uzyskać więcej informacji na temat klucza LMCompatibilityLevel, zobacz msdn.microsoft.com.
• Uruchom farmę internetową maszyn proxy RPC z konfiguracją opisaną powyżej.
• Wdróż zaporę między Internetem a serwerem proxy RPC.
• Aby uzyskać optymalną wydajność, skonfiguruj usługi IIS w celu wysłania krótkiej odpowiedzi dla kodów błędów, które nie powiodły się. Ponieważ użytkownik odpowiedzi usług IIS jest procesem zautomatyzowanym, nie ma potrzeby wysyłania przyjaznych dla użytkownika wyjaśnień do klienta; będą one po prostu ignorowane przez RPC przez klienta HTTP.

Podstawowe cele serwera proxy RPC z perspektywy zabezpieczeń, wydajności i możliwości zarządzania są następujące:

• Podaj pojedynczy punkt wejścia dla RPC przez ruch HTTP do sieci serwera. Posiadanie pojedynczego punktu wejścia dla RPC przez ruch HTTP do sieci serwera ma dwie główne korzyści. Po pierwsze, ponieważ serwer proxy RPC stoi w Internecie, większość organizacji izoluje takie maszyny w specjalnej sieci nazywanej niezaufaną siecią obwodową, która jest oddzielona od normalnej sieci organizacyjnej. Serwery w niezaufanej sieci obwodowej są bardzo starannie zarządzane, skonfigurowane i monitorowane, aby wytrzymać ataki z Internetu. Im mniej maszyn w niezaufanej sieci obwodowej, tym łatwiej jest konfigurować, monitorować i monitorować je. Po drugie, ponieważ jedna farma sieci Web z zainstalowanymi serwerami proxy RPC może obsługiwać dowolną liczbę wywołań RPC za pośrednictwem serwerów HTTP znajdujących się w sieci firmowej, warto oddzielić serwer proxy RPC od serwera RPC przez serwer HTTP i mieć serwer proxy RPC znajduje się w niezaufanej sieci obwodowej. Jeśli serwer proxy RPC znajdował się na tej samej maszynie co RPC za pośrednictwem serwera HTTP, organizacje musiałyby umieścić wszystkie serwery zaplecza w niezaufanej sieci obwodowej, co znacznie utrudniłoby zabezpieczenie niezaufanej sieci obwodowej. Rozdzielenie roli serwera proxy RPC i RPC za pośrednictwem serwera HTTP pomaga organizacjom zachować liczbę maszyn w niezaufanej sieci obwodowej, którymi można zarządzać, a tym samym bezpieczniejszą.
• Służy jako bezpiecznik bezpieczeństwa dla sieci serwerowej. Serwer proxy RPC jest zaprojektowany jako ekspansowalny bezpiecznik dla sieci serwerów — jeśli coś pójdzie nie tak na serwerze proxy RPC, po prostu wychodzi i w ten sposób chroni prawdziwy RPC przez serwer HTTP. Jeśli do tej pory zostały opisane najlepsze rozwiązania opisane w tej sekcji, RPC przez ruch HTTP jest szyfrowany za pomocą szyfrowania RPC oprócz protokołu SSL. Szyfrowanie RPC jest między klientem a serwerem, a nie między klientem a serwerem proxy. Oznacza to, że serwer proxy nie rozumie i nie może odszyfrować odbieranych ruchu RPC. Rozumie tylko niektóre sekwencje sterowania wysyłane do niego przez klienta zajmującego się ustanowieniem połączenia, kontrolą przepływu i innymi szczegółami tunelowania. Nie ma on dostępu do danych wysyłanych przez klienta HTTP do serwera. Ponadto RPC przez klienta HTTP musi niezależnie uwierzytelniać się zarówno na serwerze proxy RPC, jak i RPC za pośrednictwem serwera HTTP. Zapewnia to ochronę w głębi systemu. Jeśli bezpieczeństwo maszyny serwera proxy RPC zostanie naruszone, z powodu błędu konfiguracji lub naruszenia zabezpieczeń, dane przekazywane przez nie są nadal bezpieczne przed naruszeniami. Osoba atakująca, która przejmie kontrolę nad serwerem proxy RPC, może w większości przerwać ruch, ale nie odczytać go ani manipulować nim. Jest to miejsce, w którym jest odgrywana rola bezpiecznika serwera proxy RPC — jest to możliwe bez zabezpieczenia RPC przez naruszenie ruchu HTTP.
• Rozłóż niektóre testy dostępu i odszyfrowywanie między wiele maszyn z uruchomionym serwerem proxy RPC w farmie sieci Web. Działając dobrze w farmie sieci Web, serwer proxy RPC umożliwia organizacjom odciążanie odszyfrowywania PROTOKOŁU SSL i niektórych kontroli dostępu, dzięki czemu zwalnia większą pojemność na serwerze zaplecza do przetwarzania. Korzystanie z farmy serwerów proxy RPC umożliwia również organizacji zwiększenie możliwości wytrzymania ataków typu "odmowa usługi" (DoS) przez zwiększenie pojemności na serwerach frontonu.

Zgodnie z wytycznymi określonymi do tej pory organizacje nadal mają wybory. Każda organizacja ma opcje i kompromisy między niedogodnościami użytkownika, zabezpieczeniami i kosztami:

• Użyj uwierzytelniania podstawowego lub zintegrowanego uwierzytelniania systemu Windows do uwierzytelniania na serwerze proxy RPC? RPC za pośrednictwem protokołu HTTP obecnie obsługuje tylko protokół NTLM — nie obsługuje protokołu Kerberos. Ponadto, jeśli istnieje serwer proxy HTTP lub zapora między RPC za pośrednictwem klienta HTTP i serwera proxy RPC, który wstawia za pośrednictwem pragma w nagłówku HTTP, uwierzytelnianie NTLM nie będzie działać. Jeśli tak nie jest, organizacje mogą wybrać uwierzytelnianie podstawowe i NTLM. Zaletą uwierzytelniania podstawowego jest to, że jest szybszy i prostszy, dlatego oferuje mniej możliwości ataków typu "odmowa usługi". Jednak protokół NTLM jest bezpieczniejszy. W zależności od priorytetów organizacji może wybrać opcję Podstawowa, NTLM lub zezwolić swoim użytkownikom na wybór między nimi. Jeśli wybrano tylko jeden z nich, najlepiej wyłączyć drugą z katalogu wirtualnego serwera proxy RPC, aby zmniejszyć ryzyko ataku.
• Użyj tego samego zestawu poświadczeń zarówno dla serwera proxy RPC, jak i RPC za pośrednictwem serwera HTTP, lub użyj różnych poświadczeń dla każdego? Kompromisem za tę decyzję jest wygoda użytkownika i bezpieczeństwo. Niewielu użytkowników lubi wprowadzać wiele poświadczeń. Jeśli jednak dojdzie do naruszenia zabezpieczeń w niezaufanej sieci obwodowej, posiadanie oddzielnych zestawów poświadczeń serwera proxy RPC i RPC przez serwer HTTP zapewnia dodatkową ochronę. Należy pamiętać, że jeśli są używane oddzielne poświadczenia, a jednym zestawem poświadczeń jest poświadczenia domeny użytkownika, zaleca się użycie poświadczeń domeny użytkownika dla RPC przez serwer HTTP, a nie dla serwera proxy RPC.