Zawartość rozdziału:
Dzienniki zdarzeń są jednym z najważniejszych - z punktu widzenia bezpieczeństwa - elementów systemu. Tworzą one historię działań systemu, zwaną zapisem audytu. To dzięki nim można się dowiedzieć o nieprawidłowościach w działaniu systemu, próbach penetracji i włamań i to one powinny być jednym z najbardziej strzeżonych jego zasobów.
Z oczywistych względów dzienniki zdarzeń nie powinny znajdować się na tym samym serwerze, z którego pochodzą. Intruz, który włamie się na serwer może je łatwo zmodyfikować zacierając po sobie wszystkie ślady. Może również umieścić w nich fałszywe informacje wskazujące np. na kogoś innego.
Dlatego też:
Demon syslog działa w oparciu o dwa parametry konfiguracyjne: facility i priority, których dokładny opis znajduje się w podręczniku man - syslog(3), a cała konfiguracja odbywa sie poprzez edycję pliku /etc/syslog.conf.
Możemy tak skonfigurować demon syslog, aby wszystkie najważniejsze informacje były kierowane do jednego centralnego pliku, bądź były kierowane do kilkunastu dzienników - jeden dziennik dla jednej aplikacji bądź demona systemowego. Pierwsza metoda jest wygodniejsza w przypadku pojedynczego serwera, gdy jednak zarządzamy kilkoma serwerami lepszym rozwiązaniem wydaje się być centralny serwer logów i wiele dzienników.
W przypadku, gdy serwer nie będzie wysyłał logów na inny host tworzymy jak najmniej dzienników, w których będą zapisywane wszystkie ważniejsze informacje. W tym celu wszystkie informacje o priorytetach debug i wyższych zapisujemy do /var/adm/messages.
Przykład konfiguracji /etc/syslog.conf:
mail.debug /var/log/syslog *.debug;mail.none /var/adm/messages
W tym przypadku rozdzielamy poszczególne typy informacji do różnych plików:
kern.debug /var/log/all/kern.log user.debug /var/log/all/user.log mail.debug /var/log/all/mail.log daemon.debug /var/log/all/daemon.log auth.debug /var/log/all/auth.log syslog.debug /var/log/all/syslog.log lpr.debug /var/log/all/lpr.log news.debug /var/log/all/news.log uucp.debug /var/log/all/uucp.log cron.debug /var/log/all/cron.log local0.debug /var/log/all/local0.log local1.debug /var/log/all/local1.log local2.debug /var/log/all/local2.log local3.debug /var/log/all/local3.log local4.debug /var/log/all/local4.log local5.debug /var/log/all/local5.log local6.debug /var/log/all/local6.log local7.debug /var/log/all/local7.log
Należy również pamiętać o utworzeniu powyższych plików i ustawieniu następujących praw dostępu i właściciela:
chmod -R 600 /var/log chgrp -R sys /var/log
Przetestować powyższe ustawienia możemy za pomocą polecenia logger, np.:
/usr/ucb/logger -p facility.priority -t test "Test"oraz przejrzeć zawartość odpowiedniego pliku (oczywiście zmienne: facility oraz priority należy zastąpić odpowiednimi wartościami, np. local0.debug).
Domyślnie SUN Solaris ma wyłączoną opcję zbierania informacji o nieudanych próbach logowania. Ponieważ informacje tego typu są bardzo cenne (mogą np. świadczyć o ataku brutalnym na hasło użytkownika) należy taką możliwość włączyć:
cd /var/adm touch loginlog chgrp sys loginlog chmod 600 loginlog
Powyższy plik powinien być sprawdzany przynajmniej raz dziennie, lub monitorowany przez narzędzia takie jak swatch.
Wykorzystując program tcpwrapper lub xinetd należy ustawić kilka nieużywanych popularnych portów jako włączone (np. SMB, imap, login, http itp.) lecz bez żadnego prawdziwego demona, np.:
imap stream tcp nowait root /usr/local/bin/tcpd imap.trap
w hosts.allow należy ustawić:
imap.trap: ALL
gdzie imap.trap nie istnieje lub jest np. skryptem shellowym (/usr/sbin/imap.trap) zawierającym tylko komendę wyjścia.
Ustawienie takiego zabezpieczenia na 3 czy 4 serwerach pozwoli stwierdzić, czy skanowana była cała podsieć, czy konkretna usługa, czy też wszystkie usługi.
Tego rodzaju pułapki warto stosować przede wszystkim na serwerze dns, mail lub www.
Jest to skrypt, który znajduje się standardowo np. w przypadku instalacji serwera Apache. Ponieważ dość często jest celem ataku zalecamy jego zmianę na skrypt, którego głównym zadaniem jest logowanie prób jego użycia.
Ponieważ standardowe mechanizmy rotacji logów pozostawiają dużo do życzenia, zalecamy stosowanie skryptów alternatywnych. Można np. skorzystać ze skryptów dostępnych w pakiecie PARCdaily.Z. Więcej szczegółów można znaleźć na stronie www.yassp.org.
Usunięcie standardowego mechanizmu rotacji logów z tablicy crontab konta root (/var/spool/cron/crontabs/root) wykonujemy poprzez skomentowanie poniższych linii:
#10 3 * * 0,4 /etc/cron.d/logchecker #10 3 * * 0 /usr/lib/newsyslog
Następnie należy zainstalować skrypt do rotacji logów stosując się do wytycznych znajdujących się w dołączonej do niego dokumentacji.
Ponieważ przeglądanie logów w przypadku dużych systemów może być zajęciem żmudnym i czasochłonnym, można je zautomatyzować poprzez użycie narzędzi, takich jak np. logcheck lub swatch.
Accounting czyli monitorowanie systemu operacyjnego (dawniej używane do rozliczania użytkowników korzystających z zasobów systemu) jest kolejnym elementem przydatnym przy audycie. Umożliwia on zapisywanie danych o czasie uruchomienia i zakończenia procesów, liczbie zużytej pamięci, identifikatorze użytkownika uruchamiającego proces itp. W przypadku systemu Solaris, informacje te są zapisywane w pliku /var/adm/pacct.
Accounting włączamy poleceniem accton:
/usr/lib/acct/accton /var/adm/pacct
Informacje zapisane w pliku /var/adm/pacct odczytujemy za pomocą polecenia lastcomm. Polecenie to działa dość wolno, dlatego też lepszym rozwiązaniem jest użycie programu Spar. Pomimo wielu zalet process accounting posiada ograniczone możliwości. Potężnym narzędzie do audytu, którym dysponuje Solaris jest BSM.
SunSHIELD Basic Security Module umożliwia uruchomienie systemu na poziomie bezpieczeństwa C2, którego jednym z wymagań jest rejestrowanie wszystkich istotnych z punktu widzenia bezpieczeństwa zdarzeń wykonywanych przez użytkowników i system. BSM bardzo często wykorzystywany jest przez systemy IDS bazujące na hoście, np. RealSecure. BSM wymaga dokładnej konfiguracji, dlatego niezbędne jest skorzystanie z dokumentacji "SunSHIELD Basic Security Module Guide" z AnswerBook2. Należy zauważyć, że niewłaściwa konfiguracja może doprowadzić do szybkiego zapełnienia dysku.
Do odczytywania zdarzeń zarejestrowanych przez BSM służą polecenia: praudit i auditreduce. Ze względu na niezbyt wygodną obsługę tych komend zachęcamy również do zainstalowania dodatkowych skryptów (jak np. audit2info), które ułatwiają przeglądanie danych.
init S cd /etc/security ./bsmconv
Włączamy rejestrowania argumentów poleceń wykonywanych przez użytkowników i system poprzez dodanie do pliku /etc/security/audit_startup polecenia:
auditconfig -setpolicy +argv
Aby zapisywać wszystkie komendy wykonywane przez użytkowników, do /etc/security/audit_control wstawiamy:
flags:ex
Aby dokładnie rejestrować działania superużytkownika, do pliku /etc/security/audit_user dodajemy:
root:lo,ex,fd,fc,fm,fw:no
sync reboot
W celu przetworzenia danych rejestrowanych przez BSM do postaci czytelnej należy użyć polecenia:
auditreduce | praudit > ascii_plik.txt
Tak przygotowany plik możemy poddać obróbce przy pomocy skryptu audit2info. Skrypt ten wymaga również zainstalowania GNU awk, który jest dostępny na stronie www.sunfreeware.com.
Ponieważ sam system operacyjny nie ma możliwości rejestrowania prób połączeń TCP/IP, umożliwia to osobom z zewnątrz skanowanie portów w celu wyszukania otwartych usług, wersji serwisów, ewentualnych dziur czy uruchamiania programów złośliwych bez żadnego odnotowania w systemie.
Dlatego podstawowym narzędziem każdego administratora powinien być używanie narzędzi takich jak snort lub iplogger, ewentualnie narzędzi alternatywnych (patrz punkt: 1.19)
 |
 |
 |