HARD CORE SECURITY LAB

Zapraszam do zapoznania się z kolejnym opracowaniem biorącym udział w Urodzinowym Konkursie HCSL, zorganizowanym przez serwis HARD CORE SECURITY LAB oraz firmę Securitum. Autorem poniższego artykułu, w którym obszernie omówione zostały bardzo interesujące metody pozwalające na zautomatyzowanie mechanizmów typu IDS/IPS, jest Adrian "Vizzdoom" M. (e-mail: vizzdoom w domenach gmail.com lub linux.pl). Autor jest studentem Politechniki Śląskiej (kierunek Informatyka, wydział AEI), programistą, pasjonatem sieci i systemów operacyjnych oraz założycielem grupy Underground Crew, zajmującej się badaniem bezpieczeństwa informacji (http://ucrew.tk/). Zapraszam do lektury!

Każdy ceniony administrator zna narzędzie iptables. Na podstawie zdefiniowanych reguł, iptables loguje ruch sieciowy i decyduje o przeznaczeniu pakietów. Kontrola odbywa się w jądrze systemowym i jest niezwykle skuteczna. Wszystkie zdarzenia i akcje są logowane, co umożliwia znalezienie agresorów, zmianę polityki bezpieczeństwa, analizę powłamaniową. Ilość generowanych informacji w dużych systemach może być jednak tak ogromna, że może uniemożliwić ręczną konfigurację. W takim przypadku pomoże nam pakiet psad (ang. Port Scan Attack Detector), który automatyzuje wiele czynności związanych z ustawieniami iptables. Artykuł nastawiony jest na opis psad, jednak w celu zwiększenia bezpieczeństwa systemu zostanie krótko opisany również snort, fwsnort oraz fwknop.

Założenia, budowa i wstępna konfiguracja systemu

Dokładne zbadanie aspektów bezpieczeństwa oraz zrozumienie działania iptables i jego pomocników (snort,psad,fwsnort,fwknop i wielu innych) jest niemożliwe bez przedstawienia praktycznych wdrożeń systemów. Dla celów artykułu został stworzony prosty system, który może być stworzony przez każdego czytelnika w domowym zaciszu.

Założeniem jest następujące: stwórzmy serwer WWW (np. w celu udostępniania materiałów studentom uczelni). Serwer to zwykły komputer w sieci osiedlowej (nazwijmy go vizzdoom-laptop), który jest podłączony do świata poprzez router o nazwie CISCO (nazwa służy do identyfikacji, firma nie ma tu raczej znaczenia). Czasem chcemy wrzucać pliki z innych komputerów w sieci (poprzez FTP) oraz chcemy w tej sieci zdalnie administrować węzłem (poprzez SSH).

Ustalmy politykę bezpieczeństwa dla tego systemu. W tym artykule zakładam, że komputer jest podłączony do sieci lokalnej 192.168.0.0/24. Węzeł vizzdoom-laptop (192.168.0.143 wlan0) jest systemem, który chcemy zabezpieczyć. Węzeł ten jest skonfigurowany tak, aby:

• udostępnić serwer WWW na porcie 80 tylko z sieci zewnętrznej,
• udostępnić serwer FTP dla klientów tylko w sieci wewnętrznej,
• udostępnić serwer SSH dla klientów tylko w sieci wewnętrznej,
• umożliwić pingowanie serwera z sieci wewnętrznej i zewnętrznej.

DIAGRAM 1. Schemat sieci

O iptables napisano wiele bardzo dobrych artykułów. Tematyka związana z najsławniejszym firewallem na świecie jest bardzo rozbudowana i nie będzie tutaj przytaczana. W celu skonfigurowania serwera zgodnie z wcześniejszymi założeniami stworzymy skrypt powłoki, który odpowiednio doda reguły iptables.

Skrypt nosi nazwę iptables.sh, jego treść znajduje się na listingu 1. W podstawowy sposób udostępniamy odpowiednie porty i protokoły, które wdrażają wszystkie założenia projektowe. Specjalnie nie robimy skomplikowanych wpisów (jak np. anty-spoofing) aby zauważyć moc opisywanych tu narzędzi wspomagających. Listing jest mocno skomentowany, aby każdy mógł zrozumieć znaczenie poszczególnych wpisów.

Testy polityki bezpieczeństwa

Zacznijmy od krótkich testów na root@vizzdoom-laptop aby sprawdzić czy mamy dostęp do danych usług. Listing 2. przedstawia udane próby pingowania, łączenia się na serwery stron WWW, autoryzację SSH oraz FTP. Testowo podłączono się do bazy danych mysql, połączenie nie zostało ustanowione co jest zgodne z założoną polityką.

Teraz czas na test zapory dla drugiego zestawu reguł. Listing 3. obrazuje test przeprowadzony z komputera podłączonego do sieci wewnętrznej (voldy@Om-nom-nom). Dla przyśpieszenia testów i czytelności, użyto skanera Nmap. Pierwsze skanowanie zostało przeprowadzone bez włączonego firewalla z wcześniej napisanym skryptem. Skaner wykrył usługi FTP, SSH, HTTP, MySQL (i dwie inne, nieznane usługi). Drugie skanowanie nie powiodło się, ponieważ serwer nie odpowiadał na zmodyfikowane pingi Nmap. Trzecie skanowanie pomija pingowanie Nmapa i testuje wszystkie porty. Zgodnie z założeniami, widoczny jest tylko port 21/ftp oraz 22/ssh. Po odpowiednim skonfigurowaniu routera, pod odpowiednim adresem IP była możliwość odwiedzenia strony WWW serwera HTTP nginx postawionego na serwerze vizzdoom-laptop. Zapora iptables jest więc skonfigurowana poprawnie.

Snort

Snort jest jednym z najpopularniejszych systemów wykrywania włamań. Jest to oprogramowanie stworzone dla systemów Uniksowych, jednak w uproszczonej wersji może zostać zainstalowane na systemach z rodziny Windows. Z pewnością dzięki temu popularność tego programu znacznie wzrosła. Snort jest w stanie wykrywać skomplikowane ataki pracując w trybie sniffera, rejestratora pakietów lub IDS/IPS. Projekt stosunkowo szybko się rozwija i ciągle zysuje nowe możliwości. Możemy wykrywać takie ataki jak próba przepełnienia bufora, popularne ataki na usługi WWW czy chociaż dzielić żądania HTTP na oddzielne komponenty (Metody, URI, Nagłówki, Ciastka, Treść) i analizować je oddzielnie. Wykrywanie podejrzanego ruchu polega na jego analizie i dopasowywaniu do tysiąca reguł, które zasilają bazę Snort (co pewien czas ją powiększając). Reguły Snorta są to zestawy wielu wzorców w plikach konfiguracyjnych, które cechują się znakomitą skutecznością.

Jest to program o którym trudno nie wspomnieć poruszając tematykę IDS/IPS. Faktem jest, że pomimo skuteczności, Snort jest mało elastycznym oprogramowaniem (dla początkujących), które nie potrafi w łatwy sposób rozwiązać większości problemów związanych z bezpieczeństwem w sieci. Jednakże skuteczność wspomnianych wyżej wzorców-reguł jest na tyle wysoka, że warto je zastosować w innych projektach. My natomiast skupimy się na troszkę innym systemie zabezpieczającym o nazwie PSAD, który czerpie całymi garściami z reguł Snort. Podobnie rzecz się ma z fwsnort - projektem pokrewnym dla psad, jeszcze bardziej zwiększającym bezpieczeństwo dzięki iptables. Program psad zostanie dokładniej omówiony w dalszej części opracowania.

Pamiętajmy, że Snort jest bardzo ciekawym systemem - jest defacto podstawową bazą danych dla innych projektów, które po części zostaną opisane. O Snort można znaleźć bardzo dużo informacji w sieci (także w polskiej), więc zainteresowanych zachęcam do lektury.

==== PSAD ====

Wielką elastyczność, dużą prostotę oraz praktycznie 100% skuteczność ochrony przed intruzami na serwerze zapewnia firewall iptables. Każda reguła konfiguracji tej zapory dzięki jej specyfice opisuje w jednoznaczny sposób mały wycinek polityki bezpieczeństwa. Tak definiowane reguły pozwalają określić jak zachowuje się sieć w takim, a nie innym przypadku... i firewall to zapewnia.

Nie sposób jednak przewidzieć wszystkich wektorów ataku. Pomagają w tym oczywiście logi. Tysiące linii ostrzeżeń generowanych przez iptables, skonfigurowanego nawet dla średnio-skomplikowanej polityki bezpieczeństwa skutecznie zniechęcają administratorów do analizy logów. W efekcie napastnik atakujący system w sposób roztropny i mało agresywny może kolekcjonować wiele danych pozostając niezauważonym. Pakiet psad przetwarza dane tworzone przez iptables i analizuje je pod kątem podejrzanego ruchu. Doskonale spisuje się w detekcji skanowania systemu przy użyciu narzędzi w stylu Nmap, rozpoznaje ataki DDoS i wiele innych. Oprócz wykrywania podejrzanego ruchu, psad zbiera wiele informacji o agresorze (np. poprzez whois), posiada zdolność pasywnego wykrywania systemu operacyjnego używanego przez atakującego (poprzez p0f). Aby zmaksymalizować ochronę systemu, psad może wysyłać ostrzeżenia pocztą elektroniczną w postaci raportów lub generować ostrzeżenia w syslogu. Dodatkowo potrafi zmieniać reguły iptables w taki sposób, aby automatycznie odciąć agresora od naszego systemu. Łatwo zintegrować go z wieloma programami, które wspólnie potrafią stworzyć potężny system IDS/IPS – takimi jak Swatch (monitoruje logi systemowe), fwsnort (wspiera kontrolę pakietów w sieci), fwknop (autoryzacja metodą Port Knocking).

Port Scan Attack Detector jest zbiorem trzech daemonów – głównego psad napisanego w Perlu oraz kmsgd i psadwatchd napisanych w C. Celem kmsgd jest czytanie logów iptables i zapisywanie ich w oddzielnym pliku. Usługa psadwatchd jest strażnikiem, który sprawdza czy dwie pozostałe części pakietu działają w systemie. Dzięki temu wszystkie daemony uruchomione są dokładnie raz, co chroni przed wieloma nieprzyjemnościami. Aby psad działał poprawnie, należy tak ustawić reguły firewalla, aby niechciane pakiety były logowane, a następnie odrzucane (tzw. polityka LOG&DROP). Dzięki temu oprogramowanie agresora nie będzie w stanie wyrządzić większych szkód, a dodatkowo psad zasilany jest danymi, dzięki którym istnieje możliwość identyfikacji intruza. Pakiet psad można zainstalować w standardowy sposób kompilując odpowiednią paczkę lub używając polecenia sudo apt-get install psad (na systemach z rodziny Debian/Ubuntu Linux). Warto nadmienić, że psad jest ściśle związany z firewallem iptables, dlatego nie istnieje jego odmiana na inne systemy niż Linux.

Instalacja psad

Instalacja psad jest bardzo prosta. Paczka instalacyjna znajduje się w dziale download na stronie projektu. Należy ją ściągnąć oraz zainstalować. Użytkownicy niektórych dystrybucji Linuksa mogą pokusić się o skorzystanie z narzędzia w stylu popularnego apt-get, aptitude lub innych, jednakże nie powinna nas odstraszać instalacja ze skryptu udostępnionego na stronie projektu.

Proces instalacji przebiega łatwo i w dodatku umożliwia stworzenie w łatwy sposób podstawowej konfiguracji dla tego oprogramowania. Listing 4. przedstawia proces instalacji psad ze skryptu perla install.pl. Możemy zauważyć, że podczas instalacji zostanie przekopiowany do systemu osobny klient Whois (Marco d'Itri's whois client), wiele reguł snort (który będzie pokrótce przedstawiony w dodatku A) oraz inne dodatkowe oprogramowanie niezbędne do działania. Instalator ponadto zadaje serię pytań, które tworzą prostą konfigurację naszemu asystentowi ściany ogniowej. Istnieje możliwość automatycznego ściągnięcia sygnatur psad z serwerów producenta poprzez instalator lub w przyszłości poprzez użycie programu z odpowiednim przełącznikiem (psad --sig-update).

Podczas instalacji zostaną dodane odpowiednie linie do plików konfiguracyjnych syslogd lub syslog-ng (w zależności, który program rejestruje zdarzenia w systemie) oraz osobny program whois. Wszystkie usługi psad używają pliku konfiguracyjnego /etc/psad/psad.conf który zostanie w dalszej części artykułu dokładniej opisany.

Konfiguracja psad

Plik /etc/psad.conf używa standardowej konwencji czyli zestaw par klucz-wartość (zakończone średnikiem). Najważniejsze klucze to:

• EMAIL_ADDRESSES : określa adresy emailowe, pod które zostaną wysłane raporty z ostrzeżeniami.
• HOME_NET : definiuje sieć wewnętrzną, dzięki czemu można identyfikować podejrzany ruch, który zostanie wykryty dzięki regułom oprogramowania Snort w łańcuchu FORWARD iptables. Sieci wpisuje się w notacji CIDR rozdzielając je przecinkami (np. 192.168.0.20/24, 10.0.0.14/24).
• HOSTNAME jest pełną nazwa hosta w notacji Fully Qualified Domain Name.
• DANGER_LEVEL1 – DANGER_LEVEL5 : Każde działanie, które jest podejrzane, zostanie zaklasyfikowane do jednego z pięciu poziomów ostrzegawczych. Duża ilość pakietów, częstotliwość ich wysyłania, zakresy portów oraz dopasowanie do groźnych sygnatur zwiększa poziom DANGER LEVEL. W zmiennych tych ustalamy ilość pakietów, która spowoduje zaklasyfikowanie danego działania do odpowiedniego poziomu ostrzeżenia.
• ALERTING_METHODS, EMAIL_LIMIT, EMAIL_ALERT_DANGER_LEVEL : Częstotliwość i jakość generowanych raportów można regulować zmiennymi ALERTING_METHODS (możliwość wyłączenia logowania na email i/lub syslog), EMAIL_LIMIT (maksymalna liczba wysyłanych ostrzeżeń o danym IP), EMAIL_ALERT_DANGER_LEVEL (określa od jakiego poziomu zagrożenia mają zostać wysyłane raporty).
• SNORT_SID_STR : ustawienie tej opcji wspomaga nasz system poprzez logi wygenerowanymi przez reguły Snort. Zmienna jest używana w celu zintegrowania dwóch systemów wykrywania włamań.
• SHOW_ALL_SIGNATURES - ustawienie tej zmiennej skutkuje dołączaniem sygnatur na temat adresu IP napastnika przy każdym ostrzeżeniu. Teoretycznie mamy więcej przydatnych informacji, jednak w przypadku bardzo natarczywego ataku zostanie wygenerowanie bardzo dużo informacji, które potrafią zalać logi (oraz np. EMAIL). Warto zaznaczyć, że wszystkie nagłówki i tak są wysyłane przez psad przez pewien okres czasu (ustawiony w zmiennej CHECK_INTERVAL - domyślnie 5 sekund).
• SCAN_TIMEOUT : określa w sekundach ile czasu psad ma śledzić skanowanie napastnika. W przypadku gdy atakujący zacznie skanowanie o godzinie 12:00, następnie 12:30 oraz 12:50 w celu nie generowania podejrzanych logów - nasz system to wykryje i trzy skanowania zostaną zaklasyfikowane w jeden, zbiorczy pakiet na podstawie którego zostanie wygenerowany odpowiedni poziom ostrzeżenia.
• SYSLOG_DAEMON : bardzo przydatna opcja dla osób, które mają problemy z psad. Dzięki niej można zdefiniować program, który odpowiada za logi systemowe. Możliwe opcje w tym kluczu to: syslogd, syslog-ng, ulogd, metalog.
• ENABLE_AUTO_IDS, AUTO_IDS_DANGER_LEVEL : Istnieje możliwość ustawienia psad w tryb systemu wykrywania i przeciwdziałania włamaniom w czasie rzeczywistym (IDS/IPS). Dzięki zmiennym ENABLE_AUTO_IDS oraz AUTO_IDS_DANGER_LEVEL psad może dynamicznie zmienić reguły iptables w taki sposób, aby cały ruch z podanego adresu IP został zablokowany. Jest to bardzo przydatna opcja, jednak domyślnie jest ona wyłączona. Jest kilka czynników działających na niekorzyść włączenia IPS do danego systemu. Bliżej zostanie to omówione w jednym z poniższych paragrafów, tymczasem wystarczy zapamiętać jak włączyć taki mechanizm w psad.
• AUTO_BLOCK_TIMEOUT : definiuje czas blokowania danego adresu IP w momencie gdy ustawiona zostanie zmienna ENABLE_AUTO_IDS na wartość Y. Domyślna wartość 3600 oznacza, że atakujący zostanie zablokowany przez 1 godzinę.

Przykład: 

Załóżmy, że mamy pewność, że adres 10.0.0.1 jest komputerem przyjaznym i nie chcemy uaktywniać systemu IDS/IPS gdy przychodzą pakiety z tego adresy IP. Dodatkowo chcemy aby nasi współpracownicy z sieci 10.0.1.0/24 nie grzebali w zasobach naszego systemu i chcemy im nadać wyższy, domyślny stopień zagrożenia dla FTP (3). Pamiętamy też mały DDOS z maszyn przejętych przez konkurencyjną firmę (sieć 80.220.0.0/24). Aby atak się nie powtórzył, damy im najwyższy stopień zagrożenia (5). Modyfikacja plik u auto_dl zgodnie z powyższymi założeniami powinna wyglądać następująco:

10.0.0.1 0;
10.0.1.0/24 3 udp/21;
80.220.0.0/24 5;

Konfiguracja psad może być rozszerzona o edycję kilku innych plików. Plik /etc/psad/pf.os posiada informacje o systemach operacyjnych z projektu p0f. Modyfikując /etc/psad/snort_rule_dl można zmieniać domyślne poziomy zagrożenia przy odpowiednich zasadach Snort (podobne działanie do pliku auto_dl). Plik sygnatur znajduje się w /etc/psad/signatures. Jest to część zmodyfikowych reguł Snort, które mogą być łatwo aktualizowane.

Obsługa psad

Uruchamiamianie, zatrzymywanie oraz restartowanie daemona psad:
psad start
psad stop
psad -R

Sprawdzanie statusu:
Pokazuje stan uruchomionych usług współpracujących z psad, najczęściej wykryte sygnatury ataków, najaktywniejszych agresorów, najczęściej oblegane porty podczas ataku, wiadomości odnośnie atakujących adresów IP i wiele innych przydatnych informacji:
psad –Status

Aktualizacja pliku sygnatur:
psad --sig-update

ATAK NA SYSTEM

Pierwszym (i najczęściej najważniejszym) krokiem na drodze do przełamania zabezpieczeń systemu jest zbieranie o nim informacji. Najczęściej wykonuje się to poprzez różne skanery (gdzie króluje nmap), próby podłączenia do portów, analiza odpowiedzi na konkretne pakiety. Skanowanie jest tematyką bardzo rozległą. Proste skany łatwo jest wykryć lub zablokować na firewallu, jednak gdy napastnik ma dużo cierpliwości i dobrze zna się na protokołach telekomunikacyjnych - może przysporzyć nam wiele problemów.

Przykłady skanowania systemu przez agresora w sieci lokalnej

Skanowanie będzie przeprowadzane w tej sekcji cały czas z komputera voldy@Om-nom-nom. W momencie gdy węzeł CISCO byłby routerem "przezroczystym", tj. nie blokowałby pakietów (tylko zmieniałby nagłówki IP) wtedy skanowanie z zewnątrz praktycznie niczym nie różniłoby się od skanowania wewnątrz sieci.

FIN SCAN

Jest to ciekawa metoda, w szczególności że może zawieść gdy cel pracuje na niektórych wersjach Windowsa (ale również na routerach CISCO). Na hosty Uniksowe FIN SCAN sprawuje się dobrze, nazywany jest skanowaniem ukrytym, ostrożnym. Polega na wysłaniu pakietu TCP/FIN do danego portu. Pakiety tego typu są wysyłane, gdy węzeł chce zakomunikować, że kończy operację przesyłania danych - co umożliwia odpowiednie wywołanie metod w stylu close() zamykających połączenie zarówno u źródła jak i u celu. Wychwycenie nieprawidłowych pakietów FIN jest trudne, dlatego skanowanie tego typu jest bardzo skuteczne (podobnie jak omawiane niżej XMAS SCAN oraz NULL SCAN - które są odmianami FIN SCAN).

nmap 192.168.0.143 -sF
Host is up (0.0020s latency).
All 1000 scanned ports on 192.168.0.143 are open|filtered

cat /var/log/messages | grep -i "psad"
Oct 10 23:15:32 vizzdoom-laptop psad: src: 192.168.0.150 signature match: "SCAN FIN" (sid: 621) tcp port: 472
Oct 10 23:15:32 vizzdoom-laptop psad: scan detected: 192.168.0.150 -> 192.168.0.143 tcp: [5-1000] flags: FIN tcp pkts: 300 DL: 3

XMAS SCAN

Podobne do FIN SCAN, metoda ta używa pakietów FIN, ale dodatkowo używa jeszcze flag PSH i URG. Paczka taka jest bardzo widoczna, ale o dziwo omija wiele filtrów i zapór.

nmap 192.168.0.143 -sX


Host is up (0.0030s latency).
All 1000 scanned ports on 192.168.0.143 are open|filtered
cat /var/log/messages | grep -i "psad"
Oct 10 23:18:00 vizzdoom-laptop psad: src: 192.168.0.150 signature match: "SCAN nmap XMAS" (sid: 1228) tcp port: 290
Oct 10 23:18:00 vizzdoom-laptop psad: scan detected: 192.168.0.150 -> 192.168.0.143 tcp: [21-995] flags: URG PSH FIN tcp pkts: 85 DL: 2

NULL SCAN

NULL SCAN też należy do grupy "skanowania ukrytego" (FIN/XMAS/NULL). W tej wersji flagi TCP są jeszcze inaczej ustawione - na wartość 0.

nmap 192.168.0.143 -sN


Host is up (0.0020s latency).
All 1000 scanned ports on 192.168.0.143 are open|filtered
cat /var/log/messages | grep -i "psad"
Oct 10 23:23:42 vizzdoom-laptop psad: scan detected: 192.168.0.150 -> 192.168.0.143 tcp: [1-1000] flags: NULL tcp pkts: 1999 DL: 4

SYN SCAN

Skanowanie półotwarte, domyślnie używane przez nmapa. Wysyłany jest pakiet SYN (synchronizacja) na dany port, oczekiwana jest odpowiedź (SYN|ACK lub RST - synchronizacja, akceptacja / reset). Skanowanie tą metodą ma pewne zalety w stosunku do zwykłego (głośnego) skanowania TCP, ale robi sporo hałasu.

nmap 192.168.0.143 -sS

Host is up (0.0023s latency).
Not shown: 998 filtered ports
PORT   STATE SERVICE
21/tcp open  ftp
22/tcp open  ssh
cat /var/log/messages | grep -i "psad"
Oct 10 23:28:57 vizzdoom-laptop psad: scan detected: 192.168.0.150 -> 192.168.0.143 tcp: [1-1000] flags: SYN tcp pkts: 3980 DL: 4

UDP SCAN

Wszystkie wcześniej wymienione metody używały pakietów TCP. Metod używanych do skanowania przez TCP jest bardzo dużo, w odróżnieniu od wersji UDP. Jest to spowodowane przez założenia protokołów. TCP służy do komunikacji, gdy zależy nam na 100% poprawności przesyłanych danych, przez co ramka TCP posiada dużo więcej nagłówków, które można wykorzystać przy ataku. UDP jest protokołem prostszym, szybszym, ale nie gwarantującym takiej skuteczności w komunikacji. Wszystko to sprawia, że wielu administratorów ignoruje UDP (może z wyjątkiem ustawień dla FTP) - dzięki czemu skanowanie to (chociaż wolniejsze) może przynieść wymierne korzyści. Skanowanie UDP polega na wysyłaniu pakietu UDP bez danych i odpowiedniej analizie odpowiedzi.

nmap 192.168.0.143 -sU

Host is up (0.061s latency).
All 1000 scanned ports on 192.168.0.143 are open|filtered
cat /var/log/messages | grep -i "psad"
Oct 10 23:34:02 vizzdoom-laptop psad: scan detected: 192.168.0.150 -> 192.168.0.143 udp: [26-999] udp pkts: 100 DL: 2

Analiza logów każdego typu skanowania

Interpretacja informacji nagromadzonej przez iptables w przeciągu kilku dni może być czasem zadaniem wręcz niemożliwym. Już przy kilku połączeniach na minutę iptables może wygenerować dziesiątki tysiecy linii w przeciągu kilku dni. Zauważenie nieprawidłowości w takim wypadku jest tak utrudnione - że zazwyczaj implikuje zaprzestanie przeglądania logów przez administrację do momentu złamania systemu i wyrządzeniu wielu szkód. Ten natłok informacji zostaje przefiltrowany przez psad - przez co administrator otrzymuje zbiór kilku zwięzłych informacji w syslogu lub drogą emailową.

FIN SCAN

Metoda ta narobiła stosunkowo dużo hałasu w systemie(dodatkowo skanowanie trwało długo), nie podała nam jednak zbyt dużo cennych informacji. Jest to spowodowane podstawowymi założeniami-wpisami w iptables, które na mało pozwalają. Nasz system logował pakiety i prawidłowo je zinterpretował w czasie (a to w tym typie skanowania mogło być trudne, ponieważ czasem trzeba śledzić pakiety FIN). Poziom niebezpieczeństwa został przypisany temu atakowi przez psad na 3 (gdzie 5 to maksymalny, najgroźniejszy stopień). 

XMAS SCAN

Ten skan skutkował wysłaniem trzykrotnie mniejszej liczby pakietów. Napastnik również nie uzyskał ciekawych informacji na temat systemu, wygenerował jednak bardzo mało ruchu (najmniej ze wszystkich, opisywanych tu technik), został wykryty i zaklasyfikowany na DL 2.

NULL SCAN

Trzecia wersja skanowania w podobnej technice. Można tutaj zauważyć jak mała zmiana we flagach TCP podczas używania nmap zmienia ruch wytwarzany przez agresora. NULL SCAN był bardzo kiepskim pomysłem - wygenerował 4 poziom niebezpieczeństwa pomimo, że nie otrzymano żadnych ciekawych informacji o systemie.

SYN SCAN

Sama definicja skanowania półotwartego w dokumentacji nmap sugeruje, że jest to skanowanie bardzo hałaśliwe. Zbieranie informacji było szybkie i opłacalne - intruz wie o otwartych portach dla ftp oraz ssh. Nie wie jedynie o dużych kłopotach, gdyż administrator został powiadomiony o dużych zagrożeniu (DL 4).

UDP SCAN

Część administratorów zapomina o prawidłowym zabezpieczeniu tego protokołu. Wie o tym agresor, który używając tego skanowania wygenerował duży alarm (DL 4) w krótkim czasie. Niestety, oprócz kłopotów - nie zyskał żadnej informacji.

Nieświadomy agresor jest już na celowniku administracji. Osiągnął jednak cel (zna pewne otwarte porty) i próbuje atakować dalej. Przykładowe ostrzeżenie otrzymane na adres mailowy zapisany w konfiguracji psad prezentuje listing 5.

Dalszy atak

Podczas skanowania typu SYN SCAN napastnik dowiedział się o serwerze FTP oraz SSH. Agresor ma dużo czasu i może powoli próbować kolejnych autoryzacji z różnych węzłów sieci. Ograniczając liczbę jednoczesnych połączeń z jednej maszyny nie wzbudzi wielkiego zainteresowania systemów IDS/IPS. Próbuje wykorzystać kilka innych, popularnych wektorów ataku. Zobaczmy jak poradzi sobie z tym psad.

Administrator systemu otrzymuje kolejnego maila z ostrzeżeniem. Po zalogowaniu się na serwer sprawdza status IDS poprzez polecenie:
sudo psad --Status

i analizuje zwrócone informacje. Listing 6 przedstawia w zwięzły sposób wszystkie niebezpieczne wydarzenia w systemie. Analiza logów polega na interpretacji powyższego polecenia, komendy "cat /var/log/messages | grep -i "psad" oraz analizie plików zawartych w listingu 7. Po kwadransie można stwierdzić, że stary agresor 192.168.0.150 przestał być aktywny. Nowe zagrożenie przyszło ze strony 192.168.0.132. Węzeł o tym adresie próbował wielu połączeń (bruteforce) aby uzyskać dostęp do konta FTP. Zaobserwowano również kilkadziesiąt prób łączenia się do SSH. Przy okazji zauważono, że serwer posiada kilka niepotrzebnych aplikacji, które generują zbędny i niepowołany ruch do wielu różnych adresów IP - zdecydowanie jest to ważna rzecz do sprawdzenia.

Trudności z agresorem mogą powodować frustrację administracji. Należy rozważyć decyzje odnośnie wdrożenia systemu IPS, aby odcinać od sieci agresywne węzły.

System zapobiegania włamaniom

W celu ochrony systemu przed wykrytym napastnikiem warto zablokować mu dostęp do naszego systemu. Jest to całkowicie intuicyjne podejście, w szczególności gdy posiadamy system automatycznie wykrywający ataki. Dzięki temu można odciąć większość (wszystkie) węzły kontrolowane przez intruza - chroniąc cenne zasoby. Jest to ogólna idea każdego systemu zapobiegania włamaniom (IPS). Systemy te praktycznie zawsze współpracują z systemami wykrywającymi włamania (tj. psad, Snort, HIDS).

Zalety wdrożenia takiego systemu są jednoznaczne. Czy pomimo tego można mieć powody, które przemawiają przeciwko wprowadzeniu IDS do polityki bezpieczeństwa? Pytanie jest tym ciekawsze, gdy uświadomimy sobie fakt łatwości wprowadzenia takiej funkcjonalności. W omawianym oprogramowaniu psad jest to możliwe poprzez zmianę jednego klucza w pliku konfiguracyjnym psad (ENABLE_AUTO_IDS).

Niestety należy być ostrożnym. Po pierwsze jest to kolejny (i to znaczący) element, który modyfikuje ruch w naszym firewallu. Implikuje to konieczność dokładnej analizy przynajmniej kilku przypadków użycia. Większym problemem może okazać się reakcja agresora przy zauważeniu IDS/IPS. Możemy oczekiwać pewnego rodzaju sprzężenia zwrotnego, gdyż przyciągniemy jego uwagę lub uwagę bardziej wyrafinowanych agresorów. System zapobiegania włamaniom blokuje (bądź utrudnia) ruch agresora, który szybko zauważy nieoczekiwane zmiany czekając na cenne dane. Wielu początkujących agresorów zostanie spłoszonych, jednakże uwaga zaawansowanych intruzów zostanie skupiona na każdym elemencie naszego systemu. Tracimy w takim wypadku praktycznie najważniejszy atut polityki bezpieczeństwa - utrzymywanie agresora w stanie niewiedzy. Wyłącznie aktywny system wykrywania włamań IDS, chociaż może doprowadzić do załamania systemu - wymusza lenistwo, brak uwagi i pośpiech u agresora. Zazwyczaj wtedy zapomina się o stosowaniu proxy, odpowiednio dobieranym oprogramowaniu skanującym oraz o logach, zacieraniu śladów i wielu innych czynnościach - które są w stanie usidlić agresora na kilka lat w zakładzie karnym.

Ogółem tematyka wprowadzaniu IDS do systemu jest dość rozległa i warto przestudiować przynajmniej kilka innych artykułów na ten temat.

IPS w snort

Aby włączyć IPS w psad należy odpowiednio zmienić kilka kluczy w pliku konfiguracyjnym /etc/psad/psad.conf.

Wartości te to ENABLE_AUTO_IDS, AUTO_IDS_DANGER_LEVEL oraz AUTO_BLOCK_TIMEOUT opisane w jednym z wcześniejszych paragrafów (Konfiguracja psad). Dokładniejsza konfiguracja możliwa jest również przez ustawienie IPTABLES_BLOCK_METHOD, IPTABLES_AUTO_RULENUM oraz TCPWRAPPERS_BLOCK_METHOD.

Ciekawym faktem jest nazwa opcji ENABLE_AUTO_IDS sugerująca automatyczne włączanie systemu detekcji włamań (a nie zapobieganiu włamaniom) - jednak nie należy się tym zrażać.

Efekt wprowadzenia IPS

Oct 13 00:58:58 vizzdoom-laptop psad: src: 192.168.0.132 signature match: "SCAN nmap XMAS" (sid: 1228) tcp port: 129
Oct 13 00:58:58 vizzdoom-laptop psad: scan detected: 192.168.0.132 -> 192.168.0.143 tcp: [3-996] flags: URG PSH FIN tcp pkts: 300 DL: 3
Oct 13 00:58:58 vizzdoom-laptop psad: added iptables auto-block against 192.168.0.132 for 3600 seconds

Skanowanie serwera przeróżnymi metodami przez agresora praktycznie przestało mieć sens. Nawet w przypadku bardzo powolnego skanowania, psad potrafi zbierać dane przez długi czas (patrz SCAN_TIMEOUT) i odcinać dany adres IP odpowiednio zmodyfikowanymi regułami iptables od systemu. Metody bruteforce lub te, które generują duży ruch praktycznie też przestają być efektywne. Dzięki sygnaturom wiele najpopularniejszych wektorów ataku jest przerywana praktycznie od razu. Sukces?

Atak na system IPS

Przez wielkie opóźnienia i odrzucanie pakietów, agresor dowiedział się o istnieniu systemu IPS. Nie daje za wygraną i próbuje przechytrzyć system.

Pakiet TCP posiada nagłówki, tj. adres źródłowy i adres docelowy. Agresor zmienia adres źródłowy na adres IP popularnego serwisu, np. 74.125.77.121 (http://www.hcsl.pl) oraz wykonuje skanowanie na podstawie tak podrobionych pakietów. Wyniki takiego skanowania nie zwrócą węzłowi 192.168.0.132 żadnych ciekawych informacji, jednak system IDS (psad) zarejestruje próbę skanowania i przyporządkuje poziom niebezpieczeństwa w identyczny sposób, jak wyglądało to kilka paragrafów wcześniej.

Osiągniecie odpowiedniego Danger Level wyzwoli działanie IPS (tutaj również psad), który wygeneruje tymczasową regułę blokującą dla IP 74.125.77.121.

Osiągniecie takiego efektu jest możliwe poprzez wywołanie polecenia (na węźle 192.168.0.132):

nmap -sF -n -e eth0 -S 74.125.77.121 192.168.0.143 -Pn

Akcje podjęte przez psad przedstawia listing 8.

W efekcie serwer zaczyna blokować adres 74.125.77.121. Domyślnie adres ten nie będzie mógł podłączyć się do serwera przez godzinę. Czy jest w tym coś niebezpiecznego? Teoretycznie można przez serię takich skanowań przeprowadzić mały atak DoS, uniemożliwiając znanym adresom IP przykładowo odwiedzanie danej strony hostowanej na serwerze.

Dokładna analiza procesu blokady przynosi jednak pomysł na szersze zastosowanie tego ataku. Łatwo zauważyć, że serwer też nie jest w stanie zarówno odbierać jak i nawiązywać połączeń z/do 74.125.77.121. Czy to dobrze? Teoretycznie tak. W praktyce należy sobie uświadomić, że w nagłówku "źródło" protokołu TCP można wpisać dosłownie dowolny adres IP. Gdyby serwer hostował strony WWW moglibyśmy użyć adresu IP googla - uniemożliwiając ładowanie apletów map, Facebooka - uniemożliwiając korzystanie z gadżetów tego serwisu i wielu innych. W momencie przechwycenia adresów DNS systemu, moglibyśmy rozłożyć serwer na łopatki poprzez jedno skanowanie nmapem. Wtedy narzędzie, którego celem było chronienie nas - obróciłoby się przeciwko nam.

Jak się chronić, jak używać IPS w psad

Ochrona przed atakami na IPS nie jest prosta. Powyższy atak jest tylko jednym wektorem ataku. Lekarstwem może być dodawanie adresów IP znajdujących się w naszej infrastrukturze do białych list (/etc/psad/auto_dl). Można też zmodyfikować reguły iptables wyzwalane podczas osiągnięcia danego DL w taki sposób, aby blokowały jedynie połączenia przychodzące. Każdy przypadek jest inny i podlega ocenie administratora systemu. Ogólna tematyka IPS/IDS jest niestety bardzo rozbudowana.

Dalsze rozszerzenie zabezpieczeń

fwsnort

Przedstawiony w artykule psad jest ciekawym i bardzo łatwym w konfiguracji systemem. Bazuje on jednak na danych, które dotarły już do systemu. Zestaw reguł iptables musi zostać odpowiednio dobrze skonfigurowany, aby oprogramowanie to działało w zadawalający sposób. Niestety psad nie posiada bardzo rozbudowanych sygnatur takich jak Snort - ma przepisane najpopularniejsze ataki i to wystarczy w prostych zastosowaniach. Oprogramowanie pochodzące od tych samych ludzi, którzy napisali psad - fwsnort - wychodzi naprzeciw tej sytuacji. Pakiet fwsnort działa na poziomie jądra Linuksa. Kontroluje na niskim poziomie pakiety rozszerzając bezpieczeństwo systemu. Wynikiem działania skryptu fwsnort jest wygenerowanie reguł iptables. Przy pierwszym uruchomieniu pakiet ten analizuje aktualnie ściągnięte reguły znakomitego psad oraz próbuje wdrożyć odpowiednią politykę poprzez polecenia iptables (oczywiście na podstawie przeprowadzonej konfiguracji). W najnowszych wersjach fwsnort potrafi przetłumaczyć nawet do 60-70% wszystkich reguł psad. Ze względu na ich skomplikowanie, wielką ilość oraz częste aktualizacje jest to wynik imponujący.

Widać tutaj niezwykłą moc tego programu. Wykrywanie włamań na poziomie jądra skutkuje bardzo dobrym zabezpieczeniem. Dodatkowo warto nadmienić, że dzięki temu cały proces dzięki temu zajmuje bardzo mało zasobów, dlatego może być śmiało wprowadzony w prawie każdym systemie. Dlaczego nie używać więc tego narzędzia zamiast psad? Odpowiedź jest prosta - ponieważ to kolejna warstwa zabezpieczeń, która chroni serwer przed wieloma szkodami. Najlepszym jednak rozwiązaniem jest połączenie mocy psad ze skutecznością fwsnort. Należy nadmienić, że wykrywanie włamań przed tym, zanim pojawią się one w naszym systemie (a dokładniej w naszych aplikacjach) ma podstawową wadę - nie możemy nikogo powiadomić o zaistniałej sytuacji. Kernel nie wyśle nam ostrzeżenia pocztą oraz nie wygeneruje ładnego raportu. Wygenerowane reguły iptables przez fwsnort są idealnym źródłem danych dla psad - który wykorzysta je do dalszej obróbki.

Konfiguracja fwsnort jest stosunkowo prosta i przypomina troszkę konfigurację psad. Warto zainteresować się tym produktem, w szczególności że zachęca do tego prosty proces instalacji. Odpowiednie paczki instalacyjne można znaleźć na stronie projektu.

fwknop

Nie sposób nie napisać kilku słów o programie fwknop, gdy opisano psad oraz fwsnort. Oprogramowanie to również wyszło spod rąk tych samych ludzi co wcześniej wymienione programy. Służy do uproszczenia wdrożenia autoryzacji poprzez tzw. "Port Knocking" polegającego na wysyłaniu odpowiedniej sekwencji zapytań do ustalonych portów. Domyślnie możemy skonfigurować firewall w taki sposób, że nie dopuszczamy żadnych połączeń dla przykładowo ssh. Agresor gdy połączy się na port SSH nie otrzyma żadnej odpowiedzi - port będzie zamknięty (można nawet założyć, że ten port nie jest standardowym portem przyporządkowanym dla SSH). Klient (mający normalny dostęp do systemu) może zawrzeć "umowę" z serwerem w stylu:

"KLIENT: Serwerze, chciałbym się połączyć do ciebie do usługi SSH.


"SERVER: Dobrze kliencie, zrób to jednak w taki sposób: połącz się do portu x wysyłając pakiet y. Odczekaj z milisekund i zrób to ponownie. Wtedy na kilka sekund zmienię reguły zapory ogniowej w taki sposób, że przepuszczę 'pukający' adres IP do tego portu na kilka sekund"


"KLIENT: Dobrze, zapamiętam Twoje rady serwerze. Dzięki naszej umowie nikt nie będzie wiedział, że oczekujesz na połączenia SSH - dobry pomysł".

Program fwknop w dużym uproszczeniu pozwala na "zawarcie" takiej umowy. Można go ściągnąć po odwiedzeniu tej strony internetowej.

PODSUMOWANIE

Każdy informatyk zna ogólny sens świata - jedni próbują go chronić, inni próbują go zniszczyć. Istnieje odwieczny wyścig pomiędzy administratorami White Hat, a agresorami Black Hat. Dzień w dzień odkrywane jest wiele metod ataku na najpopularniejsze oprogramowanie lub nawet całe systemy teleinformatyczne. W pocie czoła audytorzy szukają, zabezpieczają oraz śledzą agresorów. Tworzą coraz doskonalsze narzędzia automatyzujące wiele żmudnych czynności. Wielkim, ponadczasowym projektem jest zdecydowanie zapora dla systemów Linuksowych o nazwie iptables. Jej administracja jest stosunkowo prosta, jednak jej "konserwacja" jest momentami bardzo kosztowna lub wręcz niemożliwa. Jednym z najlepszych dostępnych dzisiaj systemów IDS/IPS jest system SNORT. Jest szeroko opisywany i powszechnie chwalony. Potrafi  jednak czasem przysporzyć problemów, a jego konfiguracja nie jest zbyt prosta. W artykule zostały przedstawione alternatywne metody ochrony systemu, które de facto działają tak jak SNORT - nawet rozszerzając jego funkcjonalność.

Wprowadzenie psad do systemu jest banalnie proste i nawet Linuksowy laik po przeczytaniu tego artykułu jest w stanie uruchomić zaawansowany system wykrywania/zapobiegania włamaniom w 10 min. Rozszerzenie ostrzegania i raportowania poprzez psad przez działanie fwsnort w trybie jądra, dodając do tego bezpieczną autoryzację do podstawowych usług systemu przy pomocy fwknop tworzy bardzo silną barierę, która jest w stanie powstrzymać bardzo, bardzo wiele ataków bez angażowania do tego administracji.

Należy jednak pamiętać o szczegółowej analizie i wielu testach - w szczególności dotyczy się to podstawowej konfiguracji iptables. Proces zabezpieczania systemu powinien przebiegać w sposób spokojny, dokładny, bez pośpiechu. Nie można też spocząć na laurach i doglądać oprogramowanie co pewien czas.

Mam nadzieję, że dostatecznie blisko przybliżyłem ideę systemów IDS/IPS w Linuksie udowadniając, że ich instalacja nie jest wcale taka skomplikowana.

Prawa autorskie

Powyższe opracowanie zostało opublikowane na licencji Creative Commons Uznanie autorstwa-Użycie niekomercyjne 2.5 Polska. Możesz je więc wykorzystać w dowolnym serwisie (wyłącznie niekomercyjnym), jednak wymagamy, aby na początku bądź na końcu publikacji znalazł się następujący zapis:

"Źródło: Tytuł materiału linkujący do oryginalnego wpisu w HCSL (HARD CORE SECURITY LAB) Artykuł powstał w związku z konkursem zorganizowanym przez serwis HARD CORE SECURITY LAB oraz firmę Securitum."