Zarządzanie logami systemowymi (rsyslog) - centralny serwer logów

Red Hat 6.x / CentOS 6.x

Centralizacja przechowywania logów systemowych przynosi wiele korzyści, ale również i zagrożeń. Wysyłanie przez sieć plików mogących zawierać wrażliwe dane systemowe zawsze obarczona jest pewnym ryzykiem. Na szczęście rsyslog może być skonfigurowany, aby używał szyfrowanych transmisji danych, co znacząco podnosi bezpieczeństwo informacji.

Konfiguracja serwera rsyslog, który będzie wykorzystywał transmisję szyfrowaną wymaga doinstalowania jednego pakietu:

[root@rsyslog-server ~]# yum install gnutls-utils

Pakiet ten zawiera narzędzie certtool niezbędne do wygenerowania certyfikatów ssl na potrzeby naszej komunikacji.

Generowanie CA - centrum autoryzacji

Większe firmy zazwyczaj używają centralnego systemu autoryzacyjnego certyfikatów, i podpisanie certyfikatów poszczególnych serwerów jest zlecane do tych jednostek. Mniejsze firmy działają często na certyfikatach podpisywanych przez utworzone przez siebie centra certyfikacyjne, tzw. self-signed. W naszym przykładzie zajmiemy się rozwiązaniem kompleksowym, więc wymagającym rónież wygenerowania naszego centrum autoryzacyjnego dla pozostałych certyfikatów.

Certyfikatu CA wygenerowanego na naszym serwerze sysloga będziemy używać do podpisywania certyfikatów poszczególnych maszyn kontaktujących się z serwerem centralnym przy użyciu TLS.
Klucze prywatne serwerów, a szczególnie klucz prywatny CA nie powinny być udostępniane, dlatego warto umieścić je w katalogu z ograniczonym dostępem, np w /etc/pki/CA.

Generowanie centrum autoryzacji sprowadzi się do dwóch kroków:

* generowanie klucza prywatnego serwera centrum autoryzacji

[root@rsyslog-server ~]# cd /etc/pki/CA/
[root@rsyslog-server CA]# certtool --generate-privkey --outfile private/ca-key.pem
Generating a 2048 bit RSA private key...
[root@rsyslog-server CA]# ll private
-rw-------. 1 root root 1679 Sep 13 09:11 ca-key.pem

BARDZO WAŻNE. Pliku klucza prywatnego nie należy pod żadnym pozorem udostępniać! Osoba mająca do niego dostęp będzie mogła wygenerować i autoryzować certyfikaty podszywając się pod nasz serwer.

* generowanie certyfikatu CA (self-signed)

[root@rsyslog-server CA]# certtool --generate-self-signed --load-privkey private/ca-key.pem --outfile certs/ca.pem
Generating a self signed certificate...
Please enter the details of the certificate's distinguished name. Just press enter to ignore a field.
Country name (2 chars): PL
Organization name:
Organizational unit name:
Locality name:
State or province name:
Common name: rsyslog-server
UID:
This field should not be used in new certificates.
E-mail:
Enter the certificate's serial number in decimal (default: 1442129065):


Activation/Expiration time.
The certificate will expire in (days): 3650


Extensions.
Does the certificate belong to an authority? (y/N): y
Is this a TLS web client certificate? (y/N):
Is this also a TLS web server certificate? (y/N):
Enter the e-mail of the subject of the certificate:
Will the certificate be used for signing (required for TLS)? (y/N): y
Will the certificate be used for encryption (not required for TLS)? (y/N):
Enter the URI of the CRL distribution point:
X.509 Certificate Information:
        Version: 3
        Serial Number (hex): 55f524a9
        Validity:
                Not Before: Sun Sep 13 07:24:26 UTC 2015
                Not After: Wed Sep 10 07:24:30 UTC 2025
        Subject: C=PL,CN=rsyslog-server
        Subject Public Key Algorithm: RSA
                Modulus (bits 2048):
                        ce:ac:f1:c6:1a:fe:98:e0:4b:7e:4f:da:f1:91:4c:02
                        50:3b:29:7f:7e:a4:3c:d1:c2:30:3a:7f:78:8e:ab:fd
                        ea:6a:e1:79:e5:af:28:c2:ec:3a:c1:8a:3f:b3:d4:9d
                        88:0b:6d:76:21:a4:f2:3f:d6:e7:53:84:61:e7:3f:22
                        54:ee:db:66:64:91:54:ba:56:43:cd:58:49:bb:86:08
                        dd:0c:f0:99:5e:1e:52:2c:41:96:4f:ef:96:5e:dc:6c
                        19:13:b9:66:05:86:3a:71:25:7e:7b:82:73:ee:59:a1
                        83:14:84:c5:b0:11:42:8e:cf:2e:ab:71:dc:5f:a4:a0
                        db:50:f2:2f:f8:fe:78:7e:25:42:39:b5:46:bd:04:b5
                        5a:73:79:fe:ed:23:c9:62:8f:e8:cb:ae:79:62:a0:02
                        70:de:ee:78:15:2c:36:a2:70:61:9c:de:13:d9:67:31
                        a1:ab:eb:3a:74:94:7c:43:05:ee:25:12:07:43:20:c9
                        86:77:9a:72:71:56:c3:a7:61:a0:9a:db:2c:e3:14:fb
                        a1:f0:f6:8b:fd:fe:f0:98:5f:ad:41:08:a2:ca:c6:ae
                        cf:db:0a:35:85:6d:0b:1a:89:1c:54:fc:c3:0a:4d:be
                        60:a3:01:0e:3d:5e:74:43:56:0c:88:19:ce:17:66:c9
                Exponent (bits 24):
                        01:00:01
        Extensions:
                Basic Constraints (critical):
                        Certificate Authority (CA): FALSE
                Key Usage (critical):
                        Digital signature.
                Subject Key Identifier (not critical):
                        315478ae5bf71e519b702b2b82e9faa314aff2b3
Other Information:
        Public Key Id:
                315478ae5bf71e519b702b2b82e9faa314aff2b3

Is the above information ok? (Y/N): y


Signing certificate...

Nasz certyfikat będzie wykorzystywany jedynie do weryfikacji podpisu innych certyfikatów (autoryzowania ich), więc, żeby nie trzeba było zbyt często odnawiać kompletu certyfikatów warto podać dużą liczbę dni do wyexpirowania.
Certyfikat CA, jako podpisujący inne certyfikaty musi zostać rozdystrybuowany pomiędzy wszystkimi hostami, dla których świadczy usługą autoryzacyjną, oraz zostać dodany do zaufanych centrów autoryzacji na tych serwerach. Ścieżka do niego musi zostać wskazana w naszym pliku konfiguracyjnym rsyslog poprzez dyrektywę $DefaultNetstreamDriverCAFile - o tym poniżej.

Kreowanie certyfikatu serwera

Po wykreowaniu centrum autoryzacji, które będzie poświadczać autentyczność certyfikatów poszczególnych maszyn przejdźmy do wykreowania indywidualnego certyfikatu serwera rsyslog.
Tak jak w przypadku centrum CA należy pamiętać, aby nie udostępniać wygenerowanego klucza prywatnego nikomu.

Certyfikat rsyslog utworzymy w innym niż CA katalogu, mianowicie w /etc/pki/rsyslog.

Generowanie i podpisanie certyfikatu będzie przebiegało trójstopniowo:

* wygenerowanie klucza prywatnego serwera

[root@rsyslog-server rsyslog]# certtool --generate-privkey --outfile key.pem

Generating a 2048 bit RSA private key...

* na podstawie klucza prywatnego możemy wystąpić do naszego centrum autoryzacyjnego CA o wystawienie/pdpisanie certyfikatu naszego serwera. Realizujemy to poprzez wygenerowanie requestu certyfikatu:

[root@rsyslog-server rsyslog]# certtool --generate-request --load-privkey key.pem --outfile request.pem
Generating a PKCS #10 certificate request...
Country name (2 chars): PL
Organization name:
Organizational unit name:
Locality name:
State or province name:
Common name: rsyslog-server.my.domain
UID:
Enter a dnsName of the subject of the certificate:
Enter the IP address of the subject of the certificate:
Enter the e-mail of the subject of the certificate:
Enter a challenge password:
Does the certificate belong to an authority? (y/N):
Will the certificate be used for signing (DHE and RSA-EXPORT ciphersuites)? (y/N):
Will the certificate be used for encryption (RSA ciphersuites)? (y/N):
Is this a TLS web client certificate? (y/N):
Is this also a TLS web server certificate? (y/N):

Wszelkie odpowiedzi są opcjonalne, dlatego na tym etapie pozostały puste. Dane podamy podczas podpisywania certyfikatu przez CA, aczkolwiek, jeśli korzystamy z zewnętrznego CA podanie tych danych może być wymagane przez centrum autoryzacyjne.

* przygotowany w ten sposób request podpisujemy naszym centrum CA tworząc certyfikat serwera.
Warto pamiętać, że generowanie certyfikatu serwera wymagać będzie fizycznego dostępuu do klucza prywatnego centrum CA, dlatego wszystkie certyfikaty podpisywane są na maszynie serwera rsyslog, na którym to tworzyliśmy nasze CA.

[root@rsyslog-server rsyslog]# certtool --generate-certificate --load-request request.pem --outfile cert.pem --load-ca-certificate ../CA/certs/ca.pem --load-ca-privkey ../CA/private/ca-key.pem
Generating a signed certificate...
Enter the certificate's serial number in decimal (default: 1442133914):


Activation/Expiration time.
The certificate will expire in (days): 730


Extensions.
Do you want to honour the extensions from the request? (y/N):
Does the certificate belong to an authority? (y/N):
Is this a TLS web client certificate? (y/N): y
Is this also a TLS web server certificate? (y/N): y
Enter a dnsName of the subject of the certificate: rsyslog-server.my.domain
Enter a dnsName of the subject of the certificate:
Enter the IP address of the subject of the certificate: 
Will the certificate be used for signing (DHE and RSA-EXPORT ciphersuites)? (y/N):
Will the certificate be used for encryption (RSA ciphersuites)? (y/N):
X.509 Certificate Information:
        Version: 3
        Serial Number (hex): 55f5379a
        Validity:
                Not Before: Sun Sep 13 08:45:15 UTC 2015
                Not After: Tue Sep 12 08:45:18 UTC 2017
        Subject: C=PL,CN=rsyslog-server.my.domain
        Subject Public Key Algorithm: RSA
                Modulus (bits 2048):
                        a2:df:ee:0d:b9:1d:97:8c:bc:87:34:e9:0c:33:e9:c3
                        4c:a9:03:b2:10:44:90:69:38:4a:e1:6f:21:3b:c6:63
                        78:e4:1b:a6:f5:b5:71:22:60:4a:41:e5:67:de:f3:0a
                        dd:35:4a:e6:00:8e:5f:86:cc:14:05:1b:e8:21:34:c3
                        fe:3a:41:0b:9e:60:2a:73:73:6d:dd:29:c2:d3:f9:c5
                        5c:f2:49:17:64:e6:3e:d1:9e:85:23:38:46:25:fb:e4
                        9f:50:08:6f:a0:19:10:44:e6:8f:68:96:72:34:50:2e
                        fc:9f:ae:30:ed:26:6e:89:be:68:d1:6e:4d:cd:ae:e7
                        5e:46:5b:ce:0e:ca:fb:fd:52:fb:23:68:ba:87:a3:e6
                        0a:f9:1c:fd:1d:0e:1c:25:ed:76:3b:1d:a9:05:00:bd
                        c5:81:de:81:18:4f:82:ea:9c:8f:fc:22:89:18:66:64
                        25:93:fc:9f:51:f6:3c:6e:7d:ee:a4:2f:ec:57:b1:85
                        6c:f3:01:22:d8:3b:31:34:28:d8:3b:fa:dd:ef:2a:61
                        28:e2:2b:2d:ba:04:c8:7c:6b:0c:43:2c:15:a8:07:6e
                        3c:22:34:3d:ce:24:c8:60:f6:e4:96:dd:ca:25:46:fb
                        98:b9:5f:0d:4e:88:c9:68:ff:73:2c:e8:7b:2a:c4:11
                Exponent (bits 24):
                        01:00:01
        Extensions:
                Basic Constraints (critical):
                        Certificate Authority (CA): FALSE
                Key Purpose (not critical):
                        TLS WWW Client.
                        TLS WWW Server.
                Subject Alternative Name (not critical):
                        DNSname: rsyslog-server.my.domain
                Subject Key Identifier (not critical):
                        759a9b9363d64af2b97742d4aa0d0f0584fb5c0f
                Authority Key Identifier (not critical):
                        b7539df12f3859ff625c5b67756bb3e74bacc0c3
Other Information:
        Public Key Id:
                759a9b9363d64af2b97742d4aa0d0f0584fb5c0f

Is the above information ok? (Y/N): y


Signing certificate...

Certyfikat serwera, zależnie od polityk bezpieczeństwa może być wystawiony na różne okresy czasowe. W naszym przypadku będą to 2 lata.

Słowo wyjaśnienia należy się również odnośnie pozycji Enter a dnsName of the subject of the certificate oraz Enter the IP address of the subject of the certificate.
Każdy serwer może posiadać kilka wpisów DNS pod którymi będzie rozpoznawalny w sieci. Nasz certyfikat może być wystawiony w taki sposób, aby przechodził weryfikację dla każdej z nich, a to za sprawą zwielokrotnienia pytania o nazwę. Certtool będzie pytał o nazwę dnsName, aż do podania w odpowiedzi pustego entera, co widać na przykładzie powyżej.
Podawanie adresu IP serwera ogranicza nam walidację naszego certyfikatu do tego właśnie adresu. W przypadku zmiany adresacji serwera wymagane będzie wygenerowanie i podpisanie nowego certyfikatu.

Konfiguracja rsyslog server

Poprawne wygenerowanie certyfikatów pozwoli nam dokonywać transferu naszych logów w sposób bezpieczny. Po ich wygenerowaniu pozostaje nam konfiguracja samej usługi rsyslogd, która będzie nasze logi zbierać, oraz doinstalowanie pakietu zawirającego niezbędną do tego bibliotekę.

[root@syslog-server ~]# yum install rsyslog-gnutls

Sama konfiguracja serwera sprowadza się do zdefiniowania ścieżek do certyfikatów serwera, oraz definicji portu nasłuchu w pliku /etc/rsyslog.conf. Poniższe wpisy dodajemy w dowolnym miejscu pliku (np. na początku). Warto zaznaczyć, że nie kolidują one z już obecnymi definicjami, więc nie ma potrzeby ich usuwania.

[root@syslog-server ~]# vi /etc/rsyslog.conf
...
$DefaultNetstreamDriver gtls

$DefaultNetstreamDriverCAFile /etc/pki/CA/certs/ca.pem #sciezka do certyfikatu centrum autoryzacji
$DefaultNetstreamDriverCertFile /etc/pki/rsyslog/cert.pem #sciezka do certyfikatu rsyslog serwera
$DefaultNetstreamDriverKeyFile /etc/pki/rsyslog/key.pem #sciezka do klucza prywatnego serwera

$ModLoad imtcp
$InputTCPServerStreamDriverMode 1
$InputTCPServerStreamDriverAuthMode x509/name
$InputTCPServerStreamDriverPermittedPeer *.my.domain
$InputTCPServerRun 6514 #port nasluchu uslugi
...

Dyrektywa $InputTCPServerStreamDriverAuthMode x509/name oznacza, że hosty-klienci będą musiały autoryzować się do serwera centralnego swoją nazwą z użyciem certyfikatów. Możliwa jest również komunikacja anonimowa - wtedy należy zamienić x509/name na anon.
W przypadku autoryzacji po nazwie konieczne jest zdefiniowanie hostów/domeny hostów, które mogą przesyłać logi do naszego serwera. Służy do tego dyrektywa $InputTCPServerStreamDriverPermittedPeer *.my.domain. Może ona występować kilkukrotnie, a jako wartość przyjmować konkretne nazwy DNS hostów czy adresy ip maszyn.

Po dokonaniu zmian w konfiguracji należy zrestartować serwis, oraz zweryfikować, czy zdefiniowany port nasłuchuje:

[root@syslog-server ~]# service rsyslog restart
Shutting down system logger:                               [  OK  ]
Starting system logger:                                    [  OK  ]
[root@syslog-server ~]# ss -an | grep 6514
LISTEN     0      25                       :::6514                    :::*
LISTEN     0      25                        *:6514                     *:*

W przypadku aktywnego firewalla należy otworzyć ruch dla tego portu:

[root@syslog-server ~]# iptables -I INPUT 5 -p tcp -m tcp --dport 6514 -j ACCEPT
[root@syslog-server ~]# service iptables save
iptables: Saving firewall rules to /etc/sysconfig/iptables:[  OK  ]

Troubleshooting

Usługa rsyslog nie podnosi się po restarcie, w /var/log/messages pojawia się wpis:

syslog-server rsyslogd-2066: could not load module '/lib64/rsyslog/lmnsd_gtls.so', dlopen: /lib64/rsyslog/lmnsd_gtls.so: cannot open shared object file: No such file or directory

Oznacza to, że nie mamy zainstalowanej paczki rsyslog-gnutls. Należy ją doinstalować np. yum install rsyslog-gnutls

TIPS

Dla mniej "pamiętliwych" przykładowa konfiguracja oraz proces tworzenia CA i certyfikatów są dostępne w systemowej dokumentacji pakietu rsyslog w plikach /usr/share/doc/rsyslog-5.8.10/rsyslog_tls.html, /usr/share/doc/rsyslog-5.8.10/tls_cert_ca.html czy /usr/share/doc/rsyslog-5.8.10/tls_cert_server.html. Należy jednak zwrócić uwagę na fakt, że dokumentacja podaje jako przykładowy port działania usługi 10514, a domyślnym portem jest 6514. W przypadku zmiany portu domyślnego może zajść konieczność zmiany portu w selinux.