Forum

Notifications
Clear all

Qualys Troubleshooting

4 Posts
1 Users
0 Reactions
1,837 Views
Posts: 12
Admin
Topic starter
(@netsec)
Member
Joined: 5 years ago

Troubleshooting "Hosts Not Alive"

Problem

During the host discovery phase, the service checks if the host to be scanned is up and running in order to avoid wasting time on scanning a dead or unreachable host. The "No Host Alive" message displayed on the screen means the scanner did not find the target to be alive during  the Discovery phase of the scan. If the host is not "alive" then the scan will not proceed beyond this point and no assessment will be performed. 

Error

Hosts are shown under the "Hosts Not Alive" section of scan results

Cause

To determine if the host is “alive”, the service pings each target host using ICMP, TCP, and UDP probes. The TCP and UDP probes are sent to default ports for common services on each host, such as DNS, TELNET, SMTP, HTTP and SNMP. If any of these probes t doesn't trigger any response from the host, the host is considered as not alive.
The types of probes sent, and the list of ports scanned during host discovery are configurable in the option profile (see Host Discovery on the Additional tab in the profile). 

Ports used for host discovery:  

  • TCP SYN packets are sent to these well-known TCP ports: 21, 22, 23, 25, 53, 80, 110, 111, 135, 139, 443, 445 and 5631.

  • TCP ACK packet with a source port of 80 and a destination port of 2869 

  • TCP ACK packet with a source port of 25 and a destination port of 12531 

  •  TCP SYN-ACK packet with a source port of 80 and a destination port of 41641 

  • UDP packets are sent to the following well-known UDP ports: 53, 111, 135, 137, 161, 500 

  • ICMP ‘Echo Request’ packets 

Solution
  • Ensure that the Qualys scanner is able to reach the concerned target on required ports.
    • For external scans, go to Help > About to see the IP addresses for external scanners to whitelist.
    • Users can run the following command on the endpoint during scan to determine what ports are open on the host at that time: netstat -anp
  • Enable ICMP to the system, this will allow the system to be discovered alive.

  •  If there are any other ports open on the target, other than those mentioned above, you may add these ports in TCP Ports/UDP ports in Additional tab of the Option Profile. 

  • You can choose to scan “dead” hosts through your scan options in the option profile (see Scan Dead Hosts on the Scan tab in the option profile), but this may increase scan time and is not suggested for Class C or larger networks.

If you have ruled out the above reasons, then debug scan will be required against the target to get additional information to investigate the issue further.

3 Replies
Posts: 12
Admin
Topic starter
(@netsec)
Member
Joined: 5 years ago

Issue: The host was not scanned with authentication using the VM module, or this record type is not appropriate for the host.

 

Video: Secure Unix Authentication

https://vimeo.com/showcase/4948215/video/252606942

 

About Remote and Authenticated Scans

In an Authenticated Scan, the scanning service is allowed to log in to each target system during the scan. This enables in-depth security assessment and visibility into the security posture of each system. This scan gives you the most accurate results with fewer false positives. The scanner checks the complete remote registry, packages, registry key configuration, non-running kernels, Cisco configuration, and more for vulnerabilities. For more details, see Why Use Host Authentication?

Advantages of an authenticated scan:
Complete Patch Audit: Relying on a patching solution to audit and report solely on what was patched is not adequate. A patching solution must have defined objectives to ensure whether the patch is deployed and to register it as installed. Qualys through the use of authenticated scanning verifies more on the endpoint instead of relying solely on the software lists of the installed packages. It also verifies whether the endpoint is flagged for a reboot.  Since many updates require a reboot, the actual patch remains staged on the endpoint. Upon reboot, the core system files need to be unhooked and can be replaced. With a patching solution that does not take this into account and just reports "patched", while the system requires a reboot, the endpoint continues to remain vulnerable until reboot. Such lapses can lead to organizations staying vulnerable to a large number of unpatched vulnerabilities. 

Many Potential vulnerabilities are converted to Confirmed vulnerabilities: 

Authenticated scans save time by minimizing potential vulnerabilities and assist in prioritizing confirmed vulnerabilities as Authenticated scans give you the most accurate results, with fewer false positives. There are vulnerabilities in the Qualys KnowledgeBase that can be tested only with authentication on the target host. You can use this information to prioritize remediation that can save time and money. 

Robust information gathering: Authenticated scans assist in more robust information gathering. You can check more than 100+ QIDs with information such as OS detected, Application running, open ports, Software's, Antivirus, Browser's detected, and many more. Refer to the Resources section for information on the supported OS for authentication.

Reply
Posts: 12
Posts: 12
Admin
Topic starter
(@netsec)
Member
Joined: 5 years ago
Document created by Martin Walker on May 15, 2017. Last modified by Martin Walker on Aug 24, 2021.
Description

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

Reply
Share: