How to make sure your Linux system users won’t hide or delete their .bash_history / Securing .bash_history file

If you’re running multi user login Linux system, you have probably realized that there are some clever users that prefer to prevent their command line executed commands to be logged in .bash_history.
To achieve that they use a number of generally known methodologist to prevent the Linux system from logging into their $HOME/.bash_history file (of course if running bash as a default user shell).
This though nice for the user is a real nightmare for the sysadmin, since he could’t keep track of all system command events executed by users. For instance sometimes an unprivilegd user might be responsible for executing a malicious code which crashes or breaks your server.
This is especially unpleasent, because you will find your system crashed and if it’s not some of the system services that causes the issue you won’t even be able to identify which of all the users is the malicious user account and respectively the code excecuted which fail the system to the ground.
In this post I will try to tell you a basic ways that some malevolent users might use to hide their bash history from the system administrator.
I will also discuss a few possible ways to assure your users .bash_history keeps intact and possibly the commands executed by your users gets logged in in their.
The most basic way that even an unexperienced shell user will apply if he wants to prevent his .bash_history from sys admins review would be of directly wiping out the .bash_history file from his login account or alternatively emptying it with commands like:

malicious-user@server:~$ rm -f. bash_history
ormalicious-user@server:~# cat /dev/null > ~/.bash_history

In order to prevent this type of attack against cleaning the .bash_history you can use the chattr command.
To counter attack this type of history tossing method you can set your malicious-user .bash_history’s file the (append only flag) with chattr like so:

root@server:~# cd /home/malicious-user/
root@server:~# chattr +a .bash_history

It’s also recommended that the immunable flag is placed to the file ~/.profile in user home

root@server:~# chattr +i ~/.profile

It would be probably also nice to take a look at all chattr command attributes since the command is like swiss army knife for the Linux admin:
Here is all available flags that can be passed to chattr
append only (a)
compressed (c)
don~@~Yt update atime (A)
synchronous directory updates (D)
synchronous updates (S)
data journalling (j)
no dump (d)
top of directory hierarchy (T)
no tail-merging (t)
secure deletion (s)
undeletable (u)
immutable (i)

It’s also nice that setting the “append only” flag in to the user .bash_history file prevents the user to link the .bash_history file to /dev/null like so:

malicious-user@server:~$ ln -sf /dev/null ~/.bash_history
ln: cannot remove `.bash_history': Operation not permitted

malicious-user@server:~$ echo > .bash_history
bash: .bash_history: Operation not permitted

However this will just make your .bash_history append only, so the user trying to execute cat /dev/null > .bash_history won’t be able to truncate the content of .bash_history.

Unfortunately he will yet be able to delete the file with rm so this type of securing your .bash_history file from being overwritten is does not completely guarantee you that user commands will get logged.
Also in order to prevent user to play tricks and escape the .bash_history logging by changing the default bash shell variables for HISTFILE an d HISTFILESIZE, exporting them either to a different file location or a null file size.
You have to put the following bash variables to be loaded in /etc/bash.bashrc or in /etc/profile
# #Prevent unset of histfile, /etc/profile
# Don't let the users enter commands that are ignored# in the history file
readonly HISTFILE
readonly HISTSIZE

everytime a user logs in to your Linux system the bash commands above will be set.
The above tip is directly taken from Securing debian howto which by the way is quite an interesting and nice reading for system administrators :)

If you want to apply an append only attribute to all user .bash_history to all your existing Linux server system users assuming the default users directory is /home in bash you can execute the following 1 liner shell code:

#Set .bash_history as attr +a
2. find /home/ -maxdepth 3|grep -i bash_history|while read line; do chattr +a "$line"; done

Though the above steps will stop some of the users to voluntary clean their .bash_history history files it won’t a 100% guaranttee that a good cracker won’t be able to come up with a way to get around the imposed .bash_history security measures.

One possible way to get around the user command history prevention restrictions for a user is to simply using another shell from the ones available on the system:
Here is an example:

malicious-user:~$ /bin/csh

csh shell logs by default to the file .history

Also as far as I know it should be possible for a user to simply delete the .bash_history file overwritting all the .bash_history keep up attempts up-shown.
If you need a complete statistics about accounting you’d better take a look at The GNU Accounting Utilities

In Debian the GNU Accounting Utilities are available as a package called acct, so installation of acct on Debian is as simple as:

debian:~# apt-get install acct

I won’t get into much details about acct and would probably take a look at it in my future posts.
For complete .bash_history delete prevention maybe the best practice is to useg grsecurity (grsec)

Hopefully this article is gonna be a step further in tightening up your Server or Desktop Linux based system security and will also give you some insight on .bash_history files :) .

Share this on

More helpful Articles

Download PDFDownload PDF


17 Responses to “How to make sure your Linux system users won’t hide or delete their .bash_history / Securing .bash_history file”

  1. Rob Fortune says:

    Download own statically compiled bash, run it on top. You’d need to poll /proc/[0-9]+/exe say once every 10 seconds to stop this one and I wouldn’t have to use horrible csh :)

    Also, you say chattr +a allows deletion, I don’t know what kernel you are running but under OpenSUSE’s version of it doesn’t allow deletion and if it does in mainline (which I find a bit hard to believe) then you could easily patch it not to.

    Thanks for the other commands though, not being a sysadmin anymore they’re not really relevant and I would only rely on process accounting to account for process activity, none-the-less, interesting read.

  2. Rob Fortune says:

    BTW, a lot of those attributes aren’t respected by filesystems, the “secure delete” being a prime example, ext2 ext3 are explicitly mentioned as ignoring it in the manual, I tested it with ext4 and ext4 too takes no notice. I filed a bug on it and the response made me believe there are other attribs commonly ignored – you should test they actually work with your file system before relying on them.

  3. Rob Fortune says:

    And from bash man page:

    Do not read either the system-wide startup file /etc/profile or any of the personal initialization files ~/.bash_profile, ~/.bash_login, or ~/.profile. By default, bash reads these files when it is invoked as a login shell (see INVOCATION below).

    So I gave it a little try and viola, a login shell without downloading my own where I can unset HISTFILE :)

    • admin says:

      Thanks for all the feedback Rob! That’s a good points to expose how hardly Linux can be secured nowadays.


  4. Rob Fortune says:

    And then there is history -c …

  5. Rob Fortune says:

    rob@bob:~/tmp/foo> exec env -i bash –noprofile –norc
    bash-4.1$ unset HISTFILE

  6. Rob Fortune says:

    You could of course patch bash to not have these options, but you were correct in saying “it won’t a 100% guaranttee that a good cracker won’t be able to come up with a way to get around the imposed .bash_history security measures.”

    I’m far from a good cracker :) I bet there are other ways around it too.

  7. Rob Fortune says:

    Do you have python or perl installed? A quick REPL loop that executes system calls and you have a very lame bash with no history :)

    • admin says:

      Yes you’re absolutely correct. What I meant by this post was just to give a basic overview on the current ways to improve a lame person who has access to the shell not to be able to delete their history. I know it’s far from superior :)

  8. Doug Mckay says:

    Absolutely the best software I’ve used to date, automatically detects a plethora of patterns and automatically adds the IP to the iptables block list. Has lots of extra features for detecting malicious file activity and SU logins as well as some basic checks to make sure your configurations are secure.

  9. Ali Rabiee says:

    Thank you, the post’s and the comments’ authors.

  10. Milo says:

    To prevent saving session-history to .bash_history:
    $  ps
      PID TTY          TIME CMD
    13803 pts/4    00:00:00 bash
    15368 pts/4    00:00:00 ps

    $  kill -9 13803
    Kill the login-shell process instead of logging out the normal way.

  11. How can I audit users and access attempts to SSH on my server? - Popular Ubuntu Questions says:

    […] Prevent users from deleting logs: Users shouldn’t be able to touch auth.log. In order to stop them from playing with bas_history you need to do a couple of tricks. […]

  12. How can I audit users and access attempts to SSH on my server? | XL-UAT says:

    […] Prevent users from deleting logs: Users shouldn’t be able to touch auth.log. In order to stop them from playing with bas_history you need to do a couple of tricks. […]

Leave a Reply

Notify me of followup comments via e-mail. You can also subscribe without commenting.