Istnieje kilka modeli umożliwiania pracownikom korzystania z dobrodziejstwa sieci Internet. Każda z dostępnych opcji gwarantuje inny poziom realizacji przyjętej w organizacji polityki bezpieczeństwa oraz posiada inną możliwość w zakresie granulacji wykorzystywanych zabezpieczeń.
Klasycznie najprostszą i do tej pory często wykorzystywaną metodą (zwłaszcza w małych firmach) jest zestawienie połączenia z Internetem za pomocą dowolnego urządzenia warstwy III tzn. routera bądź specjalnego przełącznika. W takim przypadku jedynym mechanizmem rozdzielającym sieć lokalna firmy od świata zewnętrznego jest NAT a pracownicy mają dostęp do wszystkich usług w ramach dowolnego adresu IP i w pełnym zakresie portów (zarówno TCP jak i UDP).
Ewolucyjnie kolejnym możliwym rozwiązaniem jest również zastosowanie routera (lub klasycznego filtra pakietów) z funkcją kontroli dostępu w warstwie II i IV. Przy takim rozwiązaniu użytkownicy maja dostęp do zasobów sieci Internet ograniczony do zdefiniowanych przez zasady organizacyjne i polityki portów (ewentualnie również adresów IP aczkolwiek jest to rzadko spotykane ze względu na kłopotliwe zarządzanie).
Najbardziej rozbudowanym oferującym jednocześnie wysoko zaawansowane funkcje kontroli jest zastosowanie tzw. serwerów proxy i powierzenie im roli bramy do Internetu.
Serwer proxy zwany również serwerem pośredniczącym to wyspecjalizowane oprogramowanie przeznaczone do nawiązywania połączenie w zastępstwie właściwego klienta. Ponieważ najbardziej znane są serwery proxy dla ruchu HTTP na tym przykładzie opiszę jak dokładnie wygląda tego typu komunikacja.
Załóżmy, że użytkownik pragnie nawiązać sesję HTTP na port 80 z adresem www.domena.com. W klasycznym rozwiązaniu wpisuje on ww. adres w przeglądarce internetowej po czym po rozwiązanie adresu FQDN na właściwy mu adres IP przeglądarka wysyła pakiet HTTP GET na zadany rozwiązany wcześniej adres docelowy. Ponieważ adres docelowy jest inny niż adres komputera w sieci lokalnej pakiet taki wysyłany jest to routera gdzie po translacji NAT jest przesyłany dalej (najczęściej na adres bramy domyślnej routera).
W przypadku wykorzystania serwera proxy komunikacja wygląda zgoła odmiennie. Nasz użytkownik próbujący otworzyć stronę pod adresem www.domena.com ma w ustawieniach swojej przeglądarki skonfigurowanie wykorzystanie serwera proxy o adres X.X.X.X na porcie YY (najczęściej 8080). Gdy wpisuje wspomniany adres przeglądarka po rozwiązaniu go na adres IP generuje pakiet HTTP GET lecz tym razem przesyła go z adresem i portem docelowym serwera proxy (prawdziwy docelowy adres IP zapisany jest wewnątrz nagłówka HTTP). Serwer proxy odbiera tak skonstruowany pakiet i nawiązuje komunikację z docelową stroną WWW przy czym wszystkie odebrane z niej informacje przesyłane są do użytkownika inicjującego połączenie. Istnieje również możliwość aby nasze proxy działo w trybie przezroczystym. Oznacza, że po stronie użytkownika nie konfiguruje się żadnych ustawień (wysyła on pakiety na docelowy adres np. www.domena.com) a serwer proxy znajduje się na drodze pakietu od użytkownika do Internetu (np. jako Gateway). Gdy taki serwer (skonfigurowany jako przezroczysty) otrzyma pakiet http od użytkownika przechwyci go nawiąże sesje z adresem docelowym po czym odpowiedź wyśle do użytkownika (z ta różnicą że użytkownik nie będzie świadomy proxy i odbierze odpowiedź tak jakby pochodziła od serwera doceloweg).
Architektura tego typu może występować w kilku odmianach i konfiguracjach zależnych do potrzeb danej organizacji oraz wykorzystywanego serwera proxy. Najczęściej wykorzystywane postaram się opisać w dalszej części artykułu. Na początek wystarczy nadmienić, że wykorzystanie serwera proxy sprowadza się do udostepnienia pracownikom dostępu tyko do samego serwera proxy i wykorzystanie go jako serwera pośredniczącego w ruchu pomiędzy pracownikami a światem zewnętrznym.
Możliwe zagrożenia
Wykorzystanie jednej z ww. metod do oferowania pracownikom dostępu do Internetu zależy od przyjętej w organizacji polityki bezpieczeństwa oraz od poziomu swobody dawanej użytkownikom. Istnieje bowiem szereg zagrożeń i problemów które mogą wyniknąć przy wykorzystaniu każdej z nich. Przy czym serwery proxy możemy uznać za najbezpieczniejsze i najszerszej konfigurowalne.
Z bardzo długiej listy ewentualnych ryzyk wyróżnić należy kilka najważniejszych tj. ryzyko wzrostu kosztów operacyjnych, ryzyko reputacyjne oraz ryzyko utraty bądź wycieku informacji.
Z ryzykiem wzrostu kosztów operacyjnych mamy do czynienia w przede wszystkim w dwóch przypadkach kiedy w wolumen ruchu generowanego przez pracowników korzystających z Internetu przewyższa lub znacząco utylizuje posiadane przez nas łącze oraz kiedy korzystanie z Internetu zaczyna mieć wpływ na efektywność i produktywność pracowników. Realizacja dostępu do Internetu za pomocą zwykłego routera daje pracownikom możliwość korzystania z takich aplikacji jak GG, Skype czy też z klientów P2P etc. Wszystkie z nich w większości nie są wykorzystywane do zadań służbowych a korzystanie z nich może doprowadzić do konieczności podwyższenia przepustowości posiadanego łącza aby zagwarantować pasmo dla działań stricte powiązanych z przedmiotem działalności. Problem korzystania z ww. aplikacji można prosto rozwiązać (a tym samym odsunąć konieczność ponoszenia dodatkowych kosztów) poprzez wprowadzenie filtrowania ruchu w warstwie IV i dopuszczenie tylko wybranych portów np. 80, 443, 25 etc. co skutecznie uniemożliwi np. korzystanie z GG czy P2P.
Innym problem wynikającym z korzystania ze wspomnianych aplikacji aczkolwiek w dużej mierze głownie z korzystania przez pracowników z szeregu stron internetowych niezwiązanych z wykonywaną przez nich pracą (np. serwisy społecznościowe) jest odczuwalny spadek efektywności pracy (co potrafi wygenerować znaczne koszty).
Korzystanie z pewnych kategorii stron WWW jest również meritum ryzyka reputacyjnego (odczuwalnego zwłaszcza w instytucjach o charakterze publicznym). Wiele tego typu instytucji nie może sobie pozwolić aby ich pracownicy korzystali ze stron zawierających materiały erotyczne, terrorystyczne czy np. o charakterze nazistowskim etc. Dopuszczenie do takich incydentów oraz ich ujawnienie może być ogromną dyskredytacji danej instytucji i powodować wiele nieprzyjemnych konsekwencji.
O ile jak już wspomniałem wiele aplikacji jest dość prosto o tyle kontrola ruchu http jest zadaniem bardziej skomplikowanym i wymaga zastosowania wspomnianych na początku serwerów proxy. W tym miejscu należy nadmienić, że poprzez serwer proxy rozmieć należy w szczególności wyspecjalizowane urządzenia klasy UTM wyposażone w odpowiednie dla tego typu funkcjonalności oprogramowanie.
Jednakże samo zastosowanie proxy nie rozwiązuje jeszcze problemu potrzebujemy bowiem listy adresów które chcielibyśmy blokować. Ze względu na ogromną liczbę dostępnych adresów samodzielne konstruowanie takiej listy stanowi zadanie raczej niewykonalne. Aby sobie z tym poradzić producenci rozwiązań bezpieczeństwa dostarczają tzw. subskrypcje kontroli treści które zawierają na bieżąco aktualizowaną i podzieloną na kategorie bazę stron (komponowaną przez zespoły ludzi oraz specjalne algorytmy heurystyczne) z których serwery proxy mogą korzystać (z opłatą) w celu filtrowania ruchu. W takiej sytuacji administrator wybiera kategorie (bądź jeśli to konieczne pojedyncze strony) do których dostęp chce zablokować (ewentualnie zezwolić) a serwer analizuje każde zapytanie przez niego przechodzące porównując jest z posiadana bazą i dopuszcza je lub odrzuca w zależności o polityki. Tego typu konstrukcja jest względnie prosta w administracji i w większości przypadków można ją uznać za skuteczną.
Oddzielną kategorią problemów stanowią ryzyka związane z utratą bądź ujawnieniem danych. W większości firm niepowołanym jest aby pracownicy udostępniali informacje nad którymi pracują osobą trzeci ( w niektórych przypadkach jest to wręcz być albo nie być firmy ). Pomijając udostępnianie, firmy nie chcą również aby pracownicy wynosili dane poza obręb firmy np. poprzez wysyłanie ich na prywatną pocztę elektroniczną. Dodatkowo, bardzo niebezpiecznym jest dopuszczenie do zawirusowania służbowych komputerów co w konsekwencji może prowadzić do nieautoryzowanego wydostania się danych np. do twórców wirusa. Najprostszą możliwą metodą walki z tego typu zagrożeniami jest zabronienie całego ruchu na zewnątrz organizacji i wykorzystywanie proxy do pośredniczenie w każdej komunikacji (nie tylko http). Dodatkowo należy wykorzystywać urządzenia oferujące oprócz kontroli treści i pośredniczenia również kontrole antywirusową oraz zabronić ściągania i wysyłania (udostępniania szczególnych kategorii plików).
Omijanie zabezpieczeń
Gdy postanowimy wykorzystać wspomniane powyżej metody musimy liczyć się z faktem, że istnieją sposoby za pomocą których „sprytni” użytkownicy vel hakerzy mogą względnie skutecznie ominąć wprowadzone zabezpieczenia. Jeżeli więc utrzymywana przez nas polityka bezpieczeństwa kategorycznie nie dopuszcza wyjątków a opisane wcześniej ryzyka stanowią dla nas duże zagrożenie przy wyborze dowolnej metody powinniśmy dodatkowo zaimplementować szeroki zakres monitowania ruchu aby w odpowiednim czasie wychwycić ewentualne wrogie działania i skutecznie im przeciwdziałać.
Można również podjąć kroki aby wprowadzić bardziej kompleksowe systemy zabezpieczeń i skutecznie zablokować ewentualne naruszenia. Poprzez bardziej kompleksowe systemy należy rozumieć filtrowanie i inspekcję ruchu w warstwie VII oraz wspomniane systemy DLP. Lecz zacznijmy od początku.
Załóżmy, że jako administrator na polecenie naszego kierownictwa zablokowaliśmy (na wykorzystywanym przez nas rozwiązaniu UTM) strony z pornografią oraz serwisy społecznościowe. Wydaje się, że w tym momencie wszyscy pracownicy zwiększą swoja efektywność i przestaną marnować czas. Tymczasem kilku sprytnych (lepiej zaznajomionych z technologią) użytkowników postanowiło wykorzystać dostępną w Internecie (łatwo znaleźć w google) sieć TOR. Pobrali oni lub przynieśli np. na pendrivie specjalnie przygotowaną przeglądarkę internetową (np. TOR Browser Bundle). Po jej uruchomieniu nawiązywane jest szyfrowane połączenie z jednym z darmowych i powszechnie dostępnych serwerów proxy stanowiących sieć TOR. Po nawiązaniu połączenia można korzystać z Internetu identycznie jak z normalnej przeglądarki z tym, że cały ruch jest szyfrowany i przesyłany na adresy serwera TOR (niewidocznie dla naszego serwera proxy) a nasze serwery proxy nie są w stanie go zablokować.
Rozważmy inna sytuację. Zablokowaliśmy wybrane kategorie stron WWW oraz większość portów wychodzących, lecz pozostawiliśmy otwarty port 25 dla wychodzącego ruchu SMTP. Nasi sprytni użytkownicy ponownie znaleźli rozwiązanie aby korzystać z zablokowanych stron. Mając dostęp do komputera dostępnego w Internecie (posiadającego publiczny adres IP lub korzystającego z DDNS) skonfigurowali na nim serwer SSH słuchający na porcie 25. Następnie wykorzystując klienta SSH (np. PUTTY) ustawili na nim dynamiczne proxy wykorzystujące protokół SOCKS słuchające na dowolnie wybranym lokalnym porcie. Na koniec ustawili przeglądarkę internetową do wykorzystywania SOCKS proxy na skonfigurowanym wcześniej porcie i adresie localhost uzyskując tym samym możliwość nie skrępowanego korzystania z zasobów Internetu. Taka metoda nazywa się tunelowaniem SSH i może być wykorzystana do przesłania dowolnego portu i dowolnej aplikacji o ile umożliwia ona skonfigurowanie na niej SOCKS proxy.
Aby zablokować tunelowanie SSH zablokowaliśmy wszystkie porty wychodzące z naszej sieci i udostępniliśmy tylko i wyłącznie serwer proxy. Jednak i na takie zabezpieczenie użytkownicy znaleźli metodę. Tunelowanie SSH można bowiem skonfigurować aby wykorzystując metodę HTTPConnect przesłało ruch SSH przez wykorzystywane w organizacji proxy.
Gdy postanowimy zablokować metodę HTTPConect na to również jest sposób. Użytkownicy wykorzystają narzędzie httptunel które nawiąże tunel http (bez metody Connect) po czym poprzez ten tunel wykonają połączenie SSH.
Oprócz ww. istnieje jeszcze wiele metod tunelowania tj. tunelowanie DNS, ICMP etc. Jednak idea działania jest zawsze taka sama różni się tylko implementacja i wykorzystywane oprogramowanie.
Filtrowanie aplikacji
Kiedy wydaje się już, że nie jesteśmy wstanie zapobiec ominięciu naszych zabezpieczeń w kontekście dostatecznie zmotywowanego użytkownika mamy w zanadrzu jeszcze jeden oręż, mianowicie filtry aplikacyjne. Każda wykorzystywana na komputerze aplikacja sieciowa ma pewien znany schemat działania. Właściwą dla siebie konstrukcję nagłówków i zawartych w nim informacji oraz pewne szczególne własności charakterystyczne tylko i wyłącznie dla niej. Taki zestaw informacji jest jakby odciskiem palca aplikacji. Posiadając odpowiednie sygnatury dla danych typów aplikacji oraz urządzenia będące w stanie przeanalizować transportowany ruch w warstwie aplikacji i porównać go z sygnaturami jesteśmy wstanie wykryć czy dany ruch jest rzeczywiście tym za co się podaje. Odpowiednio skonfigurowane proxy może np. wykryć że wewnątrz pakietów http przesyłany jest ruch SSH lub że aplikacja inna niż http przesyła ruch na porcie 80 czy 443 i taki ruch zablokować.
Nowoczesne rozwiązania UTM oraz Web filtering posiadają tego typu firewalle aplikacyjne które skutecznie potrafią poradzić sobie z próbami tunelowania czy wykorzystania sieci TOR.
Czy warto ?
Jak już wcześniej wspominałem wybór metody dostępu do Internetu oraz przyjęty poziom zabezpieczeń zależy od bardzo wielu czynników tj. jak kluczowość naszych danych, poziom wyszkolenia pracowników czy też zakres pozostawianej im swobody. Jednakże, nie ulega wątpliwości, że nawet przy największym zaufaniu zawsze warto antycypować pewne zagrożenia i aktywnie im zapobiegać. Dlatego właśnie pewien podstawowy zakres ochrony (chociażby blokowanie wyższych portów) jest wskazany prawie w każdym z przypadków. Jednocześnie przy coraz popularniejszych a tym samym tańszych bardzo skutecznych i wydajnych rozwiązaniach UTM warto rozważyć ich zakup i wykorzystać oferowanie przez nie funkcjonalności. Często koszty implementacja takiego rozwiązania nie będą wyższe niż klasycznego firewalla a ewentualne korzyści (zatrzymanie wycieku danych) mogą okazać się znamienne.
RAMKA 1 Konfiguracja tunelu SSH
Konfiguracji musimy dokonać zarówno po stronie klienta i serwera. Przyjmijmy, że posiadamy serwer z Linuksem (niech to będzie jedna z najpopularniejszych dystrybucji tj. CentOS).Serwer dostępny jest pod publicznym adresem IP X.X.X.X (albo podłączony bezpośrednio do Interentu lub za NAT-em z przekierowanymi wszystkimi lub określonymi portami). Z wnętrza sieci w naszej firmie można wyjść bez specjalnych restrykcji na porty 80 i 443.
W ramach podstawowej instalacji Linuksa mamy zainstalowany i działający serwer SSH musimy tylko sprawić aby słuchał na określonym porcie (w naszym przypadku 80). W tym celu podejmujemy następujące kroki:
- Za pomocą naszego ulubionego edytora otwieramy plik „/etc/ssh/sshd_config”
- Odnajdujemy wy komentowaną linię „Port 22”
- Usuwamy komentarz i zmieniamy „22” na 80”
- Następnie restartujemy demona SSH za pomocą komendy „service sshd restart”
Jeżeli korzystamy z IPTABLES musimy jeszcze zmienić port ssh w regule go dopuszczającej. W tym celu wykonujemy:
- Edytujemy plik „/ets/sysconfig/iptables”
- Odnajdujemy linię „-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT”
- Zmieniamy 22 na 80 i zapisujemy zmiany
- Następnie restartujemy IPTABELS za pomocą komendy „service iptables restart”
Po stronie klienta (zakładam, że jest Windows) rozpoczynamy od pobrania i uruchomienia Putty.exe po czym wykonujemy następujące kroki:
W Kategorii „Session” w polu „Host Name” wpisujemy adres IP naszego serwera tj. X.X.X.X i zaznaczmy SSH. W polu „Port” wpisujemy 80.
- Przechodzimy do Kategorii SSHàTunnels
- W polu „Source port” wpisujemy np. „8080”, zaznaczmy opcję „Dynamic” i klikamy „Add”
- Wracamy o Kategorii „Session” i klikamy „Open”
- Wpisujemy Login i Hasło po czym zostajemy połączeni.
- W opcjach naszej przeglądarki odnajdujemy ustawienia Proxy
- Zaznaczmy „SOCKS proxy”, w polu adres wpisujemy „localhost” a w polu port „8080”
Po wykonaniu tych kroków możemy zacząć surfować bez ograniczeń.
