Lynis – narzędzie do audytu bezpieczeństwa systemów Linux

Czasem zdarza się, że znajdę jakieś stare, fajne narzędzie, którego nie znałem wcześniej. Tak jest w przypadku Lynis – programu open source napisanego przez CISOfy służącego do audytu bezpieczeństwa systemu na podstawie bieżących ustawień. Przypadkiem, na komórce w tramwaju mignął mi wpis o nim gdzieś w sieci, opis był ciekawy, więc postanowiłem dać szansę, choć od dłuższego czasu nie interesowałem się podobnymi programami. Kiedyś, na początku przygody z Linuksem bawiłem się Bastille Linux i to w zasadzie wszystko, jeśli chodzi o automaty.

Działanie Lynis sprawdzałem tylko na Debianie i Ubuntu – działa bardzo sprawnie, generuje sensowne raporty z uwzględnieniem specyfiki dystrybucji. Przy każdym raporcie jest link do krótkiego opisu z wytłumaczeniem danej opcji. Dla początkujących jest to dobra okazja do poczytania nt. ustawień i ich wpływu na bezpieczeństwo systemu, dla zaawansowanych automat, który sprawdzi, czy czegoś nie przeoczyliśmy lub nie zapomnieliśmy włączyć np. po testach.

Program jest dostępny jako pakiet, więc instalacja sprowadza się do:

apt-get install lynis

Uruchomienie audytu również jest proste:

lynis audit system

Polecam dodanie przełącznika -Q. Program jedynie generuje raport, niczego nie zmienia w systemie, więc uruchomienie jest bezpieczne. Wynik wyświetla na ekran oraz do logu, znajdziemy tam zarówno znalezione błędy, ostrzeżenia, jak i wskazówki do hardeningu systemu.

Narzędzie ma zastosowanie raczej dla systemów, prywatnych,  utrzymywanych ręcznie – te konfigurowane automatycznie raczej nie mają miejsca na powstanie błędu, a forma raportu jest raczej przyjazna dla ludzi, niż maszyn.

Oczywiście przy domyślnej konfiguracji zgłosi także odstępstwa od normy, które są zamierzone albo nieistotne, więc wynik będzie nieco przegadany. Mimo to polecam wypróbowanie samodzielnie.

Polecenie su – zmiany

Jakiś czas temu zauważyłem, że mój Debian unstable na domowym desktopie zmienił zachowanie. Na koncie root przestał działać skrypt do aktualizacji systemu i usypianie.

Szybko sprawdziłem i oczywiście chodziło o PATH. Dopisałem pełne ścieżki do poleceń i prawie zapomniałem o sprawie, przypuszczając, że chodzi o jakiś chwilowy błąd w którymś z pakietów.

Jednak problem nie zniknął, więc postanowiłem sprawdzić dokładnie, co się wydarzyło. Na pierwszy ogień poszło sprawdzenie /etc/profile, w którym znalazłem spodziewane:

if [ "`id -u`" -eq 0 ]; then
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
else
PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"

Również w /etc/login.defs wszystko wyglądało poprawnie:

# *REQUIRED* The default PATH settings, for superuser and normal users.
#
# (they are minimal, add the rest in the shell startup files)
ENV_SUPATH PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
ENV_PATH PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

Skończyły mi się pomysły, więc udałem się na kanał #debian-next z pytaniem, czy to błąd, czy może były ostatnio jakieś zmiany. I okazuje się, że zmiany były, grubsze, dotyczące polecenia su.

Uprzednio, wydanie „gołego” polecenia su zmieniało użytkownika na root oraz ustawiało należną mu ścieżkę. Obecnie należy podawać su – (forma niezalecana) lub, lepiej, su -l, aby osiągnąć ten efekt.

I jeszcze co ciekawsze fragmenty dokumentacji (man su). Było:

The current environment is passed to the new shell. The value of $PATH is reset to /bin:/usr/bin for normal users, or /sbin:/bin:/usr/sbin:/usr/bin for the
superuser. This may be changed with the ENV_PATH and ENV_SUPATH definitions in /etc/login.defs.
[...]
-, -l, --login
Provide an environment similar to what the user would expect had the user logged in directly.

Aktualnie jest:

For backward compatibility, su defaults to not change the current directory and to only set the environment variables HOME and SHELL (plus USER and LOGNAME
if the target user is not root). It is recommended to always use the --login option (instead of its shortcut -) to avoid side effects caused by mixing envi-
ronments.
[...]
-, -l, --login
Start the shell as a login shell with an environment similar to a real login:
o clears all the environment variables except TERM
o initializes the environment variables HOME, SHELL, USER, LOGNAME, and PATH
o changes to the target user's home directory
o sets argv[0] of the shell to '-' in order to make the shell a login shell

Więc gdyby komuś w jakiejś debianopodobnej dystrybucji niebawem su przestało ustawiać PATH, to najprawdopodobniej chodzi o tę zmianę.

MauiBot – analiza zachowania bota

Pewnego dnia patrząc w logi serwera WWW zauważyłem sporą aktywność bota identyfikującego się jako:

MauiBot (crawler.feedback+dc@gmail.com)

Z zapałem crawlował labirynt dla botów, w User Agent nie było zazwyczaj obecnego URLa, żeby poczytać, co to za wynalazek, więc uruchomiłem wyszukiwarkę. Szybko udało mi się ustalić, że to bad bot, działający z chmury Amazonu (AWS) i nawet są reguły dla nginx do blokowania ruchu od niego.

Na początek parę znalezionych linków:

Wygląda, że bot pojawił się w marcu tego roku, czyli jest dość świeży. Wygląda też, że potrafi spowodować trochę problemów, przynajmniej na shared hostingach i/lub stronach słabo zoptymalizowanych.

Dokładniejszych informacji nie ma, więc postanowiłem poobserwować zwyczaje bota na własną rękę.

Wygląda, że 25 lipca ok. 1:20 trafił na moją stronę domową i zaczął podążać za kolejnymi linkami. Korzystał z IP 54.237.208.52, nie dało się obserwować opisywanego w niektórych miejscach wykonywania requestów grupami po 4-8 co 30 sekund. Wykonywał między 100 a 250 requestów na godzinę.

Tego samego dnia ok. 20:40 zmienił IP na 54.87.252.55 i… zaczął wszystko od początku. 26 lipca około 1:20 skończyły się requesty dotyczące blogów, pozostały tylko dotyczące wypasania botów.  W tym momencie intensywność crawlowania znacząco wzrosła – między 1600 a 2100 requestów na godzinę. Daje się też zauważyć grupowanie requestów, choć wygląda ono nieco inaczej niż w opisywanych w sieci przypadkach – 3-4 requesty co 5-6 sekund. Być może każdy wątek dla danej ścieżki wykonuje 4 requesty co 30 sekund.

Zaczynam też obserwować spadek liczby zapytań na godzinę. 26 lipca o godzinie 7 było 1500 requestów, następnie systematycznie z godziny na godzinę spada do 900 requestów o 19 i 550 o godzinie 5 następnego dnia. O godzinie 19 27 lipca jest już tylko 340 requestów, a o godzinie 9 28 lipca już tylko 250 zapytań na godzinę.

W tym momencie zaczynam eksperymentować. Po pierwsze dodaję przed linkami z parametrami i za nimi linki z inną ścieżką, ale również prowadzące do labiryntu. Bot natychmiast za nimi podąża, najwyraźniej dokładając nowe wątki/procesy, bo liczba requestów wzrasta do ponad 700/h, przy czym liczba do bazowego powoli spada do ok. 200/h.

31 lipca liczba requestów to ok. 150/h. Podstawiam linka do labiryntu ale w innej domenie, ale MauiBot ignoruje tego linka. Trochę zbyt długo zwlekałem z analizą, obecnie bot reaguje bardzo powoli, więc publikuję teraz, a kolejne obserwacje pojawią się wkrótce, jako aktualizacja tego wpisu.

UPDATE

Aby sprawdzić, czy pomija ze względu na inną domenę, czy w ogóle przestał, dołożyłem kolejnego linka, tym razem w crawlowanej dotychczas domenie. Podążył za nim, a liczba requstów wzrosła do ok. 210/h. Podobnie bot podążył za URLem w tej samej domenie po podaniu pełnej ścieżki zamiast względnej, używanej wszędzie dotychczas.

Wygląda na to, że odwiedzone URLe są zapamiętywane – bot nie wrócił do początkowego indeksu, mimo podanie osobnego linka w odwiedzonej już ścieżce.

Aby sprawdzić, jak sobie radzi z forkowaniem i jak to wpływ na ilość requestów, wysłałem go w dziewięć kolejnych, niezależnych miejsc.

Ostatecznie przestałem go obserwować na bieżąco przez cztery tygodnie i w zasadzie czekałem tylko, kiedy skończy pobierać i czy np. nie zmieni IP. Nie zmienił, za to pobierać przestał 20 sierpnia 2018. Tempo pobierania w ostatnich godzinach to ok. 335/h, pobierał ze wszystkich stron w grupach nie po 4, a po 8 requestów.

Mail RBL checker (Python)

Tak się zdarzyło w ostatnim czasie, że w paru miejscach pojawiły się problemy z dostarczaniem maili. Prawdopodobna przyczyna niedocierania poczty była ta sama – obecność IP serwera pocztowego na RBL. Przypomniały mi się stare czasy i walka z wypisywaniem IP z RBL oraz różne metody zapobiegania dostawania się na RBLe.

Zanim jednak zaczniemy cokolwiek robić, trzeba wiedzieć, że jesteśmy na RBLu, czyli monitorować obecność IP serwera pocztowego na RBL. Do szybkich, ręcznych, doraźnych sprawdzeń pojedynczych IP polecam stronę Multi-RBL Check, nie rozwiązuje to jednak tematu ciągłego, automatycznego monitoringu obecności IP na RBLach, np. przy pomocy Zabbiksa.

Sam monitoring jest trywialny – wystarczy odpytywać przy pomocy DNS, warto to jednak jakoś „opakować”. Napisałem to ze dwa razy w życiu (IIRC oba w Perlu), napiszę więc i trzeci, tym razem w Pythonie. Oczywiście podobnych rozwiązań na GitHubie jest wiele, ale w każdym coś mi nie pasowało – albo język, albo rozbudowane zależności, albo sposób przekazywnia informacji. To ostatnie to w sumie detal, łatwo można przefiltrować informacje przy pomocy grep lub awk.

W każdym razie, wczoraj opublikowałem mail-rbl-monitor. Zdecydowanie nie jest skończony, a struktura wynika z przygotowania pod przyszłe funkcje. Znaczy sprawdzanie listy IP pobieranej z pliku.

Wkrótce temat pokrewny, ale nieco trudniejszy – monitoring reputacji IP serwerów pocztowych.