Systemy firewall (zapory) pojawiły się już dość dawno, bo pod koniec lat osiemdziesiątych ubiegłego wieku. Pomimo to trudno oprzeć się wrażeniu, że wielu projektantów i programistów aplikacji sieciowych zdaje się zupełnie nie dostrzegać tego faktu, co możemy zaobserwować w działaniu tworzonych przez nich aplikacji.
Jedno z najczęściej używanych rozwiązań pracy systemów sieciowych oparte jest na współpracy aplikacji (uruchamianej za pomocą przeglądarki internetowej na serwerze aplikacji) z bazą danych. Taki model współpracy określany jest fachowo aplikacją uruchamianą po stronie serwera (server side application).
Implementacja powyższego rozwiązania bez wcześniejszego zrozumienia środowiska w jakim będzie ono pracować, może doprowadzić do ujawnienia się pewnej "wady konstrukcyjnej". Prześledźmy sposób działania takiej aplikacji.
Klient uruchamia przeglądarkę, wywołuje url aplikacji, loguje się i zaczyna pracę na serwerze z programem. W tle serwer aplikacji loguje się do bazy danych zgodnie z jego profilem. Dodatkowo, zupełnie bez wiedzy użytkownika, na urządzeniu firewall, którego istnienia użytkownik może nie być świadom, została odnotowana sesja TCP - poprzez wpis do tablicy połączeń. Oczywiście wszystko to ma miejsce przy założeniu, że użytkownik powinien mieć dostęp do aplikacji, oraz że urządzenie filtrujące ruch jest poprawnie skonfigurowane.
Sam proces wykrycia poprzez firewall nowej sesji skutkuje optymalizacją pracy urządzenia. Ograniczana jest potrzeba przetwarzania wszystkich zdefiniowanych reguł dla każdego przychodzącego pakietu, zidentyfikowanego w ramach nawiązanego już połączenia. Aby jednak podejście to nie mogło zostać wykorzystane do wykonania ataku (np. poprzez przejęcie niezamkniętej, a wygasłej jednostronnie sesji) urządzenia mają zdefiniowany licznik braku aktywności ruchu (timeout conn). Jeżeli do upływu czasu wyznaczonego przez ten parametr nie pojawi się pakiet w ramach danego połączenia, wpis o połączeniu jest usuwany z tablicy. Bardzo często spotykaną wartością licznika jest jedna godzina.
Urządzenia mające opisaną wyżej funkcjonalność, określaną jako SPI (Statefull Packet Inspections), są obecnie najczęściej używane na rynku, głównie z uwagi na prostotę konfiguracji (w ramach jawnie dopuszczonego nawiązanego połączenia pakiety zwrotne są wpuszczane bez potrzeby dodatkowej konfiguracji).
Przyjrzyjmy się jeszcze pozostałym urządzeniom biorącym udział w komunikacji. Serwery baz danych są z natury swojej pracy maszynami mocno obciążanymi ruchem. Administratorzy, aby bronić sie przed nadmierną eksploatacją zasobów przez poszczególnych użytkowników, często ograniczają liczbę możliwych sesji do dwóch lub trzech jednoczesnych połączeń. Również na poziomie bazy danych istnieje parametr timeout, określający stopień nieaktywności użytkownika. Pozwala on wyłowić opuszczone sesje. Jednak często jest on ustawiany na dość wysokie wartości - średnio kilka godzin.
Mając na uwadze właściwości przedstawionego środowiskaprzeanalizujmy dodatkowy problem. W codziennej pracy z aplikacją (np. do wystawiania faktur) może wystąpić sytuacja, kiedy użytkownik nie jest wylogowany z aplikacji, ale przez pewien czas nie wykonuje w niej żadnych działań. W takich okolicznościach zostanie przekroczony czas bezczynności. Wówczas użytkownik korzystający z aplikacji, po wypełnieniu formularza klika wyślij i dostaje komunikat o przekroczeniu czasu sesji. Co następnie robi? Loguje się ponownie. Na firewallu otwierana jest nowa sesja TCP. Na serwerze również otwierana jest nowa sesja w aplikacji i ponownie następuje logowanie do serwera bazy danych. Zaplanowana czynność przez użytkownika zostaje wykonana. Jeżeli jednak znów nastąpi okres bezczynności rzędu jednej godziny, to następna próba logowania nie powiedzie się. Będzie to spowodowane przekroczeniem liczby dopuszczonych jednoczesnych użytkowników pracujących w bazie danych.
Ze strony bazy danych problem ten określany jest jako problem opuszczonych sesji (ang. orphended sessions). Ze punktu widzenia użytkownika początkowa analiza wskazuje jako źródło problemu system firewall.
Najczęściej pojawiają się dość absurdalne pomysły rozwiązania tego problemu w postaci zwiększenia czasu dla bezczynnych sesji TCP. Nie jest to jednak zgodne z wytycznymi bezpieczeństwa dla systemów IT. Tworzy się bowiem niebezpieczną lukę w zabezpieczeniach, która może zostać wykorzystana do przeprowadzenia włamania do systemu. Jak temu zaradzić? Najprościej poprzez wyposażenie aplikacji w mechanizm sygnalizacji aktywności (keepalive packets). Specjalne pakiety, w niewielkim stopniu absorbujące aplikację oraz pasmo sieci, są przesyłane w stałych odstępach czasu, co pozwala utrzymać aktywny wpis w tablicy sesji firewalla i nie dopuścić do wygaśnięcia sesji.
Oczywiście nie jest to jedyne możliwe rozwiązanie i nawet jeżeli po stronie serwera baz danych znajdzie się lepsze, to konstruowanie aplikacji informującej urządzenia sieciowe o swojej aktywności wydaje się być dobrą praktyką.
Jak widać programowanie aplikacji sieciowych nie jest zagadnieniem prostym. Potrzeba dużej wiedzy zarówno programistycznej jak i wyobraźni sieciowej, aby powstał produkt możliwy do zastosowania w każdej infrastrukturze sieciowej. Dobrym początkiem dla każdego programisty chcącego napisać rozwiązanie sprawnie działające w dowolnym środowisku sieciowym, powinna być chęć zgłębienia co kryje się poniżej API języka programowania.
***
Autorem artykułu jest Jakub Rosiak.
NetWorld
