Zarządzanie zaporą systemu Windows Vista
 |
Zawartość strony
Jakiś czas temu autor tego artykułu umieścił na swoim blogu dokument dotyczący zapory systemu Windows Vista. Wpis wskazywał po prostu pewne przyjemne funkcje, ale nie oferował zbyt wielu wytycznych odnośnie rozmieszczania.
W niniejszym artykule w sposób bardziej szczegółowy omówione zostaną wybrane funkcje zapory Windows Vista®, które zostały zaprojektowane specjalnie z myślą o ułatwieniu procesu zarządzania. Ponadto przedstawione zostaną wskazówki, mówiące jak można wykorzystać te funkcje do uproszczenia pracy i zwiększenia bezpieczeństwa użytkowników.
Wraz z opublikowaniem najnowszego dodatku SP1 dla systemu Windows Vista możemy spodziewać się zwiększonej liczby wdrożeń systemu Windows Vista w korporacjach (korporacje często czekają na pierwszy dodatek Service Pack przed migracją do nowej wersji systemu operacyjnego). Czytelnicy należący do grupy specjalistów IT, którzy coraz poważniej zastanawiają się nad rozmieszczeniem systemu Windows Vista w swoim środowisku korporacyjnym, powinni przyjrzeć się dokładniej zaporze sieciowej. Po poznaniu możliwości zapory systemu Windows Vista niektóre firmy mogą zdecydować się na renegocjację umowy z zewnętrznymi dostawcami zabezpieczeń i usunięcie z pakietu zapory sieciowej.
Zapora systemu Windows kiedyś i teraz
Zapora w pierwotnej wersji systemu Windows® XP pozostawiała wiele do życzenia. Chociaż posiadała funkcje zabezpieczeń odpowiadające funkcjonalności ówczesnych komercyjnych zapór sieciowych hosta, nie oferowała niczego nowego ani innowacyjnego.
Wersja zastępcza dostarczana w dodatku Windows XP SP2 uległa diametralnym zmianom. Została zaprojektowana specjalnie w celu ułatwienia procesu zarządzania w obrębie całej korporacji. Zapora systemu Windows XP SP2 jest bardzo atrakcyjna ze względu na małe obciążenie, możliwości centralnego zarządzania, efektywność i subtelność. A co prawdopodobnie najważniejsze realizowała pewien bardzo istotny cel: zapora systemu Windows XP SP2 chroniła system w fazie rozruchu.
Ta ostatnia właściwość jest bardzo istotna. W przeszłości wiele systemów było infekowanych podczas rozruchu, nawet gdy zapora sieciowa była włączona. W rzeczywistości podczas wyżu epidemii wirusa Blaster współczynnik ataków wynosił aż jeden co cztery minuty. Innymi słowy, jeśli pozostawiliśmy niechroniony komputer z dostępem do Internetu, był on narażony na zainfekowanie średnio co cztery minuty. A zatem w przypadku zastosowania zapory sieciowej, która nie chroni systemu w fazie rozruchu, 1 system na 12 zostałby zainfekowany w fazie rozruchu. Te współczynniki spowodowały, że firma Microsoft w wersji Windows XP SP2 zapory zdecydowała się na ochronę systemu także w fazie rozruchu.
W systemie Windows Vista zapora sieciowa przeszła kolejne kompletne przeobrażenie. Najbardziej oczywistą zmianą z perspektywy zarządzania jest to, że interfejsy zarządzania protokołem Internet Protocol Security (IPsec) oraz zaporą zostały scalone. Jest to bardzo logiczna zmiana. Protokół IPsec oraz zapora zostały zaprojektowane w celu blokowania niedozwolonych elementów. Różnica polega na tym, że w przypadku zapory parametry definiujące co jest dozwolone, nie są bardzo szczegółowe, natomiast jednoczesne blokowanie lub autoryzowanie dużych przestrzeni adresowych w protokole IPsec jest dość skomplikowane.
Dzięki temu, że powyższe dwie funkcje znajdują się w tym samym interfejsie zarządzania, administratorzy mogą stosować obie technologie naraz, nie martwiąc się aż tak, czy coś wymaga reguły IPsec, czy raczej filtra zapory. Zasadniczo istnieje jeden widok obszaru systemu narażonego na ataki sieciowe, co pomaga w zminimalizowaniu ryzyka pomyłki.
Dodatek SP1 dla systemu Windows Vista dodaje do funkcji zapory pewne ulepszenia niezawodności. Wprowadza także nowe algorytmy, w szczególności algorytmy Suite B, do zastosowania w technologii IPsec. Jest to zestaw związanych z szyfrowaniem algorytmów, składający się z algorytmów Advanced Encryption System (AES), Elliptic Curve Cryptography (ECC) oraz Secure Hash Algorithm (SHA) 256 i 384.
A co najważniejsze Service Pack 1 dodaje wsparcie dla ochrony dostępu do sieci (Network Access Protection - NAP). NAP to narzędzie do wymuszania zasad, które zapewnia, że zanim zarządzane i kontrolowane systemy klienckie otrzymają zezwolenie na podłączenie się do sieci, muszą dysponować najaktualniejszymi zasadami zabezpieczeniami, aktualizacjami i definicjami złośliwego oprogramowania. Ochrona NAP nie potrafi powstrzymać złośliwych hostów przed łączeniem się z siecią, ale zapewnia, że wszystkie zarządzane hosty są w pełni zgodne z wymaganiami, o ile nie zostały skutecznie przejęte w wyniku ataku.
Zapora systemu Windows Vista, nazywana Zaporą systemu Windows z zabezpieczeniami zaawansowanymi, została dołączona również do systemu Windows Server® 2008. Wszystkimi funkcjami można zarządzać także zdalnie i konfigurować je w obrębie sieci przy użyciu Zasad grupy.
Typy reguł i scenariusze
Połączenie funkcjonalności zapory i zabezpieczeń IPsec w jednym interfejsie zarządzania oznacza, że istnieją obecnie dwa typy reguł: reguły kierunkowe oraz reguły połączeń. Reguły kierunkowe to standardowe reguły zapory definiujące, jaki ruch jest dozwolony w określonym kierunku. Reguły połączeń definiują parametry zabezpieczeń dla połączeń między komputerami. Dla porównania reguły kierunkowe przypominają w pewnym stopniu reguły zapory znane z poprzednich wersji, natomiast reguły połączeń przypominają bardziej reguły IPsec wykorzystywane w połączeniu z zaporą sieciową w systemie Windows XP SP2.
Połączenie funkcji zapory i IPsec w tym samym interfejsie umożliwiło realizowanie kilku bardzo interesujących scenariuszy. Na przykład jedną z najbardziej wartościowych, dostępnych obecnie koncepcji zabezpieczeń jest izolowanie poszczególnych systemów w sieci. Firma Microsoft nazywa ten mechanizm "Izolacją serwera i domeny".
Izolacja serwera i domeny wykorzystuje zarówno funkcjonalność IPsec, jak i zapory. Z tego względu nowy interfejs zarządzania zaporą zawiera specjalną funkcję reguł izolacji. Przydaje się ona, gdy chcemy na przykład ograniczyć połączenie oparte na atrybutach systemów źródłowych lub docelowych, takich jak członkowstwo w domenie.
Jak widać na Rysunku 1, Kreator nowej reguły zabezpieczeń połączeń (New Connection Security Rule Wizard) rozpoczyna od pytania, jakiego typu regułę chcemy stworzyć. Gdy wybierzemy opcję Izolacja (Isolation), kreator prekonfiguruje pewne ustawienia, które dotyczą reguły izolacji.
Rysunek 1: Wykorzystanie Kreatora nowej reguły zabezpieczeń połączeń do tworzenia reguły izolacji.
Jak można zauważyć na podstawie Rysunku 1, reguła izolacji wspomina o kondycji. Reguły wykorzystywane do Izolacji serwera i domeny to w rzeczywistości te same reguły, które są stosowane do ochrony NAP.
Nie możemy wymuszać uwierzytelniania dla pewnych typów ruchu. Na przykład przypuszczalnie nie chcemy wymagać uwierzytelniania do rozpoznawania nazw DNS. Punkty końcowe tego typu ruchu wymagają użycia reguły Wykluczenie uwierzytelniania. Reguła Wykluczenie uwierzytelniania, jak sama nazwa wskazuje, wyklucza ruch z wymagań IPsec.
Reguła Od serwera do serwera nosi nieco mylącą nazwę. Choć najczęściej wykorzystywana jest dla serwerów, może być również wykorzystywana dla maszyn klienckich. Reguła Od serwera do serwera konfiguruje po prostu połączenie tak, aby wymagało ono uwierzytelniania. Różni się ona od reguły Izolacja pod tym względem, że reguła Izolacja wymaga nie tylko uwierzytelniania, ale również spełnienia pewnych dodatkowych kryteriów, takich jak członkowstwo w domenie lub kondycja.
Reguła Tunelowania zasadniczo tworzy sieć typu Virtual Private Network (VPN) pomiędzy dwoma lokalizacjami oraz tunel między komputerami bramy. Reguły Tunelowania są rzadko wykorzystywane w systemie Windows Vista, ponieważ istnieje niewielkie prawdopodobieństwo, że będziemy wykorzystywali system Windows Vista w roli bramy sieci. Możemy także tworzyć niestandardowe reguły, które umożliwiają dostosowywanie wszystkich parametrów.
Kolejność reguł
Kwestia kolejności reguł wydaje się na początku dość skomplikowana. Kluczem do zrozumienia tego mechanizmu jest zapomnienie o kolejności. Nie chodzi tyle o porządek, co o wybór dopasowań. Weźmy pod uwagę na przykład ruch przychodzący. Ruch przychodzący niepasujący do żadnej reguły, która by na niego zezwalała, jest domyślnie blokowany. Z pozoru podejście to może przypominać uporządkowanie, zgodnie z którym "Reguły zezwalające są rozważane jako pierwsze", lecz takie założenie byłoby błędne. Jeśli określony pakiet pasuje zarówno do metody zezwalającej, jak i metody blokowania, reguła blokowania przeważy. To oznacza, że dopasowanie jest w uproszczeniu następujące:
1. Reguły blokowania. Jeśli pakiet lub połączenie pasuje do jednej z nich, zostaje usunięty.
2. Reguły zezwalające. Jeśli pakiet lub połączenie pasuje do jednej z nich, zostaje zaakceptowany.
3. Domyślne zachowanie profilu kierunkowego. Jeśli nie można dopasować żadnej reguły blokowania bądź zezwalania, ruch będzie traktowany zgodnie z zachowaniem określonym jako domyślne dla ruchu w tym kierunku w danym profilu. W konfiguracji domyślnej kierunku przychodzącego wszystkich profili oznacza to blokowanie ruchu. W konfiguracji domyślnej kierunku wychodzącym oznacza to zezwolenie na ruch.
Proces dopasowywania jest kontrolowany przez reguły obejścia uwierzytelnionego (IPsec). Zastosowanie tego typu reguły powoduje, że cały uwierzytelniony ruch, który pasuje do innych parametrów reguły, jest dozwolony niezależnie od tego, czy pasuje do innych reguł. Reguły obejścia uwierzytelnionego stanowią reguły kierunkowe, dla których zaznaczona została opcja Zastąp (Override), jak pokazano na Rysunku 2. Są one brane pod uwagę jako pierwsze, aby uwierzytelniony ruch zawsze dotarł do systemu. W ten sposób możemy łatwo zezwolić na ruch z uwierzytelnionych hostów, ale zablokować ruch z wszystkich innych miejsc. Rozwiązanie to można postrzegać jako regułę 0. W związku z tym pełna lista reguł w odpowiedniej kolejności wygląda następująco:
Rysunek 2: Zaznaczanie opcji Zastąp reguły blokowe (Override block rules) w celu skonfigurowania reguły obejścia uwierzytelnionego.
0. Reguły obejścia uwierzytelnionego
1. Reguły blokowania
2. Reguły zezwalające
3. Domyślne zachowanie profilu kierunkowego
Tak naprawdę nieważna jest liczba reguł w każdej klasie pasującej do wzorca ruchu. Gdy tylko którakolwiek reguła zostanie dopasowana do ruchu, przetwarzanie reguł zakończy się.
Publiczny, Prywatny oraz Domena
Nowa zapora posiada trzy profile: publiczny, prywatny i domenę. Natomiast zapora systemu Windows XP SP2 posiadała dwa profile sieciowe: standardowy i domeny. Profil domeny jest wywoływany automatycznie, gdy komputer może odnaleźć kontroler domeny. W przeciwnym przypadku w systemie Windows XP wykorzystywany był profil standardowy. To zapewniało szerokie możliwości, dzięki którym administrator zabezpieczeń mógł kompletnie zablokować komputer, gdy był on podłączony zdalnie i nadal zezwalać na pełną funkcjonalność zarządzania, która była niezbędna w momencie podłączenia do sieci organizacji. Jednak takie podejście przysparzało pewne problemy niektórym użytkownikom, w szczególności tym posiadającym sieć osobistą w domu. Ponieważ profil standardowy był wykorzystywany zawsze wtedy, gdy system nie mógł uzyskać dostępu do kontrolera domeny, system często zostawał blokowany, gdy znajdował się w domu użytkownika.
Nowy profil prywatny dołączony do systemu Windows Vista pomaga w rozwiązaniu tego problemu. Teraz kiedy łączymy system z nową siecią zostaniemy spytani, czy sieć jest publiczna (to po prostu nowa nazwa dawnego profilu standardowego) czy prywatna, a następnie system zostanie odpowiednio skonfigurowany. System zapamiętuje konfigurację za każdym razem, gdy łączy się z określoną siecią, bazując na parametrach sieciowych zaprezentowanych mu przez serwery infrastruktury w tej sieci. Mechanizm ten nie jest niezawodny, lecz pomaga w lepszym blokowaniu dodatkowych sieci.
Logika wykrywania, czy system znajduje się w domenie, również została poprawiona. Wynikiem jest szybsze i bardziej niezawodne przejście oraz mniejsza liczba systemów, które myślą, iż powinny użyć publicznego lub prywatnego profilu, podczas gdy w rzeczywistości znajdują się w domenie.
Można powiązywać reguły z określonym typem sieci, dzięki czemu system nie udostępnia zbyt wielu informacji i nie próbuje łączyć się z systemami w niezaufanych sieciach. Jest to jeden z obszarów, w których integracja zapory i IPsec zaczyna przynosić korzyści.
Wykorzystując te nowe reguły, możemy wprowadzić pewne ograniczenia w obszarach, w których kiedyś nie było to możliwe. Na przykład przez wiele lat osoby atakujące dokonywały prób ataku poprzez zwodzenie po to, aby użytkownicy nawiązywali połączenia Server Message Block (SMB) w sieciach Windows z niezaufanymi hostami. To pozwalało im narzucać kolejność uwierzytelniania dającą im dostęp do pary pytanie-odpowiedź, która może posłużyć do łamania haseł. Starsze wersje tego typu ataku były również wykorzystywane do degradowania mechanizmu uwierzytelniania do zwykłego tekstu lub do odzwierciedlania pary pytanie-odpowiedź z powrotem na pierwotnym komputerze. Pierwsza technika została zdekonspirowana lata temu. Zastosowaniu drugiej zapobiega dodatek Windows XP SP2, niemniej należy pamiętać, że dobrowolne podawanie par pytanie-odpowiedź jest cokolwiek nieroztropne.
Aby temu zapobiec, można użyć innej nowej funkcji zapory systemu Windows Vista, a mianowicie filtrowania ruchu wychodzącego. Administrator może zdecydować się na przykład na zablokowanie wszystkich wychodzących połączeń SMB (tych nasłuchujących w portach TCP 135, 139, 445 oraz UDP 137, 138, 445) w profilu publicznym. To znacznie utrudnia wykorzystanie systemu w atakach poprzez zwodzenie w celu pozyskania par pytanie-odpowiedź i uniemożliwia uzyskanie dostępu do niezaufanych udziałów plików Windows w sieci Internet.
Ponownie mechanizm ten zdecydowanie nie jest niezawodny. Jeśli system został już złamany, ta reguła nie powstrzyma systemu przed komunikowaniem się ze światem zewnętrznym, gdyż osoba atakująca może po prostu wyłączyć regułę. Jednak mechanizm ten jest bardzo przydatny jako środek do ochrony pozostających pod kontrolą, ale potencjalnie narażonych na ataki systemów organizacji.
Należy zaznaczyć, że podobnie jak w systemie Windows XP SP2 w systemach Windows Vista oraz Windows Server 2008 tylko jeden profil może być aktywny w danym momencie. Jeśli w systemie istnieją dwa interfejsy sieciowe i jeden z nich znajduje się w domenie, natomiast drugi w sieci publicznej, dla obu zastosowany zostanie profil publiczny zapory. Wykorzystywany będzie zawsze najbardziej restrykcyjny z profili. Jak łatwo się domyślić, profil publiczny jest bardziej restrykcyjny niż prywatny, a profil prywatny bardziej restrykcyjny niż profil domeny. A zatem warto mieć świadomość, że reguła blokowania wychodzącego ruchu SMB może przechwytywać dużą część ruchu w połączeniach VPN.
Aby umożliwić ruch w ramach połączeń VPN, gdy komputer znajduje się w sieci publicznej lub prywatnej, można stworzyć reguły kierunkowe, które odnoszą się jedynie do interfejsów VPN. Aby mechanizm ten zadziałał, interfejsy VPN muszą być rozpoznawane jako takie przez system Windows. W przypadku niewykorzystywania serwera VPN Microsoft® Routing and Remotes Access Services, należy dokładnie przetestować tę funkcjonalność przed wdrożeniem jej na szeroką skalę. Problem ten dotyczy przede wszystkim ruchu przychodzącego do systemu klienckiego oraz wszelkich niestandardowych reguł ruchu wychodzącego, jakie zostały stworzone.
Budowanie reguł zapory
Budowanie reguł zapory jest w nowej wersji zapory dużo łatwiejsze. Kreator nowej reguły (New Rule Wizard), pokazany na Rysunku 3, umożliwia definiowanie wszystkich najpopularniejszych typów reguł. A także zawiera Uprzednio zdefiniowane (Predefined) reguły dla określonych usług.
Rysunek 3: Uprzednio zdefiniowane reguły w kreatorze nowej reguły.
Uprzednio zdefiniowane reguły są szczególnie istotne. Izolacja serwera zasadniczo polega na zastrzeżeniu usług w taki sposób, aby były one dostępne jedynie dla tych systemów, które naprawdę ich potrzebują. W produktach serwerowych można wykorzystać kreator konfiguracji zabezpieczeń systemu Windows (Security Configuration Wizard - SCW), który ułatwia ten proces, aczkolwiek nie czyni go całkiem bezbolesnym (kreator SCW został omówiony w magazynie TechNet Magazine w numerze z marca 2008 roku).
Jednak wersje klienckie systemu Windows nie posiadały do tej pory podobnej funkcjonalności. Zastosowanie typu reguły uprzednio zdefiniowanej pozwala nam zaoszczędzić wiele pracy związanej z określaniem, jakie punkty końcowe wykorzystywane są przez usługę. Zapora nie tylko wspiera aplikacje, w ten sposób że wie, który program reprezentuje usługę "iSCSI Service", ale także zawiera uprzednio zdefiniowane reguły, które opisują określoną funkcjonalność. Dzięki temu możemy skoncentrować się na tym, które komputery muszą zostać objęte tą regułą. Jest to nadal trudne i czasochłonne zadanie, ale przynajmniej jest ono charakterystyczne dla naszego środowiska.
Istnieje również niestandardowa reguła (zasłonięta przez listę rozwijaną na Rysunku 3), która zapewnia pełną elastyczność, jakiej można oczekiwać od zapory weryfikującej uwierzytelnienia. Na przykład jeśli potrzebujemy reguły, która zezwala jedynie na zaszyfrowany ruch IPsec, powinniśmy wybrać opcję zezwalania tylko na bezpieczne połączenia na stronie Akcje (Action) kreatora pokazanego na Rysunku 2.
Po wybraniu tej opcji istnieje możliwość włączenia szyfrowania. Pozostawienie tej opcji pustej powoduje, że ruch wykorzystywać będzie konfigurację ESP-NULL (Encapsulated Security Payload z kluczem NULL). Jest to zalecany sposób stosowania protokołu IPsec do uwierzytelniania. Umożliwia on działanie sieciowych narzędzi zarządzania, ponieważ ruch przechodzi przez sieć w jawnej postaci, a gdyby szyfrowanie okazało kiedyś potrzebne, wystarczy zaznaczyć odpowiednie pole wyboru.
W wielu sytuacjach szyfrowanie ruchu sieciowego jest dużo mniej istotne niż nieakceptowanie żadnego ruchu pochodzącego ze złośliwych hostów. Szyfrowanie ruchu w sieci powstrzymuje niepożądane osoby, którym udało się uzyskać dostęp do sieci, przed oglądaniem zawartości pakietu. Natomiast wymóg uwierzytelniania może w pierwszej kolejności zapobiec wysłaniu pakietu i uchronić przed atakiem. Oczywiście istnieje wiele sytuacji, w których szyfrowanie na poziomie sieci jest istotne, ale również wiele innych sytuacji, w których wystarczy samo uwierzytelnianie.
Budowanie reguł izolacji domeny
W większości środowisk chcemy, aby ograniczona liczba komputerów miała możliwość przesyłania ruchu do stacji roboczej. Wszystkie stacje robocze powinny być skonfigurowane przynajmniej przy użyciu reguł izolacji domeny. W systemie Windows XP stosowanie takiego rozwiązania było dość skomplikowane, ale w systemie Windows Vista uległo znacznemu uproszczeniu.
Na początku otwieramy wybrane narzędzie do zarządzania i zaznaczamy węzeł Reguły zabezpieczeń połączeń (Connection Security Rules). Następnie klikamy węzeł prawym przyciskiem myszy i wybieramy opcję Nowa reguła (New Rule). Otrzymujemy okno dialogowe pokazane na Rysunku 1 . Zaznaczamy regułę Izolacja (Isolation) i klikamy przycisk Dalej (Next). Teraz musimy zadecydować, czy chcemy wymuszać regułę czy też nie. W większości sytuacji będziemy chcieli wymagać uwierzytelniania połączeń przychodzących. To uniemożliwi komputerom niedołączonym do domeny przesyłanie ruchu do tej stacji roboczej. Jednak aby można było korzystać z usług infrastruktury, system musi pozwalać na przekazywanie wybranego ruchu wychodzącego w jawnej postaci. A zatem najlepszym rozwiązaniem jest wymaganie uwierzytelniania dla połączeń przychodzących i żądanie uwierzytelniania dla połączeń wychodzących.
Następnie wybieramy metodę uwierzytelniania. Domyślnie wybrana opcja nosi nazwę Domyślne (Default), co stanowi nieszczególnie pomocny tytuł. Można skonfigurować domyślną metodę uwierzytelniania dla każdego komputera osobno we właściwościach IPsec (dostępnych po kliknięciu prawym przyciskiem myszy węzła Zapora systemu Windows z zabezpieczeniami zaawansowanymi oraz wybraniu opcji Właściwości). Metoda Kerberos jest zawsze domyślną metodą uwierzytelniania ze względu na swoją prostotę i bezpieczeństwo. Jednak w celu zwiększenia czytelności zaleca się zaznaczenie opcji Kerberos podczas budowania reguł. Zazwyczaj chcemy uwierzytelniać jedynie komputer, a nie jego użytkownika. Konieczność uwierzytelniania obu wiąże się z brakiem możliwości zaakceptowania pewnego typu ruchu związanego z zarządzaniem infrastrukturą, takiego jak np. anonimowo przesyłany ruch SNMP.
Po wybraniu metody uwierzytelniania musimy stylko określić, w których profilach ma być dostępna dana reguła. Ponieważ jest to reguła odnosząca się do komputerów dołączonych do domeny, które mogą zaprezentować bilet protokołu Kerberos, nie ma sensu otwierać tego określonego przejścia w profilu Prywatnym bądź Publicznym. Zapisujemy regułę i gotowe.
Podstawowe reguły izolacji zostały znacznie uproszczone. Jednak aby wykorzystać szerokie możliwości IPsec w zakresie izolacji, trzeba zaimplementować izolację serwera nawet na stacjach roboczych. Dzięki temu można zabronić stacjom roboczym nawiązywania połączeń z innymi klientami i zamiast tego zezwolić im jedynie na podejmowanie interakcji z odpowiednimi stacjami zarządzania. Wyobraźmy sobie, o ile zmniejszyłaby się skuteczność różnego typu złośliwych programów, gdyby systemy klienckie odmawiały słuchania innych systemów klienckich.
Skrypty do obsługi zapory
Nowa zapora dostarcza solidny interfejs API, który umożliwia tworzenie skryptów dla procesu rozmieszczenia oraz oceny. Idealnym rozwiązaniem byłoby rozmieszczanie przy użyciu Zasad grupy, ale ponieważ nie zawsze są one dostępne, warto dysponować odpowiednim zestawem API do konfiguracji zapory. Interfejsy API są pogrupowane w zestawie INetFWPolicy2. Software Development Kit oraz MSDN® Library zawierają bardziej szczegółowe informacje na temat ich wykorzystania, ale kilka przykładów może pomóc w zilustrowaniu ogólnej koncepcji.
Jedną z typowych sytuacji jest potrzeba określenia, czy grupa reguł jest włączona. Załóżmy na przykład, że aplikacja lub administrator chcą sprawdzić, czy system zezwala na udostępnianie plików i drukarek. Można osiągnąć ten cel przy użyciu metody INetFWPolicy2::IsRuleGroupCurrentlyEnabled. Rysunek 4 prezentuje przykładowy skrypt VBScript realizujący tę funkcję.
' Tworzenie obiektu FwPolicy2.
Dim fwPolicy2
Set fwPolicy2 = CreateObject("HNetCfg.FwPolicy2")
' Pobieranie obiektu Rules
Dim RulesObject
Set RulesObject = fwPolicy2.Rules
'Tworzenie obiektu profilu
Dim CurrentProfile
CurrentProfile = fwPolicy2.CurrentProfileTypes
'Sprawdzenie, czy włączone jest Udostępnianie plików i drukarek oraz ewentualne włączenie tej opcji
if fwPolicy2.IsRuleGroupEnabled(CurrentProfile, "File and Printer Sharing") <> TRUE then
fwPolicy2.EnableRuleGroup CurrentProfile, "File and Printer Sharing", TRUE
end ifRysunek 4: Wykorzystanie metody INetFWPolicy2::IsRuleGroupCurrentlyEnabled.
Teraz, jeśli udostępnianie plików i drukarek jest wyłączone, a chcemy je włączyć, musimy najpierw zapewnić, że można to zrobić i że ustawienie to nie zostanie nadpisane przez Zasady grupy. Cel ten realizujemy przy pomocy API INetFWPolicy2::LocalPolicyModifyState. Szkielet, który może zostać wypełniony właściwym kodem, został zaprezentowany poniżej:
netsh advfirewall firewall add rule name="Block CIFS Out in the Public profile" dir=out action=block enable=yes profile=public localIP=any remoteIP=any remoteport=445 protocol=TCP interfacetype=any
Wiersz polecenia a typy interfejsów
Żadna zapora nie byłaby kompletna bez odpowiedniej funkcjonalności wiersza polecenia służącej do zarządzania. Istnieje podrzędny kontekst narzędzia netsh o nazwie advfirewall. Kontekst advfirewall oferuje dostęp z wiersza polecenia do wszystkich możliwości oferowanych przez graficzny interfejs użytkownika. Jeśli chcemy na przykład zaimplementować blokadę ruchu wychodzącego na porcie 445, możemy uruchomić następujące polecenia z wiersza polecenia o podniesionych uprawnieniach:
netsh advfirewall firewall add rule name="Allow CIFS on VPN interfaces" dir=out action=allow enable=yes profile=public localIP=any remoteIP=any remoteport=445 protocol=TCP interfacetype=RAS
Następnie musimy uruchomić to samo polecenie, zastępując TCP protokołem UDP w celu uzupełnienia blokady. To wystarczy do zaimplementowania reguły.
Jedną z ciekawszych funkcji zapory jest możliwość konfigurowania reguł w oparciu o typ interfejsu sieciowego. Jak pamiętamy, niektóre reguły mogą mieć wpływ na połączenia VPN. Jednak jeśli system Windows rozpoznaje interfejs jako VPN, możemy użyć tego typu reguły do wykluczenia ruchu przechodzącego przez ten interfejs:
netsh advfirewall firewall add rule name="Allow CIFS on VPN interfaces" dir=out action=allow enable=yes profile=public localIP=any remoteIP=any remoteport=445 protocol=TCP interfacetype=RAS
Ten sam efekt możemy osiągnąć, korzystając z graficznego interfejsu użytkownika, ale dopiero po stworzeniu reguły. Wtedy klikamy regułę prawym przyciskiem myszy, wybieramy opcję Właściwości (Properties) i klikamy kartę Zaawansowane (Advanced). Tam odnajdujemy sekcję Typy interfejsów (Interface types), w której możemy zaznaczyć odpowiednie typy interfejsów.
Filtrowanie ruchu wychodzącego
Brak funkcji filtrowania ruchu wychodzącego w zaporze systemu Windows XP SP2 był przedstawiany jako główny dowód, że wbudowana zapora nie stanowiła odpowiedniego mechanizmu zabezpieczania. Istnieją pewnie tysiące artykułów opisujących, jak mało bezpieczna jest zapora Windows XP SP2 ze względu na brak funkcji filtrowania ruchu wychodzącego. Pomimo faktu, iż żadna zapora sieciowa w systemie Windows XP nie mogła zapewnić bezpiecznego filtrowania ruchu wychodzącego.
Fundamentalna funkcjonalność, która zapewniałaby, iż filtrowanie ruchu wychodzącego będzie przydatną funkcją zabezpieczającą bądź narzędziem wymuszania zasad, a nie tylko nic nieznaczącym progiem spowalniającym, po prostu nie istnieje w systemie Windows XP. Natomiast istnieje w systemie Windows Vista. Logiczne jest zatem, że nowa zapora wykorzystuje tę nową funkcję. Domyślnie większość ruchu przychodzącego jest blokowana, a ruchu wychodzącego dozwolona.
Domyślnie funkcja filtrowania ruchu wychodzącego w nowej zaporze systemu Windows Vista blokuje jedynie niepotrzebny ruch pochodzący z usług. To w zasadzie wszystko, co można zrobić w celu zapewnienia ochrony przed przejęciem kontroli nad hostem, który oferuje filtry ruchu wychodzącego i zrealizowanie tej funkcji w systemie Windows XP byłoby bezcelowe.
Usługi w systemie Windows Vista mogą być uruchamiane w bardzo ograniczonym kontekście. Zasadniczo każda usługa ma swój własny unikatowy identyfikator zabezpieczeń (SID). Ten identyfikator SID usługi może posłużyć do ograniczenia dostępu do zasobów, takich jak porty sieciowe. Jest to ta sama funkcjonalność, jaką widzieliśmy wcześniej, gdy analizowaliśmy mechanizm ograniczania ruchu generowanego przez użytkowników. To oznacza, że pomimo iż dwie usługi mogą być uruchomione jako NetworkService, mogą zarządzać jedynie własnym procesem i zapora może zostać skonfigurowana tak, aby tylko jednej z nich zezwalać na komunikację ze światem zewnętrznym. Gdy zablokowana usługa zostanie skutecznie zaatakowana, nie będzie mogła przejąć kontroli nad usługą posiadającą zezwolenie i wykorzystać jej dozwolonego portu do komunikacji wychodzącej, ponieważ port jest zastrzeżony dla SID usługi.
Funkcjonalność ta to kolejna bardzo fajna funkcja zabezpieczeń dodana do systemu Windows Vista i nowa zapora wykorzystuje ją do zapewniania rzeczywistych korzyści w zakresie bezpieczeństwa poprzez filtrowanie ruchu wychodzącego w zaporze.
Faktycznie filtrowanie w zaporze na podstawie identyfikatorów SID usług jest w nowej zaporze włączone domyślnie. Jednak nie istnieje graficzny interfejs użytkownika do konfigurowania tego ustawienia. Te reguły są predefiniowane w kluczu rejestru HKLM\System\CurrentControlSet\services\sharedaccess\parameters\firewallpolicy\RestrictedServices. Jednak w przypadku własnoręcznego modyfikowania tego klucza, należy zachować dużą ostrożność, ponieważ metoda ta nie jest wspierana.
Jak duże bezpieczeństwo może zapewnić funkcja filtrowania ruchu wychodzącego?
Rzeczywisty wpływ filtrowania ruchu wychodzącego na bezpieczeństwa to źródło wielu nieporozumień w społeczności zajmującej się bezpieczeństwem. Autor artykułu wspomniał do tej pory o dwóch scenariuszach, które zapewniają bezpieczeństwo poprzez filtrowanie ruchu wychodzącego, ale oba z nich bazują na nowej funkcjonalności systemu Windows Vista, która nie była kiedyś dostępna. Pomimo tego istnieje powszechne przekonanie, iż filtrowanie ruchu wychodzącego jest ogólnie przydatne i powinno stanowić kluczowy czynnik podczas podejmowania decyzji o zakupie zapory sieciowej.
Jak na ironię w wielu organizacjach możliwości filtrowania ruchu wychodzącego, które zaowocowały decyzją o zakupie, nie są w ogóle wykorzystywane po zaimplementowaniu zapory. To wprowadza w błąd i doprowadza do utraty pieniędzy oraz nakładu pracy grupy ds. zabezpieczania informacji. Decyzja ta może być w większym stopniu motywowana pragnieniem uzyskania poczucia dobrze spełnionego obowiązku w zakresie bezpieczeństwa niż właściwą analizą prawdziwych zagrożeń. Zbyt często chęć uzyskania tego typu "teatru bezpieczeństwa" prowadzi do podejmowania decyzji, które zamiast tego powinny być pokierowane faktami.
Istnieje bardzo prosty fakt dotyczący filtrowania ruchu wychodzącego, którego orędownicy tej funkcji nie biorą pod uwagę. Typowy argument dostawców zapór bazujących na hoście jest taki, że jeśli system zostanie skutecznie zaatakowany, czy to przez robaka czy też interaktywnego złośliwego użytkownika, filtrowanie ruchu wychodzącego zatrzyma robaka przed infekowaniem innych systemów lub powstrzyma osobę atakującą przed komunikacją ze światem zewnętrznym. A to nieprawda.
Prawda jest taka, że gdyby wszystkie pozostałe warunki pozostałe niezmienione, filtrowanie ruchu wychodzącego powstrzymałoby pewne znane z historii złośliwe programy. Jednak gdyby system Windows XP oferował funkcję filtrowania ruchu wychodzącego, robaki, z którymi mieliśmy do czynienia do tej pory, najprawdopodobniej zostałyby napisane tak, aby tę funkcję wyłączyć lub w inny sposób ominąć.
W systemie Windows XP (i wcześniejszych wersjach systemu Windows) wszelkie robaki działające jako usługi (a wszystkie najpopularniejsze i najczęściej omawiane robaki były uruchamiane jako usługi), mogły osiągnąć ten cel. Jedyny powód, dla jakiego tego nie zrobiły, był taki, że nie istniało praktycznie żadne środowisko wykorzystujące filtrowanie ruchu wychodzącego, a zatem nie trzeba go było wyłączać. W ataku interaktywnym osoba atakująca mogła swobodnie ominąć filtry ruchu wychodzącego. To proste biorąc pod uwagę fakt, iż potrafiła ona uruchomić dowolny kod. A jeśli to konieczne, osoba atakująca mogła również zwieść użytkownika w celu pominięcia filtrów.
Ominięcie filtrów ruchu wychodzącego zapór bazujących na hostach można osiągnąć na kilka sposobów, w zależności od scenariusza samego ataku. Najprostszym sposobem było "poproszenie" użytkownika o podwyższonych uprawnieniach, aby zrobił to za nas. W zbyt wielu środowiskach użytkownicy nadal działają na kontach administratorów. Użytkownicy ci mają prawo do pominięcia zasad zabezpieczeń. Osoba atakująca musi jedynie postawić użytkownika przed wyborem między pewną niematerialną i niebezpośrednią korzyścią płynącą z zabezpieczenia, a czymś co użytkownik ceni sobie bardziej, a mianowicie przysłowiowymi tańczącymi świnkami.
W wielu przypadkach użytkownik jest zasypywany tyloma różnymi oknami dialogowymi, że klika je w pośpiechu i odruchowo bez uprzedniego zastanowienia. Jest to główny problem związany z mechanizmem filtrowania ruchu wychodzącego. Bezpieczeństwo zawsze przegrywać będzie z wystarczająco atrakcyjną nagrodą, taką jak tańczące świnki, ponieważ większość okien dialogowych, które proszą użytkowników o dokonanie decyzji wpływających na bezpieczeństwo, jest pozbawiona jakichkolwiek informacji faktycznie umożliwiających im podjęcie tego typu decyzji.
Prezentowanie okien dialogowych z prośbą o podjęcie decyzji dotyczących bezpieczeństwa przy użyciu wystarczających informacji, na których można byłoby oprzeć tę decyzję, jest dużo trudniejsze niż to się z pozoru wydaje. Tego typu produkt zabezpieczający (np. zapora) nie tylko musiałby rozpoznawać porty, protokoły i aplikacje dokonujące żądania, ale także rozumieć prawdziwe intencje żądań i ich wpływ na użytkownika. Bardzo trudno byłoby programistycznie pozyskać tego typu informacje. Na przykład fakt, iż program Microsoft Word próbuje nawiązać połączenie wychodzące jest dużo mniej interesujący niż to, do czego tak naprawdę program Word ma zamiar wykorzystać to połączenie.
Musimy zredukować liczbę pozbawionych znaczenia okien dialogowych, a nie zwiększać ją, a zapory z funkcją filtrowania ruchu wychodzącego nie pomagają w osiągnięciu tego celu. Aby dowiedzieć się, jaki jest aktualny stan wiedzy w zakresie zapewniania użytkownikom dostępu wartościowych informacji, autor tego artykuł zapoznał się z dokumentacją handlową głównego dostawcy zapory sieciowej bazującej na hoście. Błyszczący prospekt reklamował możliwości filtrowania ruchu wychodzącego i funkcji doradzania. Funkcje doradzania wykrywają, jaką czynność użytkownik usiłuje wykonać i udzielają odpowiedniej porady. Przynajmniej teoretycznie. Tekst broszury był wzbogacony o zrzut ekranu z informacją: "Porada dla tego programu nie jest jeszcze dostępna. Wybierz jedną z poniższych opcji lub kliknij przycisk Więcej informacji w celu uzyskania pomocy". Wygląda na to, że nawet w materiałach marketingowych dostawcy nie potrafią zapewnić okien dialogowych ze stosownymi informacjami.
Ponieważ użytkownicy nie posiadają informacji wystarczających do podejmowania odpowiednich decyzji dotyczących bezpieczeństwa, ciężar konfigurowania całego mechanizmu filtrowania ruchu wychodzącego spocząłby na administratorze, ponieważ użytkownik końcowy nie byłby do tego zdolny. A to spowodowałoby nałożenie na administratora niewyobrażalnych obowiązków.
Nawet jeśli użytkownik kliknie przycisk "Nie. Spytaj mnie później" w odpowiedzi na monit zapory, złośliwe oprogramowanie może zwykle obejść zaporę sieciową. Jeśli użytkownik, w którego kontekście wykonywany jest złośliwy kod, może otworzyć połączenia wychodzące na pewnym porcie, niepożądany kod może po prostu użyć tego portu. A zatem dowolny proces może podszyć się pod istniejący już proces, w szczególności w starszych systemach operacyjnych. Począwszy od systemu Windows Vista procesy mogą być odpowiednio ograniczane, dlatego usługi, które są ograniczone domyślnie, są domyślnie blokowane przy użyciu filtrów ruchu wychodzącego.
Niestety większość osób sądzi, że filtrowanie ruchu wychodzącego przez zapory bazujące na hostach powstrzyma przejęty zasób przed atakowaniem innych zasobów. To niemożliwe. Umieszczenie środków zabezpieczających na przejętym zasobie i proszenie go o nieatakowanie innych zasobów po prostu nie działa. Za ochronę powinien odpowiadać zasób, który chcemy zabezpieczyć, a nie ten, przed którym chcemy się obronić! Proszenie złodziei, aby nie kradli naszych kosztowności, po tym jak włamali się już do naszego domu, jest dużo mniej efektywne niż powstrzymanie ich przed dokonaniem włamania.
Materiały dodatkowe dotyczące sieci
| • | |
| • | |
| • | |
| • |
O autorze
Jesper M. Johansson to Software Architect zajmujący się oprogramowaniem zabezpieczającym oraz stały współpracownik magazynu TechNet Magazine. Posiada tytuł PhD w dziedzinie Management Information Systems i ponad 20-letnie doświadczenie w obszarze bezpieczeństwa. Został wyróżniony tytułem Microsoft MVP w zakresie Enterprise Security. Jego najnowsza książka to Windows Server 2008 Security Resource Kit.