Archive for October, 2015

h1

Rsyslog quick configuration

October 6, 2015

Hi there,

Rsyslog provides a logging daemon on our Linux system to catch different events in a organized manner as well providing a way to send/receive these logs to/from a remote machine which can be used for example for logs aggregation on our network.

Rsyslog provides a number of “facilities” (types of programs with a common functionality) that can be classified into the following categories:

syslog_facilities

The localX facilities can be used in case we write/use any application that does not use the common facilities.

Each of these facilities, will generate different entries on the logs depending on the severity of the action that triggered the log entry:

severity_logging

The main configuration file for rsyslog is normally located (tested on a Ubuntu machine) in:

/etc/rsyslog.conf

Here we can set up a number of interesting directives such as:

#UDP log reception
#$ModLoad imudp
#$UDPServerRun 514

#TCP log reception
#$ModLoad imtcp
#$InputTCPServerRun 514

#RELP log reception
#$ModLoad imrelp
#$InputTCPServerRun 2514

It may be surprising that “RELP” protocol for you. RELP is basically a protocol designed for reliable log messages transport between different entities. By means of some wrappers it can be used along with TLS which will provide and reliable and encrypted communication channel for logs.

If we want to restrict which nodes can send logs to our server we can use the following directive:
$AllowedSender UDP, 192.168.1.100, 192.168.1.101, myhost.mydomain.net

We can also allow by TCP. Beware of IP spoofing attacks here.

There are other interesting directives to for example give certain rights to the logs, which is important if we don’t want non-privileged users to access the log files. Check “man rsyslog.conf” for more details about this.

The important directives to configure the logging have the following appearance:
facility.priority

Where the variables used are the ones from the tables above. If we want for example to log all the authentication messages we will add an entry like:
auth.* -/var/log/auth.log
auth.warn -/var/log/auth_warn.log

If we specify a severity level (like warn in the example) all the events with severity from “emerg” to “kern” will be captured into this log. If we want just one certain level we have to use = operator:
auth.=warn -/var/log/auth_warnonly.log

If we want to catch messages from several (or all) facilities but to restrict some we can use the “.none” modifier after a “;” to specify which ones:
*.critical;auth,kern.none -/var/log/all_noauthkern.log

To use the “local” facilities, it follows the same pattern than before:
local0.* -/var/log/myapplocal0.log

If we want to send logs (messages, events…) to a remote machine (a log aggregator for example) we can use the following:
*.* @192.168.1.1 #this uses UDP
*.* @@192.168.1.1 #this uses TCP
*.* :omrelp:192.168.1.1:2514 #this uses RELP (port 2514)

Security factors to take into consideration:

  • If we allow remote logs reception, make sure your daemon is running on a limited partion under a chroot environment or something similar to avoid a disk fill-up
  • Unless some sort of VPN/SSL/TLS, etc is used, our logs will travel unencripted over the network, therefore we are susceptible to suffer a MiTM attack.
  • Only the hosts (or sensors) that will generate logs should be able to send logs over the network, therefore our networking devices should filter any traffic not belonging to these addresses by means of ACL, Iptables or similar. This do not protect from IP spoofing, so if we need are in an untrusted enviroment we should somehow authenticate this traffic.

This gives you few basics to start with syslog. There are other interesting topics such as templates (custom log entries), users restriction, filters (to filter out only information we need), database connection, etc.

Good luck!

Advertisements