vermin.eu.org

System po instalacji jest piękny i ładny. Ba, domyślnie jest nawet w miarę bezpieczny, (chociaż dziwi mnie fakt, iż debian nie ustawia automatycznie firewalla, który mają suse czy też redhat). Niemniej bezpieczeństwo jest nie tyle stanem, co procesem, który powinien zachodzić ciągle. Oznacza to, że musimy dbać o jego stan na kilka sposobów.

Pierwszym z nich jest aktualizacja systemu. Polecenia aptitude update && aptitude upgrade w wypadku debiana/ubuntu, czy też yast update dla suse pomogą nam utrzymywać system aktualny zgodnie z aktualizacjami. W zasadzie bardzo podoba mi się rozwiązanie w suse/ubuntu, które pokazuje z jakiego powodu dana aktualizacja bezpieczeństwa miała miejsce (i może wstępnie ocenić stopień ryzyka jaki pojawi się z nieinstalowania danej poprawki - wiadomo, stabilność in-house applications jest najważniejsza!).
W debianie w automatyzacji tego procesu pomoże pakiecik apt-cron, który pozwala na automatycznw ściąganie z serwerów poprawek w wypadku ich pojawienia się. Dzięki temu przychodząc rano do pracy admin otrzymuje (syslog) komunikat, że coś takiego miało miejsce, może przeczytać odpowiednie biuletyny bezpieczeństwa i zainstalować poprawki.
(Warto wspomnieć tutaj o temacie przeglądania logów pod linuxem, który postaram się opisać w jednym z nadchodzących artykułów.)

Ok - poprawki są wgrywane na system, niemniej dziury mnożą się każdego dnia, a i nie wszystkie są znane. W związku z tym musimy kontrolować sam system i wykrywać nieautoryzowane zmiany. Możemy oczywiście śledzić stan systemu korzystając z typowych narzędzi takich jak netstat, ps, lsof (oczywiście korzystając w tym celu z kompilacji statycznych, niekorzystających ze współdzielonych bibliotek), ale zadanie to jest mocno czasochłonne i nienajłatwiejsze ;). W związku z tym sięgniemy po pewne automaty - AIDE (advanced intrusion detection environment) oraz tripwire.

Pierwszy z nich, AIDE, chociaż w nazwie ma słowo advanced jest dosyć prostym programem skanującym zawartość dysków systemowych i porównujących stan aktualny z istniejącą bazą. Konfiguracja programu jest dosyć banalna - określamy grupy dopuszczalnych/monitorowanych zmian (lub używamy predefiniowanych) po czym przypisujemy je do poszczczególnych katalogów. aide –init tworzy bazę danych, domyślnie w /var/lib/aide/aide.db, a zadanie w cron wykonuje się codziennie i przesyła na określony adres różnice, jakie zostały wykryte przez aide pomiędzy stanem zdefiniowanym a bieżącym.
Aktualizacja bazy danych jest także dość prosta - wystarczy uruchomić aide –update a zostanie utworzony plik aide.db.new, po podmianie którego aide twierdzi, że wszystko jest w najlepszym porządku.

Stąd dla mnie aide jest systemem dodatkowym, zaś podstawowzm stało się tripwire - aplikacja, która chociaż w zasadzie robi to samo, to ma jednak zdecydowaną przewagę nad konkurentem.
Przede wszystkim w tripwire konfiguracje są zabezpieczone hasłem lokacji zaś baza danych innym, hasłem lokalnym. Nie jest przez to łatwa ani zmiana konfiguracji, ani zmiana baz danych. Co do tych ostatnich, to tripwire pozwala na łatwe (edytor tekstowy) zaznaczenie, które pliki chcemy zaktualizować w bazie, a których nie. Pozwala to na wyrzucenie plików co do których jesteśmy pewni, że są ok z logów programu.
Sama konfiguracja programu polega na stworzeniu pliku z polityką bezpieczeństwa - twpol.txt (reguły podobne jak w aide), a następnie przeskanowaniu wg zdefiniowanej polityki systemu plików (tripwire –init przy wstępnej konfiguracji, a dla istniejących zestawów polis - tripwire -m p –secure-mode low twpol.txt). Sprawdzanie systemu (tripwire –check) jest wykonywane jako zadanie cron’a, po ktorym generowany jest raport, który służy do aktualizacj bazy danych (polecenie: tripwire -m u -r /var/lib/tripwire/report/--.twr)
Jak widać system jest złożony, wieloetapowy, co powoduje pewne utrudnienia w jego oszukaniu. Oczywiście w obydwu rozwiązaniach zabezpieczeń, pliki kluczowe najlepiej trzymać na medium niezapisywalnym (CD), co uniemożliwi łatwą podmianę baz danych. Niestety rozwiązanie to jest pewnym problemem przy obsługiwaniu serwerów zdalnych…

Kolejną propozycją, którą warto zaimplementować na swoim systemie jest tiger - rozbudowany, wieloskryptowy system, którego zadaniem jest pilnowanie bezpieczeństwa systemu w wielu aspektach. Używa on m.in. AIDE jako file checkera, sprawdza demony nasłuchujące na interfejsach wraz z ich właścicielami, sprawdza czy konta systemowe są używane, czy pliki nie mają dziwnych zestawów uprawnień, czy zamontowane systemy plików spełniają zadane kryteria i wiele, wiele innych. System jest ciekawy, średnio trudny w konfiguracji - szczególnie ze względu na ilość funkcji z których korzysta. Żeby przybliżyć program musiałbym wkleić tu jego configa, to już chyba ciut za wiele Za to polecam własne testy.

W celu zwiększenia poziomu zabezpieczeń możemy także automatycznie sprawdzać poziom trudności haseł programem john the ripper. Programik pozwala na przetestowanie zbioru haseł pod kątem słownikowym i atakiem brute-force, wg zdefinioniowanych zasad (gługość, kombinacje znaków alfanumerycznych, etc.) Ponieważ deszyfracji użytkownik dostaje powiadomienie o zbyt słabym haśle, jest to jakiś sposób wymagania polityki bezpieczeństwa.

Oczywiście są jeszcze dwa inne programy o których warto wspomnieć - portsentry, nasłuchujący na zdefiniowanych portach deamon blokujący dostęp do systemu po uderzeniu w odpowiednie porty… lub wykonujący inną zdefiniowaną akcję. I na sam koniec zostawiam snorta, którego można zdefiniować jako HIDS, chociaż sam go używam jako NIDSa, stąd w tym artykule o nim rozpisywać się nie będę.

A czego Wy używacie do zabezpieczenia swojego systemu?