Secure remote Linux logging with rsyslog

The rsyslog daemon allows a choice between UDP, TCP and RELP logging protocols for your Linux system. TCP and RELP offer guaranteed log messaging, for more secure logs.

In recent versions of Red Hat Enterprise Linux, rsyslog is used. While this log solution is similar to the traditional BSD log service, syslogd, it also offers some features that guarantee the reliable transport of log messages to a remote log host. In this article you'll read about these options.

BSD syslog offers configurability to a centralized log host. This is a good idea in systems where log management is taken seriously. In large environments it's very hard to keep track of log files if they are spread over several hosts. 

But, traditional syslog only offers remote logging over UDP, which doesn't keep track of connections, and log message arrival at the host is not guaranteed. The rsyslog solution offers a choice between three different remote logging solutions: UDP, TCP and the newly developed RELP protocol, which is available in the latest versions of rsyslog only.

UDP doesn't establish a connection when sending out packets, which means that the sender of these log messages can only trust that the message will arrive at its destination. The TCP protocol was developed to establish a connection before data was exchanged with other hosts. The solution is simple, but efficient: the receiver of a TCP message acknowledges receipt so that the sender has confirmation the message has arrived. Because of its wide availability and thorough message management, TCP is a the preferred option. The RELP protocol is relatively new and not generally implemented, which is a reason to avoid it for now.

To enable either UDP or TCP logging, you need to enable a specific module. Rsyslog uses input modules and output modules to enable reception of log messages from specific sources and send log messages to specific output destinations. To make sure the centralized log host is capable of receiving log messages over TCP, you need to include the following two lines in its /etc/rsyslogd.conf:

$ModLoad imtcp
$InputTCPServerRun 514

The first of these lines loads the input module tcp, and in the second line tells rsyslog to listen for incoming TCP connections on port 514. Next, tell the host that has to send its messages to the remote host. The following command tells the local host to send all log messages to a central log host that is available at IP address

*.*       @@

In this line, the syslog-style specification of facilities and priorities is used: the facility * (which is every event that is sent to the rsyslog process) sends events that match every priority to the centralized log host. The indication @@ makes clear that this log host listens to incoming messages on a TCP port. Alternatively, you could use @ if the messages have to be sent over UDP.

If you want to use the new RELP solution you can load the module at the centralized log host by including the following lines in its rsyslogd.conf:

$ModLoad imrelp
$InputRELPServerRun 2514

To send messages over RELP, you need to include the following to the sending host:

*.*       :omrelp:

Notice that to send it to the RELP destination host, an unprivileged port number is used, as there is no specific port reserved for the RELP protocol.

The old syslog daemon was capable of sending log messages over UDP only. In the new rsyslog daemon, you can choose between UDP, TCP and the new RELP protocol. Using TCP or RELP offers a better guarantee that the log messages will reach their destination, and using either one of them contributes to a more secure logging environment than was previously available.

ABOUT THE AUTHOR: Sander van Vugt is an author and independent technical trainer, specializing in Linux since 1994. He is also a technical consultant for high-availability (HA) clustering and performance optimization, as well as an expert on SLED 10 administration.

This was last published in June 2011

Dig Deeper on Linux monitoring and troubleshooting

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.