Sslogger Main Page
From sslogger
Contents |
Description
Sslogger is session keystroke logging utility for Unix that allows administrators the ability to manage/grant access rights for users to execute commands, or open interactive shells as other users including root. When used in interactive session mode, sslogger records keystrokes in a special file and/or a remote slogd server as they are typed. Remote logging is performed through a secure TLS session.
Privileged user escalation is set by standard sudo rules which can be managed either locally or remotely by a centrally managed LDAP infrastructure. This document will describe installation, and configuration for both small, and large scale environments.
sslogger also provides the ability to run in command mode in which sslogger to be used within a script in non-interactive mode.
Role Bases Access
Sudo already provides the ability to grant privileged access to other roles allowing while auditing commands based on roles. Sudo falls short on the ability to monitor activities evoked in interactive sessions. Wrapping sslogger around sudo enables the ability to log privileged access while logging keystrokes for interactive sessions.
Download
Compiled binary packages are aviailable for Redhat and Fedora, see Instalation below. Souce package and tarball is available is available under Project Dowloads
Installation
Redhat
Enable the epel repos and run: yum install sslogger
Fedora
The sslogger The core ssloggger package can be installed by running: yum install sslogger
Other Platforms
If any one wants to contribute instructions, feel free to use the sslogger:Community_Portal
Basic local configuration
After installation of the sslogger package, user access must be granted to the sslogger command. Access is managed via standard sudo rules.
Sudo
Below are some example on how to configure /etc/sudores. More examples can be found in the man pages for sslogger and sudo.
Sample sudoers entry to allow users in unix group wheel to run any sslogger command as root
%wheel ALL=(root) NOPASSWD:/usr/bin/sslogger
Sample sudoers entry to allow user user1 to run any command, or interactive shell as users: root or user2
user1 ALL=(root,user2) NOPASSWD:/usr/bin/sslogger
/etc/sudoers entry to allow user1 to only run "ls" as user2
user1 ALL=(testy2) NOPASSWD:/usr/bin/sslogger -c ls, /usr/bin/sslogger -c ls *
sslogger.conf
See man pages sslogger.conf for details. Below is the defult configuration for /etc/sslogger.d/sslogger.conf:
# Config file for sslogger # # # Log output of all commands, even non interactive (1 is true). Default 0 log_all_cmds=0 # # Minimum Comment length in chars, if zero, no prompt min_comment=4 # # Maximum Comment length for messages sent to syslog # Full comment is always logged to /var/log/slog/slog.log max_comment=40 # # To allow normal users replay access to log files they create, Set below to 1 allow_user_replay=1 # # slogd server name or ip. # If commented out or empty remote log collection is disabled slogd_server= # #slogd service port slogd_server_port=5556 # # slogd auth type. Must match slogd server tls_authtype # Current options are "x509" or "anon". # Setting to x509 requires x509 tls certs # to be generated and pushed to all clients. slogd_authtype=anon # # When using a slogd server, and a sslogger session is over, and logs properly # transfered to slogd server, delete the local log file on exit. # Setting to 1 will enable keeping of all local log file. keep_local_logs=0 # # Policy for when a conection to a slogd server is unavailable or unexpectedly terminiated # If set to 1, ssloger will terminate if connection is broken to slogd server # and will die if it cannot connect to the remote slogd server at startup # If set to 0, local logging will be used when we can not contact remote server # or when a network conection to the slogd server is broken require_remote_slogd=0
Usage and commands
Example Usage:
Below is an exaple opeing an interactive session for root with remote logging enabled.
-bash-3.2$ slog Sslogger started, local logfile is /var/log/slog/2010/09/slog-rhel5-64c-user1-root-2010.09.05-10:27:06.log Reason for invoking thus interactive shell for root: test sslogger SlogdServer:bx4-rhel5 SlogdLogID: slogd-rhel5-64c.test.com-2010.09.05-10:27:06.000263.log [root@rhel5-64c ~]# ls /root anaconda-ks.cfg install.log install.log.syslog ldapauth-rhel5.tar.gz [root@rhel5-64c ~]# exit Session logs successfully sent to slogd server: bx4-rhel5 Removing local log file: /var/log/slog/2010/09/slog-rhel5-64c-user1-root-2010.09.05-10:27:06.log Sslogger done
The slog command
slog is a shortcut to running "sudo [-u $USER] sslogger [cmd and args]" See man slog for details
The sslogger command
sslogger is session keystroke logging utility and allows permitted users to execute commands, or open interactive shells. When used in interactive session mode, sslogger can record keystrokes as they are typed to a local file, or a remote slogd server. A tty is required for interactive sessions. See man sslogger for details.
The rslog script
rslog is still in developent, the intent is to enable running commands on remote hosts. Sample scritps are installes in /usr/share/doc/sslogger-0.96/rslog
Logging
Local logging
The default location for keystroke logs are written localy to /var/log/slog/$year/$month/slog-$host-$user-$runAsUser-$date:$second.log. The default owner for the log is sslogger, and can be reviewed by only by users in the sloggers group. See Replaying a session for details
In addition to normal sudo audit logs, sslogger will also create an entry in the syslog as well log an entry localy to /var/log/slog/slog.log describing the user and command that was run. The slog.log file also contains the optional reason and the complete path to keystroke slog file.
Remote Logging
Remote logging is similar to local loggined but add abiliy to centraly log and audit sslogger activity within your enviroment. Accepted client connections are logged to syslog, while details on the sslogger sessions are appended to /var/log/slog/slogd.log. The default path to the kestroke log is: /var/log/slog/$year/$month/slogd-$remoteHost-$date:$second.$micorsecond.log. Session keystroke logs are written as as they are recieved.
Remote Logging consists of 2 parts:
- Configure a remote sslogger-slogd server
- Configure the sslogger clients to point to the sslogger-slogd server
Configure a remote sslogger-slogd server
On redhat based sysems: yum install sslogger-slogd chkconfig sslogger-slogd on service sslogger-slogd start
Configure the sslogger clients to point to the sslogger-slogd server
edit /etc/sslogger.d/sslogger: # slogd server name or ip. # If commented out or empty remote log collection is disabled slogd_server=your-slogd-server.domain.com
Additional configuration notes
The default configuration is to allow anonomouus TLS contections from any clients. The authentication methods for both cliets and slogd server must match.
Default anonomous configuration client setting in sslogger.conf: slogd_authtype=anon server setting in sslogger-slogd.conf: use_tls_anon=1
For enhances security, singned CA certs can be used. A sample script to create CA certs is installed under /usr/share/doc/sslogger-0.96/mkSlogCert
Signed CA certs setting client setting in sslogger.conf: slogd_authtype=x509 server setting in sslogger-slogd.conf: use_tls_cert=1
See the man page for sslogger.conf for client details and sslogger-slogd for slogd server details.
Replaying a session
sreplay <log file>
Users must be in the ssloggers group in order to replay log files. See man page for sreplay for details and usage.
Large Scale and Enterprise Configurations
<Details Comming Soon>
Authentication
In order to manage a large environment of Unix bases servers, a central authentication source is critical. I am intimately familiar working in an large environment supporting a large amount of Unix based servers. Without the ability to manage user and group from a central source, managing large environments is impossible.
LDAP - 389 Directory Server
389 Directory server authentication is quite robust and easy to set up. Details can be found here 389 Directory Setup. Not only can it be used for user authentication, but it can also be used mange roles and grant sudo access to servers.
AD Integration
A necessary evil in some environments. AD Unix Authentication
Nis Integration
Your fathers authentication. No details will be provide without community support.
Sudoers and LDAP
Instead of local configurations, sudoers access can be managed by centrally manage LDAP infrastructure. The 2 main LDAP infrastructures are AD and 389 Directory Server and are detailed below. 389 client configurateions are detailed here Sslogger Main Page#389 Client Configurations
389 Directory Server
AD integration
389 Client Configurations
RHEL 5
Fedora
LDAP and automaps
http://directory.fedoraproject.org/wiki/Howto:Automount
Known Issues
Bugs, Issues, and Feature Requests
Contact the author: https://sourceforge.net/sendmessage.php?touser=2391261
