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

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:

# yum install gnutls-utils

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

# mkdir -p /etc/ssl/rsyslog/

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

# certtool --generate-privkey --outfile ca-key.pem
Generating a 2048 bit RSA private key...

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

# certtool --generate-self-signed --load-privkey ca-key.pem --outfile ca.pem

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

Generating a self signed certificate...
Common name: CA.arubacloud.pl
The certificate will expire in (days): 3650 #uwaga! certyfikat ma ważność 10 lat.

Does the certificate belong to an authority? (y/N): Y
Will the certificate be used to sign other certificates? (y/N): Y
Will the certificate be used to sign CRLs? (y/N): Y
Is the above information ok? (y/N): Y

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:

# certtool --generate-privkey --outfile syslog-central-private.pem

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

# certtool --generate-request --load-privkey syslog-central-private.pem --outfile request-central.pem

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

Common name: syslog-central.arubacloud.pl
Is this a TLS web client certificate? (y/N): y
Is this also a TLS web server certificate? (y/N): y

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

# certtool --generate-certificate --load-request request-central.pem --outfile syslog-central-cert.pem --load-ca-certificate ca.pem --load-ca-privkey ca-key.pem
 Is this a TLS web client certificate? (Y/N): y
 Is this also a TLS web server certificate? (Y/N): y
 Enter the dnsName of the subject of the certificate: syslog-central.arubacloud.pl
 Is the above information ok? (Y/N): y

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:

# certtool --generate-privkey --outfile syslog-client-private.pem
# certtool --generate-request --load-privkey syslog-client-private.pem --outfile request-client.pem
# certtool --generate-certificate --load-request request-client.pem --outfile syslog-client-cert.pem --load-ca-certificate ca.pem --load-ca-privkey ca-key.pem

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:

# mkdir /etc/ssl/rsyslog/

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

# scp {ca.pem,syslog-central-*.pem} root@syslog-central:/etc/ssl/rsyslog/

Nie zapominajmy o serwerze syslog-client:

# scp {ca.pem,syslog-client-*.pem} root@syslog-client:/etc/ssl/rsyslog/

Ostatnie szlify

Sewer syslog-central:

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

$DefaultNetstreamDriver gtls

# pełne ścieżki do certyfikatów
$DefaultNetstreamDriverCAFile /etc/ssl/rsyslog/ca.pem # certyfikat CA
$DefaultNetstreamDriverCertFile /etc/ssl/rsyslog/syslog-central-cert.pem # klucz publiczny
$DefaultNetstreamDriverKeyFile /etc/ssl/rsyslog/syslog-central-private.pem # klucz prywatny
$ModLoad imtcp
$InputTCPServerStreamDriverAuthMode x509/name
$InputTCPServerStreamDriverMode 1 # tylko TLS
$InputTCPServerStreamDriverPermittedPeer *.arubacloud.pl
$InputTCPServerRun 10514 # nasłuchujemy na porcie 10514

Restartujemy usługę rsyslog:

# service rsyslog restart

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

# netstat -a |grep 10514
tcp 0 0 0.0.0.0:10514 0.0.0.0:* LISTEN

Serwer syslog-client:

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

$DefaultNetstreamDriver gtls

# pełne ścieżki do certyfikatów
$DefaultNetstreamDriverCAFile /etc/ssl/rsyslog/ca.pem # certyfikat CA
$DefaultNetstreamDriverCertFile /etc/ssl/rsyslog/syslog-client-cert.pem # klucz publiczny
$DefaultNetstreamDriverKeyFile /etc/ssl/rsyslog/syslog-client-private.pem # klucz prywatny
$DefaultNetstreamDriver gtls
$ActionSendStreamDriverMode 1 # wymagany TLS
$ActionSendStreamDriverAuthMode x509/name
$ActionSendStreamDriverPermittedPeer *.arubacloud.pl
*.* @@(o)syslog-central:10514 # wysyłaj wszystkie zdarzenia

Restartujemy usługę rsyslog:

# service rsyslog restart

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

# logger "123 test"

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

# tail -f /var/log/messagess

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 ;) ).