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):

Priorytety (level):