Zwykle system logowania organizuje się tak, że informacje z hostów są gromadzone w jednym miejscu, stanowiącym dobrze chroniony magazyn. "Konieczność kopiowania logów na bieżąco do drugiej lokalizacji jest oczywista z punktu widzenia bezpieczeństwa, gdyż włamywacz może wykorzystać nieznaną dotąd podatność nawet na poziomie jądra systemu. Posiadając uprawnienia systemowe, mógłby zmodyfikować lub usunąć lokalne pliki logów. W przypadku bezpiecznego składowania logów poza hostem takie działanie jest o wiele trudniejsze, gdyż wymaga przejęcia co najmniej dwóch maszyn" - uzasadnia Paweł Jakub Dawidek, CTO firmy Wheel Systems.

Zbieranie informacji na hoście nie zawsze wystarczy. Niekiedy niezbędna jest analiza tego, co robi aplikacja. W wielu systemach do tego celu służy polecenie strace (w systemie Solaris jest to truss), ale nie zawsze uzyskane tak informacje są wystarczające. Paweł Dawidek ostrzega: "Narzędzia, takie jak strace czy truss, nie zapewnią niezawodności logowania zdarzeń. Mogą gubić część operacji przy większym obciążeniu systemu operacyjnego lub przy braku miejsca w systemie plików przeznaczonym na logi. Do niezawodnego logowania wszelkich zdarzeń systemowych związanych z bezpieczeństwem służą mechanizmy, np. Security Event Auditing, dostępne m.in. w systemie FreeBSD".

Po wykryciu włamania należy wszystkie rejestrowane zdarzenia traktować jako niewiarygodne, gdyż włamywacz może przejąć kontrolę nad komputerem do poziomu uprawnień jądra włącznie. Gdy włamywacz posiada uprawnienia na poziomie jądra systemu, jest w stanie modyfikować dowolny plik, wysłać komunikat, zrealizować dowolne działanie w obrębie systemu. Logi bywają sfałszowane, nie mogą stanowić dowodu.

Prosty syslog nie wystarczy

Maszyny typu UNIX mają wbudowaną możliwość wysyłania i odbierania logów za pomocą syslogu. Do hosta można wysyłać informacje o zdarzeniach także z maszyn pracujących pod kontrolą systemów Microsoft Windows poprzez aplikacje firm trzecich. Prosty syslog ma wady, wynikające z prostoty protokołu transmisji danych przy wykorzystaniu protokołu UDP czy braku weryfikacji integralności przesyłanych danych. "Serwer usługi syslog można łatwo unieruchomić, generując atak odmowy obsługi. Wtedy informacje zbierane z atakowanej maszyny będą niekompletne, co jest w stanie uniemożliwić nawet wykrycie włamania. Niezbędne są inne rozwiązania" - wyjaśnia Paweł Dawidek.

Zarejestrować sesję

Uzupełnieniem informacji pozyskanych z logów jest rejestrowanie aktywności. Wystarczy zastosować trzy rozwiązania: maszynę pośrednią, rejestrator pośredniczący lub agenta na maszynie docelowej. Maszyna pośrednia zwana stacją przesiadkową terminuje połączenia przychodzące, wymagając od użytkownika zainicjowania połączenia do maszyny docelowej, a sesja jest wtedy rejestrowana. To niewygodne dla użytkownika, skomplikowane w utrzymaniu bezpieczeństwa, niesie ryzyko przejęcia kontroli nad maszyną pośrednią, co skutkuje naruszeniem bezpieczeństwa wszystkich sesji przez nią przechodzących. Można też rejestrować sesję przez agenta instalowanego w docelowym systemie. Agent staje się częścią systemu, co może prowadzić do mniejszej stabilności samego systemu, a każda aplikacja niesie ryzyko naruszenia bezpieczeństwa serwera. Rejestracja sesji powinna się odbywać poza serwerem, by minimalizować ryzyko przejęcia kontroli nad systemem rejestracji w przypadku przejęcia kontroli nad maszyną.

Rejestrator po drodze

Aby w sposób transparentny rejestrować sesję bez instalacji oprogramowania na serwerze, należy mieć rozwiązanie, które deszyfruje sesję użytkownika. Do tego niezbędne jest pobranie kluczy prywatnych z serwera i wgranie ich na urządzenie, które dokonuje inspekcji sesji, przekazując połączenie między klientem a serwerem. "Metoda jest niewidoczna dla użytkownika, nie wymaga zmian na serwerze i nie wprowadza dodatkowego obciążenia CPU/sieć po stronie użytkownika ani serwera. Umożliwia rejestrację i odtworzenie całej sesji, wszystkich poleceń wydanych przez połączonego użytkownika, niezależnie od jego uprawnień" - mówi Paweł Dawidek.