Configuring rsyslog to collect logs over the network via an encrypted connection
On Habré there are several articles on rsyslog, but there was not one describing how to configure the interaction between the client and the server through a secure connection. I'll try to fix this moment.
Suppose we have several servers that have access to the Internet and do not have any private network between them. At one point, we are bored of climbing each of them in turn, and we decide to set up a centralized log server. Since the data will be transmitted via the Internet, it is necessary to protect them by transmitting them via TLS.
Our test machines are CentOS 6.7, we will train with rsyslog 7.x. rsyslog server (rslserver) will be called server.com, and rsyslog client (rslclient) will be called example.com.
We will install rsyslog from their official repository (http://www.rsyslog.com/rhelcentos-rpms/).
')
The most dreary part. We need to generate a pair of CA keys and on request + a pair of keys for the server and for each client. All security. For security, generation should be done not on the server / client, but on a separate machine.
The heart of our security. We generate private key:
We generate the self-signed certificate:
Do not forget that with the help of ca-key.pem an attacker can easily replace the certificate with his own, so you need to store it in a safe place.
We generate the private key for the rsyslog server:
We generate certificate request. Rsyslog checks the authorization on the field of the X509 / name certificate, so in the common name it is better to specify the host FQDN.
We generate the certificate from request'a.
Theoretically, wildcards can be used in common name and dns name, generating one certificate for several hosts at once, but it is better not to do this. After generating the certificate, the request can be deleted.
For the client, all the steps are the same as for the server: we generate a key, then a request, then a certificate. Naturally, the file names must be replaced with rslserver with rslclient, and the common name / dns name with server.com with example.com.
The CentOS package creates the / etc / pki / rsyslog / directory, which is a sin not to use. We copy the ca.pem, rslserver-cert.pem, rslserver-key.pem files to the server and the ca.pem, rslclient-cert.pem, rslclient-key.pem files to the server.
We get something like:
Add to the top /etc/rsyslog.conf, immediately after loading the imuxsock and imklog modules:
From the names of directives everything seems to be clear: we increase the limit of open files, indicate that the stream goes through TLS, show the keys to decrypt it, and then pass the stream to the imtcp module that checks the authorization using the x509 / name field, comparing with the allowed peer.
If we want to add logs from each client to a separate file, then at the end of /etc/rsyslog.conf (or in some of the files in /etc/rsyslog.d) we need to specify the rsyslog parameters:
It's simple. First, we set a dynamic template for the file name, and then we write to these files everything that comes from “tcp-tls” (the name is given above in input). After we have created a record, we stop processing this message (stop directive) so that it does not fall into the “common pot”.
On the client is still easier. In the /etc/rsyslog.d/tls.conf file, we indicate that the network stream should be driven via TLS with such certificates, checking x509 / name for the correspondence given. The last line indicates that over the network, via TCP (@@) to the address of server.com, we send only the records from the kernel (kern).
Actually, that's all. Do not forget to open the ports on the firewall and restart rsyslog on the server and client. The preparation of the manual used the official rsyslog documentation and a post from the Kristian Reese blog .
Suppose we have several servers that have access to the Internet and do not have any private network between them. At one point, we are bored of climbing each of them in turn, and we decide to set up a centralized log server. Since the data will be transmitted via the Internet, it is necessary to protect them by transmitting them via TLS.
Our test machines are CentOS 6.7, we will train with rsyslog 7.x. rsyslog server (rslserver) will be called server.com, and rsyslog client (rslclient) will be called example.com.
Installation
We will install rsyslog from their official repository (http://www.rsyslog.com/rhelcentos-rpms/).
')
Server
wget http://rpms.adiscon.com/v7-stable/rsyslog.repo -O /etc/yum.repos.d/rsyslog.repo yum install gnutls-utils rsyslog rsyslog-gnutls mv /etc/rsyslog.conf.rpmnew /etc/rsyslog.conf # - , service rsyslog restart less /var/log/messages # rsyslog Customer
wget http://rpms.adiscon.com/v7-stable/rsyslog.repo -O /etc/yum.repos.d/rsyslog.repo yum install rsyslog rsyslog-gnutls #gnutls-utils mv /etc/rsyslog.conf.rpmnew /etc/rsyslog.conf # - , service rsyslog restart less /var/log/messages # rsyslog Customization
Certificate Generation
The most dreary part. We need to generate a pair of CA keys and on request + a pair of keys for the server and for each client. All security. For security, generation should be done not on the server / client, but on a separate machine.
CA
The heart of our security. We generate private key:
[root@sysadmin ~]# certtool --generate-privkey --outfile ca-key.pem Generating a 2048 bit RSA private key... We generate the self-signed certificate:
[root@sysadmin ~]# certtool --generate-self-signed --load-privkey ca-key.pem --outfile 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): RU Organization name: myorg Organizational unit name: Locality name: State or province name: Common name: cacert UID: This field should not be used in new certificates. E-mail: Enter the certificate's serial number in decimal (default: 1395159808): Activation/Expiration time. The certificate will expire in (days): 3650 Extensions. Does the certificate belong to an authority? (y/N): y Path length constraint (decimal, -1 for no constraint): 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: email@admin.com Will the certificate be used to sign other certificates? (y/N): y Will the certificate be used to sign CRLs? (y/N): Will the certificate be used to sign code? (y/N): Will the certificate be used to sign OCSP requests? (y/N): Will the certificate be used for time stamping? (y/N): Enter the URI of the CRL distribution point: X.509 Certificate Information: [...] Is the above information ok? (Y/N): y Signing certificate... [root@sysadmin ~]# ls -l total 136 -rw------- 1 root root 1675 Mar 18 11:12 ca-key.pem -rw-r--r-- 1 root root 1318 Mar 18 12:24 ca.pem [root@sysadmin ~]# Do not forget that with the help of ca-key.pem an attacker can easily replace the certificate with his own, so you need to store it in a safe place.
Server
We generate the private key for the rsyslog server:
[root@sysadmin ~]# certtool --generate-privkey --outfile rslserver-key.pem --bits 2048 Generating a 2048 bit RSA private key... We generate certificate request. Rsyslog checks the authorization on the field of the X509 / name certificate, so in the common name it is better to specify the host FQDN.
[root@sysadmin ~]# certtool --generate-request --load-privkey rslserver-key.pem --outfile request.pem Generating a PKCS #10 certificate request... Country name (2 chars): RU Organization name: myorg Organizational unit name: Locality name: State or province name: Common name: server.com UID: Enter a dnsName of the subject of the certificate: server.com 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): 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): y Is this also a TLS web server certificate? (y/N): y We generate the certificate from request'a.
[root@sysadmin ~]# certtool --generate-certificate --load-request request.pem --outfile rslserver-cert.pem --load-ca-certificate ca.pem --load-ca-privkey ca-key.pem Generating a signed certificate... Enter the certificate's serial number in decimal (default: 1395162401): Activation/Expiration time. The certificate will expire in (days): 3650 Extensions. Do you want to honour the extensions from the request? (y/N): Does the certificate belong to an authority? (y/N): 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: server.com 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: [...] Is the above information ok? (Y/N): y Signing certificate... [root@sysadmin ~]# rm -f request.pem Theoretically, wildcards can be used in common name and dns name, generating one certificate for several hosts at once, but it is better not to do this. After generating the certificate, the request can be deleted.
Customer
For the client, all the steps are the same as for the server: we generate a key, then a request, then a certificate. Naturally, the file names must be replaced with rslserver with rslclient, and the common name / dns name with server.com with example.com.
Copy files
The CentOS package creates the / etc / pki / rsyslog / directory, which is a sin not to use. We copy the ca.pem, rslserver-cert.pem, rslserver-key.pem files to the server and the ca.pem, rslclient-cert.pem, rslclient-key.pem files to the server.
We get something like:
[root@server.com]# ls -l1 /etc/pki/rsyslog/ -rw-r--r-- 1 root root 1172 Feb 8 20:19 ca.pem -rw-r--r-- 1 root root 1294 Feb 8 21:13 rslserver-cert.pem -rw-r--r-- 1 root root 1675 Feb 8 21:11 rslserver-key.pem [root@example.com]# ls -l1 /etc/pki/rsyslog/ -rw-r--r-- 1 root root 1172 Feb 8 20:21 ca.pem -rw-r--r-- 1 root root 1273 Feb 8 20:21 rslclient-cert.pem -rw------- 1 root root 1675 Feb 8 20:21 rslclient-key.pem Configs
Server
Add to the top /etc/rsyslog.conf, immediately after loading the imuxsock and imklog modules:
################### REMOTE LOGGING BEGIN ######################### # Increase the amount of open files rsyslog is allowed, which includes open tcp sockets # This is important if there are many clients. # http://www.rsyslog.com/doc/rsconf1_maxopenfiles.html $MaxOpenFiles 2048 # make gtls driver the default $DefaultNetstreamDriver gtls # certificate files generated on RHEL6 and stored in /root $DefaultNetstreamDriverCAFile /etc/pki/rsyslog/ca.pem $DefaultNetstreamDriverCertFile /etc/pki/rsyslog/rslserver-cert.pem $DefaultNetstreamDriverKeyFile /etc/pki/rsyslog/rslserver-key.pem # Provides TCP syslog reception # for parameters see http://www.rsyslog.com/doc/imtcp.html module(load="imtcp" MaxSessions="2000" StreamDriver.mode="1" StreamDriver.authmode="x509/name" PermittedPeer="example.com" ) input(type="imtcp" port="10514" name="tcp-tls") ################### REMOTE LOGGING END ######################### From the names of directives everything seems to be clear: we increase the limit of open files, indicate that the stream goes through TLS, show the keys to decrypt it, and then pass the stream to the imtcp module that checks the authorization using the x509 / name field, comparing with the allowed peer.
If we want to add logs from each client to a separate file, then at the end of /etc/rsyslog.conf (or in some of the files in /etc/rsyslog.d) we need to specify the rsyslog parameters:
# This one is the template to generate the log filename dynamically, depending on the client's hostname. $template FileForRemote,"/var/log/remote/%fromhost%/syslog.log" if ($inputname contains "tcp-tls") then { ?FileForRemote stop } It's simple. First, we set a dynamic template for the file name, and then we write to these files everything that comes from “tcp-tls” (the name is given above in input). After we have created a record, we stop processing this message (stop directive) so that it does not fall into the “common pot”.
Customer
On the client is still easier. In the /etc/rsyslog.d/tls.conf file, we indicate that the network stream should be driven via TLS with such certificates, checking x509 / name for the correspondence given. The last line indicates that over the network, via TCP (@@) to the address of server.com, we send only the records from the kernel (kern).
# make gtls driver the default $DefaultNetstreamDriver gtls # certificate files $DefaultNetstreamDriverCAFile /etc/pki/rsyslog/ca.pem $DefaultNetstreamDriverCertFile /etc/pki/rsyslog/rslreverb-cert.pem $DefaultNetstreamDriverKeyFile /etc/pki/rsyslog/rslreverb-key.pem #### GLOBAL DIRECTIVES #### # Use default timestamp format $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat # gtls Network Stream Driver # x509/name - certificate validation and subject name authentication # http://www.rsyslog.com/doc/ns_gtls.html $ActionSendStreamDriverAuthMode x509/name $ActionSendStreamDriverPermittedPeer server.com $ActionSendStreamDriverMode 1 # run driver in TLS-only mode kern.* @@server.com:10514 Actually, that's all. Do not forget to open the ports on the firewall and restart rsyslog on the server and client. The preparation of the manual used the official rsyslog documentation and a post from the Kristian Reese blog .
Source: https://habr.com/ru/post/276847/
All Articles