Linux RHCSA cz.35 - Logi systemowe - praca z Syslog

Skąd możemy wiedzieć, że z systemem dzieje się coś niedobrego nawet jeżeli nie widać tego na pierwszy rzut oka? Oczywiście trzeba przejrzeć logi! A tak na poważnie zrozumienie działania systemu logowania jest bardzo ważne dla rozwiązywania problemów jakie można napotkać podczas administrowania środowiskiem Linux. W logach przechowywane są wszystkie informację na temat jądra, procesu uruchomienia oraz różnych usług, które zostały uruchomione w systemie. Obok logów istnieją także narzędzia jakich możesz użyć do monitorowania i weryfikacji poprawnego działania środowiska. W tej części zobaczymy w jaki sposób można używać dostępnych narzędzi oraz logów by zdiagnozować występujące problemy i znaleźć ich rozwiązanie. W dalszej części poznamy również sposoby na zautomatyzowanie tego procesu. 

PRACA Z SYSLOG

Kiedy coś pójdzie nie tak w systemie pracująca usługa "syslog" wygeneruje komunikat. Wiadomości wygenerowane w taki sposób rejestrują to jak system działa, jakie zostały podjęte działania i z czym oraz w jakim miejscu pojawił się problem. Usługa "syslog" została wbudowana w środowisko RedHat i uruchamiana jest w raz systemem przy jego starcie. Pakiet "rsyslog" jest domyślnie zainstalowany w systemie i jest to podstawowe niezbędne narzędzie używane do logowania zdarzeń mających miejsce w systemie. 

W RHEL5 domyślnie logowaniem rozłożone zostało pomiędzy dwoma usługami : syslogd oraz klogd. Syslog obsługuje komunikaty systemowe, a klogd obsługuję komunikaty z jądra systemu. W wydaniu RHEL6 obie usługi zostały zastąpione przez rsyslogd obsługujący oba rodzaje komunikatów. Jeżeli pozostajemy przy wydaniu RHEL5 można zainstalować usługę syslog z pakietu syslogd. 

Usługa rsyslog posiada główny plik konfiguracyjny /etc/rsyslog.conf, który kontroluje gdzie trafiają wygenerowane komunikaty. Ponieważ logi są krytycznym elementem systemu operacyjnego pakiet ten jest instalowany domyślnie stając się częścią systemu operacyjnego. 

Krok 1 - Dobrym nawykiem jest sprawdzenie czy pakiet faktycznie znajduje się w systemie

# rpm -qa | grep syslog
rsyslog-4.6.2-2.el6.x86_64

Ponieważ widać, że jest zainstalowany powinniśmy sprawdzić jeszcze dwa pozostałe zagadnienia

Krok 2 - Pierwsze - upewnij się że usługa została uruchomiana wraz z systemem

# chkconfig rsyslog --list
rsyslog 0:off 1:off 2:on 3:on 4:on 5:on6:off

Krok 3 - Drugie - sprawdź czy usługa jest faktycznie uruchomiona

# service rsyslog status
rsyslogd (pid 1279) is running...

Dla wydania RHEL05 :

Krok 1 - Sprawdzenie czy pakiet znajduje się w systemie :

# rpm -qa | grep klog
sysklogd-1.4.1-44.el5

Krok 2 - Sprawdzenie czy jest uruchamiany razem z systemem podczas startu

# chkconfig syslog --list
syslog 0:off 1:off 2:on 3:on 4:on 5:on6:off

Krok 3 - Sprawdzenie czy jest uruchomiony

# service syslog status
syslogd (pid 2214) is running...
klogd (pid 2217) is running...

Teraz widać nieznaczne różnice jakie występują pomiędzy wydaniami RHEL dotyczące logowania. Usługa rsyslog działa lepiej i rekomenduje się jej używanie i instalację tam gdzie jest to możliwe.

Wszystkie wiadomości jakie wysyłane są przez usługę rsyslog przechowywane są w katalogu /var/log z podziałem na różne pliki i podkatalogi. Można również zdefiniować własny plik logu i katalog. Największym problemem z logami jest fakt, że jeżeli zostaną zlekceważone ciężko jest później nad nimi zapanować i doprowadzić je do porządku. Ponieważ logowanie totalnie wszystkiego jest sztuką samą w sobie lepiej jest zaplanować by logowane były tylko istotne elementy dla danego systemu. Istnieje dziewięć różnych powiadomień z jakich korzysta usługa syslog:

• emerg
• alert
• crit
• err
• warning
• notice
• info
• debug
• none

PLIK KONFIGURACYJNY

Plik /etc/rsyslog.conf jest podzielony na następujące części: 

• Modules - Wskazanie jaki moduł ma być uruchomiony lub wyłączony 
• Global directives - Konfiguracje startu usługi (wszystkie startują z symbolem $)
• Rules - Wskazanie na współprace pomiędzy zaznaczeniem a działaniem
• Selector - Bazuje na <facility>.<priority>
• Akcja - Definicja co zrobić z pojawiającą się wiadomością po posortowaniu przez selektor

Zobaczmy domyślną konfigurację zawartą w pliku : 

# cat /etc/rsyslog.conf

#rsyslog v3 config file

# if you experience problems, check

# http://www.rsyslog.com/troubleshoot for assistance

#### MODULES ####

$ModLoad imuxsock.so # provides support for local system logging (e.g. via

logger command)

$ModLoad imklog.so # provides kernel logging support (previously done by

rklogd)

#$ModLoad immark.so # provides --MARK-- message capability

# Provides UDP syslog reception

#$ModLoad imudp.so

#$UDPServerRun 514

# Provides TCP syslog reception

#$ModLoad imtcp.so

#$InputTCPServerRun 514

#### GLOBAL DIRECTIVES ####

# Use default timestamp format

$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

# File syncing capability is disabled by default. This feature is usually not

required,

# not useful and an extreme performance hit

#$ActionFileEnableSync on

#### RULES ####

# Log all kernel messages to the console.

# Logging much else clutters up the screen.

#kern.* /dev/console

# Log anything (except mail) of level info or higher.

# Don’t log private authentication messages!

*.info;mail.none;authpriv.none;cron.none /var/log/messages

# The authpriv file has restricted access.

authpriv.* /var/log/secure

# Log all the mail messages in one place.

mail.*

# Log cron stuff

cron.* /var/log/cron

# Everybody gets emergency messages

*.emerg *

# Save news errors of level crit and higher in a special file.

uucp,news.crit /var/log/spooler

# Save boot messages also to boot.log

local7.* /var/log/boot.log

# ### begin forwarding rule ###

# The statement between the begin ... end define a SINGLE forwarding

# rule. They belong together, do NOT split them. If you create multiple

# forwarding rules, duplicate the whole block!

# Remote Logging (we use TCP for reliable delivery)

#

# An on-disk queue is created for this action. If the remote host is

# down, messages are spooled to disk and sent when it is up again.

#$WorkDirectory /var/spppl/rsyslog # where to place spool files

#$ActionQueueFileName fwdRule1 # unique name prefix for spool files

#$ActionQueueMaxDiskSpace 1g # 1gb space limit (use as much as possible)

#$ActionQueueSaveOnShutdown on # save messages to disk on shutdown

#$ActionQueueType LinkedList # run asynchronously

#$ActionResumeRetryCount -1 # infinite retries if host is down

# remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional

#*.* @@remote-host:514

# ### end of the forwarding rule ###

Można zobaczyć w jaki sposób pliki logów zostały posortowane oraz jakim domyślnym zasadą podlegają. 

ROTACJA LOGÓW

Logi pozostawione same sobie mogą rozrosnąć się do niewiarygodnych rozmiarów. Na szczęście możemy skorzystać z polecenia "logrotate" umożliwiającego podział i rotacje plików z logami zanim staną się bardzo duże. Domyślnie "logrotate" odwołuje się do cykli dniowych tworząc nowy plik każdego dnia. Parametry i konfiguracja znajdują się w pliku /etc/cron.daily/logrotate, dalszą pracę wykona codziennie "cron". Możesz również zawsze wywołać polecenie logrotate jeżeli chcesz wykonać rotację logów jednak nie poleca się by robić to z dużą częstotliwością po prostu trzeba zachować umiar i rozwagę by zachować ład i porządek w organizacji plików z logami. 

Składnia polecenia logrotate: # logrotate [opcje] plik_konfiguracyjny

Opcje polecenia logtorate: 

• -d   - Debug, nie rób niczego ale testuj
• -f    - Wymuś rotację logów
• -v   - Wyświetlaj informację na temat wykonywanych działań 

Dla testu można wykonać rotacje aktualnych logów definiując ją w pliku konfiguracyjnym : 

 # logrotate /etc/logrotate.conf

REJESTROWANIE SCENTRALIZOWANE

Jeżeli chcemy możemy ustanowić jedno miejsce dla przechowywania logów wielu maszyn w danym środowisku. Należy zdecydować, który z serwerów będzie przeznaczony do przechowywania logów. Dla przykładu możemy użyć maszyny RHEL01 i zastosować ją jako centralne miejsce przechowywania logów. 

Krok 1 - Zobaczmy ponownie sekcje pliku /etc/rsysclog.conf

#### MODULES ####

$ModLoad imuxsock.so # provides support for local system logging

(e.g. via logger command)

$ModLoad imklog.so # provides kernel logging support (previously

done by rklogd)

#$ModLoad immark.so # provides --MARK-- message capability

# Provides UDP syslog reception

#$ModLoad imudp.so

#$UDPServerRun 514

# Provides TCP syslog reception

#$ModLoad imtcp.so

#$InputTCPServerRun 514

W sekcji modułów widzimy dwa miejsca, które dotyczą przechowywania logów w innym miejscu. Standardem jest używanie protokołu UDP na porcie 514. Odkomentowanie sekcji UDP umożliwi uruchomienie działania centralnego serwera do przechowywania logów w sieci.

Krok 2 - Usuńmy znak komentarza dla dwóch linii. 

$ModLoad imudp.so

$UDPServerRun 514

Krok 3 - Zapisujemy plik oraz restartujemy usługę syslog.

# service rsyslog restart

Shutting down system logger: [ OK ]

Starting system logger: [ OK ]

Po tych czynnościach, aby usługa była widoczna w sieci trzeba ustawić odpowiednie zezwolenie w firewall umożliwiające połączenie UDP na porcie 514.

Krok 4 - Zastosujmy "iptables" tworząc odpowiednią regułę

# iptables -I INPUT 5 -p udp -m udp --dport 514 -j ACCEPT

Krok 5 - Zapiszmy regułę firewall po utworzeniu

# service iptables save

Saving firewall rules to /etc/sysconfig/iptables: [ OK ]

Krok 6 - Restart usługi "iptables"

# service iptables restart

iptables: Flushing firewall rules: [ OK ]

iptables: Setting chains to policy ACCEPT: filter [ OK ]

iptables: Unloading modules: [ OK ]

iptables: Applying firewall rules: [ OK ]

W tej chwili ustawienia firewall nie są może najważniejsze ponieważ używamy standardowych reguł i tak na prawdę na przetestowanie działania omawianego zagadnienia można wyłączyć usługę "iptables". 

Teraz gdy mamy już uruchomioną usługę centralnego serwera logów możemy zająć się konfiguracją klienta. Wykonamy to na maszynie RHEL02. Konfiguracja spowoduje przesyłanie wszystkich logów maszyny RHEL02 na serwer logów czyli RHEL01. 

Zgodnie ze strukturą pliku konfiguracyjnego logi mają być przesyłane na centralny serwer logów. 

<log file> @<hostname or IP of system (local or remote)>

Należy przeprowadzić edycje na maszynie RHEL02 : 

# vi /etc/rsyslog.conf 

authpriv.*               @172.168.1.1

Zapisujemy plik oraz restartujemy usługę syslog na maszynie RHEL02

# service rsyslog restart

Shutting down system logger: [ OK ]

Starting system logger: [ OK ]

Jeżeli zostanie wygenerowane jakiekolwiek zdarzenie bezpieczeństwa na maszynie RHEL02 i zostanie zapisane do logu będzie można zobaczyć takie wpisy w plikach znajdujących się na maszynie RHEL01. 

Wskazując logi jakie mają zostać przesłane do centralnego serwera znajdującego się lokalnie lub zdalnie można zastosować 5 opcji : 

# Send messages using the TCP protocol instead of UDP

Authpriv.*                              @@172.168.1.1

# Displays messages on the console instead of sending them remotely

Authpriv.*                              @system

# Discard all messages generated for this log file

Authpriv.*                               ~

# Send alert to all log files ** use with caution **

Authpriv.*                               *

Opcje te mogą być używane dla przesyłania logów na zdalny serwer w połączeniu z zachowaniem ich lokalnych kopii. 

REJESTROWANIE SCENTRALIZOWANE wersja dla RHEL05 

Krok 1 - Edytujemy plik /etc/sysconfig/syslog zawierający wpis z opcją "-r"

# vi /etc/sysconfig/syslog

# Options to syslogd

# -m 0 disables ‘MARK’ messages.

# -r enables logging from remote machines

# -x disables DNS lookups on messages received with -r

# See syslogd(8) for more details

SYSLOGD_OPTIONS=”-m 0 -r”

Krok 2 - Po zapisaniu pliku wykonujemy restart usługi syslog 

# service syslog restart

Shutting down kernel logger: [ OK ]

Shutting down system logger: [ OK ]

Starting system logger: [ OK ]

Starting kernel logger: [ OK ]

Kiedy usługa syslog akceptuje już zdalne przechowywanie logów potrzebujemy ustawić odpowiednia regułę firewall. Przebiega to identycznie jak w przypadku RHEL06 co pokazane było przed chwilą. Ostatnią zmianą jaką trzeba zrobić w RHEL05 jest ustawienie zabezpieczeń SELinux. 

Krok 3 - Zapytanie wywołujące wartości logiczne 

# getsebool -a | grep logd

klogd_disable_trans --> off

syslogd_disable_trans --> off

Krok 4 - Zmiana wartości na umożliwiające wpuszczenie zewnętrznych logów

# setsebool -P klogd_disable_trans=1 syslogd_disable_trans=1

Krok 5 - Sprawdzenie ustawień po zmianach

# getsebool -a | grep logd

klogd_disable_trans --> on

syslogd_disable_trans --> on

Chociaż konfiguracja SELinux nie została jeszcze wykonana istnieją domyślne wartości jakie należało zmienić aby zrozumieć co dokładnie zostało zrobione można powrócić do tego miejsca gdy omówione zostanie w dalszych częściach zagadnienie SELinux.

 REJESTROWANIE ZDARZEŃ LOGOWANIA UŻYTKOWNIKÓW DO SYSTEMU

Po za normalnymi logami jakie generowane są przez usługę syslog istnieją dwa specjalne polecenia dotyczące logowania użytkowników. Polecenia te tworzą specjalne wpisy jakie można odczytać również używając tych samych poleceń. 

• lastlog     - Zapis ostatniego logowania 
• faillog      - Ostanie nieprawidłowe logowanie

Możemy używać tych dwóch poleceń dla przeglądu zdarzeń związanych z logowaniem się użytkowników do systemu. Polecenia te również umożliwiają namierzenie prób włamań do systemu przy pomocy technik zwanych brute-force-attack. 

Składnia polecenia lastlog : # lastlog [opcje]

Opcje polecenia lastlog:

• -b DAYS    - Wyświetla wyniki starsze niż podany dzień 
• -u LOGIN  - Wyświetla wyniki dla danego użytkownika

Zobaczmy kiedy ostatnio użytkownik USER01 logował się do systemu:

# lastlog -u user01

Username Port From Latest

user01 tty Fri Sep 10 05:16:42 -0400 2010

Możemy również poznać więcej szczegółów korzystając z polecenia faillog. 

Składnia polecenia faillog : # faillog [opcje]

Opcje polecenia faillog:

• -a    - Wyświetl wszystkie zdarzenia
• -l SEC - Zablokowanie konta po SEC sekundach po podaniu błędnego loginu
• -u LOGIN - Wyświetl wpisy dotyczące danego użytkownika (LOGIN)

Zobaczmy więc więcej informacji związanych z użytkownikiem USER01

# faillog -u user01

Login Failures Maximum Latest On

user01   0           0

Umiejętność pracy z usługą syslog ważna jest gdyż ułatwia rozwiązywanie problemów związanych z nieprawidłowym działaniem systemu Linux nie tylko RedHat. Jeżeli potrzebujemy znaleźć rozwiązanie nie prawidłowowego działania systemu pierwszym krokiem zawsze jest zapoznanie się z wpisami w logach.