Konfiguracja i wdrożenie reguł ochrony

Z punktu widzenia testujących najbardziej istotnym elementem produktów była konfiguracja reguł polityki ochrony, mówiących, jak produkt ma ochraniać urządzenia końcowe. Źle zdefiniowana polityka może uniemożliwić istotną komunikację lub pracę aplikacji wymaganych do prowadzenia codziennego biznesu, a w skrajnych przypadkach może także dopuścić do systemu szkodliwy ruch lub aplikacje.

Testowane produkty prezentują różne podejście do ochrony klienta. Niektóre z nich kontrolują tylko te aplikacje, które odbierają lub generują ruch sieciowy. Inne sprawdzają zachowanie aplikacji pod kątem oznak szkodliwego działania. Większość stosuje jednak podejście hybrydowe i łączone technologie obejmujące: reguły sieciowe zapory ogniowej, mechanizmy kontroli aplikacji, analizę protokołów i sygnatury wykrywania wtargnięć.

W celu przetestowania możliwości wdrażania polityki ochrony spróbowano utworzyć reguły, które powinny:

• blokować cały ruch wchodzący z wyjątkiem tego ze zdalnych desktopów;
• blokować ruch wychodzący na porcie 23 do zdalnych systemów;
• blokować Netcat (sterowane skryptami narzędzie, łączące się z ośrodkiem webowym, wysyłające zlecenie HTML i pokazujące odpowiedź otrzymaną z ośrodka) przed dowiązywaniem się do portu 468;
• blokować uruchomienie programu pasjansa (Soliter - sol.exe).

Po zaprojektowaniu reguł polityki testowano podłączenia zdalnych desktopów, połączeń telnet i możliwości gry w pasjansa. Próba sterowania tymi czterema procesami pozwalała uzyskać wiedzę na temat parametrów używanych przez te produkty do ustanawiania reguł dotyczących szerokiego zakresu aplikacji i aktywności sieciowej.

Interesujące wyniki przyniosły testy zakazu wykonywania sol.exe. W przypadku Symantec i eEye można wyszczególnić pliki zaufane lub zabronione, ale konieczne jest określenie pełnej ścieżki do nich. I tu jest pewien kłopot, ponieważ sol.exe rezyduje w katalogu WINNT/system32 w Windows 2000 Server, czyli tam, gdzie konsola zarządzająca dla każdego produktu, oraz w katalogu Windows/system32 w Windows XP, gdzie pracuje system, który powinien wymuszać reguły polityki. Nie można było więc testować reguł blokowania wykonywania pliku w tych produktach, gdyż żaden nie pozwolił na ręczne wprowadzenie ścieżki do tego pliku. Konieczne było wyszukanie pliku drogą przeglądania katalogów, co było niewykonalne, ponieważ pliku, którego szukano, nie było na serwerze zarządzania.

Rozwiązania przyjęte przez Check Point, Sygate i F-Secure interesują się jedynie aplikacjami, które próbują uzyskać dostęp do sieci i z tego powodu pasjans nie był uwzględniany na generowanych przez te produkty listach aplikacji działających w systemie. Telnet został pokazany natychmiast po uruchomieniu.

Przy blokowaniu wychodzących połączeń telnetowych produkty Symantec, Check Point, Sygate i eEye pomyślnie zablokowały wyjście na porcie 23. Skonfigurowana reguła blokady portu 23 w przypadku F-Secure nie działała, ale zakaz wykonywania telnet.exe pracował zgodnie z oczekiwaniami.

Skonfigurowano też reguły dopuszczające wejście na porcie 3389 dla Microsoft Remote Desktop Connection Utility. eEye, F-Secure, Sygate i Check Point pomyślnie dopuszczały zdalne połączenia. Nie uzyskano natomiast wejścia z Remote Desktop pracującego na kliencie Symantec, mimo iż polityka została skonfigurowana w sposób dopuszczający taką możliwość.

Generalnie generowanie reguł polityki ochrony było jednak pewnym wyzwaniem w przypadku wszystkich testowanych produktów. Reguły sieciowe były łatwiejsze do wdrożenia niż reguły aplikacyjne.

Napotkano kilka problemów w niektórych produktach. Przy tworzeniu reguł systemowych w eEye próbowano zwiększyć ich priorytet, ale funkcjonalność ta czasami nie działała i wywoływała błędy związane z serwerem SQL. Często także otrzymywano błąd "Server busy" w systemie, w którym pracował klient Blink. Symantec Client Firewall Administrator, wykorzystywany do tworzenia reguł, był trudny w użytkowaniu.

Klient pod obstrzałem

W testach ataku na klienta sprawdzano mechanizmy sterowania aplikacją (określane także jako blokowanie wykonywania aplikacji), uruchamiając aplikacje, która uzyskiwała dostęp do sieci w sposób zabroniony przez reguły polityki ochrony. Testowano wykrywanie wtargnięć przez skanowanie portów. Zapobieganie wtargnięciom (implementowane jako wykrywanie anomalii) testowano, uruchamiając ataki UPNP (Universal Plug and Play Protocol). Testowano też odporność ochrony, próbując dezaktywować produkt - przez usunięcie plików programowych z katalogu produktu. Kasowano wszystkie te pliki, które mógłby znaleźć i usunąć napastnik.

eEye wykonywał sterowanie aplikacją, wykrywając wtargnięcia do sieci i specyficzne ataki na sieć. Testującym udało się jednak usunąć produkt i wyłączyć ochronę.