Using screen to log user actions (auditing) on ​​Linux

Task:

Collect information about user actions (auditing) in the Linux console, namely the commands entered by him and the information displayed on the screen.

Proposed solution:

default screen for all users on Linux with logging

The necessary conditions:

1. Full logging of all users in the console, including the information output by the processes, so that you can evaluate why the user made this or that decision
2. Without the ability to disable logging
3. Since I chose screen, we use its capabilities to the maximum (opening new windows, shutting down by ^ a + d, leaving workflows running and other amenities)
4. Maximum convenience - there should not be any incompatibilities with applications
5. In the case of use by users not familiar with the screen - to make the work as familiar as possible and close to the usual command shell (shell)

')

Possible options:

1) The option offered on Habré . Work, but there are a few points:

• In an amicable way, one would have to specify the user's shell in / etc / shells
• screen as such does not work. In other words, additional windows do not open.
• Logging is disabled by the commonplace ^ a + H (capital)

2) Here, too, options are offered, but this is more raw billet

So let's get started:

There are 2 possible uses of screen for our task:

• Use the native command shell (shell), and then call screen automatically by the script
• Using screen as a user command shell

Judging by the quotes on the link, the second option is not good

Create a script to start screen so that when you start the bash command shell (after all, you have bash, right?), All users use this file and load it into the default screen with logging enabled. When you exit the screen - the session closes:
vi /usr/local/bin/get_in.sh

 #!/bin/sh SCREEN=/usr/bin/screen KILL=/bin/kill ## Check if we are already in screen ($STY is set) if [ -z "$STY" ]; then $SCREEN -LARR -S Shared -c /etc/screenrc ## Force SHELL close on exit - we don't want to allow users to escape logging outside screen $KILL -SIGHUP $PPID fi 

What we have:
-L - send the entire log to a file (where exactly - see the logfile directive in the / etc / screenrc file below)
-A - Adapt the size of the windows to the size of the current terminal. Taken from here .
-RR - reconnect the session and, if necessary, detach it or re-create it. The first session is used if more than one is available. In case of disconnection by ^ a + d, when you log in again, the same session of the same user will open.
-c - we clearly indicate which configuration file to use to avoid the possibility of disabling logging and reassigning options by users, for example, by creating a file in ~ / .screenrc.
-S - Assign session a friendly name. Each user can have the same name.

Making the script executable:
chmod 0755 /usr/local/bin/get_in.sh

Make it so that everyone uses this script. To do this, add the line to the end of the /etc/bash.bashrc file:
/usr/local/bin/get_in.sh

Correct the / etc / screenrc file:

 ## ,          .    (on),   . startup_message off # default: on ##    -   ""   shell vbell off ##      4096.    - 100. defscrollback 4096 # default: 100 ##    (shell),       .     $SHELL.      '-' ,       login-shell. defshell -/bin/bash ##      ^a+[ . crlf off # default: off ##      . caption always "%{= kg} %H | %{kc}%?%-w%?%{kY}%n*%f %t%?(%u)%?%{= kc}%?%+w%? %=|%{kW} %l %{kw}| %{kc}%{-b}%D, %m/%d/%Y | %{kW}%{+b}%c %{wk}" ## Set terminal cap info termcapinfo xterm* 'hs:ts=\E]0;:fs=\007:ds=\E]0;\007' hardstatus off ##        screen (^a + H) bind H ##     - logfile /var/log/screen/$USER@%H-%Y%m%d-%c:%s.log ## By default, screen uses an 8-color terminal emulator. Use the following line to enable more colors, which is useful if you are using a more-capable terminal emulator: term screen-256color ##       - logtstamp on 

Do not forget to create a directory for logs:

 mkdir /var/log/screen 

 chmod 0777 /var/log/screen 

By this we achieve that all commands will be logged in log files of the form:

/var/log/screen/user@server-20130716-19:52:34 min4.log

In Debian, in order for command completion to work (bash_completion) to work in screen, you need to uncomment it in /etc/bash.bashrc:

 # enable bash completion in interactive shells if [ -f /etc/bash_completion ] && ! shopt -oq posix; then . /etc/bash_completion fi 

Dear 1ex suggested the solution , how to use the wrapper for ssh to log commands that are executed without entering the interactive mode of bash like: ssh user @ host "ls -l". For this you need:
in / etc / ssh / sshd_config specify the reference to the wrapper processing:

 ForceCommand /etc/ssh/hook.sh 

Then create the wrapper itself /etc/ssh/hook.sh:

 #!/bin/sh if [ ! -z "${SSH_ORIGINAL_COMMAND}" ]; then echo "User "${USER}" remotely runs a command: ${SSH_ORIGINAL_COMMAND}" >> /var/log/screen/$USER@`hostname`-`date +%Y%m%d-%H:%M:%S`-command.log bash -c "$SSH_ORIGINAL_COMMAND" else cat /etc/motd ${SHELL} fi 

Do not forget to make it executable:

 chmod +x /etc/ssh/hook.sh 

By this we ensure that all such commands (and only commands - without information that is displayed on the screen) are logged in the same directory and will be supplemented with the suffix "-command":

/var/log/screen/user@server-20130717-12:47:53-command.log

Well that's all. Now, when connecting, all users (including root - be careful if you lose the ability to log in!) Will work in the screen, which runs from bash. When you exit the screen, the parent bash is closed and the connection is terminated. If it is necessary to leave the processes running in the background, then to exit use ^ a + d. The next time you connect, this session will connect automatically .

For further study:

• Since the output of commands is written to logs, they can take up a large amount of space. It is necessary to provide compression methods to reduce the volume / traffic.
• The best place for logs is the remote machine and further processing is done there, since the logs on the local machine are created with the user's uid / guid and can be deleted / changed by it. It is supposed to use syslog.
• Perhaps there are methods to bypass the screen and, accordingly, logging with this configuration. I would like to hear them and make changes

Sources used:

• http://habrahabr.ru/sandbox/65904/
• http://superuser.com/questions/52297/use-gnu-screen-as-login-shell
• https://spaces.seas.harvard.edu/display/USERDOCS/How+to+use+%2727screen%27+for+remoteshell+sessions
• http://www.linuxjournal.su/?p=3495
• http://www.howtoforge.com/options-for-user-auditing-on-linux-platforms

Update:

1) By remarks joneleth paths are changed to hard:
Paragraph:

 SCREEN=`which screen` KILL=`which kill` 

Replaced by:

 SCREEN=/usr/bin/screen KILL=/bin/kill 

At the moment there are 2 ways to bypass the command logging:

1) Promoted by kiltum : commands like ssh user @ host "ls -l" are not logged. In this case, the commands are executed as / bin / bash -c <command>, and the desired /etc/bash.bashrc is not readable.
Dear 1ex suggested solution using wrapper for ssh. Now all commands of this type are logged. Changes to the text made.
2) ForeverYoung is prompted : the screen -X log command disables logging.
There is no possibility to disable this feature, so it is necessary to apply administrative measures to users who run this command (this command itself will still be recorded in the log).
Best solutions are welcome.

RESULTS:

As it turned out, the screen is not exactly intended for solving such tasks, namely, forced logging of commands and their output without the possibility of disabling logging. This leads to the fact that you have to additionally edit other files.
As recommended by the respected amarao for solving such problems, it is better to look at other solutions:
a) sniffing all traffic passing through pseudo-terminals (more seriously). kiltum prompted conspy . Slipeer suggested Snoopy Logger .
b) audit systems (SELinux / Apparmor / etc), which will actually record everything being executed.
But these decisions are beyond the scope of this article.

I believe that despite the shortcomings, using screen for logging user actions and displaying information on Linux is justified, due to the ease of implementation, and most importantly, ease of reading logs (unlike auditd, for example).