rsyslog, remote logging encrypted with stunnel

Work with a partner. Both of you will run rsyslog. One of you will become a loghost, the other will send its messages to the loghost. (Well call the loghost the server, and the message sender the client.) However, the client rsyslog won't send directly to the server rsyslog. Rather, both of you will also run stunnel and your stunnels will be interposed to encrypt the traffic. So the client rsyslog will send to stunnel in the client's machine, which will send (encrypted) to stunnel in the server's machine, and the server rsyslog will receive from that.

Setting up 2 stunnels, in-line between 2 rsyslogs

First set your stunnels' configurations as:

* "fips=no"  became necessary here when a recent new stunnel version (approx. 2011) began checking that the certificate it's given meets certain particular government format standards. FIPS stands for Federal Information Processing Standards.  The government sets security requirements that software must meet in order to be considered FIPS-compliant. For example, it specifies which hash algorithms are OK to use and which are not. The government's National Institute of Standards and Technology (NIST) publication "Security Requirements for Cryptographic Modules" defines what the standards are. For use in government, software that will protect sensitive information is required to meet them. stunnel can either enforce the standards or not. By default, previously it did not and now it does. Our stunnel exercise, in order to work, requires us to tell stunnel to relax ("fips=no" in config file). It presumably objected to something about the openssl .pem certificate file that stunnel regarded as not measuring up, or that it could not verify as doing so. 

[ This assumes the presence of a certificate on the server. If it's not already there:
cd /etc/stunnel
openssl req -new -x509 -days 3650 -nodes -out stunnel.pem -keyout stunnel.pem      (accept all the defaults) ]

Then run stunnel on both machines:

stunnel  /etc/stunnel/stunnel-client.conf

stunnel  /etc/stunnel/stunnel-server.conf

Sending log messages to another machine (loghost) for disposition

Now, on the server, we want to get rsyslog to run on a chosen port number, 61514. Make the needed modifications in the /etc/rsyslog.conf configuration file. Note the following section near the top of the default file:

# Provides TCP syslog reception
#$ModLoad imtcp.so
#$InputTCPServerRun 514

Uncomment the directives and change the port number to 61514 so that the above snippet becomes:

# Provides TCP syslog reception
$ModLoad imtcp.so
$InputTCPServerRun 61514

Restart rsyslogd:

systemctl  restart  rsyslog    ( or  service  rsyslog  restart )

syslogd is now a loghost, gathering up any log messages that arrive on TCP port 61514. Ask netstat to verify that:

netstat  -pant

The server is now a loghost, gathering up any log messages that arrive on TCP port 61514. So if anybody-- like maybe stunnel-- sends a message its way, it'll accept and process that message. Sending something is the client student/partner's role.

Change the client's /etc/rsyslog.conf. There, find the line that has "/var/log/messages" as its destination. Change that to:

@@127.0.0.1:61514      (this, on the client)

referring to the IP address of this very machine. Then restart rsyslogd:

systemctl  restart  rsyslog    (or service  rsyslog  restart )

Now, when this host sends a message, it will be to port 61514, which per above is being fielded by stunnel. What will stunnel do with it? Per its configuration above, send it to port 30000 at the server IP. Then what? 30000 at the server IP is being fielded by stunnel. And it will relay it to port 61514, which is being fielded by rsyslog. It'll do with the message whatever its rsyslog.conf says. By default, it should put it into its own /var/log/messages. That file will become mixed now, some of its messages originating locally but others from a different machine. Set the loghost, with tail -f, to dynamically display activity in its main log file:

tail  -f  /var/log/messages

Then have the other machine issue a message, perhaps using logger:

logger  "Tunnel vision"

"Tunnel vision" appears in the server's messages file. It traveled most of the way there from the emitting logger program in encrypted form. The two stunnels did the encrypt/decrypt.