Firewalle aplikacyjne - Zabezpieczanie aplikacji internetowych Wojciech Dworakowski
Agenda Dlaczego tradycyjne mechanizmy nie wystarczają? Wykorzystanie zaawansowanych firewalli Firewalle aplikacyjne architektura i zasada działania NGSecureWeb CodeSeeker Podsumowanie (za i przeciw)
Podnoszenie poziomu bezpieczeństwa Podnoszenie poziomu bezpieczeństwa Metody prewencyjne zapobieganie powstawaniu zagrożeń Metody proaktywne mechanizmy aktywnie reagujące na próby ataków Dobre praktyki: należy stosować oba rodzaje zabezpieczeń zabezpieczanie na wielu poziomach
Aplikacje internetowe Aplikacje internetowe - metody prewencyjne Architektura zwiększająca bezpieczeństwo Stosowanie dobrych praktyk programistycznych! Ciągłe edukowanie programistów Reagowanie na nowe typy zagrożeń Lista webappsec: www.securityfocus.com/archive/107 Projekt OWASP: www.owasp.org
Metody prewencyjne - uwagi Administrator bazy danych, serwera aplikacji, sieci lub admin. bezpieczeństwa: Ma ograniczony wpływ na działania developerów Czasami aplikacja pochodzi ze źródeł zewnętrznych
Tradycyjne firewalle Tradycyjne firewalle Filtrują ruch na podstawie nagłówków 4-tej warstwy OSI (TCP) Firewall 9iAS 5. Aplikacji OC4J DBMS Oracle HTTP Server Web Cache Web Cache 4. TCP 3. IP Metadata 2. Łącza 1. Fizyczna Atak będzie dla nich zwykłym ruchem HTTP
Analiza na wyższych warstwach Analiza na wyższych warstwach Firewalle z rozszerzonymi możliwościami Firewalle klasy proxy Moduły filtrujące konkretne protokoły Firewalle aplikacyjne Moduł filtrujący do serwera WWW Najlepsze rozwiązanie!
Firewall z możliwością analizy ruchu Firewall z możliwością analizy ruchu HTTP Firewall Filtr HTTP 9iAS 5. Aplikacji OC4J DBMS Oracle HTTP Server Web Cache Web Cache 4. TCP 3. IP Metadata 2. Łącza 1. Fizyczna Ruch HTTP jest przekazywany do odsobnego modułu
Checkpoint Firewall-1 HTTP Security Server Filtrowanie według: metody (GET, POST, inne) zawartości URI
Firewall-1 konfiguracja Krok 1 Zdefiniowanie opisu ataku: Manage Resources New URI
Firewall-1 konfiguracja Krok 1
Firewall-1 konfiguracja Krok 2 Zdefiniowanie reguły blokującej Service Add with resource
Firewall-1 Zdefiniowana reguła: Wady Firewall-1 HTTP Security Server: Analizuje tylko URI Analiza nie obejmuje metody POST (najczęściej stosowana)
Filtrowanie na firewallu Filtrowanie na firewallu Może kontrolować ruch do wielu serwerów WWW (aplikacji) Ciężka konfiguracja (bardzo dużo reguł) Ruch SSL - niewidoczny dla analizatora Można rozszyfrowywać na firewallu Brak szyfrowania end-to-end Kłopotliwe w zaawansowanych konfiguracjach Brak kontroli serwera aplikacji nad zabezpieczeniem sesji
Filtrowanie na firewallu Filtrowanie na firewallu Ciężko jest zdefiniować dobry zestaw reguł Dużo reguł = duże obciążenie Łatwo go obejść np: kodowanie URI w hex Warto je stosować jako mechanizm uzupełniający
Firewall aplikacyjny Firewall aplikacyjny Działa jako moduł serwera WWW Apache moduł IIS Filtr ISAPI NES/iPlanet Filtr iapi Wstępną obróbką zleceń zajmuje się serwer WWW rozkodowanie SSL zdekodowanie zlecenia
Firewall aplikacyjny Firewall aplikacyjny Nie musi dbać o szyfrowanie SSL Nie da się go obejść przez zakodowanie zlecenia HTTP (np. hexadecymalnie) Uproszczenie Analizuje ruch w takiej postaci, jak go otrzyma serwer aplikacyjny
Firewalle aplikacyjne a Oracle Firewalle aplikacyjne a Oracle 9iAS Oracle HTTP Server OC4J Firewall aplikacyjny Firewall Metadata Oracle HTTP Server = Apache 1.3 OC4J można integrować z MS IIS DBMS
NGSecureWeb Program komercyjny Wersje dla Apache 1.3 na wiele różnych architektur (Linux, Solaris, BSD, Windows, HPUX) Poza tym: IIS i iplanet Konfiguracja Graficzna konsola (tylko lokalnie) Edycja plików konfiguracyjnych
NGSecureWeb Rodzaje filtrów Long URL Protection Traversal Directory Protection Long Headers Protection Forbidden Words Protection Shellcode Protection Non-Printable Characters Protection Method Protection
NGSecureWeb
NGSecureWeb - wady Brak możliwości definiowania własnych reguł Nie da się używać wyrażeń regularnych w filtrze Forbidden Words Intruz zawsze jest informowany
CodeSeeker OpenSource projekt OWASP Wg dokumentacji: Apache, IIS, iplanet W instalatorze tylko DLL do IIS Moduł Apache trzeba kompilować Jeszcze w fazie beta
CodeSeeker Architektura Jedna konsola może kontrolować wiele serwerów Konsola napisana w Javie Moduły serwerów w C/C++ Pierwszy z serwerów służy jako repozytorium polityki inspekcji ruchu Ruch międzu konsolą a modułem serwera szyfrowany SSL-em
CodeSeeker Definiowanie polityki Bardzo rozbudowane możliwości definiowania polityki inspekcji Wbudowana bogata baza sygnatur ataków ogólne charakterystyczne dla danego typu serwera Można definiować wyjątki (ścieżki URI) Opis ataków zdefiniowany w dokumencie XML
CodeSeeker Definiowanie polityki
CodeSeeker Reakcja na atak Brak reakcji Zablokowanie odwołania (można zdefiniować zwracany kod błędu i informacje tekstową) Przekierowanie do innego URL
CodeSeeker Reakcja na atak
CodeSeeker Sposoby informowania Wysłanie e-maila Zapisanie informacji przez syslog (również zdalnie) Zapisanie informacji do EventLog (Windows) Zapisanie informacji do pliku tekstowego Można definiować format informacji
CodeSeeker Sposoby informowania
CodeSeeker Sposób wdrażania 1. Uruchomienie w trybie pasywnym Tylko logowanie zdarzeń Wykonanie wszystkich operacji na monitorowanej aplikacji i sprawdzenie zachowania się filtrów 2. Tunning reguł filtrowania, zdefiniowanie wyjątków 3. Uruchomienie reakcji na ataki
CodeSeeker Wady Wersja beta Niedopracowany instalator + nieudokumentowane obejścia problemów Brak skompilowanych modułów do Apache i iplanet
Podsumowanie Filtrowanie ruchu tylko jako środek uzupełnianjący Nie zabezpiecza przed wszystkimi klasami ataków Skutecznie utrudnia zadanie intruzom Nie należy ulegać fałszywemu poczuciu bezpieczeństwa! Nic nie zastąpi dobrych praktyk programistycznych i okresowej kontroli bezpieczeństwa
Pytania? http://www.securing.pl http://www.ipsec.pl Wojciech Dworakowski wojciech.dworakowski@securing.pl