Podstawy bezpieczeństwa, czyli jak sensownie logować zdarzenia systemowe

dodał 4 grudnia 2017 o 07:19 w kategorii HowTo  z tagami:
Podstawy bezpieczeństwa, czyli jak sensownie logować zdarzenia systemowe

Wiele razy w naszej karierze trafialiśmy na sytuacje, w których wiadomo było, że stało się coś złego, ale brak było możliwości wyjaśnienia przebiegu zdarzeń – głównie ze względu na brak logów. Czas ten problem rozwiązać.

Mamy nadzieję, że wszystko logujecie na serwerach. Czy musimy tłumaczyć jak ważne jest logowanie? Logowanie może być wyjątkowo pomocne w kwestii ustalania szczegółów incydentu. Jeśli incydent będzie miał miejsce to warto go przeanalizować – tylko jak analizować incydent jeśli system nie zbierał żadnych logów lub logi z serwera zostały usunięte? Rozwiązaniem może być przesyłanie wszystkich zdarzeń do centralnego serwera (i zabezpieczenie go zgodnie z naszymi wcześniejszymi poradnikami).

Artykuł pod patronatem Aruba Cloud

We współpracy z firmą ArubaCloud pokazaliśmy Wam, jak postawić swój serwer backupów, jak skonfigurować własny serwer VPN i podłączyć do niego komputer, telefony komórkowe oraz domowy ruter a także jak schować się przed cenzurą sieci i jak zacząć serwer zabezpieczać, jak postawić swój własny zdalny pulpitswój serwer WWWjak monitorować zmiany w plikachjak zablokować reklamy na komórce, jak skonfigurować bezpieczną kopię zapasowąjak zabezpieczyć logowanie do serwera za pomocą jednorazowych tokenów  lub za pomocą klucza Yubikey a także jak monitorować swoje systemy w dwóch odsłonach oraz jak postawić swój serwer Jabbera.

Jeśli nie macie jeszcze swojego własnego serwera, to jest to dobra okazja by się w taki wyposażyć. Aruba oferuje dwa miesiące korzystania ze swojego podstawowego serwera gratis – a po zakończeniu promocji będzie on Was kosztował zaledwie 4 złote miesięcznie. Co więcej Aruba ma już serwerownię w Warszawie. Instrukcję jak krok po kroku skorzystać z promocji i uruchomić swój serwer znajdziecie w tym artykule. Jeśli macie już swój serwer – to zapraszamy do lektury kolejnych akapitów.

Zbieranie logów na dedykowanym serwerze

Poniżej znajdziecie zapis całej konfiguracji w formie filmu – a pod nim także wersję tekstową.

Do poprawnego wykonania zadania będziemy potrzebować trzech maszyn wirtualnych:

  • CA – jak nazwa wskazuje będzie to urząd certyfikacji – na tym serwerze będziemy tworzyli certyfikaty,
  • syslog-central – serwer na którym będzie uruchomiona usługa rsyslog. Serwer ten będzie przyjmował połączenia od „klientów”,
  • syslog-client – serwer, który będzie wysyłał zdarzenia do serwera centralnego.

Na serwerze w syslog-central uruchomimy usługę rsyslog, która będzie nasłuchiwała na porcie 10514/tcp. Do centralnego serwera podłączymy jednego „klienta” – syslog-client, który będzie wysyłał zdarzenia za pomocą protokołu TLS.

Bez urzędu certyfikacji…

… się nie uda. Urzędy certyfikacji CA (ang. Certification Authority) odpowiedzialne są za poświadczanie tożsamości  na zasadzie „Tak, ta osoba jest tym, za kogo się podaje, a my – ośrodek certyfikacji – potwierdzamy to”. Certyfikat ten musi być zaufany przez wszystkie serwery, które będą łączyły się do centralnego serwera rsyslog. Klucz prywatny musi być dobrze chroniony i nie powinien być przekazywany osobom trzecim. Sam certyfikat może (i musi) być rozpowszechniany.

Choć tworzenie certyfikatów oraz idea PKI może przyprawiać o ból głowy, wspomożemy się narzędziem certtool które ułatwi nam proces utworzenia odpowiednich certyfikatów. Program certtool znajduje się w pakiecie gnutls-utils (CentOS/RedHat).

Na serwerze CA instalujemy wspomniany pakiet:

Tworzymy katalog /etc/ssl/rsyslog/ w który będziemy przechowywać certyfikaty.

Generujemy klucz prywatny CA o długości 2048 bitów:

Następnie utworzymy klucz publiczny dla serwera „CA”:

Większość opcji należy ustawić według własnego uznania, szczególną uwagę należy zwrócić na:

Podsumowanie:

Utworzyliśmy dwa pliki:

  • ca-key.pem – klucz prywatny, nie rozpowszechniamy tego pliku,
  • ca.pem – klucz publiczny.

Klucze… wszędzie klucze

Każdy serwer będzie posiadał oddzielną parę kluczy. W zależności od tego ile chcemy podłączyć serwerów, tyle certyfikatów musimy wygenerować – jedną parę na każdy serwer.

Będąc zalogowanym na serwerze CA, generujemy parę kluczy dla serwera syslog-central:

W celu uzyskania certyfikatu od CA należy zgłosić żądanie wystawienia certyfikatu:

Podobnie jak przy CA – poszczególne pola wypełniamy według naszego uznania zwracając uwagę na:

Aby utworzyć klucz na podstawie żądania wydajemy polecenie:

Utworzyliśmy dwa pliki:

  • syslog-central-cert.pem – klucz publiczny,
  • syslog-central-key.pem – klucz prywatny.

Bazując na powyższym opisie generujemy kolejną parę kluczy, tym razem dla serwera syslog-client. Powtarzamy kroki opisane wyżej, zmieniając nazwę pliku:

Utworzyliśmy kolejne dwa pliki:

  • syslog-client-cert.pem – klucz publiczny,
  • syslog-client-key.pem – klucz prywatny.

Bezpiecznie przesyłamy klucze

Na serwerze syslog-central oraz syslog-client tworzymy katalog /etc/ssl/rsyslog/ do którego prześlemy odpowiednie klucze:

Z serwera CA przesyłamy klucz ca.pem oraz klucz prywatny i publiczny dla serwera syslog-central:

Nie zapominajmy o serwerze syslog-client:

Ostatnie szlify

Sewer syslog-central:

Na serwerze syslog-central tworzymy plik /etc/rsyslog.d/tls.conf z następującą zawartością:

Restartujemy usługę rsyslog:

Sprawdzamy czy usługa rsyslog nasłuchuje na porcie 10514:

Serwer syslog-client:

Na serwerze syslog-client tworzymy plik /etc/rsyslog.d/tls.conf z następującą zawartością:

Restartujemy usługę rsyslog:

Na serwerze syslog-client wysyłamy przykładowy komunikat poleceniem:

a na serwerze syslog-central sprawdzamy, czy komunikat pojawił się w logach:

Tak właściwie po co mi to?

Jeśli nie macie centralnego logowania to jak radzicie sobie z logowaniem zdarzeń? Jaką macie pewność, że logi nie zostały zmodyfikowane przez nieuprawnioną osobę? Podzielcie się w komentarzach z jakich rozwiązań korzystacie (nawet komercyjnych ;) ).