Secure remote Linux logging with rsyslog

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

Requires Free Membership to View

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 first published in June 2011

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
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
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.