Quite often we come across companies that have security tools available to them which could prove useful for internal security auditing, but often the tools are under-utilised or misconfigured meaning they don’t get the best out of them. Running regular penetration tests and vulnerability scans will help keep organisations aware of risks and make them more effective at managing them. In combination with a good patching policy and change control, it is possible to maintain a minimal attack surface both internally and externally.
This is often the case when administrators don’t have time to do more than just scratch the surface, or there are different teams coming up against configuration issues which prevent them getting the results they need. These configuration challenges can often occur when doing authenticated scans for compliance checks and build reviews. If the authentication is not set correctly, or there are other configuration issues, then you will not get a good scan and potentially miss important findings.
One of the more common scanning tools we use within organisations is Tenable’s Nessus, which is a well-known industry standard vulnerability scanner and management solution. It comes in standalone or cloud-based versions and is a great way to identify issues in an easy-to-use graphical interface. Tenable also provide some excellent FAQs on their website, and support is available, so it is always recommended to use these as required.
This two-part article covers some common configuration tips that can help to get the best results from a standalone Nessus installation.
Part One - Authenticated Scanning
Unauthenticated scanning only gets you so far, and whilst it will help to identify common problems, often it is the tip of the iceberg in terms of finding vulnerabilities. To get the most out of any vulnerability assessment, build review or compliance audit, it is best to run authenticated scans against servers and workstations. This will expose much more information and additional vulnerabilities that cannot otherwise be enumerated, including out-of-date patches for operating systems and installed software, and configuration issues that can creep in over time. It is common to see patches deployed but remain ineffective as they require to be implemented. A good example is patching for mitigation of the Spectre, and Meltdown vulnerabilities. These can be installed but are not activated by default, as there are performance considerations when the patches are enabled. This requires a further registry change, which administrators would need to deploy to mitigate the vulnerability. In a normal patching routine, it can look like everything is up to date (as the patch is installed) but the additional configuration is not in place. Authenticated scanning will detect these types of issues.
There are some challenges to overcome in order to get good scans. Windows has prerequisites depending on whether the authentication will be using a domain administrator account or a local account. Similarly, Linux can sometimes be more difficult to authenticate to when you need to run sudo or su to elevate privileges. This is becoming more common as IT departments are implementing more stringent security policies.
First some key requirements:
1. Create a dedicated local or login for the scans. Most administrators will prefer to use local administrative access, however in larger organisations this may not be practical, and a domain account with full administrative rights over workstations will likely be easier to manage. Keeping a separate domain administrator account is recommended and this can be closely monitored and enabled/disabled before and after scans.
2. Test the login works on one or more of the device(s) you are testing.
3. Ensure safe scans are enabled - this is generally the default setting in Nessus but it's always good to check before running an audit.
3.1 The global settings can be found under settings, Advanced, and then selecting the Scanning tab:
3.2 The policy used can also override the global settings, it is a good idea to check these as well:
4. Ensure regular updates are enabled so you get the latest findings - Tenable release new updates all the time - a valid license is required for plugin updates.
5. Double check whether antivirus has intrusion prevention settings - some AV products have modules which will actively block connections and prevent the scans Nessus makes. You may therefore need to organise a whitelisting for the scan server’s IP address. This can often be spotted if you get incredibly long running scans, or network interference warnings. Often the AV logs will also show active blocking alerts.
Windows Authenticated Scans
In general, a domain administrator account will have all the necessary rights to access servers and workstations, however the following should also be checked:
• Ensure the account is a domain administrator, and/or has full administrator rights over the workstation/server.
• Enable the remote registry service. Normally Nessus will try to start this during a scan, often corporate policies will restrict this by disabling it, and if it is disabled by policy then it won't complete a full scan.
If local authentication is used there are some more steps required before a scan will complete successfully:
• The account must be an administrator, so make sure it is in the administrator’s group on the local machine.
• Ideally create a new account for the testing so it can be monitored more easily should you need to and give it a strong password.
• Enable the remote registry service - normally Nessus will try to start this during a scan, often corporate policies will restrict this by disabling it, and if it is disabled by policy then it can't complete a full scan.
• For the local login method, the built-in UAC controls on Windows will silently prevent so this needs to be enabled before a full audit of the operating system can be achieved. To enable access, do the following:
1. Click Start, click Run, type regedit, and then press ENTER.
2. Locate and then click the following registry subkey: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
3. If the LocalAccountTokenFilterPolicy registry entry does not exist, follow these steps:
3a. On the Edit menu, point to New, and then click DWORD Value.
3b. Type LocalAccountTokenFilterPolicy, and then press ENTER.
4. Right-click LocalAccountTokenFilterPolicy, and then click Modify.
5. In the Value data box, type 1, and then click OK.
6. Exit Registry
Note: this can be reversed or removed following testing. It may be easier to deploy a group policy within domains or during large audits. In addition, you can use the following one-line commands if you are auditing more manually:
To check the key is set:
reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system /v LocalAccountTokenFilterPolicy /v LocalAccountTokenFilterPolicy
To add the key:
reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system /v LocalAccountTokenFilterPolicy /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f
To remove the key:
reg del HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system /v LocalAccountTokenFilterPolicy /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f
Linux Authenticated Scans
The root account will be all you need to conduct Unix based scans and audits, however it may be necessary to configure additional settings. The most common occurs when logging on directly with root is not possible and you must su or sudo to elevate permissions.
The difference between su and sudo is the password they require.
su which stands for 'switch user' (and in most cases it will be root) requires the , whereas sudo which stands for 'superuser do', requires the current user’s password.
Users with sudo rights are known as sudoers and have elevated rights assigned to them in the /etc/sudoers file. This is similar in a way to UAC in that it is prompting for authentication/authorisation when an elevated function is required but does not require a root password.
In general, the following should be checked:
• Verify if the root account can be used on its own, if this is not available you will need to sign in as a normal user and elevate permissions.
○ Depending on whether the user is a sudoer or su is required, you will need to configure the appropriate settings in the scan settings for whichever template is used.
• Verify the method used to elevate permissions by logging in to an example machine and go through the elevation process so you can match it within Nessus.
○ In general, su and sudo commands can be used on their own or combined but Nessus supports these combinations.
In the next article we will discuss best practices for configuring credentials for authenticated scans within Nessus.
Categories