1SUDO_LOGSRVD(8)           BSD System Manager's Manual          SUDO_LOGSRVD(8)
2

NAME

4     sudo_logsrvd — sudo event and I/O log server
5

SYNOPSIS

7     sudo_logsrvd [-hnV] [-f file] [-R percentage]
8

DESCRIPTION

10     sudo_logsrvd is a high-performance log server that accepts event and I/O
11     logs from sudo.  It can be used to implement centralized logging of sudo
12     logs.  The server has two modes of operation: local and relay.  By de‐
13     fault, sudo_logsrvd stores the logs locally but it can also be configured
14     to relay them to another server that supports the sudo_logsrv.proto(5)
15     protocol.
16
17     When not relaying, event log entries may be logged either via syslog(3)
18     or to a local file.  I/O Logs stored locally by sudo_logsrvd can be re‐
19     played via the sudoreplay(8) utility in the same way as logs generated
20     directly by the sudoers plugin.
21
22     The server also supports restarting interrupted log transfers.  To dis‐
23     tinguish completed I/O logs from incomplete ones, the I/O log timing file
24     is set to be read-only when the log is complete.
25
26     Configuration parameters for sudo_logsrvd may be specified in the
27     sudo_logsrvd.conf(5) file or the file specified via the -f option.
28
29     sudo_logsrvd rereads its configuration file when it receives SIGHUP and
30     writes server state to the debug file (if one is configured) when it re‐
31     ceives SIGUSR1.
32
33     The options are as follows:
34
35     -f file, --file=file
36             Read configuration from file instead of the default,
37             /etc/sudo_logsrvd.conf.
38
39     -h, --help
40             Display a short help message to the standard output and exit.
41
42     -n, --no-fork
43             Run sudo_logsrvd in the foreground instead of detaching from the
44             terminal and becoming a daemon.
45
46     -R percentage, --random-drop=percentage
47             For each message, there is a percentage chance that the server
48             will drop the connection.  This is only intended for debugging
49             the ability of a client to restart a connection.
50
51     -V, --version
52             Print the sudo_logsrvd version and exit.
53
54   Securing server connections
55     The I/O log data sent to sudo_logsrvd may contain sensitive information
56     such as passwords and should be secured using Transport Layer Security
57     (TLS).  Doing so requires having a signed certificate on the server and,
58     if tls_checkpeer is enabled in sudo_logsrvd.conf(5), a signed certificate
59     on the client as well.
60
61     The certificates can either be signed by a well-known Certificate Author‐
62     ity (CA), or a private CA can be used.  Instructions for creating a pri‐
63     vate CA are included below in the EXAMPLES section.
64
65   Debugging sudo_logsrvd
66     sudo_logsrvd supports a flexible debugging framework that is configured
67     via Debug lines in the sudo.conf(5) file.
68
69     For more information on configuring sudo.conf(5), refer to its manual.
70

FILES

72     /etc/sudo.conf            Sudo front-end configuration
73
74     /etc/sudo_logsrvd.conf    Sudo log server configuration file
75
76     /var/log/sudo_logsrvd/incoming
77                               Directory where new journals are stored when
78                               the store_first relay setting is enabled.
79
80     /var/log/sudo_logsrvd/outgoing
81                               Directory where completed journals are stored
82                               when the store_first relay setting is enabled.
83
84     /var/log/sudo-io          Default I/O log file location
85
86     /run/sudo/sudo_logsrvd.pid
87                               Process ID file for sudo_logsrvd
88

EXAMPLES

90   Creating self-signed certificates
91     Unless you are using certificates signed by a well-known Certificate Au‐
92     thority (or a local enterprise CA), you will need to create your own CA
93     that can sign the certificates used by sudo_logsrvd, sudo_sendlog, and
94     the sudoers plugin.  The following steps use the openssl(1) command to
95     create keys and certificates.
96
97   Initial setup
98     First, we need to create a directory structure to store the files for the
99     CA.  We'll create a new directory hierarchy in /etc/ssl/sudo for this
100     purpose.
101
102         # mkdir /etc/ssl/sudo
103         # cd /etc/ssl/sudo
104         # mkdir certs csr newcerts private
105         # chmod 700 private
106         # touch index.txt
107         # echo 1000 > serial
108
109     The serial and index.txt files are used to keep track of signed certifi‐
110     cates.
111
112     Next, we need to make a copy of the openssl.conf file and customize it
113     for our new CA.  The path to openssl.cnf is system-dependent but
114     /etc/ssl/openssl.cnf is the most common location.  You will need to ad‐
115     just the example below if it has a different location on your system.
116
117         # cp /etc/ssl/openssl.cnf .
118
119     Now edit the openssl.cnf file in the current directory and make sure it
120     contains “ca”, “CA_default”, “v3_ca”, and “usr_cert” sections.  Those
121     sections should include at least the following settings:
122
123         [ ca ]
124         default_ca              = CA_default
125
126         [ CA_default ]
127         dir                     = /etc/ssl/sudo
128         certs                   = $dir/certs
129         database                = $dir/index.txt
130         certificate             = $dir/cacert.pem
131         serial                  = $dir/serial
132
133         [ v3_ca ]
134         subjectKeyIdentifier    = hash
135         authorityKeyIdentifier  = keyid:always,issuer
136         basicConstraints        = critical,CA:true
137         keyUsage                = cRLSign, keyCertSign
138
139         [ usr_cert ]
140         basicConstraints        = CA:FALSE
141         keyUsage                = nonRepudiation, digitalSignature, \
142                                   keyEncipherment
143         subjectKeyIdentifier    = hash
144         authorityKeyIdentifier  = keyid,issuer
145
146     If your openssl.conf file already has a “CA_default” section, you may
147     only need to modify the “dir” setting and enable the “keyUsage” settings
148     if they are commented out.
149
150   Creating the CA key and certificate
151     In order to create and sign our own certificates, we need to create a
152     private key and a certificate for the root of the CA.  First, create the
153     private key and protect it with a pass phrase:
154
155         # openssl genrsa -aes256 -out private/cakey.pem 4096
156         # chmod 400 private/cakey.pem
157
158     Next, generate the root certificate, using appropriate values for the
159     site-specific fields:
160
161         # openssl req -config openssl.cnf -key private/cakey.pem \
162             -new -x509 -days 7300 -sha256 -extensions v3_ca \
163             -out cacert.pem
164
165         Enter pass phrase for private/cakey.pem:
166         You are about to be asked to enter information that will be
167         incorporated into your certificate request.
168         What you are about to enter is what is called a Distinguished Name
169         or a DN.
170         There are quite a few fields but you can leave some blank.
171         For some fields there will be a default value,
172         If you enter '.', the field will be left blank.
173         -----
174         Country Name (2 letter code) [AU]:US
175         State or Province Name (full name) [Some-State]:Colorado
176         Locality Name (eg, city) []:
177         Organization Name (eg, company) [Internet Widgits Pty Ltd]:sudo
178         Organizational Unit Name (eg, section) []:sudo Certificate Authority
179         Common Name (e.g., server FQDN or YOUR name) []:sudo Root CA
180         Email Address []:
181
182         # chmod 444 cacert.pem
183
184     Finally, verify the root certificate:
185
186         # openssl x509 -noout -text -in cacert.pem
187
188   Creating and signing certificates
189     The server and client certificates will be signed by the previously cre‐
190     ated root CA.  Usually, the root CA is not used to sign server/client
191     certificates directly.  Instead, intermediate certificates are created
192     and signed with the root CA and the intermediate certs are used to sign
193     CSRs (Certificate Signing Request).  In this example we'll skip this part
194     for simplicity's sake and sign the CSRs with the root CA.
195
196     First, generate the private key without a pass phrase.
197
198         # openssl genrsa -out private/logsrvd_key.pem 2048
199         # chmod 400 private/logsrvd_key.pem
200
201     Next, create a certificate signing request (CSR) for the server's cer‐
202     tificate.  The organization name must match the name given in the root
203     certificate.  The common name should be either the server's IP address or
204     a fully qualified domain name.
205
206         # openssl req -config openssl.cnf -key private/logsrvd_key.pem -new \
207             -sha256 -out csr/logsrvd_csr.pem
208
209         Enter pass phrase for private/logsrvd_key.pem:
210         You are about to be asked to enter information that will be
211         incorporated into your certificate request.
212         What you are about to enter is what is called a Distinguished Name
213         or a DN.
214         There are quite a few fields but you can leave some blank.
215         For some fields there will be a default value,
216         If you enter '.', the field will be left blank.
217         -----
218         Country Name (2 letter code) [AU]:US
219         State or Province Name (full name) [Some-State]:Colorado
220         Locality Name (eg, city) []:
221         Organization Name (eg, company) [Internet Widgits Pty Ltd]:sudo
222         Organizational Unit Name (eg, section) []:sudo log server
223         Common Name (e.g., server FQDN or YOUR name) []:logserver.example.com
224         Email Address []:
225
226         Please enter the following 'extra' attributes
227         to be sent with your certificate request
228         A challenge password []:
229         An optional company name []:
230
231     Now sign the CSR that was just created:
232
233         # openssl ca -config openssl.cnf -days 375 -notext -md sha256 \
234             -in csr/logsrvd_csr.pem -out certs/logsrvd_cert.pem
235
236         Using configuration from openssl.cnf
237         Enter pass phrase for ./private/cakey.pem:
238         Check that the request matches the signature
239         Signature ok
240         Certificate Details:
241                 Serial Number: 4096 (0x1000)
242                 Validity
243                     Not Before: Nov 11 14:05:05 2019 GMT
244                     Not After : Nov 20 14:05:05 2020 GMT
245                 Subject:
246                     countryName               = US
247                     stateOrProvinceName       = Colorado
248                     organizationName          = sudo
249                     organizationalUnitName    = sudo log server
250                     commonName                = logserve.example.com
251                 X509v3 extensions:
252                     X509v3 Basic Constraints:
253                         CA:FALSE
254                     X509v3 Key Usage:
255                         Digital Signature, Non Repudiation, Key Encipherment
256                     X509v3 Subject Key Identifier:
257                         4C:50:F9:D0:BE:1A:4C:B2:AC:90:76:56:C7:9E:16:AE:E6:9E:E5:B5
258                     X509v3 Authority Key Identifier:
259                         keyid:D7:91:24:16:B1:03:06:65:1A:7A:6E:CF:51:E9:5C:CB:7A:95:3E:0C
260
261         Certificate is to be certified until Nov 20 14:05:05 2020 GMT (375 days)
262         Sign the certificate? [y/n]:y
263
264         1 out of 1 certificate requests certified, commit? [y/n]y
265         Write out database with 1 new entries
266         Data Base Updated
267
268     Finally, verify the new certificate:
269
270         # openssl verify -CAfile cacert.pem certs/logsrvd_cert.pem
271         certs/logsrvd_cert.pem: OK
272
273     The /etc/ssl/sudo/certs directory now contains a signed and verified cer‐
274     tificate for use with sudo_logsrvd.
275
276     To generate a client certificate, repeat the process above using a dif‐
277     ferent file name.
278
279   Configuring sudo_logsrvd to use TLS
280     To use TLS for client/server communication, both sudo_logsrvd and the
281     sudoers plugin need to be configured to use TLS.  Configuring
282     sudo_logsrvd for TLS requires the following settings, assuming the same
283     path names used earlier:
284
285         # Listen on port 30344 for TLS connections to any address.
286         listen_address = *:30344(tls)
287
288         # Path to the certificate authority bundle file in PEM format.
289         tls_cacert = /etc/ssl/sudo/cacert.pem
290
291         # Path to the server's certificate file in PEM format.
292         tls_cert = /etc/ssl/sudo/certs/logsrvd_cert.pem
293
294         # Path to the server's private key file in PEM format.
295         tls_key = /etc/ssl/sudo/private/logsrvd_key.pem
296
297     The root CA cert (cacert.pem) must be installed on the system running
298     sudo_logsrvd.  If peer authentication is enabled on the client, a copy of
299     cacert.pem must be present on the client system too.
300

SEE ALSO

302     sudo.conf(5), sudo_logsrvd.conf(5), sudoers(5), sudo(8), sudo_sendlog(8),
303     sudoreplay(8)
304

AUTHORS

306     Many people have worked on sudo over the years; this version consists of
307     code written primarily by:
308
309           Todd C. Miller
310
311     See the CONTRIBUTORS.md file in the sudo distribution
312     (https://www.sudo.ws/about/contributors/) for an exhaustive list of peo‐
313     ple who have contributed to sudo.
314

BUGS

316     If you believe you have found a bug in sudo_logsrvd, you can submit a bug
317     report at https://bugzilla.sudo.ws/
318

SUPPORT

320     Limited free support is available via the sudo-users mailing list, see
321     https://www.sudo.ws/mailman/listinfo/sudo-users to subscribe or search
322     the archives.
323

DISCLAIMER

325     sudo_logsrvd is provided “AS IS” and any express or implied warranties,
326     including, but not limited to, the implied warranties of merchantability
327     and fitness for a particular purpose are disclaimed.  See the LICENSE.md
328     file distributed with sudo or https://www.sudo.ws/about/license/ for com‐
329     plete details.
330
331Sudo 1.9.14p3                  January 16, 2023                  Sudo 1.9.14p3
Impressum