Zapora Windows: jak znaleźć regułę blokującą połączenie?
Zapora systemu Windows ma bardzo ubogi interfejs użytkownika. Jednym z poważnych jego braków jest niemożność łatwego sprawdzenia, która reguła blokuje jakieś konkretne połączenie. Odblokowanie tej możliwości jest zaskakująco trudne.
Zapora Windows nie informuje która reguła jest odpowiedzialna za zrzucenie jakiegoś pakietu/połączenia nawet gdy włączymy logowanie. Wynika to ze sposobu działania mechanizmu dostarczającego jej funkcjonalność. W ramach uruchamiania systemowej zapory, platforma WFP kompiluje reguły MS-FASP i na ich podstawie przygotowuje filtr. Filtr jest "wstawiany" w strumień pakietów sieciowych i z perspektywy WFP, jakikolwiek niechciany pakiet jest blokowany przez "całą zaporę", a nie konkretną regułę.
Wymagana inspekcja
Aby móc dowiedzieć się, która reguła odpowiedziała za blokadę, konieczne jest włączenie inspekcji dla mechanizmu WFP. Aby to osiągnąć, musimy się udać do panelu Zasady zabezpieczeń lokalnych. Panel ten pochodzi z Windows 2000 i w dzisiejszych Windowsach zachował się w postaci niezmienionej. Dlatego próba jego uruchomienia bez praw administracyjnych może zakończyć się komunikatem "Nie masz uprawnień do wykonania tej operacji". Dlatego panel należy najpierw wyszukać w menu Start, a następnie kliknąć prawym klawiszem i wybrać uruchomienie jako administrator.
W dziale "Konfiguracja zaawansowanych zasad inspekcji" musimy udać się do jedynego dostępnego obszaru "Zasady inspekcji systemu" (jeżeli są tam dostępne inne obszary, oznacza to najczęściej członkostwo w domenie). Tam, w dziale Dostęp do obiektów, znajdują się dwa ustawienia dotyczące WFP: "Przeprowadź inspekcję połączenia platformy filtrowania" oraz dotyczące wyłącznie blokad "Przeprowadź inspekcję porzucania pakietów platformy filtrowania". W obu przypadkach musimy włączyć tę konfigurację i włączyć inspekcję dla Sukcesu i Niepowodzenia.
Nazwy wbudowanych filtrów
Teraz kilka złych wiadomości. Po pierwsze, włączenie tych reguł poskutkuje odczuwalnym spadkiem wydajności, zwłaszcza w sieci o dużym ruchu. Po drugie, objętość logów będzie olbrzymia, dlatego najlepiej wyłączyć wszystkie aplikacje łączące się akurat z siecią. Po trzecie, nawet gdy włączymy inspekcję, informacje nie pojawią się w logu zapory! Zamiast tego pojawią się jako zdarzenia ETW w systemowym dzienniku zdarzeń Zabezpieczenia. Zdarzenia te zawierają informacje na temat identyfikatora reguły dla każdego pakietu. Niestety, identyfikatory te nie są łatwe do powiązania z nazwą reguły...
W tym momencie należy zatem ponowić z zewnątrz próbę połączenia przychodzącego, które jest blokowane jest zaporę. Po niej, należy zrzucić stan filtrów WFP do pliku. Reguły WFP są tworzone dynamicznie i zrzut należy wykonać dopiero teraz. Aby otrzymać zrzut, w Wierszu Poleceń uruchomionym jako administrator, w katalogu C:\Windows\Temp należy wykonać polecenie netsh wfp show state.
Utworzy ono plik wfpstate.xml, który należy otworzyć w edytorze tekstowym jak Notatnik, ale nie w przeglądarce internetowej (domyślnie skojarzonej z plikami XML). Wysoce niestandardowe formatowanie XML pliku stanu WFP, a także kodowanie UTF-8 BOM sprawiają, że przeglądarki internetowe wyświetlą go niepoprawnie, uniemożliwiając przeszukiwanie.
Znaleźć odpowiedni pakiet
Nadchodzi najtrudniejszy etap: przeczesać się przez gąszcz pakietów zalogowanych w Dzienniku, celem odnalezienia tego, którego adres źródłowy i port docelowy zgadzają się z żądaniem, którego zablokowania szukamy. Nawet, gdy włączymy wyłącznie audytowanie wyłącznie pakietów odrzuconych, wyłączymy pozostałe aplikacje sieciowe, a nasz komputer będzie za NAT-em, okaże się że blokowanych pakietów jest sporo, wręcz kilkadziesiąt. Aby otrzymać wyłącznie zablokowane pakiety przychodzące typu TCP, UDP, ICMP i IGMP, potrzebujemy użyć dość złożonego polecenia:
Get-WinEvent -FilterHashtable @{
LogName = 'Security'
ProviderName = 'Microsoft-Windows-Security-Auditing'
Id = 5152, 5153
} -EA Si | ? {
$_.Properties[2].Value -eq '%%14592' -and
$_.Properties[7].Value -in 1, 6, 17, 88 }W ten sposób otrzymamy listą pakietów, które systemowa zapora otrzymała i odrzuciła. Jeżeli wśród nich nie będzie dowodów na połączenie, którego szukamy - jest duża szansa na to, że pakiet zgubił się po drodze i nawet do nas nie dotarł. Gdy pakiet jest będzie na liście, możemy odnaleźć we wpisie wartość liczbową "Filter" (w widoku XML zdarzenia - "FilterRTID"). Tę wartość musimy następnie wyszukać w pliku wfpstate.xml, by poznać znajdującą się obok nazwę reguły blokującej połączenie.
Przy okazji, objętość listy pozwoli przekonać się, dlaczego Windows nie zachowuje się tak, jak w "starych, dobrych czasach" (2003) program ZoneAlarm. Czyli dlaczego nie wyświetla powiadomienia o każdym blokowanym połączeniu. Zostalibyśmy zalani powiadomieniami. Niemniej, konieczność włączania systemowej inspekcji celem otrzymania sensownych logów z zapory to przesada, dla której trudno o usprawiedliwienie…
Kamil J. Dudek, współpracownik redakcji dobreprogramy.pl
