Przecieki na zaporze

Standardowe rozwiązania i konfiguracje zapór sieciowych są coraz słabszą ochroną przed infiltracją sieci LAN z zewnątrz. Zmusza to do kolejnych inwestycji w systemy analizujące ruch pakietów.

Standardowe rozwiązania i konfiguracje zapór sieciowych są coraz słabszą ochroną przed infiltracją sieci LAN z zewnątrz. Zmusza to do kolejnych inwestycji w systemy analizujące ruch pakietów.

Jeszcze kilka lat temu - gdy większość firm nie udostępniała żadnych usług z własnej podsieci - do jej zabezpieczenia wystarczało uniemożliwienie realizacji połączeń przychodzących. Taki prosty NAT zapewnia dostęp do Internetu, a jednocześnie uniemożliwia bezpośrednie podłączenie do sieci LAN z zewnątrz. Eliminuje to poważne zagrożenia związane z jej infiltracją od strony Internetu. Niestety, obecnie nawet zapora wyposażona w filtr antywirusowy nie jest dobrym rozwiązaniem. Statystyki pokazują bowiem, że najpoważniejsze naruszenia bezpieczeństwa pojawiają się w obrębie sieci lokalnej, a także w momencie nawiązywania z nią połączeń zewnętrznych.

Kilka lat temu otwarcie ruchu HTTP - wraz z prostą analizą zawartości - było dość skutecznym zabezpieczeniem LAN przed pobieraniem złośliwego kodu w formie obiektów ActiveX, skryptów eksploitujących błędy Internet Explorera, a także różnych załączników. Potrafiły to wszystkie zaawansowane zapory sieciowe różnych producentów, wliczając także niektóre tanie modele dedykowane dla małych firm. Obecnie konieczna jest rewizja tego założenia, gdyż otwieranie ruchu wychodzącego na port 80 praktycznie nie zapewnia już żadnego bezpieczeństwa.

Powszechność ruchu HTTP sprawiła, że wiele firm ma ten port otwarty. Korzystając z tego twórcy złośliwego kodu zaczęli go modyfikować tak, aby wszelkie dane przesyłał właśnie przez HTTP. Takie połączenie przechodzi bez problemu przez większość typowych, prostych zapór, a użycie serwera proxy również nie jest przeszkodą, jeśli aplikacja potrafi ukraść jego ustawienia z przeglądarki. Zazwyczaj to potrafi. Powstaje więc problem - jak odfiltrować normalny ruch HTTP związany z przeglądaniem Internetu od tego, który jest skutkiem pracy złośliwego kodu i innych niechcianych aplikacji.

Niepożądana bezpośredniość

Każdy analizator ruchu pokaże, że otwarcie jakiegokolwiek bezpośredniego połączenia z sieci lokalnej nie jest dobrym pomysłem. Niektóre aplikacje spyware, czy peer-to-peer potrafią to wykryć i wykorzystać. Aby mieć kontrolę nad ruchem, należy zablokować wszystkie bezpośrednie połączenia między stacjami roboczymi a Internetem. Wszelki ruch HTTP powinien być przekazywany za pomocą pośrednika (proxy), zapewniając odpowiednie filtrowanie niepożądanej zawartości. Warto pamiętać, że koszty wdrożenia takiego rozwiązania nie są problemem, bo oprócz względnie drogich, dedykowanych systemów, są także darmowe serwery pośredniczące, które przy odpowiedniej konfiguracji sprawdzą się całkiem nieźle.

Zastosowanie proxy nie rozwiązuje wszystkich problemów, bowiem nadal są aplikacje, które mogą korzystać z proxy http. Potrafi to wiele tuneli VPN, udających normalne połączenie. Istnieje nawet tunel IP-over-http zrealizowany jako aplet Java, uruchamiany wewnątrz środowiska przeglądarki internetowej. Problem leży, jak zwykle, w błędnych założeniach dotyczących ochrony sieci. Typowa konfiguracja większości zapór zakłada uproszczoną kontrolę przesyłanych danych. Nie sprawdzają one czy zapytania kierowane na port HTTP są rzeczywiście związane z ruchem HTTP, a także, czy nie mają zdefiniowanych zasad blokowania niepożądanych połączeń.

Wszędzie SSL

Kolejnym elementem, który niesie zagrożenie, jest powszechność ruchu SSL. Wewnątrz połączenia SSL mogą być przekazywane dowolne dane - od zwykłych stron HTTP, takich jak bezpieczne zakupy czy bankowość elektroniczna, przez nawigację do obcych stron w ramce - to potrafi wiele urządzeń SSL VPN wykorzystujących tzw. core access - aż do dowolnych połączeń na wybrany port wewnątrz tunelu SSL przy użyciu apletu w języku Java - to zapewniają niektóre realizacje SSL VPN.

Ruch SSL umyka tradycyjnym zaporom, gdyż jest szyfrowany. Niestety, z tego korzystają również twórcy złośliwego kodu, a także reklamodawcy przenoszący swoje treści wewnątrz SSL, aby uniknąć odfiltrowania zawartości na zaporze. Bywa, że zainteresowani ominięciem zapór są też przemyślni pracownicy firmy chcący skorzystać z komunikatorów, aplikacji VoIP i innych podobnych narzędzi, które z zasady są blokowane.

Dopóki nie ma skutecznego i niedrogiego sposobu na odfiltrowanie niepożądanej treści wewnątrz połączeń SSL, dopóty jedyną metodą umożliwiającą zapewnienie bezpieczeństwa sieci jest podjęcie bardzo radykalnego kroku - należy domyślnie zablokować ruch SSL, a odblokowywać go tylko dla konkretnych adresów IP - źródłowych i docelowych.

Klasyfikować i pośredniczyć

Daje się zauważyć trend polegający na coraz większym nacisku na analizę ruchu, zaś coraz mniejsze znaczenie ma kontrola portów, na których odbywa się komunikacja. Najpoważniejszą zaletą podejścia bazującego na analizie ruchu jest to, że blokowanie obejmuje ruch danej aplikacji niezależnie od portu, na którym ona się komunikuje. Jeśli niedozwolona aplikacja zmieni port, nadal będzie zablokowana przez zaporę, która identyfikuje ją według ruchu, a nie portu.

Tymczasem tradycyjna zapora, gdzie stosuje się reguły oparte na portach, jest bezradna wobec mechanizmu zmiany portów przez oprogramowanie. Popularną aplikacją, która w założeniu ma omijać zapory, jest Skype - program bardzo trudny do zablokowania, który szyfruje transmisję przy użyciu nowoczesnej kryptografii i wystarczy jedna luka w zabezpieczeniu połączeń, aby cała podsieć mogła z niej korzystać. Skype często zmienia porty i klasyfikacja ruchu jest jedyną w miarę skuteczną bronią, oprócz oczywiście ręcznego aktualizowania reguł przez doświadczonego administratora. To samo dotyczy niektórych sieci peer-to-peer.

Przykładem nowoczesnych urządzeń, które stosują zaawansowaną analizę ruchu, są zapory firmy Palo Alto Networks, ale potrafią to niemal wszystkie nowoczesne systemy IPS. Niektóre z nich są wyposażone w gotowy zestaw reguł do blokowania połączeń spyware, sieci peer-to-peer, a także Skype. Mając skuteczną klasyfikację, można ograniczyć niepożądane połączenia poprzez przypisanie odpowiednich reguł dla wykrywanego ruchu. O ile ruch nie jest szyfrowany, można to zrobić od dawna. Nawet tanie urządzenie firmy 3Com z serii X potrafi skutecznie zablokować np. spyware za pomocą prostych opcji konfiguracji. To samo dotyczy wszystkich nowoczesnych systemów IPS i zapór. Ale nie każde urządzenie radzi sobie z ruchem SSL.

Gdy ruch podlega szyfrowaniu SSL, istnieje możliwość deszyfrowania go na zaporze, dokonania jego inspekcji i ponownego zaszyfrowania przed przesłaniem do klienta. Jest to stosunkowo stara technologia, ale dopiero niedawno doczekała się praktycznej realizacji, gdyż wymaga dużych mocy obliczeniowych zapory. Inspekcja ruchu wykorzystująca deszyfrowanie na zaporze daje możliwość rozdziału ruchu, który będzie przechodził bez deszyfrowania, od tego, który będzie podlegał kontroli.

Można podzielić ruch SSL od stacji roboczej na dozwolony (kierowany do autoryzowanych serwisów, takich jak bankowość elektroniczna) i pozostały, podlegający deszyfrowaniu. W ten sposób można zapewnić prywatność i bezpieczeństwo podczas przeglądania serwisów transakcyjnych w bankach internetowych, a pozostały ruch może podlegać inspekcji i kontroli. Podział na strefę prywatności i maksymalnego bezpieczeństwa, niepodlegającą kontroli, może się odbywać na podstawie nagłówków pakietów albo innych reguł bazujących także na adresach IP. Jest to mocne narzędzie, bowiem zapewnia zabezpieczenie przed załącznikami poczty Yahoo mail czy Outlook Web Access transmitowanymi wewnątrz połączenia SSL.

Powoduje to jednak ryzyko ataków man-in-the-middle, ponadto kontrola szyfrowanej transmisji może być uznana za naruszenie prywatności pracowników. W krajach, w których wszelka ingerencja w prywatność jest mocno przestrzegana, może to rodzić problemy natury prawnej.