Uwierzytelnianie w RPC Microsoftu

RPC Microsoftu udostępnia mechanizm uwierzytelniający, ale nie wszystkie systemy operacyjne potrafią go obsługiwać (obsługuje go Windows NT, ale Windows 95 i Windows 9 nie). W rezultacie tylko nieliczne aplikacje rzeczywiście używają uwierzytelniania RPC, ponieważ ogranicza to liczbę platform, na których może działać aplikacja, i wymaga dodatkowej pracy programistów. Aplikacje, które wymagają zabezpieczenia transmisji, posługują się RPC ponad SMB, zamiast używać RPC bezpośrednio ponad TCP/IP, i korzystają z uwierzytelniania SMB (SMB jest opisany dalej w tym rozdziale).

Charakterystyka filtrowania pakietów w RPC. Usługi oparte na RPC bardzo trudno kontrolować za pomocą filtrowania pakietów, ponieważ zwykle nie wiesz, jakiego portu będzie używała usługa w konkretnym komputerze jest też bardzo prawdopodobne, że używany port będzie się zmieniał po każdym uruchomieniu komputera. Nie wystarczy zablokowanie dostępu do serwera lokalizującego napastnik może pominąć fazę porozumiewania się z serwerem lokalizującym i po prostu wypróbować wszystkie porty TCP i UDP (sprawdzenie wszystkich 65 536 portów w konkretnym komputerze to kwestia minut), szukając odpowiedzi od serwera opartego na RPC, takiego jak NFS lub NIS.

Niektóre nowsze filtry pakietów mogą się porozumiewać z serwerem lokalizującym, aby ustalić położenie serwerów i filtrować ruch na podstawie tych informacji. Zauważ, że w przypadku usług opartych na UDP trzeba to weryfikować dla każdego pakietu z osobna. Filtr będzie się musiał kontaktować z serwerem lokalizującym po otrzymaniu każdego pakietu, gdyż po restarcie komputera usługa może się przenieść do innego portu. Ponieważ TCP jest protokołem połączeniowym, wystarczy weryfikować numer portu na początku połączenia. Przepuszczanie ruchu UDP za pomocą takiego mechanizmu wiąże się z dużym obciążeniem i prawdopodobnie nie nadaje się do zastosowań, w których intensywnie wykorzystuje się UDP.

Choć to nie wystarczy, powinieneś i tak zablokować dostęp do serwera lokalizującego, ponieważ niektóre wersje tego serwera mogą działać jako pośrednicy dla klientów napastnika.

Co więc zrobić, żeby zabezpieczyć usługi oparte na RPC? Kilka spostrzeżeń: po pierwsze, okazuje się, że większość niebezpiecznych usług opartych na RPC (zwłaszcza NIS i NFS) jest domyślnie udostępniana przez UDP. Po drugie, większość usług, do których chciałbyś mieć dostęp przez filtr pakietów, opiera się na TCP, a nie na UDP godne uwagi wyjątki to DNS, NTP i syslog. Te spostrzeżenia prowadzą do rozpowszechnionej metody obsługiwania RPC za pomocą filtrów pakietów: zablokować cały ruch UDP, pozostawiając konkretne i ściśle kontrolowane „okna” dla DNS, NTP i syslog. W takiej metodzie, chcąc przepuścić w dowolnym kierunku jedną usługę RPC opartą na TCP, będziesz musiał przepuścić wszystkie albo użyć filtra pakietów, który może się kontaktować z usługą lokalizującą.

Windows NT umożliwia ściślejszą kontrolę nad portami używanymi przez RPC. To może pomóc, jeśli chcesz pozwolić zdalnym klientom na dostęp do swoich serwerów, ale nie pomoże klientom wewnętrznym w dostępie do serwerów zewnętrznych (chyba że zdołasz namówić właścicieli tych serwerów na zmianę konfiguracji komputerów). Większość zastosowań RPC to w rzeczywistości zastosowania DCOM, który udostępnia interfejs użytkownika umożliwiający konfigurowanie portów (omówiony dalej w tym rozdziale). Możesz także bezpośrednio kontrolować zakres portów używanych przez RPC. W tym celu musisz zmodyfikować klucz rejestru

Leave a reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>