Według różnych statystyk ok. 80% ataków hakerskich dotyczy portu 80, przez który przechodzi ruch webowy. Ciężar ochrony aplikacji webowych spada głównie na urządzenia warstwy sieciowej. Aplikacje webowe potrzebują jednak specjalnej ochrony.

Zapory ogniowe zaprojektowane specjalnie do ochrony aplikacji webowych mogą rozpoznawać próby wykorzystania efektów przepełnienia bufora, przemycania fałszywych komend - SQL lub systemowych czy też manipulowania strumieniem danych. Rozpoznają zagrożenia, których nie są w stanie wykryć zapory ogniowe warstwy sieciowej. Pierwsze zapory ogniowe to proste filtry pakietów. Potem pojawiły się zapory z kontrolą kontekstową (stateful inspection), a następnie systemy wykrywania wtargnięć (Intrusion detection). Nowszą technologię ochronną Internetu reprezentują zapory ogniowe ze szczegółową kontrolą pakietów (deep packet inspection), chroniące przed szkodliwymi tworami programowymi, które mogą przenikać przez starsze technologie ochronne do sieci przedsiębiorstwa.

Analiza pakietów w kontekście stanów połączenia, rozkładanie ich na czynniki pierwsze i analizowanie strumienia pakietów tworzących indywidualną sesję, umożliwia aplikacyjnym zaporom ogniowym identyfikowanie nieprawidłowych zachowań - w ramach poszczególnych protokołów - mogących być sygnałem całkiem nowej formy ataku. Zapory ogniowe ze szczegółową kontrolą pakietów są najnowszym etapem ewolucji technologii zapór ogniowych.

Szczegółowe prześwietlanie pakietu

Zapory aplikacyjne mogą rozpoznawać szkodliwy ruch, nierozpoznawany przez zapory stateful inspection. Te ostatnie analizują w pakiecie nagłówki poziomu sieciowego, dopiero jednak szczegółowa kontrola pakietów pozwala na odnalezienie ataku ukrytego w legalnym protokole - przez wyszukiwanie charakterystycznych sygnatur w kolejnych warstwach pakietu.

Systemy wykrywania włamań działają podobnie, ale ich reakcją jest alarm wysłany do administratora sieci, który decyduje, czy podejrzany ruch jest atakiem (praktycznie już będącym w toku). Zapory ze szczegółową kontrolą pakietów różnią się tym, że automatycznie podejmują działania zmierzające do blokowania wykrytego ataku. Analizują, jak przebiega realizacja protokołu i czy przebieg ten jest zgodny z polityką określającą poprawne wzorce ruchu. Zapora składa pakiety w ciąg reprezentujący sesję i analizuje, czy przebieg sesji jest typowy dla właściwego korzystania z aplikacji. Nabywa wiedzę o każdej aplikacji, wyszukując takie elementy, jak używane przez aplikacje URLe, ich strukturę i sposób korzystania z cookie. Opierając się na tych informacjach, jest budowany profil pracy aplikacji i sposób jej używania. Tworzony jest model służący do analizy bieżących zachowań i wykrywania anomalii, które mogą być blokowane automatycznie lub oznaczone do kontroli przez personel IT.

Wykrycie ataku przez zaporę ogniową poziomu aplikacyjnego wymaga właściwej reakcji. Bardziej pożądane jest blokowanie jedynie adresu IP źródła ataku niż całego ruchu używającego danego portu.

Implementacja zapory

Funkcje zapory ogniowej aplikacji webowych są realizowane przez specjalizowane urządzenia, oprogramowanie serwerowe lub są integrowane w platformach ochrony bądś przełącznikach sieciowych.

Programowe zapory ogniowe warstwy aplikacyjnej są dobrym wyborem dla ochrony jednego czy dwóch serwerów. Pewną zaletą jest to, że produkty programowe mogą rezydować na tym samym serwerze webowym co chroniona aplikacja.

Jednak dla dużych organizacji zapory ogniowe w postaci urządzeń są w praktyce koniecznością. Poza wyborem pomiędzy sprzętem a czystym oprogramowaniem w zaporach aplikacyjnych można poszukiwać mechanizmów białych i czarnych list sygnatur.

Podobnie jak w oprogramowaniu antywirusowym, czarne listy zawierają powszechne znane sygnatury ataków i po rozpoznaniu takich sygnatur w monitorowanym ruchu ostrzegają administratora lub blokują użytkownika. Wadą czarnych list jest to, że nieaktualna lista sygnatur może przepuszczać niewłaściwy ruch.

Zapory aplikacyjne w bramach ochronnych web services

Zwiększająca się złożoność ataków na poziomie aplikacyjnym i wzrost wolumenu ruchu aplikacyjnego zmuszają firmy do wdrażania w sieciach specjalizowanych urządzeń ochronnych oraz przyśpieszających. Obejmują one zapory ogniowe do ochrony ruchu HTTP i HTTPS, akceleratory SSL (Secure Socket Layer) do wykonywania szyfrowania i deszyfrowania; serwery proxy do translacji wrażliwych wewnętrznych URL i ukrywania informacji o platformie oraz akceleratory we/wy do zarządzania ustawianiem połączeń TCP.

Web services są otwarte na takie same formy ataków, jak aplikacje HTML, toteż działy IT stoją przed perspektywą wdrażania kolejnych specjalizowanych urządzeń do ochrony ruchu XML. Rozwiązaniem są bramy ochronne aplikacji. Takie urządzenia chronią aplikacje HTML i XML oraz wykonują dodatkowe funkcje ochronne i sieciowe, dotychczas wykonywane przez specjalizowane produkty.

Bramy ochronne aplikacji pozwalają obniżyć liczbę urządzeń w sieci. Konsolidacja funkcji polepsza całkowitą wydajność aplikacji drogą minimalizacji liczby przejść na drodze do serwera webowego. Mniej urządzeń i reguł polityki bezpieczeństwa do zarządzania powoduje zmniejszenie kosztów operacyjnych.

Bramy ochronne aplikacji, operujące w warstwie siódmej, przechwytują i kontrolują ruch zanim osiągnie on serwer webowy i po tym, jak ten serwer opuści. Weryfikują, czy zlecenie użytkownika i odpowiedś serwera odpowiadają parametrom i strukturze definiującym poprawne zachowania w języku aplikacyjnym (HTML lub XML). Każde odchylenie od poprawnego zachowania aplikacji jest natychmiast blokowane.

Poza podstawowymi funkcjami ochrony aplikacji HTML i XML, bramy ochronne aplikacji mogą wykonywać następujące funkcje:

1. Przyspieszanie SSL - deszyfruje i analizuje ruch SSL, wykrywając zakamuflowane w zaszyfrowanej treści ataki hakera. Wykonywanie przyspieszania SSL na bramie istotnie zwiększa przepustowości i czas odpowiedzi, uwalniając serwer webowy od tych zasobożernych operacji.
2. Ochrona obiektów biznesowych - analiza wychodzącego ruchu aplikacyjnego w celu wychwycenia informacji wrażliwych, takich jak numery kart kredytowych czy kont, co zapobiega wyciekom poufnych informacji z aplikacji webowych i baz danych zaplecza.
3. Przyspieszenie ruchu webowego - polepsza wydajność aplikacji i czas odpowiedzi przez odciążenie serwera webowego z ustanawiania połączeń TCP przez przeniesienie tego procesu poza serwer. Brama ochronna aplikacji kończy wszystkie wchodzące połączenia klienckie i multipleksuje je do niewielkiej wiązki trwałych połączeń z serwerem webowym.
4. Osłona aplikacji - chroni przed uzyskiwaniem przez hakera wrażliwej informacji o serwerach webowych, bazach danych, systemach operacyjnych, wewnętrznych nazwach domen itp. Wielopoziomowa osłona blokuje hakerowi dostęp do informacji ważnej dla wstępnej, rozpoznawczej fazy ataku.
5. Proxy aplikacyjne - dwukierunkowa translacja URL pozwala na publikowanie przyjaznych i zwartych URL, bez względu na wewnętrzną strukturę ich nazw. I tak bank może prezentować klientom online URL w postaci http://www.mybank.com, podczas gdy wewnętrzny URL, który jest docelowy, to często bardzo długi ciąg nic niemówiących znaków.
6. Ochrona przed zniszczeniem - wykrywa nawet najmniejsze zmiany na stronach webowych i blokuje uszkodzone strony przed udostępnianiem.

Bramy ochronne aplikacji zapewniają zintegrowaną linię obrony dla aplikacji HTML i XML, a także eliminują konieczność stosowania wielu specjalizowanych urządzeń, zapewniając lepszą wydajność aplikacji i niższe koszty zarządzania.

Zobacz także

• Audyt bezpieczeństwa systemów IT
• Audyt systemów ochrony
• Ciągłość działania i dyspozycyjność (Business Continuity and Availability)
• ILM Cykl życia informacji
• Ocena bezpieczeństwa sieci
• Strategia ochrony informacji
• Wzmocniony system operacyjny
• Zarządzanie cyklem życia informacji
• Zarządzanie incydentami