Bociek PLD - Pisarz
I. Informacje podstawowe
II. Instalacja
III. Podręcznik użytkownika
IV. Podręcznik administratora
Usługi dostępne w PLD
Syslog-ng
V. Tworzenie PLD - Praktyczny poradnik
VI. O podręczniku
O tej książce
Spis treści
Inne wersje tego dokumentu
PDF
HTML (jeden plik)
TXT
Odnośniki
Tworzymy dokumentację PLD
Strona PLD
Listy dyskusyjne PLD

Syslog-ng

<- ->
 

Wstęp

W PLD domyślnie instalowanym systemem magazynowania zdarzeń systemowych (logów) jest syslog-ng (syslog - new generation), zajął on miejsce klasycznego tandemu syslogd i kalogd. Jest to program o bogatych opcjach konfiguracji, zapewniający większą pewność działania, a co za tym idzie większe bezpieczeństwo logów.

Większe bezpieczeństwo zapewnia możliwość użycia protokołu TCP w komunikacji z tzw. loghostem, aby jednak korzystać z dobrodziejstw tego protokołu na obu maszynach musi być użyty demon "nowej generacji". Możliwa jest także komunikacja z klasycznym syslogiem, w tym wypadku musimy użyć protokołu UDP i portu 514 (wartość domyślna dla syslog-ng).

Konfiguracja

Syslog-ng jest dostarczany z rozbudowanym plikiem konfiguracji, znajdziemy w nim wiele gotowych do wykorzystania przykładów.

Konfiguracja demona polega na zdefiniowaniu pewnych obiektów, a na następnie połączenie ich ze sobą w reguły. Mamy trzy rodzaje obiektów: źródła, filtry i cele. Źródła wskazują miejsca pochodzenia komunikatów, filtry pozwalają selekcjonować dane, cele zaś wskazują sposób i miejsce magazynowania logów (zwyczajowo jako pliki tekstowe w katalogu /var/log). Całą konfigurację umieszczamy w jednym pliku: /etc/syslog-ng/syslog-ng.conf.

  • Źródła - definiujemy je następująco:

    source $nazwa { $źródło($opcje); };

    najpopularniejsze źródła komunikatów to:

    • internal - komunikaty demona syslog-ng

    • tcp - komunikaty od innych komputerów w sieci (TCP)

    • udp - komunikaty od innych komputerów w sieci (UDP)

    • pipe - nazwane potoki

    • unix-stream - gniazda uniksowe

    przykłady:

    source  src  { internal(); };
    source  udp  { udp(); };
    source  tcp  { tcp(ip(192.168.1.5) port(1999) max-connections(20)); };

    Pierwszy z przykładów jest źródłem komunikatów syslog-a. Drugi tworzy źródło komunikatów wysyłanych z dowolnej maszyny w sieci - nasłuch na domyślnym porcie (514 UDP). Trzeci oczekuje komunikatów od komputera 192.168.1.5 na porcie 1999 z ograniczeniem do 20 połączeń.

  • Filtry:

    filter $nazwa { $rodzaj($wartość); };

    rodzaje:

    • facility - pochodzenie zdarzenia: cron, daemon, mail, ... - szczegóły w dodatku

    • level - priorytet: emerg, alert, crit, ... - szczegóły w dodatku

    • host - filtrowane po nazwie hosta z użyciem wyrażeń regularnych

    • program - filtrowane po nazwie programu z użyciem wyrażeń regularnych

    przykłady:

    filter f_emergency { level(emerg); };
    filter f_daemon    { facility(daemon); };
    filter f_foo       { host("foo"); };
    filter f_su_sudo   { program("^su|sudo$"); };

    Pierwszy przykładowy filtr przepuszcza jedynie powiadomienia o najpoważniejszych błędach. Drugi zdarzenia pochodzące od demonów, trzeci wybiera zdarzenia pochodzące od komputera mającego w nazwie ciąg "foo". Ostatni odfiltrowuje zdarzenia wywoływane w skutek działania programów su i sudo - użycie wyrażeń regularnych.

    W filtrach możemy używać operatorów logicznych (and, or, not):

    filter f_syslog  { not facility(authpriv, cron, lpr, mail, news); };
    filter f_ppp     { facility(daemon) and program(pppd) or program(chat); };

  • Cele - ogólna definicja:

    destination $nazwa { $cel($miejsce); };

    najpopularniejsze cele:

    • file - plik tekstowy / urządzenie znakowe (/dev/)

    • usertty - ekran terminala wskazanego użytkownika

    • tcp - komunikaty do loghosta (TCP)

    • udp - komunikaty do loghosta (UDP)

    przykłady:

    destination  kernel       { file("/var/log/kernel"); };		
    destination  console_all  { file("/dev/tty12"); };		
    destination  root         { usertty("root"); };			
    destination  loghost      { udp("10.0.0.1"); };

    W pierwszym przykładnie komunikaty są kierowane do pliku /var/log/kernel, w drugim będą wyświetlane na dwunastym wirtualnym terminalu. Trzeci cel spowoduje wyświetlanie komunikatu na ekranie terminala użytkownika root. Czwarty obiekt pozwoli na wysyłanie komunikatów do loghosta o adresie IP 10.0.0.1 (uwaga na zgodność protokołów TCP/UDP u nadawcy i odbiorcy).

  • Regułki - budujemy je na samym końcu, kiedy mamy już zdefiniowane źródła, filtry i cele:

    log { source($źródło); destination($cel); };

    log { source($źródło); filter($filtr1); filter($filtr2); destination($cel); };

    np.:

    log { source(src);  destination(console_all); };
    log { source(src);  filter(f_emergency);  destination(loghost); };

Aby zmiany weszły w życie oraz utworzone zostały nowe pliki dzienników, należy ponownie uruchomić demona:

# service syslog-ng reload

Test konfiguracji

Najlepszą metodą sprawdzenia konfiguracji sysloga jest wysłanie własnych komuników systemowych. Posłużymy się w tym celu programem logger, pozwalającym wysyłać dowolne komunikaty z wiersza poleceń. Dla naszych potrzeb wywołujemy program następująco:

logger -p {$źródło}.{$poziom} {$komunikat} np.:

# logger -p mail.warning Test ostrzeżenia

Uwagi

  • Podobnie jak poprzednik nie kontroluje objętości logów, tak więc nie można zapomnieć o programie rotującym np. logrotate.

  • Domyślnie demon nie nasłuchuje komunikatów z sieci, definicja źródła za to odpowiedzialna jest wykomentowana.

  • W ramach ochrony przed atakami DoS syslog-ng obsługuje domyślnie do 10 połączeń sieciowych, aby to zmienić należy użyć parametru "max-connections" w opcjach źródła (patrz przykłady).

Dodatek

System operacyjny posiada wewnętrzny, niezależny od demona logów, schemat klasyfikowania zdarzeń, dzielą się one na dwie grupy:

Pochodzenie komunikatów (facility):

Nazwa Opis
user różnorodne programy zwykłych użytkowników
mail komunikaty podsystemu poczty elektronicznej
daemon różne demony systemowe
auth, authpriv bezpieczeństwo (autoryzacja użytkowników)
syslog syslog
lpr drukarka
news system grup dyskusyjnych (Usenet)
uucp podsystem UUCP
cron demony zegarowe: AT, CRON
ftp serwer FTP
local0 - local7 uniwersalne źródła lokalne, możliwe do dowolnego zastosowania przez administratora

Priorytety (level):

Nazwa Opis
emerg system już nie nadaje się do użytku
alert poważna awaria - należy podjąć natychmiastową akcję
crit zdarzenie krytyczne
err błędy
warning ostrzeżenia
notice ważne zdarzenia
info informacje
debug dodatkowe informacje - przydatne przy odpluskwianiu
 
<- ->