Relay mode was introduced to sudo_logsrvd in sudo version 1.9.7. But, first of all, what is sudo_logsrvd? It is the sudo recording service that allows you to collect sudo session recordings centrally. Using relay mode makes it possible to collect sudo session recordings even when the central service is inaccessible and provides you with a single exit point from your network.

In this blog you will learn why relay mode is important and how you can test it.

To use relay mode you will need sudo version 1.9.7 or higher. At the time of writing, this is currently available in openSUSE Tumbleweed and FreeBSD & OpenBSD ports. For other operating systems, check if a binary package is available on the sudo website download page or compile it yourself from source.

For my tests I used openSUSE Tumbleweed and FreeBSD, but any other OS should work as long as you install sudo 1.9.7 on it.

Sudo version 1.9.7p1 was made available shortly before my blog was published. It addresses a problem in relay mode when store_first is set to true in sudo_logsrvd.conf and the central server was unavailable at start-up.

When you record sessions, it is important to make sure that they can actually be stored. By default, sudo refuses to run if the recording service is unavailable. Placing a sudo_logsrvd in relay mode on each of your networks ensures that session recording is available to hosts even if the central recording service is unavailable for some reason (network problem, planned maintenance, etc.).

You can also use it to simplify your firewall rules: a single exit point for sudo session recordings instead of allowing each hosts on your network to send recordings to the central server.

When you have internal networks without direct network connection to the outside world, you can use sudo_logsrvd in relay mode on gateway hosts with interfaces on both networks. For example a private subnet in AWS.

For testing you need three hosts: a client, a relay and a server. The relay needs to run sudo version 1.9.7 or later, the other hosts need at least sudo version 1.9.1, as earlier versions lack central recording capability.

I used a single internal network and did not enable TLS. For a production environment you should enable TLS for additional security, but configuring TLS is outside the scope of this blog.

On the central server you do not have to configure anything (except for TLS), you can start sudo_logsrvd with the default configuration.

On the client sending session recordings to relay, you have to setup session recording and forwarding. Start visudo and append the following two lines (do not forget to change the IP address to match your environment):

Defaults log_servers = 172.16.167.164:30343
Defaults log_output

On the relay, open /etc/sudo_logsrvd.conf in your favorite text editor and in the [relay] section, add a single line (do not forget to change the IP address to match your environment):

relay_host = 172.16.167.161

If you have a stable connection to your relay host, but the connection from the relay to the central server is either slow or unstable, you might want to add another line to the [server] section:

store_first = true

This will cause sudo_logsrvd to store recordings in a queue on the relay host and only forward them when the session has finished. By default it is set to false, and recordings are forwarded immediately without storing them on the relay.

Once you have started sudo_logsrvd on the relay host you are ready for testing.

The testing part is easy. Just start a command through sudo as a user with the appropriate sudo privileges. You should see the recording on the central server.

[czanik@localhost ~]$ sudo ls /root/
[sudo] password for czanik: 
anaconda-ks.cfg  a.py~	      pp.conf				   url
approval.py	 auditbla.py  __pycache__
approval.py~	 audit.py~    syslog-ng-3.25.1.96.g26cc51b.tar.gz
a.py		 tografana.conf
[czanik@localhost ~]$ 

On the central recording server you should see the following in the logs:

Jun 08 11:09:36 localhost.localdomain sudo[1279]:   czanik : HOST=localhost.localdomain ; TTY=pts/0 ; PWD=/home/czanik ; USER=root ; TSID=000005 ; COMMAND=/usr/bin/ls /root/

And you should also be able to play back the session:

[root@localhost ~]# sudoreplay -l | tail -1
Jun  8 11:09:36 2021 : czanik : TTY=/dev/pts/0 ; CWD=/home/czanik ; USER=root ; HOST=localhost.localdomain ; TSID=000005 ; COMMAND=/usr/bin/ls /root/
[root@localhost ~]# sudoreplay 000005
Replaying sudo session: /usr/bin/ls /root/
anaconda-ks.cfg  a.py~	      pp.conf				   url
approval.py	 auditbla.py  __pycache__
approval.py~	 audit.py~    syslog-ng-3.25.1.96.g26cc51b.tar.gz
a.py		 tografana.conf
[root@localhost ~]# 

For a production environment you should enable TLS. Check the sudo_logsrvd.conf manual page for additional information about TLS and settings to fine tune sudo_logsrvd for your environment.

If you would like to be notified about new posts and sudo news, sign up for the sudo blog announcement mailing list.