Bezpieczeństwo Linuksa z Aruba Cloud – monitorowanie zmian w systemie plików

Częstą przyczyną długiej przerwy między włamaniem a jego wykryciem jest niski poziom monitoringu ważnych zdarzeń w zaatakowanym systemie. Dzisiaj pokażemy Wam, jak prosto i skutecznie monitorować linuksowy system plików.

We współpracy z firmą ArubaCloud pokazaliśmy Wam, jak postawić swój serwer backupów, jak skonfigurować własny serwer VPN i podłączyć do niego komputer, telefony komórkowe oraz domowy ruter a także jak schować się przed cenzurą sieci i jak zacząć serwer zabezpieczać oraz jak postawić swój własny zdalny pulpit i swój serwer WWW. Dzisiaj z kolei pokażemy, jak wdrożyć czasem bardzo przydatny monitoring dowolnie wybranych plików lub katalogów.

Po co taki monitoring

Jeśli nie macie jeszcze swojego własnego serwera, to jest to dobra okazja by się w taki wyposażyć. Aruba oferuje dwa miesiące korzystania ze swojego podstawowego serwera gratis – a po zakończeniu promocji będzie on Was kosztował zaledwie 4 złote miesięcznie. Instrukcję jak krok po kroku skorzystać z promocji i uruchomić swój serwer znajdziecie w tym artykule. Jeśli macie już swój serwer – to zapraszamy do lektury kolejnych akapitów.

To, do czego może się Wam przydać monitoring plików, ogranicza jedynie Wasza wyobraźnia. Przykładowe rozwiązania to np. otrzymywanie emaila zawsze, gdy zmieni się zawartość katalogów serwera WWW – może to pomóc wykryć udaną próbę włamania na serwer. Inne pomysły na wykrycie intruza to np. monitoring pliku /etc/shadow (gdy ktoś spróbuje zmodyfikować lub dodać swojego użytkownika) czy plików z kluczami SSH pozwalającymi logować się na konto roota. Niekoniecznie muszą to być tylko funkcje wykrywania prób włamania – można także np. zaprogramować restart serwera WWW gdy następuje zmiana jego pliku konfiguracyjnego – jeśli ktoś często w nim grzebie, to może oszczędzić w ten sposób kilka minut życia.

Kilka słów wstępu

Aby opisać metodę monitorowania zmian, warto zacząć od tego, co będziemy tak naprawdę monitorować. Każdemu obiektowi w systemie plików (np. katalogowi czy plikowi) odpowiada i-węzeł (ang. inode, index node). Uproszczając jest to struktura określająca obiekt w systemie plików w której zawarte są różne informacje o obiekcie, z wykluczeniem jego nazwy i jego zawartości.

Jak wygląda struktura i-węzła w systemie plików ext4? W repozytorium jądra systemu Linux w pliku nagłówkowym ext4.h zadeklarowana jest następująca struktura:

struct ext4_inode {
	__le16	i_mode;		/* typ pliku - zwykły, katalog, FIFO, lub 0 gdy inny */
	__le16	i_uid;		/* identyfikator własciciela pliku */
	__le32	i_size_lo;	/* rozmiar pliku w bajtach */
	__le32	i_atime;	/* data dostępu */
	__le32	i_ctime;	/* data zmiany atrybutów */
	__le32	i_mtime;	/* data modyfikacji  */
	__le32	i_dtime;	/* data usunięcia */
	(...)
}

Zamiast nazwy, i-węzeł wykorzystuje wskaźnik do punktu dla konkretnego pliku, katalogu lub obiektu. Wskaźnik jest unikalnym numerem, który zwykle określa się jako liczbę. Na przykład, aby uzyskać numer węzła, należy użyć następującego polecenia:

$ ls -i /etc/passwd
4972 /etc/passwd

Numer i-węzła zmieni się podczas przeniesienia pliku na inną partycję – w obrębie tej samej partycji numer i-węzła nie ulega zmianie. Zmiana zawartości lub zmiana właściciela pliku (itp.) nie zmienia numeru i-węzła. Można pozyskać wszystkie metainformacje zawarte w i-węźle. W tym celu najpierw utworzymy przykładowy plik z dowolna zawartością, a następnie sprawdzimy metainformacje o pliku:

# tworzymy plik
$ touch plik_testowy
# dodajemy zawartość do utworzonego pliku
$ echo "zawartość pliku testowego" > plik_testowy

Mając tak utworzony plik możemy pozyskać więcej informacji niż tylko numer węzła:

$ stat ./plik_testowy

  File: ‘plik_testowy’
  Size: 28        	Blocks: 8          IO Block: 4096   regular file
Device: fd00h/64768d	Inode: 545732      Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/krystian)   Gid: ( 1000/krystian)
Access: 2017-02-16 11:55:50.434312000 +0100
Modify: 2017-02-16 11:55:57.611312000 +0100
Change: 2017-02-16 11:55:57.611312000 +0100
 Birth: -

Monitorujemy i-węzły

W celu monitorowania i-węzłów użyjemy funkcji Inotify, która jest wbudowana w jądro Linuxa. Inotify (inode notify) to funkcja jądra która powiadamia o zdarzeniach w systemie plików. Za pomocą Inotify API można w łatwy sposób monitorować zdarzenia. W ramach omawianego przykładu będziemy chcieli monitorować zmiany i-węzłów dla katalogu /etc. Aby rozpocząć monitorowanie określonego katalogu potrzebujemy narzędzia, które umożliwi nam komunikację za pomocą Inotify API.

Jednym z takich narzędzi jest incron, który dostępny jest w repozytorium EPEL:

Name        : incron
Arch        : x86_64
Version     : 0.5.10
Release     : 8.el7
Size        : 249 k
Repo        : installed
From repo   : epel
Summary     : Inotify cron system
URL         : http://inotify.aiken.cz
License     : GPLv2
Description : This program is an "inotify cron" system.
            : It consists of a daemon and a table manipulator.
            : You can use it a similar way as the regular cron.
            : The difference is that the inotify cron handles
            : filesystem events rather than time periods.

Incron jest zbliżonym narzędziem do crontaba lecz w przeciwieństwie do niego nie bazuje na określonych odstępach czasowych, a na zdarzeniach w systemie plików. Logując się jako administrator wydajemy polecenie:

yum install incron

Uruchamiamy incron w systemie:

service incrond start

oraz zapewniamy by incron był uruchamiany podczas startu systemu operacyjnego:

systemctl incrond enable

Po instalacji pakietu incron warto zapoznać się z zawartością następujących plików:

/etc/incron.conf – główny plik konfiguracyjny
/etc/incron.d/ – katalog w którym będą zawarte dodatkowe pliki konfiguracyjne
/etc/incron.allow – zawiera listę użytkowników uprawnionych do korzystania z incron
/etc/incron.deny – zawiera listę użytkowników którzy nie mogą korzystać z incron

Składnia incron

Składnia incron jest następująca:

<ścieżka> <nazwa zdarzenia> <polecenie> opcje

gdzie:

• ścieżka określa pełną ścieżkę do pliku, katalogu lub innego obiektu w systemie plików, który chcemy monitorować
• nazwa zdarzenia:
  • IN_ACCESS – Nastąpił dostęp do pliku (odczyt)
  • IN_ATTRIB – Nastąpiła zmiana metadanych (uprawnienia, znacznik czasu, itp.)
  • IN_CLOSE_WRITE – Zamknięto plik, który był otwarty z uprawnieniami do zapisu
  • IN_CLOSE_NOWRITE – Zamknięto plik, który był otwarty z uprawnieniami tylko do odczytu
  • IN_CREATE – Utworzono plik/katalog w monitorowanym katalogu
  • IN_DELETE – Usunięto plik/katalog z monitorowanego katalogu
  • IN_DELETE_SELF – Monitorowany plik/katalog został skasowany
  • IN_MODIFY – Monitorowany plik  został zmodyfikowany
  • IN_MOVE_SELF – Monitorowany plik/katalog został przeniesiony
  • IN_MOVED_FROM – Z monitorowanego katalogu przeniesiono plik
  • IN_MOVED_TO – Do monitorowanego katalogu przeniesiono plik
  • IN_OPEN – Monitorowany plik został otwarty
  • IN_ALL_EVENTS – Wszystkie wyżej wymienione zdarzenia
• polecenie to pełna ścieżka do wskazanego przez nas skryptu/programu, który zostanie uruchomiony w razie wykrycia opisywanego zdarzenia

• opcje (argumenty wywołania polecenia):
  • $@ – pełna ścieżka monitorowanego pliku/katalogu
  • $# – nazwa pliku/katalogu którego dotyczy zdarzenie
  • $% – nazwa zdarzenia
  • $& – numeryczna reprezentacja nazwy zdarzenia

Na podstawie powyższej składni edytujemy ustawienia incron wydając polecenie:

# (opcjonalnie) ustawiamy domyslny edytor
export EDITOR=nano
export VISUAL=nano

sudo incrontab -e

Aby monitorować katalog /etc/ pod kątem modyfikacji, utworzonych/usuniętych  plików lub katalogów, wpisujemy nastepująca linię:

/etc IN_MODIFY,IN_CREATE,IN_DELETE /usr/bin/logger "Sciezka: $@/$# Zdarzenie:$%"

Każde zdefiniowane przez nas zdarzenie (IN_MODIFY, IN_CREATE, IN_DELETE) będzie raportowane w pliku /var/log/messages.

Przyklad:

# tworzymy plik /etc/plik_testowy
sudo touch /etc/plik_testowy
# zmieniamy zawartosc pliku /etc/plik_testowy
sudo echo "test" > /etc/plik_testowy
# usuwamy plik /etc/plik/testowy 
sudo rm /etc/plik_testowy

W pliku /var/log/messages pojawią się następuące wpisy:

Feb 15 09:18:45 aruba-cloud logger: "Sciezka: /etc/plik_testowy Zdarzenie:IN_CREATE"
Feb 15 09:18:45 aruba-cloud logger: "Sciezka: /etc/plik_testowy Zdarzenie:IN_MODIFY"
Feb 15 09:18:45 aruba-cloud logger: "Sciezka: /etc/plik_testowy Zdarzenie:IN_MODIFY"
Feb 15 09:18:46 aruba-cloud logger: "Sciezka: /etc/plik_testowy Zdarzenie:IN_DELETE"

W omawianym przykladzie program logger zapisuje informacje o zdarzeniu do pliku /var/log/messages. Możemy wskazać dowolny program który zostanie uruchomiony podczas wykrycia określonego zdarzenia. Innym przykładem może być skrypt, który wyśle pod wskazany adres e-mail informację o zdarzeniu.

Tworzymy plik /root/send_mail.sh, a jego zawartość wygląda następująco:

#!/bin/bash
args=("$@")

mail -s "Wykryto zmianę: ${args[0]} ${args[1]}: ${args[2]}" [email protected]

Nastepnie edytujemy incrontab

incrontab -e

i wpisujemy następującą linię:

/etc IN_MODIFY,IN_CREATE,IN_DELETE /root/send_mail.sh $@ $# $%

Od tego momentu w przypadku wystąpienia zdarzenia IN_MODIFY, IN_CREATE, IN_DELETE w katalogu /etc/ zostanie uruchomiony plik /root/send_mail.sh z argumentami: ścieżka do pliku, nazwa pliku oraz nazwa zdarzenia. Spowoduje to wysłanie emaila z informacją o zdarzeniu. Wystarczy teraz zmienić ścieżkę monitorowanego katalogu na ten, w którym przechowujemy pliki serwera WWW, by otrzymać prosty system ostrzegania o incydentach wartych analizy.

Cały proces włączenia monitoringu możecie zobaczyć na poniższym filmie a kod skryptu do wysyłania poczty znajdziecie na naszym GitHubie.

Zapraszamy także do testowania serwerów w ArubaCloud.

Dla pełnej przejrzystości – za przygotowanie oraz opublikowanie powyższego artykułu otrzymujemy wynagrodzenie.