Background
The topic of security of the account that Qualys uses for authenticated scanning on *nix systems is one that is broached by customers regularly. There is frequent angst among *nix administrators about the requirement for "sudo" root access. This article intends to provide some answers to mitigate that angst.
Auth Scanning Process Overview
One of the first things to note is that the OS fingerprinting plays absolutely no role in determining what authentication record to use. Authentication is based upon presence of the IP in an authentication record, and what ports are open. If 22/tcp is open on a Windows system and its IP address is on a *nix authentication record we will attempt authentication with that record. Similarly if you have SAMBA on a *nix system and the IP is on a Windows User-Selected IPs record or it otherwise satisfies the criteria (such as claiming membership in a doma matching an Active Directory record) we will attempt Windows authentication.
When Qualys performs an authenticated scan against a *nix system with a properly configured authentication record we will create an ssh session using the credentials in the authentication record, check the effective UID (level of access), execute "sudo su -" (or other root delegation command configured in the record), re-check effective UID to ensure the elevation worked, then begin our checks.
The second thing to note, is that most checks are run from small script files temporarily created in /tmp and removed following their execution. Finally, also be aware that because we need to ensure that we have a clean shell that is unaffected by the prior commands and possible abends, we do not run all checks through a single ssh session. Instead many individual ssh sessions are created during the scan.
This process tends to produce the following questions or concerns from customers:
1) You are "filling" up roots "history" file
2) How do we audit the activity being performed under the scanner account?
3) Unfettered root access is against policy, why do you need it?
4) I'm uneasy about this whole sudo root thing, how do we control it?
Filling Up root's History File
See my recent Keeping Root's Bash History File with Qualys Authenticated Scanning on the root history file and how to resolve it. First note, a Bash history file is NOT an audit mechanism (it is easily changed or removed without trace), it is NOT a security mechanism, it is simply a convenience feature for shell users. History files typically contain 500 or 1,000 lines (set by environmental variables) and is highly unlikely to fill a disk or cause other resource consumption issues unless this is set to some nonsensical value, in which case anything that can write to this file has the same opportunity to fill a filesystem. However history file behavior is controlled via environmental variables and the convenience requirement is easily solved.
Auditing Scanner Activity
As mentioned above, the history file is a convenience tool not an auditing or security tool. If the *nix team is using/claiming history as an auditing mechanism they are doing it wrong. The mechanism for auditing activity on a *nix system is typically auditd. If the team is concerned about auditing then auditd is the mechanism they should use. Auditd should be configured to send audit logs to some off-system receiver, possibly a SIM/SEIM system.
Why Do We Need root?
Hariom Singh wrote an excellent article regarding Policy Compliance on Unix Scanning Credential Requirement (Why Qualys PC requires root access). These arguments hold true for some of the VM QIDs as well. There are actually a relatively low number of QIDs that require root, most QIDs will run just fine without root. However, those that do need elevated privileges will likely fail in unpredictable ways if the service account does not have the necessary privileges. This is especially true if some control has been placed on the service account such that it has access for some commands and not others, and therefore an effective UID check indicates that sudo su - worked correctly even if we truly do not have root. The most likely failure mode for these QIDs is false negative.
How Can We Control root Activity?
First, customers should be strongly discouraged from placing granular controls around the Qualys service account because of the reasons stated above. In addition to this, new QIDs are published at a very rapid rate, and a new QID that requires root privileges and runs a new command (or an old command with different arguments), may be introduced without notice. There is no mechanism for identifying new QIDs that use new commands or use commands differently than past QIDs, therefore a customer who implements granular control around what the Qualys service account can run as root will likely never know when new QIDs are failing with a false negative. Even if it were possible to publish this list, it would likely take a lot of effort to maintain its currency. For *nix systems this problem is compounded by the multitude of *nix distributions and the many differences between them. AIX, Solaris, SuSE, RedHat, Debian.....the list of supported *nix-like operating systems is very large and each one may have a slightly different mechanism for the same QID. Simply listing installed packages for example (lslpp, pkginfo, zypper, rpmquery, dpkg....) is a very long list of potential commands. So the sudo list or equivalent would have to be maintained centrally for each flavor of *nix in the environment and pushed out to every system timely. This problem is further compounded by high-urgency vulnerabilities (shellshock, heartbleed, struts etc) which the time to detect is critical. For those that must be detected remotely, until the sudoers file has been properly updated on every machine the likelihood is a false negative of highly critical and time-sensitive vulnerabilities. It is simply not a reasonably manageable approach to security.
Below is a list of commands that a Qualys service account might run during a scan. Remember not every command is run every time, and *nix distributions differ. This list of commands is neither comprehensive nor actively maintained.
acroread
aex-diagnostics
aria2c
asadmin
asterisk
avahi-dnsconfd
awk
bogofilter
cat
clamav-config
cpio
ctastat
cups-config
cut
cvs
db2ls
defaults
df
dir
dnsmasq
dovecot
dpkg
dscl
dspmqver
echo
egrep
emgr
enable
env
esxupdate
evolution
export
fetchmail
find
firefox
free
freeciv-server
freetype-config
gconftool-2
gimp
git
gpg
gpgsm
grep
gs
gzip
hcpd
head
httpd
id
ifconfig
isainfo
istat
java
kextstat
konqueror
lftp
libpng-config
lighttpd
locale
locate
lookupd
ls
lsb_release
lscfg
lslpp
lsnrctl
modinfo
nagios
named
nano
nawk
ndd
netstat
nfsstat
nidump
omnicc
opatch
openssl
openvpn
opera
oslevel
pdns_recursor
perl
php
pkginfo
psql
putenv
python
radiusd
rm
rpcinfo
rpm
rssh
rsync
seamonkey
sed
sh
show
showmount
showrev
smbclient
smbstatus
smcwebserver
sneep
snort
spamass-milter
ssh
start
startserv
stat
strings
sudo
svcs
svn
sw_vers
swlist
sysctl
sysinfo
system
system_profiler
tar
tcpdump
test
tethereal
tftp
thunderbird
tiffinfo
tr
ttversion
uname
uniq
unzip
user
uudecode
uustat
vlc
vm_stat
vmstat
vmware
vmware-installer
vpn
wadm
weborf
webservd
weechat-curses
which
whoami
wireshark
xmms
ziproxy
