Istnieje wiele opcji logowania wiadomości SYSLOG do baz danych. Wśród nich znajdziemy zarówno opcje darmowe, jak i komercyjne. Domyślnie standardowo używany w systemach Unix/Linux demon SYSLOOGD nie współpracuje z bazą danych. Z kolei SYSLOG-NG wymaga zewnętrznego skryptu, który będzie potrafił odczytać dane zapisywane do kolejek. Mimo wszystko to całkiem popularna implementacja. Inna implementacja w postaci RSyslog rozszerza funkcjonalność o możliwość natywnego połączenia do bazy danych w celu zapisywania logów. Z kolei Sysklog-sql rozszerza w standardzie sysklogd o możliwość logowania do bazy danych. Istnieje także nxlog, który posiada moduł om_dbi, służący do zapisywania danych w bazie. Istnieje wiele komercyjnych narzędzi, które integrują SYSLOG z bazą danych.

Typy wdrożeń - standardowe i rozproszone

W zależności od przeznaczenia systemu i typu monitorowanej infrastruktury, konieczne będzie zastosowanie określonego typu wdrożenia. W praktyce spotkamy się z modelem logowania lokalnego, centralnego oraz mieszanego.

Logowanie lokalne jest standardowo realizowane przez większość systemów operacyjnych. Implementacja takiego rozwiązania jest zazwyczaj najłatwiejszą opcją, ale możliwości analizy tak zebranych dzienników zdarzeń zostają silnie ograniczone. Logowanie lokalne pozwala nadzorować i rozwiązywać problemy w obrębie danego serwera czy urządzenia. Nie ma w tym przypadku możliwości korelacji zdarzeń pochodzących z różnych systemów. W rzeczywistości włamanie na tak skonfigurowany serwer, pozwala atakującemu dowolnie zmodyfikować czy nawet usunąć dzienniki zdarzeń, które od tego momentu nie będą już przydatne. W praktyce tego typu logowanie nie jest zalecane ze względu na zbyt wysokie ryzyko naruszenia integralności dzienników zdarzeń. Jeżeli wdrożenie jest niewielkie, dysponujemy ograniczoną ilością maszyn i nie ma możliwości przeznaczenia jednej z nich na serwer logujący, może to być jedyne rozwiązanie. Stosunkowo wiele wad skłania jednak do realizacji nieco bardziej zaawansowanych scenariuszy.

Naturalną konsekwencją i rozwinięciem logowania lokalnego stało się logowanie scentralizowane. Na czym polega? Wykorzystywany jest w tym przypadku centralny serwer logujący, który zapewnia odpowiednią wydajność oraz pamięć masową. W celu uzyskania pełnej redundancji systemu takie serwery powinny być utrzymywane w postaci równoległej. Każda maszyna logująca powinna dodatkowo posiadać odpowiednie zasoby sprzętowe w postaci przestrzeni dyskowej, redundancji zasilania, wykorzystania RAID, podwójnych kart sieciowych. Każdy klient powinien zapisywać dzienniki zdarzeń na dwie niezależne maszyny. Jeżeli jedna z maszyn zawiedzie, klient musi mieć możliwość zapisania swoich dzienników zdarzeń na innej maszynie. Warto pamiętać, że serwery logujące powinny wyróżniać się szczególną dbałością o bezpieczeństwo i znajdować się poza celem atakującego. Jeżeli realizujemy korelację dzienników zdarzeń z różnych urządzeń, otrzymujemy znacznie większe możliwości analizy, a ponadto redukujemy liczbę czynności administracyjnych. Zdecydowanie łatwiej jest jednocześnie identyfikować zdarzenia na podstawie danych pochodzących z różnych elementów infrastruktury. Jeżeli maszyna wysyłająca logi zostanie zaatakowana, dane nie będą dostępne dla atakującego. W przeciwieństwie do logowania lokalnego w takiej sytuacji, zawsze będą dostępne dzienniki zdarzeń, które pozwolą wyjaśnić sytuację.

Szczególnym przypadkiem jest połączenie obu wyżej przedstawionych technik. Jeżeli nie działa połączenie do serwerów logujących, dzienniki zdarzeń są przechowywane lokalnie na zasobach klientów generujących informacje. Najczęściej forma tych dzienników zdarzeń jest silnie zredukowana w przypadku przechowywania lokalnego. Należy także poświęcić nieco więcej uwagi na odpowiednią konfigurację poziomu logowania, rotacji dzienników zdarzeń. W przypadku przywrócenia pracy centralnych serwerów, wysyłane są do nich zdarzenia z maszyn lokalnych.