RELP

RSyslog Windows Agent 3.3 Released

Adiscon is proud to announce the 3.3 release of RSyslog Windows Agent.

This is a bugfixing release with minor feature update.

Most importantly, the Adiscon SNMP MIB now supports messages sizes up to 64k (previous limit was 255 characters). The OpenSSL Library has been updated to 1.0.2h. Bugs were fixed primarily in RELP and syslog forwarding processing. For details please see the change log.

Detailed information can be found in the version history below.

Build-IDs: Service 3.3.152, Client 3.3.235

Features

  • Components:
    • OpenSSL library updated to 1.0.2h.
  • Adiscon SNMP Mib:
    • Changed DisplayString limit from 255 characters to 65536. Now, strings above 255 characters can be send using the adiscon mibs.

Bugfixes

  • Send Syslog Action:
    • Fixed an issue with the “Disable processing, forward as it is” Option. RawSyslogMsg property is used instead of msg property.
  • Send Relp Action:
    • Fixed an issue in the Session Close shutdown procedure which could lead to leaking sessions on Relp Servers.
    • Send Relp Action: Fixed an issue setting a proper status on failure.
    • Fixed a problem handling socket failures.
  • Event Monitor V2:
    • Dynamic properties could break XML format if they contained spaces in their name. Spaces and control characters are now properly replaced with underscores.
  • Relp Listener:
    • Fixed Socketsystem startup if only one Relp Listener Service was configured without any other network related services.
  • Syslog Server:
    • Fixed an issue relaying the priority / facility properties on Syslog Forward. The prifac property was not properly recreated if the message source was Syslog.
    • Fixed an issue with RFC5424 header parsing which partially parsed invalid formatted syslog messages. This broke the original message.
    • Fixed a parsing issue (TCP Protocol only) when the syslog header was missing. When the first characters were a number, TCP Syslog tried to detect octet framing. This failed but the beginning characters of the message were lost. Also octet framing was not disabled resulting in unexpected endings of the message.
    • Fixed an issue with RFC 3164 Syslog Header parsing when “take syslog source from msg” is enabled.
  • Property Replacer:
    • Date related options are now evaluated before and after the property is truncated. But only if a match before the string truncation was not successful.

Version 3.3 is a free download. Customers with existing 2.x keys can contact our Sales department for upgrade prices. If you have a valid Upgrade Insurance ID, you can request a free new key by sending your Upgrade Insurance ID to sales@adiscon.com. Please note that the download enables the free 30-day trial version if used without a key – so you can right now go ahead and evaluate it.

RSyslog Windows Agent 2.3 Released

Adiscon is proud to announce the 2.3 release of RSyslog Windows Agent.

This is the maintenance release and contains mainly bugfixes.

Most notably, this version includes OpenSSL library 1.0.1h. This fixes all security issues from the OpenSSL Security Advisory (2014-06-05).

Detailed information can be found in the version history below.

Build-IDs: Service 2.3.119, Client 2.3.145

Features

  • Updated embedded OpenSSL library to 1.0.1h

Bugfixes

  • SETP Protocoll: Fixed a bug in zlib decompression.
  • RELP Action: The RELP Action failed when no other network related Actions/services was configured.
  • Configuration Client: Fixed minor bugs in the configuration client.

 

Version 2.3 is a free download. Customers with existing 1.x keys can contact our Sales department for upgrade prices. If you have a valid Upgrade Insurance ID, you can request a free new key by sending your Upgrade Insurance ID to sales@adiscon.com. Please note that the download enables the free 30-day trial version if used without a key – so you can right now go ahead and evaluate it.

rsyslog 7.5.1 (v7-devel) released

This release opens the new 7.5 development branch. Most importantly, this version provides certificate-based authentication for RELP. It also includes mmfields, a module that can be used to parse CEF and other similar delimited formats. BSD-support has been improved and imjournal has been hardened to prevent corrupt journal databases from spamming the system too much. More information about configuring the certificate-based authentication for RELP: http://www.rsyslog.com/using-tls-with-relp/

ChangeLog: http://www.rsyslog.com/changelog-for-7-5-1-v7-devel/

Download: http://www.rsyslog.com/rsyslog-7-5-1-v7-devel/

As always, feedback is appreciated.

Best regards,
Florian Riedl

Using TLS with RELP

In this guide, we want to describe how to setup rsyslog with a RELP connection which is to be secured with TLS. For this guide you need at least rsyslog 7.5.1 and librelp 1.1.3 as well as gnutls 2.10.0 or above. These need to be installed on the server as well on the clients. The guide will split up into 3 parts.

  1. Creating the certificates
  2. Client Configuration
  3. Server Configuration

Step 1 – Creating the certificates

1.1 Setting up the CA

The first step is to set up a certificate authority (CA). It must be maintained by a trustworthy person (or group) and approves the indentities of all machines. It does so by issuing their certificates. In a small setup, the administrator can provide the CA function. What is important is the the CA’s private key is well-protocted and machine certificates are only issued if it is know they are valid (in a single-admin case that means the admin should not issue certificates to anyone else except himself). The CA creates a so-called self-signed certificate. That is, it approves its own authenticy. This sounds useless, but the key point to understand is that every machine will be provided a copy of the CA’s certificate. Accepting this certificate is a matter of trust. So by configuring the CA certificate, the administrator tells rsyslog which certificates to trust. This is the root of all trust under this model. That is why the CA’s private key is so important – everyone getting hold of it is trusted by our rsyslog instances.

To create a self-signed certificate, use the following commands with GnuTLS (which is currently the only supported TLS library, what may change in the future). Please note that GnuTLS’ tools are not installed by default on many platforms. Also, the tools do not necessarily come with the GnuTLS core package. If you do not have certtool on your system, check if there is package for the GnuTLS tools available (under Fedora, for example, this is named gnutls-utils-<version> and it is NOT installed by default).

  1. generate the private key:
    certtool --generate-privkey --outfile ca-key.pem

    This takes a short while. Be sure to do some work on your workstation, it waits for radom input. Switching between windows is sufficient ;)

  2. now create the (self-signed) CA certificate itself:
    certtool --generate-self-signed --load-privkey ca-key.pem --outfile ca.pem

    This generates the CA certificate. This command queries you for a number of things. Use appropriate responses. When it comes to certificate validity, keep in mind that you need to recreate all certificates when this one expires. So it may be a good idea to use a long period, eg. 3650 days (roughly 10 years). You need to specify that the certificates belongs to an authority. The certificate is used to sign other certificates.

Sample Screen Session

Text in red is user input. Please note that for some questions, there is no user input given. This means the default was accepted by simply pressing the enter key.

[root@rgf9dev sample]# certtool --generate-privkey --outfile ca-key.pem --bits 2048 
Generating a 2048 bit RSA private key... 
[root@rgf9dev sample]# 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): US 
Organization name: SomeOrg 
Organizational unit name: SomeOU 
Locality name: Somewhere 
State or province order research paper online name: CA 
Common name: someName (not necessarily DNS!) 
UID: 
This field should not be used in new certificates. 
E-mail: Enter the certificate's serial number (decimal): 
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: someone@example.net 
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: 
Version: 3 
Serial Number (hex): 485a365e 
Validity:  
Not Before: Thu Jun 19 10:35:12 UTC 2008 
Not After: Sun Jun 17 10:35:25 UTC 2018 
Subject: C=US,O=SomeOrg,OU=SomeOU,L=Somewhere,ST=CA,CN=someName (not necessarily DNS!) 
Subject Public Key Algorithm: 
RSA Modulus (bits 2048): 
d9:9c:82:46:24:7f:34:8f:60:cf:05:77:71:82:61:66 
05:13:28:06:7a:70:41:bf:32:85:12:5c:25:a7:1a:5a 
28:11:02:1a:78:c1:da:34:ee:b4:7e:12:9b:81:24:70 
ff:e4:89:88:ca:05:30:0a:3f:d7:58:0b:38:24:a9:b7 
2e:a2:b6:8a:1d:60:53:2f:ec:e9:38:36:3b:9b:77:93 
5d:64:76:31:07:30:a5:31:0c:e2:ec:e3:8d:5d:13:01 
11:3d:0b:5e:3c:4a:32:d8:f3:b3:56:22:32:cb:de:7d 
64:9a:2b:91:d9:f0:0b:82:c1:29:d4:15:2c:41:0b:97 
Exponent: 
01:00:01 
Extensions: 
Basic Constraints (critical): 
Certificate Authority (CA): TRUE 
Subject Alternative Name (not critical): 
RFC822name: someone@example.net 
Key Usage (critical): 
Certificate signing. 
Subject Key Identifier (not critical): 
fbfe968d10a73ae5b70d7b434886c8f872997b89 
Other Information: 
Public Key Id: 
fbfe968d10a73ae5b70d7b434886c8f872997b89 
Is the above information ok? (Y/N): y 
Signing certificate... 
[root@rgf9dev sample]# chmod 400 ca-key.pem 
[root@rgf9dev sample]# ls -l 
total 8 
-r-------- 1 root root 887 2008-06-19 12:33 ca-key.pem 
-rw-r--r-- 1 root root 1029 2008-06-19 12:36 ca.pem 
[root@rgf9dev sample]#

Be sure to safeguard ca-key.pem! Nobody except the CA itself needs to have it. If some third party obtains it, you security is broken!

 

1.2 Generating the machine certificate

In this step, we generate certificates for each of the machines. Please note that both clients and servers need certificates. The certificate identifies each machine to the remote peer. The DNSName specified inside the certificate can be specified inside the tls.PermittedPeer config statements. For now, we assume that a single person (or group) is responsible for the whole rsyslog system and thus it is OK if that single person is in posession of all machine’s private keys. This simplification permits us to use a somewhat less complicated way of generating the machine certificates. So, we generate both the private and public key on the CA (which is NOT a server!) and then copy them over to the respective machines. If the roles of machine and CA administrators are split, the private key must be generated by the machine administrator. This is done via a certificate request. This request is then sent to the CA admin, which in turn generates the certificate (containing the public key). The CA admin then sends back the certificate to the machine admin, who installs it. That way, the CA admin never get’s hold of the machine’s private key. Instructions for this mode will be given in a later revision of this document. In any case, it is vital that the machine’s private key is protected. Anybody able to obtain that private key can imporsonate as the machine to which it belongs, thus breaching your security.

Sample Screen Session Text in red is user input. Please note that for some questions, there is no user input given. This means the default was accepted by simply pressing the enter key. Please note: you need to substitute the names specified below with values that match your environment. Most importantly, machine.example.net must be replaced by the actual name of the machine that will be using this certificate. For example, if you generate a certificate for a machine named “server.example.com”, you need to use that name. If you generate a certificate for “client.example.com”, you need to use this name. Make sure that each machine certificate has a unique name. If not, you can not apply proper access control.

[root@rgf9dev sample]# certtool --generate-privkey --outfile key.pem --bits 2048 
Generating a 2048 bit RSA private key... 
[root@rgf9dev sample]# certtool --generate-request --load-privkey key.pem --outfile request.pem 
Generating a PKCS #10 certificate request... 
Country name (2 chars): US 
Organization name: SomeOrg 
Organizational unit name: SomeOU 
Locality name: Somewhere 
State or province name: CA 
Common name: machine.example.net 
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 challange 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 
[root@rgf9dev sample]# certtool --generate-certificate --load-request request.pem --outfile cert.pem --load-ca-certificate ca.pem --load-ca-privkey ca-key.pem 
Generating a signed certificate... 
Enter the certificate's serial number (decimal): 


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


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 the dnsName of the subject of the certificate: machine.example.net {This is the name of the machine that will use the certificate} 
Enter  the IP address of the subject of 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): 485a3819 
Validity: 
Not Before: Thu Jun 19 10:42:54 UTC 2008 
Not After: Wed Mar 16 10:42:57 UTC 2011 
Subject: C=US,O=SomeOrg,OU=SomeOU,L=Somewhere,ST=CA,CN=machine.example.net 
Subject Public Key Algorithm: RSA 
Modulus (bits 2048): 
b2:4e:5b:a9:48:1e:ff:2e:73:a1:33:ee:d8:a2:af:ae 
2f:23:76:91:b8:39:94:00:23:f2:6f:25:ad:c9:6a:ab 
2d:e6:f3:62:d8:3e:6e:8a:d6:1e:3f:72:e5:d8:b9:e0 
d0:79:c2:94:21:65:0b:10:53:66:b0:36:a6:a7:cd:46 
1e:2c:6a:9b:79:c6:ee:c6:e2:ed:b0:a9:59:e2:49:da 
c7:e3:f0:1c:e0:53:98:87:0d:d5:28:db:a4:82:36:ed 
3a:1e:d1:5c:07:13:95:5d:b3:28:05:17:2a:2b:b6:8e 
8e:78:d2:cf:ac:87:13:15:fc:17:43:6b:15:c3:7d:b9 

Exponent: 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: machine.example.net 
Subject Key Identifier (not critical): 
0ce1c3dbd19d31fa035b07afe2e0ef22d90b28ac 
Authority Key Identifier (not critical): 
fbfe968d10a73ae5b70d7b434886c8f872997b89 
Other Information: 
Public Key Id: 
0ce1c3dbd19d31fa035b07afe2e0ef22d90b28ac 

Is the above information ok? (Y/N): y 
Signing certificate... 
[root@rgf9dev sample]# rm -f request.pem 
[root@rgf9dev sample]# ls -l 
total 16 
-r-------- 1 root root 887 2008-06-19 12:33 ca-key.pem 
-rw-r--r-- 1 root root 1029 2008-06-19 12:36 ca.pem 
-rw-r--r-- 1 root root 1074 2008-06-19 12:43 cert.pem 
-rw-r--r-- 1 root root 887 2008-06-19 12:40 key.pem 
[root@rgf9dev sample]# # it may be a good idea to rename the files to indicate where they belong to 
[root@rgf9dev sample]# mv cert.pem machine-cert.pem 
[root@rgf9dev sample]# mv key.pem machine-key.pem 
[root@rgf9dev sample]# 

Distributing Files Provide the machine with:

  • a copy of ca.pem
  • cert.pem
  • key.pem

Never provide anyone with ca-key.pem! Also, make sure nobody but the machine in question gets hold of key.pem.

Step 2: Client Configuration

Usually, this is a rather simple matter. It is basically a configuration to forward messages via RELP, just with a few extra parameters. A configuration could look like this:

module(load="imuxsock") 
module(load="omrelp")
module(load="imtcp")
input(type="imtcp" port="514")
action(type="omrelp" target="192.168.233.153" port="20514" tls="on" tls.caCert="/home/test/cert/ca.pem" tls.myCert="/home/test/cert/ubuntu1-cert.pem" tls.myPrivKey="/home/test/cert/ubuntu1-key.pem" tls.authmode="name" tls.permittedpeer=["ubuntu-server"] )

The configuration is basically made of 3 parts.

First we load the modules that we need. In this case it is imuxsock, omrelp and imtcp. While imtcp and imuxsock are input modules and thus basically server for “generating” log data, omrelp is a output module and server to forward messages to a server via RELP.

The second part is a input. While imuxsock is always listening when the module is loaded, imtcp needs to be configured as an extra item. This also holds the possibility to configure multiple TCP listeners which could listen to different ports or have different parameters.

The third part is the action. In our case, we simply take all messages and forward them via RELP to our central server. Basically for a RELP connection it would be sufficient to configure the target and the port to send on. For this case, we enable TLS transportation with tls=”on” and secure it with our certificates. As you can see, we need to load our three certificate files as mentioned in the first section. They are all three needed. Also, we define the authentication mode as “name”. By that, the certificate of the other machine will be checked against the hostname to ensure the right machine uses the certificate. Also we allow a certain peer with tls.permittedpeer to answer to this machine.

Step 3: Server Configuration

The server configuration is only a little more complicated than the client configuration. Here is the example.

module(load="imuxsock")
module(load="imrelp" ruleset="relp")
input(type="imrelp" port="20514"
tls="on" 
tls.caCert="/home/test/cert/ca.pem" 
tls.myCert="/home/test/cert/server-cert.pem" 
tls.myPrivKey="/home/test/cert/server-key.pem"
tls.authMode="name" 
tls.permittedpeer=["ubuntu-client1","ubuntu-client2","ubuntu-client3"] ) 
ruleset (name="relp") { action(type="omfile" file="/var/log/relp_log") }

Again, the configuration is made of 3 sections.

First we load the modules. In this case, we load imuxsock for local logging ability (though not further used here) and imrelp for receiving log messages via RELP. As you can see, the module has the ruleset parameter given. That means, that the whole module is bound to a ruleset. This means, that all configured listeners will automatically use the later configured ruleset. This is contrary to other modules where you can configure a separate ruleset for each listener, but this is not possible with imrelp.

The second portion is the input. For a basic configuration it would be sufficient to specify the port to listen on. But since we want to enable TLS-functionality, we need to use tls=”on” again. Also we need to configure the parameters for all the parts of the certificate. Please note, that except for the CA certificate (which is the same on all machines) the certificate and key need to be for this single machine. Also we configure the authentication mode to “name” and an array of permitted peers.

Finally, as third step, we configure the ruleset and the action. In this case, we simply use the omfile module. The functionality is automatically loaded through rsyslog and we do not need to configure the module explicitely at the beginning.

Verdict

One would agree, that setting up rsyslog to use TLS-secured RELP for transferring log messages is basically very easy. Though, creating and maintaing all the certificates can be a tedious amount of work. But, a secure log transmission sure is worth the effort. Also, despite what has been mentioned, a machine certificate could also be created for multiple machines at once, though this is not recommended by Adiscon.

Something that is also noteworthy concerns the authentication mode. There are two other options that can be used, but these are not as secure as authentication against the name. Anonymous authentication can be reached by simply using tls=”on”, but not setting any other parameters. This only secures transportation of log messages, but does not ensure, that no false log data can be injected by a compromised machine or a machine not belonging to your network. A different approach would be fingerprint authentication. This can be used by using the fingerprint of a machine certificate on the peer machine. The fingerprint can be either received by the error log of a machine and then copying and pasting it into tls.permittedpeer, or by using certtool to review certificate details. Please note, that this is not very secure as well as the peers only check for the fingerprint of the certificate and not the certificate itself.

rsyslog 7.5.0 (v7-devel) released

This release opens the new 7.5 development branch. Most importantly, this version provides TLS protection for RELP (note that librelp 1.1.1 is required).

More information can be found in this blogpost: http://blog.gerhards.net/2013/06/new-rsyslog-devel-branch-75.html

ChangeLog:

http://www.rsyslog.com/changelog-for-7-5-0-v7-devel/

Download:

http://www.rsyslog.com/rsyslog-7-5-0-v7-devel/

As always, feedback is appreciated.

Best regards,
Florian Riedl

Action’s with directives

This snippet will show, how Action directives need to be applied to work properly. We will show it with the RELP output module. RELP should ensure a safe and loss-free transmission between two machines. But if not configured properly, messages may get lost anyway. This is mainly meant for any client side configuration.

First of all you have to enable the RELP module.

To load the module use this:

$ModLoad omrelp

To make sure, messages will not get dropped in the event the receiver is not available, we basically need the following directives. Additionaly, the queued messages should get saved to the harddrive if the client service needs to shut down. It is followed by a forwarding action via RELP to our remote server.

$ActionQueueType LinkedList # use asynchronous processing
$ActionQueueFileName srvrfwd # set file name, also enables disk mode
$ActionResumeRetryCount -1 # infinite retries on insert failure
$ActionQueueSaveOnShutdown on # save in-memory data if rsyslog shuts down
*.* :omrelp:192.168.152.2:20514

Attention: The directives are only valid for the next configured action! So you have to set the directives each time you use a new action.

Here is an example with two actions.

#first action
$ActionQueueType LinkedList # use asynchronous processing
$ActionQueueFileName srvrfwd # set file name, also enables disk mode
$ActionResumeRetryCount -1 # infinite retries on insert failure
$ActionQueueSaveOnShutdown on # save in-memory data if rsyslog shuts down
:syslogtag, isequal, “app1” :omrelp:192.168.152.2:20514

#second action
$ActionQueueType LinkedList # use asynchronous processing
$ActionQueueFileName srvrfwd # set file name, also enables disk mode
$ActionResumeRetryCount -1 # infinite retries on insert failure
$ActionQueueSaveOnShutdown on # save in-memory data if rsyslog shuts down
:syslogtag, isequal, “app2” :omrelp:192.168.152.3:20514

As you can see, we have the whole block of directives mulitple times. But this time, we filter the message for the syslogtag and have the diffenrently tagged messages sent to different receivers. Now if the receiver is not available, sending the messages will be retried until it is back up again. If the local rsyslog needs to shut down, all queued messages get written to disk without being lost.

Scroll to top