iptables+psad jako zaawansowany system wykrywania włamań

10 sierpnia 2013, 10:04 | Narzędzia, Teksty | komentarzy 8
: zin o bezpieczeństwie - pobierz w pdf/epub/mobi.

Wstęp

iptables zna praktycznie każdy użytkownik Linuksa. Niektórzy właśnie od niego zaczęli swoją przygodę z pingwinem stawiając darmowy serwer usługi NAT+firewall. W większości przypadków to jedyne zadania jakie powierzamy iptables nie zdając sobie sprawy z jego potencjału. Niniejszy artykuł prezentuje jak przy pomocy iptables oraz psad stworzyć solidny system wykrywania ataków oraz aktywnej ochrony.

 

iptables – podstawowa konfiguracja

Poniżej przedstawiono prostą konfigurację iptables. Ważne linie zostały pogrubione.

Zakładana polityka bezpieczeństwa zakłada, że dopuszczone są usługi SSH, FTP, HTTP, HTTPS, DNS oraz whois. Akceptowane są nowe połączenia (NEW) do wybranych usług oraz te, które w jakiś sposób związane są z połączeniami już otwartymi (ESTABLISHED, RELATED).

Dodatkowo iptables ma logować pakiety niepasujące do polityki („zabłąkane” pakiety, skanowanie portów) oraz niezwiązanych z żadnymi połączeniami (INVALID). Dopuszczalne pakiety przechodzą dalej, niechciane natomiast zostają zapisane do loga i odrzucane.

Jakkolwiek dziwnym może się wydawać, iż najważniejsze dla ochrony jest logowanie połączeń, w istocie iptables najpierw musi dostarczyć informacji, na podstawie których podjęte będą działąnia obronne.

 

iptables – wykrywanie zagrożeń

Po stworzeniu zapory warto zwrócić uwagę jak zareaguje ona na żądania nie pasujące do przewidzianych w polityce bezpieczeństwa. Zapora ma adres 192.168.11.105, atakujący komputer 192.168.11.99.

Na początek połączenie TCP z portem 5555:

iptables odrzuca żądanie:

Następnie próba połączenia UDP:

iptables ponownie raportuje:

i trzecia próba – polityka przewiduje odpowiedź tylko na żądanie ICMP Echo. Oto co się stanie gdy iptables dostanie nieoczekiwaną odpowiedź ICMP Echo:

iptables ponownie raportuje niewłaściwy pakiet:

Przyjrzyjmy się dwu pierwszym raportom. Opcja --log-tcp-options rozszerza standardowy log iptables o pola portów źródłowych oraz docelowych, flagi, okno ECN, znacznik zarezerwowane i opcje w przypadku segmentu TCP natomiast w przypadku datagramu UDP dodaje jego długość oraz informacje o portach źródłowym i docelowym. Dzięki opcji --log-ip-options logowane są także opcje nagłówka IP. Informacje te przydadzą się przy dalszej analizie.

 

psad czyli trochę magii

Chociaż można analizować log linijka po linijce lepiej poświęcić się mniej mechanicznym zajęciom a nudne zadanie powierzyć komuś innemu – psad. Port Scan Attack Detector został popełniony przez eksperta w dziedzinie ochrony sieci, Machaela Rasha. Skrypt ten analizuje informacje dostarczane przez iptables w poszukiwaniu podejrzanych działań jak skanowanie portów, ataków DDoS a także śladów backdoorów. W połączeniu z fwsnort może wykrywac i generować alarmy również w przypadku ataków na warstwę aplikacji. psad korzystając z danych p0f (oraz rozszerzonych logów iptables) umożliwia również pasywne wykrywanie systemu operacyjnego używanego przez atakującego. Oprócz tego potrafi automatycznie uruchomić aktywną ochronę w postacji czasowego blokowania adresów IP (domyślnie wyłączone) oraz wysyła szczegółowe raporty pocztą elektroniczną.

Instalacja w systemie debian nie jest do końca zautomatyzowana. Po wydaniu polecenia:

pojawia się komunikat:

Cała dodatkowa konfiguracja sprowadza się do dodania linijki na końcu /etc/syslog.conf:

Po dopisaniu powyższego należy uaktualnić sygnatury psad przy pomocy psad --sig-update a następnie uruchamić poleceniem /etc/init.d/psad start. psad zakłada, że logowane są tylko odrzucane pakiety (polityka log&drop) i sprawdza przed uruchomieniem poprawność ustawień iptables w łańcuchu INPUT oraz FORWARD. Jeśli wymaganych reguł brakuje psad informuje o tym. Konfiguracja narzędzia znajduje się w /etc/psad/psad.conf i zawiera ponad 100 parametrów. Na razie pozostańmy przy konifguracji domyślnej i zajrzyjmy do logów w poszukiwaniu informacji od psad.

 

psad analizuje logi i informuje o zagrożeniach

Zabaczmy jak psad zareaguje na próbę skanowania portów TCP connect():

oprócz informacji iptables w logu pojawia się komunikat od psad

Nie ma potrzeby analizowania każdej informacji od iptables z osobna – psad analizuje je za nas i informuje o zagrożeniach. Informacja zawiera adres IP skąd zarejestrowano skanowanie (warto pamiętać, że adres ten może być sfałszowany) a także zakres skanowanych portów i liczbę pakietów. DL oznacza poziom zagrożenia wedle poziomów zdefiniowanych w /etc/psad/psad.conf (zmienne DANGER_LEVEL).
Należy zaznaczyć, że ponieważ w logach iptables nie ma jednoznacznej informacji w jakim łańcuchu wykryto logowane zagrożenie psad przyjmuje następujące założenia:

  • komunikaty, które nie zawierają interfejsu wyjściowego pochodzą z reguł łańcucha INPUT
  • komunikaty, które nie zawierają interfejsu wejściowego pochodzą z reguł łańcucha OUTPUT
  • komunikaty, które zawierają oba interfejsy pochodzą z reguł łańcucha FORWARD

Skanowanie TCP FIN:

i ponownie psad informuje o zdarzeniu:

W przypadku gdy DL zdarzenia przekroczy EMAIL_ALERT_DANGER_LEVEL psad wyśle e-mail z informacją o zdarzeniu do administratora systemu. Informacja ta zawiera poziom zagrożenia, porty i flagi skanowania, źródłowy i docelowy adres IP, liczbę e-maili dotyczących tego źródła zagrożenia, zakres skanowanych portów oraz informacje z bazy whois. psad przechowuje sporo informacji o zdarzeniach w katalogu /var/log/psad. Na przykład katalog /var/log/psad/192.168.11.99 zawiera informacje whois dla adresu, ostatni alert wysłany e-mailem do administratora, znacznik czasowy pierwszego podejrzanego pakietu, aktualny stopień zagrożenia oraz plik z wynikiem pasywnego skanowania systemu operacyjnego. Ponieważ niewygodne jest ręczne przedzieranie się przez katalogi psad --Status udostępnia informacje o aktualnym statusie serwera psad, psad -A natomiast analizuje archiwalne logi iptables znajdujące się w /var/log/messages.

 

psad na straży porządku

Zanim przejdziemy teraz do konfiguracji aktywnej ochrony systemu przed zagrożeniem należy zauważyć, iż zgodnie z prawem Murphy’ego każde rozwiązanie rodzi nowe problemy. Napastnik może szybko zauważyć aktywne blokowanie źródeł zagrożeń i obrócić to przeciwko chronionemu systemowi. psad umożliwia więc dodanie białej listy zawierającej komputery i sieci, które nigdy nie powinny być blokowane.
W ramach aktywnej ochrony systemu psad umożliwia m.in.:

  • ręczne dodanie lub usunięcie reguły blokującej zadany adres IP – opcje --fw-block-ip oraz --fw-rm-block-ip
  • podgląd w statusie psad aktualnie zablokowanych adresów wraz z czasem do ich odblokowania
  • dodawanie niekolidujących z dowolną polityką bezpieczeństwa reguł iptables blokujących napastników (reguły dodawane są w osobnym łańcuchu)
  • konfigurowanie minimalnego poziomu zagrożenia związanego z blokowaniem
  • blokowanie stałe lub tymczasowe
  • informowanie za pomocą e-mail o dodaniu blokady
  • wybór czy blokady będą związane ze skanowaniem portów bądź atakami pasującymi do sygnatur

Wyedytujmy zatem plik /etc/psad/psad.conf w celu uaktywnienia aktywnej obrony systemu. Najważniejszą zmienną jest ENABLE_AUTO_IDS, nadajmy jej wartość Y. W tym momencie aktywowane są pozostałe zmienne AUTO_IDS_DANGEL_LEVEL (zmieńmy na 3) odpowiadająca za minimalny poziom zagrożenia skutkujący zablokowaniem adresu (dokładniejsze poziomy związane z konkretnymi adresami/sieciami można ustawic w /etc/psad/auto_dl), AUTO_BLOCK_TIMEOUT określająca czas blokady w sekundach (0 powoduje ustawienie blokady stałej, gdy FLUSH_IPT_AT_INIT ma wartość Y blokada usuwana jest przy restarcie psad/systemu). Ważną zmienną jest IPT_AUTO_CHAIN, która określa tworzenie reguł blokujących – domyślnie konfiguruje 3 dodatkowe łańcuchy PSAD_BLOCK_INPUT, PSAD_BLOCK_OUTPUT oraz PSAD_BLOCK_FORWARD. Dla łańcuchów tych ustawiane są reguły DROP związane z adresem napastnika uniemożliwiające komunikację zarówno z firewallem jak i chronionymi maszynami pracującymi w sieci lokalnej.

Zrestarujmy psad i spróbujmy skanowania portów TCP SYN:

Napastnik został zablokowany na godzinę. Aktualny stan blokad możemy uzyskać na dwa sposoby:

Chain PSAD_BLOCK_INPUT (1 references)
pkts bytes target prot opt in out source destination
1133 49852 DROP all — * * 192.168.11.99 0.0.0.0/0

Chain PSAD_BLOCK_OUTPUT (1 references)
pkts bytes target prot opt in out source destination
0 0 DROP all — * * 0.0.0.0/0 192.168.11.99

Blokada zostanie usunięta po upływie określonego czasu lub po wydaniu polecenia

Wszystko działa jak powinno. Rozważmy jednak następującą sytuację. Napastnik domniema, iż skanowanie portów skutkuje blokadą adresu IP, zauważył też, że system atakowany stoi na łączu TP DSL i wykonał następujące polecenie
nmap -sS -P0 -S 194.204.159.1 -e eth1 -n 83.16.X.X
po chwili psad blokuje adres serwera DNS:
Jan 11 09:27:06 debian psad: added iptables auto-block against 194.204.159.1 for 3600 seconds
Jeśli powtórzyć operację dla drugiego serwera DNS istnieje duże prawdopodobieństwo praliżu pracy przedsiębiorstwa za firewallem. Aby uchronić się przed podobną sytuacją należy dodać zaufane adresy, które nie powinny być blokowane do pliku /etc/psad/auto_dl z poziomem zagrożenia równym 0.

 

psad, swatch i ssh

psad posiada naprawdę spore możliwości. W połączeniu z regułami Snort pozwala również reagować na zagrożenia w warstwie aplikacji. Dodatkowo samemu można wykorzystać go we własnych skryptach lub wraz z innymi narzędziami co zostanie pokazane poniżej.
Implementacja blokowania adresu IP, z którego nie powiodło się logowanie ssh zrealizujemy przy pomocy swatch, który na bieżąco analizuje /var/log/auth.log w poszukiwaniu informacji o nieudanym logowaniu ssh.
Tworzymy plik swatchrc o poniższej zawartości:

po czym uruchamiamy z linii poleceń:

Po paru nieudanych logowaniach przez ssh adres IP jest blokowany.

Dziękuję za uwagę. Mam nadzieję, że artykuł zachęci do dalszego poznawania możliwości psad a być może pomoże skutecznie ochronić czyjeś cenne zasoby :-)

Łukasz Międzybrodzki

 

Ten artykuł został napisany w ramach konkursu na artykuł o bezpieczeństwie IT zorganizowanego przez firmę Securitum oraz wortal jakilinux.org.

Tekst opublikowany jest na licencji Creative Commons Uznanie Autorstwa 2.5, co w skrócie oznacza, że możesz go dowolnie modyfikować, publikować i rozpowszechniać również dla użytku komercyjnego. Jeśli skorzystasz z tego tekstu prosimy Cię jedynie o link zwrotny do strony strony securitum.pl oraz wortalu jakilinux.org , informację o autorze oraz o tym, że został on pierwotnie opublikowany w naszym serwisie.

Spodobał Ci się wpis? Podziel się nim ze znajomymi:



Komentarze

  1. gh

    Bardzo dobry artykuł. Super, że są w polskim necie serwisy skierowane do szerokiego grona odbiorców, prezentujące praktyczne przykłady na przyzwoitym poziomie.

    Odpowiedz
  2. Reader

    Bardzo dobrze prowadzony serwis. Super Arty.
    Znalazłem was przez przypadek. Widzę, że mam trochę lektury u was do nadrobienia :D Tak Trzymać !

    Odpowiedz
    • @reader: ha, to miłej lektury archiwum :-) nie zapomnij też polecić sekuraka znajomym ;)

      Odpowiedz
  3. pejot

    rewelacyjny artykuł.

    Odpowiedz
  4. Trochę czasu minęło od kiedy ostatnio siedziałem w temacie security.

    psad -S nie zauważył skanowania pomimo:
    -dodania „kern.info |/var/lib/psad/psadfifo” do /etc/rsyslog.conf
    -restartu rsysloga
    – wklepania linijek
    iptables -A INPUT -j LOG
    iptables -A FORWARD -j LOG
    – restartu psad

    Coś źle robię?Coś jest jeszcze wymagane?

    Odpowiedz
    • Magus

      musisz w konfiguracji psad –> /etc/psad/psad.conf ustawić parametr ENABLE_AUTO_IDS Y;
      –> service psad restart
      powinno być ok

      Odpowiedz
      • Ustawiałem to na samym początku.
        Raczej problem u mnie w iptables.
        Coś czuje, że musiał na tym dłużej posiedzieć :)

        Odpowiedz
  5. Magus

    Jak wygląda sytuacja, kiedy na iptable’sie jest ustawiony np
    $IPTA DROP_LOG_IN -m limit –limit 5/min -j LOG –log-prefix „DROP_LOG_IN: ” –log-level 4 –log-ip-options –log-tcp-options , czy psad wyłapie próby skanowania systemu ?

    Odpowiedz

Odpowiedz