04.12.2017 | 07:19

avatar

krystian

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:

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

Powrót

Komentarze

  • avatar
    2017.12.04 09:39 AlexP

    Log Analytics od Microsoftu mi ogarnia co trzeba, a jak logów nie jest więcej niż 500MB dziennie to się mieszczę w darmowym tierze ;)

    Odpowiedz
  • avatar
    2017.12.04 09:50 janmarian

    Dobry pomysl z PKI, ja do tej pory spinalem serwery VPNem i w ten sposob zapisuje logi.

    Odpowiedz
  • avatar
    2017.12.04 15:31 Piotr

    Ok, a co jeśli mam tylko jedną maszynę?

    Odpowiedz
    • avatar
      2017.12.05 13:10 janmarian

      mozesz logi na maila wysylac

      Odpowiedz
  • avatar
    2017.12.04 16:49 bbb

    Drugi scp mały błąd: root@syslog-central, powinno być root@syslog-client :)

    Odpowiedz
    • avatar
      2017.12.04 17:44 Krystian

      Faktycznie literówka, dzięki :)

      Odpowiedz
  • avatar
    2017.12.04 17:34 Nyuu

    Dwużyłowy UART

    Odpowiedz
  • avatar
    2017.12.04 21:15 S.J.

    Dla całej tej infrastruktury zabrakło jednak wykończenia. Co jakiś czas z centralnego serwera logów pliki logów powinny być odsyłane (najlepiej po jakimś vpn-ie) do np. zewnętrznego urządzenia jakim jest nasz komputer – po tej operacji trzeba (np. jakimś skryptem automatycznym) bezwzględnie czyścić te logi z CA w celu uniknięcia a) zwiększonego ryzyka przechwycenia całej bazy logów naszej odległej/lokalnej/itd. sieci/maszyn/itd. b) szybkiego zapełniania się tych tanich vps-ików za 4 zeta – nie oszukujmy się, jak jest porada dla określonego rozwiązania z aruba, to raczej nikt nie będzie brnął w dodatkowe koszta. W końcu nie każdy musi to robić z rozmachem setek maszyn na poziomie pół lub w pełni profesjonalnym – wtedy na pewno będzie go stać na profesjonalne narzędzia do tego.

    Odpowiedz
  • avatar
    2017.12.06 10:48 gosc

    Ja zastanawialem sie nad domowym sposobem:

    1. Zbieranie ostrzezen = „logwatch”

    Niestety logwatch choc daje duzo podstawowych info,
    to nie wylapie np. typu ataku z logow, albo skonfigurowac tego jeszcze nie umiem. Moral z tego ze jesli zauwaze cos podejrzanego musze recznie przegladac logi ( np. z serwera. )
    W przyszlosci moze warto bedzie to zamienić na „suricata”

    2. Stworzenie serwera poczty
    Dzieki temu bede mógł wybierać co wysłać i kiedy.

    3. Napisanie skryptu który
    – co jakiś czas dziennie bedzie
    otwieral zapore dla serwera poczty ( oczywiscie dla danego IP )
    niestety bedzie musial otworzyc takze zapore dla skryptu lub kienta który pobierze z serwera zaszyfrowany plik z IP, jesli bedzie nie aktualny lub nie znajdzie, nie wysle. Gdybym mial stale IP bylo by prosciej, bo wtedy nie musialbym pobierać aktualne IP.
    Mozna by tez spróbować dodać „podwójną weryfikację”
    – i wysylal logi na poczte wlasciciela.
    – logi mozna dowolnie szyfrować
    – nie udane wyslanie takze mozna logowac

    4. Skonfigurowanie
    – swojej zapory dla zmiennego IP,
    – swojego klienta poczty
    – skryptu do pobierania i wysylania swojego IP w postaci zaszyfrowanej

    W poradniku na samej gorze
    – jest o tyle lepiej że do odbiorcy trafia caly log.
    Nie jestem zwolennikiem otwierania portów na stałe, ale jeśli zaporę ustawiłeś otwartą tylko dla określonego IP, to powinno być bezpiecznie.
    – W twoim przypadku logi prawdopodobnie moga byc odczytywane tylko przez administratora ( nie wiem, zgaduję )
    A w moim przez uzytkownika, klienta poczty. W przypadku smieci, to bez roznicy, ale nigdy nie wiadomo co tam sie trafi.
    Moze znajde jakis sposob przez ssh i scp skryptem …
    – poza tym przydalo by sie jakies zabezpieczenie – informacja, jesli jakis log przypadkiem do Ciebie nie trafi. ( w postaci np. skryptu który przejzy log pod kątem czasu, czy wiadomosci informujacej ze serwer wciaz zyje ), no chyba ze o czyms zapomnialem.

    Odpowiedz
  • avatar
    2017.12.07 17:37 Mateusz

    Ściema z tym Aruba Cloud. Najpierw 3 dni czekałem na kod vouchera, a teraz nie mogę utworzyć żadnego serwera VPS. Wyskakuje błąd: Wystąpił błąd, proszę spróbować później. Helpdesk odzywa się po pół dnia, albo każe pisać maile gdzie indziej. Zaproponowali, żebym założył serwer w innym DC – co z tego, jak tam też nie działa? Partacze i tyle. Wolę nawet nie myśleć, bo by było gdyby nastąpiła jakaś awaria…

    Aruba Cloud? Nie polecam!

    Odpowiedz
    • avatar
      2017.12.08 12:30 Stefan

      Ja nawet kodu nigdy nie dostałem, próbowałem kilka razy… Wole zapłacić pare dolarów za AWS :P

      Odpowiedz

Zostaw odpowiedź

Jeśli chcesz zwrócić uwagę na literówkę lub inny błąd techniczny, zapraszamy do formularza kontaktowego. Reagujemy równie szybko.

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

Komentarze