Table of contents :
The theory behind local security checks and common questions about them
How to enable local security checks
Acknowledgements
The theory behind local security checks
What are "local" security checks ?
Starting with Nessus 2.2, it is possible to give Nessus SSH credentials to
log into the remote Unix systems and determine which patchs need to be applied.
What this really means is that if you give Nessus the proper SSH key, it will litterally log into the remote host, extract the list of installed software, and tell you which packages have an update ready for them.
The real goal of this feature is to easily keep track of all the missing patches of a given system, without the potential hazards and false positives of remote security checks. It is really important to understand that enabling local
security checks do not discover flaws such as unauthorized suid binaries, they simply determine which patches are missing from the remote operating system.
Which operating systems are supported at this time ?
At this time, Nessus is able to determine the missing patches of the following operating systems :
We hope to support more systems in the future (Tru64, etc...)
Which Solaris patches are checked for ?
We have implemented checks for Solaris 2.5.1, 7, 8, 9 and 10 (both on sparc and i386 architectures). We check for every patch listed by Sun in the "Patch containing security fixes" section of their patch page.
What are "local" security checks NOT ?
At this time, Nessus does not check the local security policy of the remote system, like
Tiger does (ie: directories
writeable by any users, wrong permissions on a sensitive configuration file, and so on...). We may
implement this feature as a NASL script in the future though.
Why do we need to perform local security checks ? Is not Nessus good enough to determine security issues ?
Nessus 2.0 is, at its heart, a network based scanner. This means that it will connect to the remote host
and attempt to determine the flaws affecting every service on it. However, testing everything from the point of view of the network has its own shortcomings. In particular, a 100% network-based security scanner can not do the following :
- Determine client-side flaws : There are more and more client-side vulnerabilities published every day, ranging from flaws in mail clients to XML libraries. It simply is not possible to check for those from the point of view of an active scanner. The only way to detect such flaws is to deploy a passive scanner (ie: PVS) or to locally check that every host has been patched.
- Determine local flaws : Obviously, the security level of local utilities can not be determined from the point of view of the network. By running local security checks, Nessus will tell you if a user logged into the remote host
can use an overflow in a suid binary to gain root privileges ;
- Determine flaws in disabled services : If a host has a vulnerable service installed, but it's not running at the time of the scan, a vulnerability will be missed. Having an unpatched disabled service is a potential security hazard - if the service is ever enabled in the future, it might be exploited.
So traditional network-based scanners have their inherent limitations, which can now be overcomed thanks to this new feature.
I have compiled my DNS server by hand instead of using the system's one. Will Nessus see it ?
No. Nessus sticks the patches provided by your OS vendor. However, note that it usually is a good administrative practice to stick to your vendor packages, as
it makes the upgrade of your system much easier.
In the future, Nessus might be able to detect if a running server is not of the same version as the one installed by RPM (or any other packaging system) and may improve its output this way.
Why should I care if my web server has local overflows in suid binaries ? There's no local user on it, apart from me !
When I first talked about this feature, many people would object that they don't really care about local security
because their server simply is a web server with no local users, therefore nobody can exploit a local vulnerability.
The answer is a simple security practice: containment. If your web server is vulnerable to a given flaw (be it a misconfiguration,
a badly written PHP script, or an 0day in Apache), an attacker will be able to obtain a shell on your system. The question
really is : do you want to make it easy for the attacker to gain super-user privileges and gain the full control of your system,
or do you want to contain him to the privileges your web server is running with ? (these privileges will prevent the attacker
to modify your kernel, load a rogue kernel module, and generally will make it harder for him to cover his tracks).
So local security really matters, since it's your last line of defense.
How enabling local security checks can improve my scanning experience ?
Depending on how you use them, local security checks can dramatically improve your scanning experience :
- By reducing false positives: it is not always possible to remotely determine if a given service is vulnerable to a given flaw or not (sometimes the only way to check for it is to actually crash the service, which is not an option in a production network). Sometimes, vendors do not upgrade a faulty product to the newest version but backport the fix instead (see Red Hat's statement about this), which also makes life more difficult for network-based scanners ;
- By speeding up the checks: if all you are interested in is to determine if all the patches have been installed on your remote hosts, you may want to only enable local security checks and dramatically reduce the time it takes to scan your systems.
It only takes 6 seconds to find all the local flaws of a remote system (over a VPN link) whereas it takes over one minute to scan the same system entirely with all the network checks ;
- By scanning more often: Every network-based security scanner create the risk of crashing devices/services on your network.
This is not specific to Nessus, this really is a hard fact about security scanning in general. The reason is simple : a scanner attempts to connect to all the services on the remote host, and some services (and TCP/IP stacks) out there are so poorly written that connecting to them too quickly or not sending them the exact data they are waiting for may crash them. No matter how gentle the scanner is, there is always a risk of crashing a custom application, a loaded server which is low on memory, and so on. This is especially true for embedded devices, most of which being designed without any consideration for security. There are scanners vendors out there who are trying to claim that they have reached "100% unintrusive scanning", and this is just a blatant lie. If a scanner interacts with a network service, there is always a risk for crashing it.
As a result, many people only scan once a month or once a quarter, even though security issues
appear every day !
By only enabling local checks and disabling port scanners and every other plugins, nessusd will only connect to the SSH port of the remote hosts - no stress on the network, no bad surprises.
So wether you administrate a small number of hosts or a huge number of systems, local security checks can definitely make your job much easier.
Does this feature slow down the scan ?
No. Nessus will minimize the number of SSH logins into the remote host, and will
actually log in once, then load its knowledge base with various information found on the remote host. Please view the source code of the plugin ssh_get_info.nasl for more details about what is gathered.
What are the caveats of this new feature ?
At this time, the following caveats are known :
- Only SSHv2 is supported. You can not log into the remote host using SSHv1
- This documentation only deals with OpenSSH.
- If you use password-based authentication for SSH (which we do not recommend), Nessus will be vulnerable to man-in-the-middle attacks which may allow an
attacker on your local network to steal the password of the user.
How to enable local security checks
As a reminder, if you are interested in Windows security checks please read this document instead.
The principle
To enable local security checks, the idea is to :
- Create a SSH private/public key pair for Nessus to use
- Create a user account on every system for which you want to perform a local scan
- Copy the SSH public key Nessus will use in the directory of the new user
- Tell Nessus to use this SSH private and public keys and perform the scan
As you can see this is pretty simple. Nessus can not use password authentication, otherwise it would be vulnerable to a man-in-the-middle attack when scanning the remote systems (we do not want to handle key management for the remote systems just yet).
If you are not familiar with SSH public key authentication and understand what it does, you may want to read this document.
Generating a SSH public key
To generate a SSH public key, use ssh-keygen and save the key in a safe place.
$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/Users/renaud/.ssh/id_dsa): /home/renaud/Nessus/ssh_key
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/renaud/Nessus/ssh_key.
Your public key has been saved in /home/renaud/Nessus/ssh_key.pub.
The key fingerprint is:
06:4a:fd:76:ee:0f:d4:e6:4b:74:84:9a:99:e6:12:ea renaud@myth.local
|
As you can see in the example above, two files have been created :
- /home/renaud/Nessus/ssh_key is the private SSH key. Do not transfer it on a system other than the one running your Nessus client.
- /home/renaud/Nessus/ssh_key.pub is the public SSH key. You will copy this file on every system you want to scan with Nessus.
When ssh-keygen asks you for a passphrase, you may want to enter return twice (ie: don't set any passphrase). It's safer to protect a key with
a passphrase, however, given the way Nessus is implemented it will not buy you extra security, as the passphrase will have
to circulate between your Nessus client and the Nessus server, and will be stored in clear text in your .nessusrc configuration
file. If you feel safer, feel free to enter a passphrase
Creating a user account and setting up the SSH key
On every platform you want to test, you want to create a new user account dedicated to Nessus. We will call this user nessus
in this document, but you can set his name to any value.
Once you created an account for the user (using adduser or any utility that the system provides you with), make sure that he has no valid password set (ie: when editing the file with 'vipw' make sure that the password field only contains a star) :
# vipw
(...)
nessus:*:502:502::0:0:Nessus Test Account:/home/nessus:/bin/bash
(...)
|
Now that the user has been created, you simply need to copy the key to his home and set the correct permissions on the .ssh directory :
# mkdir ~nessus/.ssh
# mv ssh_key.pub ~nessus/.ssh/authorized_keys
# chown -R nessus:nessus ~nessus/.ssh/
# chmod 0600 ~nessus/.ssh/authorized_keys
# chmod 0700 ~nessus/.ssh/
|
Setting up Nessus
First, make sure that you are running Nessus 2.2.0 or newer and that
it has been compiled with SSL support. You can do that by typing nessusd -d :
[root@myth Home]$ nessusd -d
This is Nessus 2.2.3 for Darwin 7.4.0
compiled with gcc version 3.3 20030304 (Apple Computer, Inc. build 1495)
Current setup :
nasl: 2.2.3
libnessus: 2.2.3
SSL support: enabled
|
Then fire the Nessus GUI, and go to the 'Credentials' section and set the SSH user name and SSH keys properly :
Make sure not to mix the public key (keyname.pub) and the private one. Make sure that the option "enable dependencies" at
runtime (in the plugins) section is checked, and run a scan against the remote host. The Nessus report should now tell you that
login in was successful, and should show you all the missing patches on the remote system :
Repeat the operation for every server for which you want to do a local scan, and you are ready to go !
|
|
