Wyszukiwanie w witrynie

Jak utworzyć scentralizowany serwer dzienników za pomocą Rsyslog w CentOS/RHEL 7

Aby administrator systemu mógł zidentyfikować lub rozwiązać problem w systemie serwerowym CentOS 7 lub RHEL 7, musi znać i przeglądać zdarzenia, które miały miejsce w systemie w określonym okres czasu z plików dziennika przechowywanych w systemie w katalogu /var/log.

Serwer syslog na komputerze z systemem Linux może działać jako centralny punkt monitorowania w sieci, do którego mogą wysyłać swoje logi wszystkie serwery, urządzenia sieciowe, routery, przełączniki i większość ich wewnętrznych usług generujących dzienniki, niezależnie od tego, czy są one związane z konkretnym problemem wewnętrznym, czy po prostu wiadomościami informacyjnymi .

W systemie CentOS/RHEL 7 głównym preinstalowanym serwerem logów jest demon Rsyslog , a po nim następuje Daemon Systemd Journal (journald mocny>).

Serwer Rsyslog zbudowany jako usługa architektury klient/serwer i może pełnić obie role jednocześnie. Może działać jako serwer i zbierać wszystkie logi przesyłane przez inne urządzenia w sieci lub może działać jako klient, wysyłając wszystkie wewnętrzne zdarzenia systemowe zarejestrowane do zdalnego serwera syslog punktu końcowego.

Kiedy rsyslog jest skonfigurowany jako klient, dzienniki mogą być przechowywane lokalnie w plikach lokalnego systemu plików lub mogą być wysyłane zdalnie zamiast zapisywać je w plikach przechowywanych na komputerze lub lokalnie zapisywać pliki dziennika zdarzeń i wysyłać je do zdalnego serwera syslog pod adresem o tym samym czasie.

Serwer Syslog obsługuje dowolny komunikat dziennika, korzystając z następującego schematu:

type (facility).priority (severity)  destination(where to send the log)

A. Dane obiektu lub typu są reprezentowane przez wewnętrzne procesy systemowe, które generują komunikaty. W Linuksie wewnętrzne procesy (obiekty) generujące logi są ustandaryzowane w następujący sposób:

  • auth = wiadomości generowane przez procesy uwierzytelniania (logowanie).
  • cron= wiadomości generowane przez zaplanowane procesy (crontab).
  • demon = wiadomości generowane przez demony (usługi wewnętrzne).
  • jądro = wiadomości generowane przez samo jądro Linuksa.
  • poczta = wiadomości generowane przez serwer pocztowy.
  • syslog = wiadomości generowane przez samego demona rsyslog.
  • lpr = wiadomości generowane przez drukarki lokalne lub serwer druku.
  • local0 – local7 = niestandardowe wiadomości zdefiniowane przez administratora (local7 jest zwykle przypisywany dla Cisco lub Windows).

B. Poziomy priorytetu (ważności) również są ustandaryzowane. Każdemu priorytetowi przypisany jest standardowy skrót i numer, jak opisano poniżej. Siódmy priorytet to wyższy poziom ze wszystkich.

  • emergencja = Nagły wypadek – 0
  • alert = Alerty – 1
  • err = Błędy – 3
  • warn = Ostrzeżenia – 4
  • powiadomienie = powiadomienie – 5
  • info = Informacja – 6
  • debugowanie = debugowanie – 7

Specjalne słowa kluczowe Rsyslog:

  • *=wszystkie udogodnienia lub priorytety
  • none=obiekty nie mają określonych priorytetów, np.: mail.none

C. Trzecia część schematu syslog jest reprezentowana przez dyrektywę destination. Demon Rsyslog może wysyłać komunikaty dziennika, które mają zostać zapisane w pliku w lokalnym systemie plików (przeważnie w pliku w katalogu /var/log/) lub przesłane potokiem do innego procesu lokalnego lub wysłane do lokalna konsola użytkownika (na standardowe wyjście) lub wyślij wiadomość do zdalnego serwera syslog poprzez protokół TCP/UDP, a nawet odrzuć wiadomość do /dev/null.

Aby skonfigurować CentOS/RHEL 7 jako centralny serwer dzienników, najpierw musimy sprawdzić i upewnić się, że partycja /var, na której zapisywane są wszystkie pliki dziennika, jest wystarczająco duża ( minimum kilka GB), aby móc przechowywać wszystkie pliki dziennika, które będą przesyłane przez inne urządzenia. Dobrą decyzją jest użycie osobnego dysku (LVM, RAID) do zamontowania katalogu /var/log/.

Wymagania

  1. Procedura instalacji CentOS 7.3
  2. RHEL 7.3 Procedura instalacji

Jak skonfigurować Rsyslog na serwerze CentOS/RHEL 7

1. Domyślnie usługa Rsyslog jest instalowana automatycznie i powinna działać w CentOS/RHEL 7. W celu sprawdzenia czy demon jest uruchomiony w systemie należy wydać poniższe polecenie z uprawnieniami roota.

systemctl status rsyslog.service

Jeśli usługa nie jest domyślnie uruchomiona, wykonaj poniższe polecenie, aby uruchomić demona rsyslog.

systemctl start rsyslog.service

2. Jeśli pakiet rsyslog nie jest zainstalowany w systemie, którego zamierzasz używać jako scentralizowanego serwera rejestrowania, wydaj następującą komendę, aby zainstalować pakiet rsyslog.

yum install rsyslog

3. Pierwszym krokiem, który musimy wykonać w systemie, aby skonfigurować demona rsyslog jako scentralizowany serwer logów, aby mógł odbierać komunikaty logów dla klientów zewnętrznych, jest otwarcie i edycja przy użyciu Twojego ulubiony edytor tekstu, główny plik konfiguracyjny z /etc/rsyslog.conf, jak przedstawiono w poniższym fragmencie.

vi /etc/rsyslog.conf

W głównym pliku konfiguracyjnym rsyslog wyszukaj i odkomentuj następujące linie (usuń znak hashtagu # na początku linii), aby zapewnić odbiór transportu UDP do serwera Rsyslog przez 514 Port. UDP to standardowy protokół używany do przesyłania dzienników przez Rsyslog.

$ModLoad imudp 
$UDPServerRun 514

4. Protokół UDP nie ma narzutu TCP, co sprawia, że przesyła dane szybciej niż protokół TCP. Z drugiej strony protokół UDP nie gwarantuje niezawodności przesyłanych danych.

Jeśli jednak chcesz używać protokołu TCP do odbioru logów, musisz przeszukać i odkomentować następujące wiersze z pliku /etc/rsyslog.conf, aby skonfigurować demona Rsyslog do wiązania i nasłuchiwania gniazda TCP na 514 Port. Gniazda nasłuchowe TCP i UDP do odbioru można skonfigurować jednocześnie na serwerze Rsyslog.

$ModLoad imtcp 
$InputTCPServerRun 514

5. W następnym kroku nie zamykaj jeszcze pliku, utwórz nowy szablon, który będzie używany do odbierania wiadomości zdalnych. Ten szablon poinstruuje lokalny serwer Rsyslog, gdzie ma zapisywać otrzymane wiadomości wysyłane przez klientów sieci syslog. Szablon należy dodać przed początkiem bloku GLOBALNE DIRECTIVES, jak pokazano w poniższym fragmencie.

$template RemoteLogs,"/var/log/%HOSTNAME%/%PROGRAMNAME%.log" 
. ?RemoteLogs & ~

Powyższa dyrektywa $template RemoteLogs instruuje demona Rsyslog, aby zbierał i zapisywał wszystkie otrzymane komunikaty dziennika w odrębnych plikach na podstawie nazwy komputera klienckiego i zdalnej funkcji klienta (aplikacji), która wygenerowała komunikaty na podstawie zdefiniowane właściwości znajdują się w konfiguracji szablonu: %HOSTNAME% i %PROGRAMNAME%.

Wszystkie te pliki dziennika zostaną zapisane w lokalnym systemie plików w dedykowanym pliku nazwanym na cześć nazwy hosta komputera klienckiego i zapisane w katalogu /var/log/.

Reguła przekierowania & ~ instruuje lokalny serwer Rsyslog, aby zaprzestał dalszego przetwarzania odebranego komunikatu dziennika i odrzucił komunikaty (nie zapisywał ich w wewnętrznych plikach dziennika).

Nazwa RemoteLogs to dowolna nazwa nadana tej dyrektywie szablonowej. Możesz użyć dowolnej nazwy, która najlepiej pasuje do Twojego szablonu.

Aby zapisać wszystkie otrzymane wiadomości od klientów w jednym pliku dziennika o nazwie odpowiadającej adresowi IP zdalnego klienta, bez filtrowania funkcji, która wygenerowała wiadomość, skorzystaj z poniższego fragmentu.

$template FromIp,"/var/log/%FROMHOST-IP%.log" 
. ?FromIp & ~

Inny przykład szablonu, w którym wszystkie wiadomości z flagą funkcji uwierzytelniania będą rejestrowane w szablonie o nazwie „TmplAuth”.

$template TmplAuth, "/var/log/%HOSTNAME%/%PROGRAMNAME%.log" 
authpriv.*   ?TmplAuth

Poniżej znajduje się fragment definicji szablonu z serwera Rsyslog 7:

template(name="TmplMsg" type="string"
         string="/var/log/remote/msg/%HOSTNAME%/%PROGRAMNAME:::secpath-replace%.log"
        )

Powyższy fragment szablonu można również zapisać jako:

template(name="TmplMsg" type="list") {
    constant(value="/var/log/remote/msg/")
    property(name="hostname")
    constant(value="/")
    property(name="programname" SecurePath="replace")
    constant(value=".log")
    }

Aby napisać złożone szablony Rsyslog, przeczytaj instrukcję pliku konfiguracyjnego Rsyslog, wydając polecenie man rsyslog.conf lub zapoznaj się z dokumentacją online Rsyslog.

6. Po dokonaniu edycji pliku konfiguracyjnego Rsyslog przy użyciu własnych ustawień, jak wyjaśniono powyżej, zrestartuj demona Rsyslog, aby zastosować zmiany, wydając następujące polecenie:

service rsyslog restart

7. Do tej pory serwer Rsyslog powinien być skonfigurowany tak, aby działał jako scentralizowany serwer logów i rejestrował wiadomości od klientów syslog. Aby zweryfikować gniazda sieciowe Rsyslog, uruchom polecenie netstat z uprawnieniami roota i użyj grep, aby przefiltrować ciąg rsyslog.

netstat -tulpn | grep rsyslog

8. Jeśli masz włączony SELinux w CentOS/RHEL 7, wydaj następujące polecenie, aby skonfigurować SELinux tak, aby zezwalał na ruch rsyslog w zależności od typu gniazda sieciowego.

semanage -a -t syslogd_port_t -p udp 514
semanage -a -t syslogd_port_t -p tcp 514

9. Jeśli zapora sieciowa jest włączona i aktywna, uruchom poniższe polecenie, aby dodać niezbędne reguły otwierania portów rsyslog w zaporze Firewalld.

firewall-cmd --permanent --add-port=514/tcp
firewall-cmd --permanent --add-port=514/udp
firewall-cmd –reload

To wszystko! Rsyslog jest teraz skonfigurowany w trybie serwera i może centralizować dzienniki od klientów zdalnych. W następnym artykule zobaczymy, jak skonfigurować klienta Rsyslog na serwerze CentOS/RHEL 7.

Używając serwera Rsyslog jako centralnego punktu monitorowania zdalnych komunikatów dziennika, możesz przeglądać pliki dziennika i obserwować stan zdrowia klientów lub łatwiej debugować problemy klienta w przypadku awarii systemu lub ataku.