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:


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:


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


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,,, 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:

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:
*.* @ #this uses UDP
*.* @@ #this uses TCP
*.* :omrelp: #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!


Fixing OpenCV and Dev-C++ linking problems

October 15, 2010

I’m trying these days OpenCV libraries and I got some annoying errors when I tried to compile. The debug window shows something like this:

g++.exe -c main.cpp -o main.o -I”lib/gcc/mingw32/3.4.2/include”  -I”include/c++/3.4.2/backward”  -I”include/c++/3.4.2/mingw32″  -I”include/c++/3.4.2″  -I”include”  -I”C:/OpenCV/include/opencv”

In file included from C:/OpenCV/include/opencv/cxcore.hpp:2243,
from C:/OpenCV/include/opencv/cxcore.h:2123,

from C:/OpenCV/include/opencv/cv.h:58,
from main.cpp:3:
C:/OpenCV/include/opencv/cxoperations.hpp: In member function `void cv::Ptr<_Tp>::addref()’:

After searching about on the internet I’ve found the solution. Just open the file C:\OpenCV2.0\include\opencv\cxoperations.cpp and change the line 68 with this:

#if __GNUC__ >= 4 || __MINGW32__
Now it worked for me and I can compile .cpp files with OpenCV functions.



Changing screen resolution on VirtualBox (Linux Debian)

October 13, 2010

Hi after … more than a year!!!

These are the necessary steps that you’ve to follow if you want to change your screen’s resolution using VirtualBox (By the way, this app rocks!) on a Debian virtual machine (Also is applicable to the most of the Linux distros):

  1. Install “build-essential” package. In debian is enough typing apt-get install build-essential
  2. On the VirtualBox menu while the VM is running, press Devices and “Install Guest Additions”. This will mount a cd drive on the system
  3. cd /media/cdrom and sh autorun.sh
  4. Log as root and edit the next file: /etc/X11/xorg.conf
  5. At the end of the file there’s a section called “Screen”. Probably you’ll see “Dept 24”. Open a new line and write the next “Modes “1366×768″ …” And the custom resolution that you need to your machine
  6. Reboot the VM with a shutdown -r now

That’s all, now you’re ready to work with the desired resolution



Some useful IBM Redbooks

May 1, 2009

I’ve found the IBM Redbooks page, in which, there’s many interesting books like this

TCP/IP Tutorial and Technical Overview

In this one, you can find info about the different network layers, from physic to application, with  explanations about routing protocols (OSPF, EIGRP, BGP…), IPv6, LDAP, VoIP, Wifi stuff, etc

Linux performance and tuning guidelines

In this, you’ll finde some very useful info. about how Linux works managing filesystems, I/O, memory, etc and how we can monitoring this with some well-know tools like Wireshark, vmstat, top, strace and many other commands.

Also in the IBM Redbooks page, there’re thousands of books about different topics, like WebSphere, DB2, AIX, Tivoli, Linux server integration and many other IBM stuff for their servers.

PD: I’ll add others redbooks :P. Send me suggestions about other books


Preventing ctrol+alt+del rebooting in our machine

May 1, 2009

Edit the /etc/inittab file as root

There’s a line like this in the file

ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now

Just comment it, or replace it with something like this
ca:12345:ctrlaltdel:echo "Use the "shutdown -r now" command if you want to reboot the system"

Also you should read the shutdown manual. This is a part of this that I think is important if we want to lock the rebooting system.
shutdown can be called from init(8) when the magic keys CTRL-ALT-DEL are pressed, by creating an appro-
priate entry in /etc/inittab. This means that everyone who has physical access to the console keyboard
can shut the system down. To prevent this, shutdown can check to see if an authorized user is logged in
on one of the virtual consoles. If shutdown is called with the -a argument (add this to the invocation
of shutdown in /etc/inittab), it checks to see if the file /etc/shutdown.allow is present. It then
compares the login names in that file with the list of people that are logged in on a virtual console
(from /var/run/utmp). Only if one of those authorized users or root is logged in, it will proceed. Oth-
erwise it will write the message

shutdown: no authorized users logged in

to the (physical) system console. The format of /etc/shutdown.allow is one user name per line. Empty
lines and comment lines (prefixed by a #) are allowed. Currently there is a limit of 32 users in this

In some distros like Fedora, you must look for the /etc/event.d/control-alt-delete file to modify this event



RSA2/DSA key access from PuTTY to a *NIX OpenSSH server

May 1, 2009

If you want to access to your *NIX server using PuTTY in Windows, you just should follow the next steps to create a secure access using RSA/DSA public key infrastructure.

1) The first thing is configuring our openSSH server in the “/etc/ssh/sshd_config” file and modifying some configuration fields

  • Protocol 2
  • RSAAuthentication yes
  • PubkeyAuthentication yes
  • AuthorizedKeysFile      %h/.ssh/authorized_keys

Reload the ssh daemon. /etc/init.d/ssh reload

2) Get the PuTTY Key Generator (Just typing it in google) and generate a RSA2/DSA public and private keys. Save them in a folder, and copy the text with Ctrl+C or in a file. This is your public key in openSSH format (The format which uses the ssh daemon)

It would be a good idea protect our private key with a passphrase, at least, if we’ll use the remote access in a public place like an office. Maybe you must try PuTTY PageAgent to manage your keys, but this is another bussiness 😛

3) Paste the text in your server in you “$home/.ssh/authorized_keys” of the user that you want to authenticate with RSA/DSA. (I suppose that “public_key” file contains the text generated by PuTTY)

  • cat public_key >>$home/.ssh/authorized_keys

4) Now, just open PuTTY and load your private key

5) Just login in the server as usual, and you should be logged in without typing your password. You must be type the keyphrase if you had set it in the  2nd step.

Regards, and be careful with your private key file 😎


Which distro version am I using?

April 18, 2009

Maybe you have asked yourself sometimes about this. There are some ways:
This shows a text like the uname -a command output
cat /proc/version
This is another way which should works in practically all *NIX systems
cat /etc/issue
And this is valid for Debian and Debian based distros
cat /etc/debian_version