Jan 2, 2013

A Simple Centralized Log Server Using Rsyslog

Logs are very useful when it comes to forensic operations. But most of the systems keep all the logs on the same host machine. But keeping logs in the same host machine is not very useful. Because hacker can destroy all the log on that vulnerable host.

Therefor we use a secure centralized log server to collect all the logs. All the systems and devices on the network will send a copy of each log entry to this centralized log server.

In this post I'm going to setup a simple centralized log using rsyslog. Most of the Linux system have this rsyslog installed by default. You just need to edit some configuration files.

In this setup we have a centralized log server (the server) and a client (simulate a system or a device on the network). First I config the server part and then I will move to the client part.

Server :-

Edit the
/etc/rsyslog.conf
to enable the UDP module and rsyslog to listen on UDP port 514.

# provides UDP syslog reception. For TCP, load imtcp.
$ModLoad imudp

# For TCP, InputServerRun 514
$UDPServerRun 514


Then you need to restart the rsyslog service.
service syslogd restart

Now the rsyslog on that host will work as the centralized log server.

Check the firewalls, iptables and SELinux settings and allow the UDP port 514 to receive data from other devices on the network.

You can use
tcpdump -i eth0 port 514
to see all incoming syslog data.


Client :-

You need to edit the same file on the other client in order to forward logs to the centralized log server.

*.* @192.168.1.1:514

In this ' *.* ' means all the logs, a single '@' sign means to use UDP protocal and the server IP and the listning port of the centralized log server.

After editing the configurations file you need to restart the rsyslog.


View collected logs:-

By default all the forwarded logs are append to the message log in the centralized server. You can view those message by viewing the
/var/log/message
log.

Note:-
As logs are in plain text, forwarding it using UDP/TCP is not a good practice.
Add filters and try to manage logs without just logging all into a single file.
Do proper log rotation.
Use log correlation mechanisms to take proactive decisions.

2 comments:

  1. Simply good but if you explain the SELinux (Context Seetings) and IPTables settings related to this it would be better....anyway thanks for sharing...:) :) :)

    ReplyDelete
  2. I'll try to add a separate IPTables post in near feature. Giving everything in a single post is not good, isn't it ?
    Anyway thanks for your comment.

    ReplyDelete

Your comments are always welcome ...