Keeping Root's Bash History File with Qualys Authenticated Scanning

Document created by Martin Walker Employee on May 4, 2017Last modified by Brian Canaday on Feb 20, 2019
Version 5Show Document
  • View in full screen mode

Many InfoSec teams who use Qualys Authenticated (Trusted) Scanning on *nix targets get complaints from the *nix platform admins about "filling up root's history file". This article describes some of the implications of Qualys' use of root's history file, and recommends an approach to separate Qualys history into its own file.


What is the history file?

The history file is a convenience tool that allows a portion of a user's (in this case root's) command history to be saved into a file and later replayed, optionally in an edited form. History is what allows a user to "arrow up" to re-run an earlier command, or to type "!ls" to rerun the last "ls" command with all its arguments. It is typically available in Bash and Korn shells and possibly others depending on the particular flavor of *nix you are using.


It should be noted that the history file is NOT an audit file, it is NOT a security log. History provides no security functions at all, it is strictly a convenience tool. It only optionally contains timestamps, and even more importantly, can easily be edited or deleted by the user without leaving a trace. If secure auditing is required, auditd is the tool that should be employed.


How does Qualys execute checks in an authenticated scan?

At a high level Qualys will initiate ssh connections to the target, authenticate, then execute "sudo su -" with an optional password, then run commands for the specific QID checks. These checks are usually executed from temporary script files created in /tmp, and often from pipelined strings of commands. Many of these require root level privileges on some or all *nix platforms (exactly why has been addressed in another recent article so will not be rehashed here). During a single scan of an individual target, Qualys will initiate many separate ssh connections. This is to ensure that each command runs in a clean, unperturbed shell. The end result of this is that root's Bash history file contains the commands Qualys runs during each session, and there are usually enough of them to obliterate commands run during the prior interactive session.


Controlling what is saved in .bash_history?

If your *nix platform admins use the history file for other things, like saving and replaying commands, this can be an annoyance. It is not a security concern. History will neither fill a file system, nor is it an audit mechanism, but history can be a convenient tool so saving that file is a nice idea. So, how do we accomplish this?


The size of the history file and optionally things like whether duplicate commands are ignored, if any commands are ignored, or the location of the file are set by environmental variables in files like ~/.profile, ~/.bashrc, ~/.bash_profile, ~/.kshrc, /etc/profile, and /etc/bashrc. These files can be modified to prevent the "filling up" of root's history file with the commands that Qualys runs during its checks. By default the size of the history file is usually 500 lines (platform dependent). Although it can be set to unlimited this is very unusual.




HISTCHARS defines up to three characters to control history expansion, HISTCMD is the index in the history list of the current command, HISTCONTROL controls how commands are saved in the history list, HISTFILE is the name of the file to which the command history is saved (usually ~/.bash_history), HISTFILESIZE is the maximum number of lines contained in the history file, HISTIGNORE is a list of patterns used to decide which command lines should be saved on the history list, HISTSIZE is the maximum number of commands to remember on the history list, and HISTTIMEFORMAT controls the optional timestamp format to display with each history entry.



How to separate Qualys history from root?

First, there is no danger of filling up a filesystem if typical values of HISTFILESIZE are maintained.


Second, the files in the /etc directory are global for all users, you should really avoid changing them if at all possible.


Now, from an individual user basis, the next question is why are there all these different files (.bashrc, .bash_profile, .profile, etc).

The primary thing to understand is that the rc files are for all shell invocations while the profiles are strictly for interactive shells. On top of that, if you are going to be using both ksh and bash, you should use .profile for ksh and .bash_profile for bash. Since most configuration directives recognized by ksh are also recognized by bash, some people who use both shells find it easier to just create a symlink between the two.


There is also the matter of .kshrc, which is actually not a file that the korn shell specifically looks for. It's just a practical convention, and many people use it, and then source the file from inside their .profile. Otherwise, ksh will not automatically read it.


In the case of Bash, probably the most common shell in use for *nix admins, the best way to prevent the overwriting of normal admin history with Qualys commands is to put the Qualys commands in a different history file and do so for interactive shells by modifying .bash_profile to set HISTFILE conditionally based on the original user.


At first blush it would seem that HISTSIZE would be the variable to use to control what commands are saved, but unfortunately this has the effect of truncating the history file eliminating all history, not just the Qualys history. Instead, the best mechanism is to simply send the the Qualys history to a different file based on detecting the original user that "sudoed" to root.


To do prevent putting Qualys commands in root's history file, add the following to the bottom of the root user's .bash_profile:

# Added to stop Qualys filling up history


if [ ${loginUser} == qualys ]; then

export HISTFILE=~/.qualys_history




Considerations when auto mounting /home from a NAS

If your organization stores the user’s /home directory on a NAS you will not want to simply redirect the history to a new file. Because the authentication is performed more than once to perform all the necessary checks to assess an asset this could cause unnecessary network traffic when a scan is run on a large number of hosts. With this configuration the growing file of bash history is returned to the asset, updated and saved back out to the remote disk with each check. To prevent this, you can set the following value for HISTIGNORE.



7 people found this helpful