FreeBSD Manual Pages
SUDO_LOGSRVD(8) System Manager's Manual SUDO_LOGSRVD(8) NAME sudo_logsrvd -- sudo event and I/O log server SYNOPSIS sudo_logsrvd [-hnV] [-f file] [-R percentage] DESCRIPTION sudo_logsrvd is a high-performance log server that accepts event and I/O logs from sudo. It can be used to implement centralized logging of sudo logs. The server has two modes of operation: local and relay. By default, sudo_logsrvd stores the logs locally but it can also be con- figured to relay them to another server that supports the sudo_logsrv.proto(5) protocol. When not relaying, event log entries may be logged either via syslog(3) or to a local file. I/O Logs stored locally by sudo_logsrvd can be re- played via the sudoreplay(8) utility in the same way as logs generated directly by the sudoers plugin. The server also supports restarting interrupted log transfers. To dis- tinguish completed I/O logs from incomplete ones, the I/O log timing file is set to be read-only when the log is complete. Configuration parameters for sudo_logsrvd may be specified in the sudo_logsrvd.conf(5) file or the file specified via the -f option. sudo_logsrvd rereads its configuration file when it receives SIGHUP and writes server state to the debug file (if one is configured) when it receives SIGUSR1. The options are as follows: -f file, --file=file Read configuration from file instead of the default, /usr/local/etc/sudo_logsrvd.conf. -h, --help Display a short help message to the standard output and exit. -n, --no-fork Run sudo_logsrvd in the foreground instead of detaching from the terminal and becoming a daemon. -R percentage, --random-drop=percentage For each message, there is a percentage chance that the server will drop the connection. This is only intended for debugging the ability of a client to restart a connection. -V, --version Print the sudo_logsrvd version and exit. Securing server connections The I/O log data sent to sudo_logsrvd may contain sensitive information such as passwords and should be secured using Transport Layer Security (TLS). Doing so requires having a signed certificate on the server and, if tls_checkpeer is enabled in sudo_logsrvd.conf(5), a signed cer- tificate on the client as well. The certificates can either be signed by a well-known Certificate Au- thority (CA), or a private CA can be used. Instructions for creating a private CA are included below in the "EXAMPLES" section. Debugging sudo_logsrvd sudo_logsrvd supports a flexible debugging framework that is configured via Debug lines in the sudo.conf(5) file. For more information on configuring sudo.conf(5), refer to its manual. FILES /usr/local/etc/sudo.conf Sudo front-end configuration /usr/local/etc/sudo_logsrvd.conf Sudo log server configuration file /var/log/sudo_logsrvd/incoming Directory where new journals are stored when the store_first relay setting is enabled. /var/log/sudo_logsrvd/outgoing Directory where completed journals are stored when the store_first relay setting is en- abled. /var/log/sudo-io Default I/O log file location /var/run/sudo/sudo_logsrvd.pid Process ID file for sudo_logsrvd EXAMPLES Creating self-signed certificates Unless you are using certificates signed by a well-known Certificate Authority (or a local enterprise CA), you will need to create your own CA that can sign the certificates used by sudo_logsrvd, sudo_sendlog, and the sudoers plugin. The following steps use the openssl(1) command to create keys and certificates. Initial setup First, we need to create a directory structure to store the files for the CA. We'll create a new directory hierarchy in /etc/ssl/sudo for this purpose. # mkdir /etc/ssl/sudo # cd /etc/ssl/sudo # mkdir certs csr newcerts private # chmod 700 private # touch index.txt # echo 1000 > serial The serial and index.txt files are used to keep track of signed cer- tificates. Next, we need to make a copy of the openssl.conf file and customize it for our new CA. The path to openssl.cnf is system-dependent but /etc/ssl/openssl.cnf is the most common location. You will need to ad- just the example below if it has a different location on your system. # cp /etc/ssl/openssl.cnf . Now edit the openssl.cnf file in the current directory and make sure it contains "ca", "CA_default", "v3_ca", and "usr_cert" sections. Those sections should include at least the following settings: [ ca ] default_ca = CA_default [ CA_default ] dir = /etc/ssl/sudo certs = $dir/certs database = $dir/index.txt certificate = $dir/cacert.pem serial = $dir/serial [ v3_ca ] subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer basicConstraints = critical,CA:true keyUsage = cRLSign, keyCertSign [ usr_cert ] basicConstraints = CA:FALSE keyUsage = nonRepudiation, digitalSignature, \ keyEncipherment subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer If your openssl.conf file already has a "CA_default" section, you may only need to modify the "dir" setting and enable the "keyUsage" set- tings if they are commented out. Creating the CA key and certificate In order to create and sign our own certificates, we need to create a private key and a certificate for the root of the CA. First, create the private key and protect it with a pass phrase: # openssl genrsa -aes256 -out private/cakey.pem 4096 # chmod 400 private/cakey.pem Next, generate the root certificate, using appropriate values for the site-specific fields: # openssl req -config openssl.cnf -key private/cakey.pem \ -new -x509 -days 7300 -sha256 -extensions v3_ca \ -out cacert.pem Enter pass phrase for private/cakey.pem: You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank. For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:Colorado Locality Name (eg, city) []: Organization Name (eg, company) [Internet Widgets Pty Ltd]:sudo Organizational Unit Name (eg, section) []:sudo Certificate Authority Common Name (e.g., server FQDN or YOUR name) []:sudo Root CA Email Address []: # chmod 444 cacert.pem Finally, verify the root certificate: # openssl x509 -noout -text -in cacert.pem Creating and signing certificates The server and client certificates will be signed by the previously created root CA. Usually, the root CA is not used to sign server/client certificates directly. Instead, intermediate certifi- cates are created and signed with the root CA and the intermediate certs are used to sign CSRs (Certificate Signing Request). In this ex- ample we'll skip this part for simplicity's sake and sign the CSRs with the root CA. First, generate the private key without a pass phrase. # openssl genrsa -out private/logsrvd_key.pem 2048 # chmod 400 private/logsrvd_key.pem Next, create a certificate signing request (CSR) for the server's cer- tificate. The organization name must match the name given in the root certificate. The common name should be either the server's IP address or a fully qualified domain name. # openssl req -config openssl.cnf -key private/logsrvd_key.pem -new \ -sha256 -out csr/logsrvd_csr.pem Enter pass phrase for private/logsrvd_key.pem: You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank. For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:Colorado Locality Name (eg, city) []: Organization Name (eg, company) [Internet Widgets Pty Ltd]:sudo Organizational Unit Name (eg, section) []:sudo log server Common Name (e.g., server FQDN or YOUR name) []:logserver.example.com Email Address []: Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []: Now sign the CSR that was just created: # openssl ca -config openssl.cnf -days 375 -notext -md sha256 \ -in csr/logsrvd_csr.pem -out certs/logsrvd_cert.pem Using configuration from openssl.cnf Enter pass phrase for ./private/cakey.pem: Check that the request matches the signature Signature ok Certificate Details: Serial Number: 4096 (0x1000) Validity Not Before: Nov 11 14:05:05 2019 GMT Not After : Nov 20 14:05:05 2020 GMT Subject: countryName = US stateOrProvinceName = Colorado organizationName = sudo organizationalUnitName = sudo log server commonName = logserve.example.com X509v3 extensions: X509v3 Basic Constraints: CA:FALSE X509v3 Key Usage: Digital Signature, Non Repudiation, Key Encipherment X509v3 Subject Key Identifier: 4C:50:F9:D0:BE:1A:4C:B2:AC:90:76:56:C7:9E:16:AE:E6:9E:E5:B5 X509v3 Authority Key Identifier: keyid:D7:91:24:16:B1:03:06:65:1A:7A:6E:CF:51:E9:5C:CB:7A:95:3E:0C Certificate is to be certified until Nov 20 14:05:05 2020 GMT (375 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated Finally, verify the new certificate: # openssl verify -CAfile cacert.pem certs/logsrvd_cert.pem certs/logsrvd_cert.pem: OK The /etc/ssl/sudo/certs directory now contains a signed and verified certificate for use with sudo_logsrvd. To generate a client certificate, repeat the process above using a dif- ferent file name. Configuring sudo_logsrvd to use TLS To use TLS for client/server communication, both sudo_logsrvd and the sudoers plugin need to be configured to use TLS. Configuring sudo_logsrvd for TLS requires the following settings, assuming the same path names used earlier: # Listen on port 30344 for TLS connections to any address. listen_address = *:30344(tls) # Path to the certificate authority bundle file in PEM format. tls_cacert = /etc/ssl/sudo/cacert.pem # Path to the server's certificate file in PEM format. tls_cert = /etc/ssl/sudo/certs/logsrvd_cert.pem # Path to the server's private key file in PEM format. tls_key = /etc/ssl/sudo/private/logsrvd_key.pem The root CA cert (cacert.pem) must be installed on the system running sudo_logsrvd. If peer authentication is enabled on the client, a copy of cacert.pem must be present on the client system too. SEE ALSO sudo.conf(5), sudo_logsrv.proto(5), sudo_logsrvd.conf(5), sudoers(5), sudo(8), sudo_sendlog(8), sudoreplay(8) AUTHORS Many people have worked on sudo over the years; this version consists of code written primarily by: Todd C. Miller See the CONTRIBUTORS.md file in the sudo distribution (https://www.sudo.ws/about/contributors/) for an exhaustive list of people who have contributed to sudo. BUGS If you believe you have found a bug in sudo_logsrvd, you can either file a bug report in the sudo bug database, https://bugzilla.sudo.ws/, or open an issue at https://github.com/sudo-project/sudo/issues. If you would prefer to use email, messages may be sent to the sudo-workers mailing list, https://www.sudo.ws/mailman/listinfo/sudo-workers (pub- lic) or <sudo@sudo.ws> (private). Please do not report security vulnerabilities through public GitHub is- sues, Bugzilla or mailing lists. Instead, report them via email to <Todd.Miller@sudo.ws>. You may encrypt your message with PGP if you would like, using the key found at https://www.sudo.ws/dist/PGPKEYS. SUPPORT Limited free support is available via the sudo-users mailing list, see https://www.sudo.ws/mailman/listinfo/sudo-users to subscribe or search the archives. DISCLAIMER sudo_logsrvd is provided "AS IS" and any express or implied warranties, including, but not limited to, the implied warranties of merchantabil- ity and fitness for a particular purpose are disclaimed. See the LI- CENSE.md file distributed with sudo or https://www.sudo.ws/about/li- cense/ for complete details. Sudo 1.9.17p2 July 14, 2024 SUDO_LOGSRVD(8)
NAME | SYNOPSIS | DESCRIPTION | FILES | EXAMPLES | SEE ALSO | AUTHORS | BUGS | SUPPORT | DISCLAIMER
Want to link to this manual page? Use this URL:
<https://man.freebsd.org/cgi/man.cgi?query=sudo_logsrvd&sektion=8&manpath=FreeBSD+Ports+15.1.quarterly>