Recent Content
Webinar: Customer Product Update Webinars - July 2025
Check out the latest monthly Customer Update Webinars below and save your spot! Recordings will be posted after the live webinar has concluded. Tenable WAS, July 8, 2025, 11 am ET: Join us for a deep dive into recently released WAS features and capabilities. Tenable Nessus, July 8, 2025, 1 pm ET: Testing for specific CVEs with Nessus. Tenable OT Security, July 9, 2025, 11 am ET: Learn how Tenable OT Security 4.3 unlocks unprecedented visibility and control across your OT/IT environment. Tenable Vulnerability Management, July 9, 2025, 1 pm ET: Credentialed scans versus uncredentialed scans and how to use managed credentials. Tenable One, July 10, 2025, 11 am ET: Learn how Tenable One can now ingest important security context from non-Tenable security tools to help better identify, prioritize and reduce cyber risk. Tenable Security Center, July 10, 2025, 1 pm ET: OS breakdown: reporting exposures by operating system.What is the nessusd.rules file?
INFORMATION The nessusd.rules file is an editable, text-based file used to configure Nessus scans to allow and reject ports, IP addresses, IP ranges, plugins, and targets. Please note that if the scans are launching from Tenable.sc or Tenable.io, all scans that use this Nessus scanner will be subject to the nessusd.rules file. By default, based on your operating system, the nessusd.rules file can be found in the following locations: Linux /opt/nessus/etc/nessus/nessusd.rules Windows (default location) C:\ProgramData\Tenable\Nessus\conf\nessusd.rules Note: The ProgramData folder is by default a hidden folder in Windows. In addition, the path specified is the default but can vary if Nessus was installed on another drive (i.e. E:\Programdata\...\). For more information, see the Microsoft article Show hidden files. macOS /Library/Nessus/run/etc/nessus/nessusd.rule Tenable Core Log in to Tenable Core on port 8000. In the left navigation, click Nessus. The nessusd.rules file can be found on the left side of the resulting screen. DETAILS Lines that start with # are comments. Lines that do not start with # are actual settings. The default nessusd.rules file begins with a series of comments which include explanations and examples. These are divided into 3 syntax sections: Target Syntax, Plugin Syntax, and Default Rule Syntax. The syntax section heading name is followed by a colon and then lists the exact allowable syntax. You can use CIDR notation, ranges using a -, or hostnames to identify the targets. Below each section heading, a sample explanation is followed by an indented line, which includes what the actual setting would look like. # Target Syntax: accept|reject address/netmask:port[-port_max] # # Reject the target with IP 10.42.123.10 # reject 10.42.123.10 # Reject any target on 10.42.123.x # reject 10.42.123.0/24 # Reject any target between 10.42.123.10-10.42.123.50 # reject 10.42.123.10-10.42.123.50 # Reject the target with hostname 'NessusHost' # reject NessusHost # Reject connecting to port 80 for 10.0.0.1 # reject 10.0.0.1:80 # Reject connecting to port 8100 for all IP addresses # reject 0.0.0.0/0:8100 All settings in the nessusd.rules file take precedence over the scan's settings configured in the Nessus GUI. If a setting is added to the nessusd.rules file to not scan certain ports, those ports will not be scanned even if those ports are listed to be scanned in any scan setting. Note: Rules work from top down. Add new rules above the default accept the line, never below it. For example, to stop port 80 from being scanned on 10.0.0.1: In the nessusd.rules file, add the following: reject 10.0.0.1:80 This statement tells Nessus to not connect to port 80 on 10.0.0.1. In Nessus, a scan configured to scan 10.0.0.1 and port 80 in the Discovery's Port Scanning range would be ignored. No plugins will fire against port 80. As a result, port 80 will not be scanned because the nessusd.rules settings take precedence over all scans configured in the GUI. If desired, you can change the location of the nessusd.rules file. The rules setting and its file location is listed in the Advanced settings of Nessus. To ensure the file's location change takes effect, restart the Nessus service. ADDITIONAL RESOURCES Default nessusd.rules file contents: # Nessus rules # # # Target Syntax: accept|reject address/netmask:port[-port_max] # # Reject any target on 10.42.123.x # reject 10.42.123.0/24 # Reject connecting to port 80 for 10.0.0.1 # reject 10.0.0.1:80 # Reject connecting to ports 8000 - 10000 (inclusive) for any host in the 192.168.0.0/24 subnet # reject 192.168.0.0/24:8000-10000 # Reject connecting to ports 1 - 1024 (inclusive) for the host 2001:db8::abcd # reject [2001:db8::abcd]:1-1024 # # # Plugin Syntax: plugin-accept|plugin-reject id[-id_max] # # Reject plugin #10335 # plugin-reject 10335 # Allow plugins #10000 through #40000 (inclusive) # plugin-accept 10000-40000 # # # Default Rule Syntax (if no other rules apply): default accept|reject # # Accept everything else # default accept # Reject everything else # default reject default accept0likes0CommentsWhat ports does "built-in" represent?
INFORMATION In a policy's "Host Discovery" tab is a section labeled Ping Methods. Configuring the Destination Ports to utilize the 'built-in' setting designates a specific set of ports to be used. DETAILS The "built-in" ports are defined by the scanner's ping_host4.inc file. This file includes the following TCP ports: 139 135 445 80 22 515 23 21 6000 1025 25 111 1028 9100 1029 79 497 548 5000 1917 53 161 9001 49000 443 993 8080 2869 You can confirm that the metadata in ping_host4.inc is used by the ping plugin by looking at the plugin code for plugin ID 10180, Ping the remote host, where the nasl code lists the included .inc files: 81 include("raw.inc"); 82 include("misc_func.inc"); 83 include("ping_host4.inc");0likes0CommentsList of ports in Nessus defined by Port Scan Range : default
INFORMATION In a Nessus or Tenable Vulnerability Management scan policy, under Discovery > Port Scanning, you can define the port scan range. This field can be set to an explicit value, range, combination of both, or default. When set using the keyword 'default', the scanner will scan approximately 4,790 common ports. The list of ports can be found in the nessus-services file on the Nessus scanner. This list can change over time. Note: 'default' is case sensitive and must be lowercase. DETAILS The nessus-services file can be found in these default locations on a Nessus scanner: Windows C:\ProgramData\Tenable\Nessus\nessus\nessus-services Mac /Library/Nessus/run/var/nessus/nessus-services Linux /opt/nessus/var/nessus/nessus-services ADDITIONAL RESOURCES An example of the nessus-services file is attached to this article. Please note that the contents of this file are subject to change. Previously, when creating a new scan or policy using the Internal PCI Network Scan template, by default the port scan range was set to 'common'. This is not the same as the 'default' list mentioned above. However, the Internal PCI Network Scan template now uses the default range.0likes0CommentsCreate custom audit policies
INFORMATION Tenable has made documentation available for writing custom audit policies as well as several command line tools and very detailed example policies. In most cases, Tenable customers have been able to use the default audit policies and remove unneeded tests. In cases where more detail is needed than the current example tests, Tenable has documented examples for each type of Unix and Windows audit point. These can be modified with values that are in line with your organization’s configuration guidelines. NOTE: Technical Support Engineers cannot directly support custom audit files. Support is available for bugs or other issues with specific functions or calls. See Support for custom audit files, plugins, and API scripts for more information. DETAILS The following are links to Tenable documentation on Compliance checks. The Audits Portal - This site allows you to search our audit file database from a convenient interface. Nessus Compliance Checks - This paper discusses how to configure Nessus to perform these audits and how Tenable's SecurityCenter can be used to manage and automate this process. Nessus Compliance Checks Reference - This document describes the syntax used to create custom .audit files that can be used to audit the configuration of Unix, Windows, database, SCADA, IBM iSeries, and Cisco systems against a compliance policy as well as search the contents of various systems for sensitive content.0likes0CommentsPhases of a vulnerability scan
INFORMATION Phases of a Vulnerability Scan: Settings: Scan Policy and Global Scanner Settings Information Gathering: Ping and Port Scanning Port Service, Banner, and Interface Checking Local Checks Information Processing: KB Reliant Checks END Type Checks DETAILS NOTE: This article outlines the process of a Vulnerability scan primarily in Nessus. There may be additional settings in Tenable Vulnerability Management or Tenable Security Center that aren't cover in this article. Settings: Scan Policy and Global Scanner Settings: Type of scan being implemented: Basic Network Scan, Advanced Network Scan, etc. The differences between a Basic Network Scan and an Advanced Network Scan are such that, the Basic Network Scan is a great policy that can be applied to virtually any host. The Advanced Network Scan, however, allows for a lot more customization to basically tailor fit a policy against a host. Specifically, there are a lot more settings that are available to customize within an Advanced Network Scan policy that are automatically set to default values in a Basic Network Scan. Also, within an Advanced scan, you have the ability to control what plugins are automatically enabled/disabled within the policy. A Basic Network Scan can be configured similarly to an Advanced Network Scan, however, that will remove the defaults which makes it safe to apply to almost any host. Please read our documentation for more information on configuration options within our policies. Type of scanner being used: Global Cloud Scanner vs. Local Scanner The type of scanner being used depends on the purpose of your scan. If the intent of a vulnerability scan is for an internal view of your network that provides vulnerability information that exists internally (locally) on your hosts, you would use a Local Nessus scanner that's been installed on your network. A Cloud Scanner, however, is great for performing cloud-based scanning from an external view. A key example for a Cloud Scanner would be if you were conducting an External PCI scan that relied on an external perspective of your network. Our Cloud scanners do not provide an internal view into networks. Examples of how Policy Configuration can affect how a scan works: Paranoia - Levels 0,1, and 2 (default is 1). This setting will tell Nessus what to report on in regards to its confidence in its finding. Paranoia level 0 means to avoid displaying results that Nessus isn't completely confident in, and 2 means display all finding regardless of confidence levels. Some plugins specifically require certain Paranoia settings. You can discover which ones by filtering for that setting on our plugin website. Supersedence - Enabled by default. This will include all of the plugins related to vulnerabilities that are patched through cumulative updates. It paints a more complete picture, but in most cases may not be necessary as installing the latest patch will cover the most recent version of that plugin (if this option is enabled, you will see vulnerabilities for older patches that may not really apply anymore as a result of having the latest patch). Please refer to this article for more information related to Plugin Supersedence. Safe Checks - Enabled by default. When this setting is on, it disables a large amount of plugins that are considered intrusive when scanning a host. Generally speaking, this is a great stress-test option for pre-production hosts vs. production hosts in which you'd want to minimize the impact of vulnerability scanning. Without safe checks, it's possible to actively test for vulnerabilities or mimic the attack of a vulnerability. With Safe Checks being enabled, certain plugin categories like ACT_DESTRUCTIVE_ATTACK, ACT_DENIAL, ACT_KILL_HOST, and ACT_FLOOD are disabled. Please refer to this article for more information related to Plugin Categories. Thorough Checks - Disabled by default. This setting can enable additional checks within certain plugins. A great example for this would be Plugin 128304. Within that specific plugin, if Thorough Checks are enabled within the policy, the plugin will perform an additional step to obtain even more information. There are also quite a few plugins that rely on this setting to run. Generally speaking, this setting will force the scan to obtain more information at the cost of performance both within the scan and on the target (it becomes more intrusive). NOTE: If rules have been defined in the nessusd.rule configuration file, those rules will supersede anything set within the policy (ports, IP, hosts, etc) (related article). Details: At the start of each scan, Nessus retrieves the scan settings, such as the ports to be scanned, which plugins are enabled, and which settings to apply under the policy's preferences. Information Gathering: Ping Method and Port Scanning: Pinging the host to ensure they're alive based on the selected method(s) (i.e. ARP, TCP, ICMP, UDP). Note: If a host doesn't respond to a ping request, Nessus will mark the host as dead unless otherwise specified from within the scan policy (i.e. scan hosts that don't respond to ping requests). As a default, if a host doesn't respond to a ping, it will not be scanned and will not return any results, that will be the end of the scan. Externally scanning for open ports using SYN scanning (default) or UDP scanning. Details: The first step that Nessus performs in a scan is performing host discovery by pinging each IP address or hostname in the target list. It then determines whether or not the host is live or not. Nessus utilizes ICMP, TCP, ARP, and UDP to make the determination. Afterward, Nessus begins scanning ports to determine which are open. This setting can be adjusted to determine which port from 1 to 65,535 to scan. With Ping Disabled: The full defined port scan range will be done for every IP. If the host is dead the scan will discontinue after the attempted port scan due to no service being found. Port Service, Banner, and Interface Checking: After viewing what ports are open, the scan will check what services are there. The scan will also attempt to interact with any Banners or Interfaces it finds to collect information for the KB. Banner checks include a wide range such as HTTP, FTP, SSH, etc. These checks are performed with the intention of figuring out what service is running and perhaps what application/version. This can also yield OS information for the host. This portion is also where the scan will attempt to remotely identify the OS of the host. Plugin 11936 is a combined plugin that has both remote and local checks within it. If credentials with the appropriate permissions are supplied, the plugin will attempt to use both components of its code. If credentials aren't supplied then only the remote portion of the plugin will fire, the rest will exit. We have a great article that expands on the remote functionality of 11936 and how it attempts to fingerprint the OS from remote checks. Details: After determining which ports are open, Nessus will attempt a series of banner captures and other tests on each of the open ports to detect what services are running on the targeted host. Based on the running services, Nessus will identify the operating system and run plugins that match appropriately (OS respective) Local Checks: The scanner attempts to access the host locally to perform local checks (This would require credentials with the appropriate permissions to access the host locally). The scanner will attempt to consolidate as much local information as it can into the KB to prevent having to connect locally over and over. Details: After the operating system has been determined, Nessus will attempt to login to the host. Afterward, it'll attempt to elevate to an administrative account (if privilege escalation is set) and check local plugins (that can only be run with an administrative account) respective to the operating system. An example of this would be Plugin 10400, which indicates that accessing the Windows Registry through supplied credentials was possible (a local check). Information Processing: KB Reliant Checks: Our plugins analyze all the information collected in our KB from the previous steps of the scan. For some background information, a Nessus KB, or rather a Knowledge Base is where Nessus stores information that our plugins gather during a vulnerability scan. A lot of plugins will utilize the KB before attempting to collect information, as a lot of the information our plugins collect is also utilized by other plugins. KBs make fewer redundant checks on a host for information already acquired by the scan (related article) Details: After all the necessary information has been gathered, the enabled plugins that are running analyze the information collected in the Nessus' knowledge base. Generally speaking, that's the conclusion to data collecting, however, if some plugins require additional information, Nessus may reconnect to a host to perform additional scanning. END Type Checks: END Type Checks are plugins that fall under the ACT_END plugin category - they are the last plugin category that are set to be executed before a vulnerability scan finishes. These are basically summary plugins that run after all the information has been collected (i.e. plugin 19506). ADDITIONAL RESOURCES Plugin Categories, Nessusd.Rules, Template Settings, Scan and Policy Templates, Plugin Database, Nessus Installation (local scanners), Local Checks on Hosts, Knowledge Base (KB)0likes0CommentsTroubleshooting credentialed scanning on Windows
ISSUE When running a credentialed scan on Windows, the Nessus Scanner cannot authenticate to the target. CAUSE Generally, this issue is due to one of the following conditions not having been met: The Windows Management Instrumentation (WMI) service must be enabled on the target. For more information, please see: Introduction to WEBMTEST. Additionally, ensure that ports 135 and 49152 through 65535 are open between the scanner and the target, as WMI connections will choose one of these ports to target. The Remote Registry service must be enabled on the target. File & Printer Sharing must be enabled in the target's network configuration. An SMB account must be used that has local administrator rights on the target. Note: A domain account can be used as long as that account is a local administrator on the devices being scanned. TCP ports 139 and 445 must be open between the Nessus Scanner and the target. Ensure that there are no security policies are in place that blocks access to these services. This can include: Windows Security Policies Antivirus or Endpoint Security rules IPS/IDS The default administrative shares must be enabled. These shares include: IPC$ ADMIN$ C$ The setting that controls this is AutoShareServer (Windows Server) or AutoShareWks (Windows Workstation) which must be set to 1. Windows 10 has the ADMIN$ disabled by default. For all other operating systems, these shares are enabled by default and can cause other issues if disabled. For more information, see http://support.microsoft.com/kb/842715/en-us RESOLUTION Testing from a Windows Host These steps will test connections to a target host using methods similar to what Nessus uses to perform credentialed checks. If these tests fail, it establishes that the issue is likely not with Nessus or the scan configuration, but with the target's security settings. Run all commands from an elevated Command prompt or PowerShell on a host in the same network as the target. Make sure this is not done on the target itself. If possible, use the scanner. Anonymous IPC$ login test Test the IPC$ share without a username by using the following command. This command is similar to how Nessus checks the share. Note: Change <Target_IP> to the target's IP address. net use \\<Target_IP>\ipc$ "" /user:"" For example: If this returns "Failed to connect to the IPC$ share anonymously." then the following should be verified: Ensure SMB is set up correctly Double-check firewall settings SMB Log on Test This is how Nessus tests the credentials to make sure it has access to the system. Run the following commands from an elevated command prompt. Note: Replace <username> and <password> with the credentials the scan is using. Also, change <Target_IP> to the target's IP address. net use \\<Target_IP>\ipc$ /user:<username> <password> net use \\<Target_IP>\admin$ /user:<username> <password> These commands should return "The command completed successfully." If it does not, then: Check the credentials. Check the account has sufficient privileges. Remote Registry Test Run the following command to check if the remote registry is running. Note: Change <Target_IP> to the target's IP address. reg query \\x.x.x.x\hklm If this returns registry keys, the service is running and accessible. If this returns "ERROR: The network path was not found." then the service is not running and must be enabled. WMI Troubleshooting and Test From another Windows host that can reach the scan target over the network: Run wbemtest from the Start Menu. Click 'Connect' in the upper-right corner. In the Namespace field, enter the target namespace as '\\target_host_ip\root\cimv2'. Thus, if the scan target is located at 10.10.0.63, enter '\\10.10.0.63\root\cimv2'. In the Credentials section, enter the credentials of the scanning account. Use 'domain\username' syntax in the User field. Click Connect in the upper-right corner. If successful, the wbemtest window should list the namespace as \\target_host_ip\root\cimv2. In the IWbemServices section below, a number of buttons should appear. Click Query... and enter the following query exactly in the popup, then click Apply: 'select DomainRole from Win32_ComputerSystem' A Query Result window with a single entry reading 'Win32_ComputerSystem=<no key>' should appear. Double-click that entry. In the Instance of Win32_ComputerSystem window, scroll down in the Properties list. A DomainRole entry should appear, with a value of 2, 3, 4 or 5. If the test above failed, do the following on the scan target: WMI Troubleshooting steps Ensure that the WMI service is enabled and running. Ensure the scan user has access to the root/CIMV2 namespace: Open wmimgmt.msc. In the left-hand panel, right-click WMI Control (Local) and choose Properties. Click the Security tab, expand the Root folder, and select the CIMV2 folder. Click the Security button. In the 'Security for ROOT/CIMV2' window, click the Advanced button. Confirm that the scanning account, or a group which it belongs to, is listed in this window. Click on the relevant entry and click the View button. Confirm that the permissions entry covering the scanning account has both the Enable Account and Remote Enable permissions set. Add the scanning account to the Distributed COM user group on the scan target. Alternatively, open Component Services (dcomcnfg) from the Start Menu. In the left panel, expand Component Services, then Computers, and right-click on My Computer. Select Properties. In the COM Security tab of the My Computer Properties window, click the Edit Limits button in the Access Permissions section. Ensure that the scanning account has all permissions. Repeat the previous step with the Edit Limits option under the Launch and Activation Permissions section. Testing from a Linux Host The program smbclient can be used as an alternative method of testing if the Nessus scanner is running on a Linux system that is scanning the Windows-based host. To install smbclient, run the following command as root: yum install samba-client To test the IPC$ share, use the following command. This command is similar to how Nessus checks the share. Note: Change <Target_IP> to the target's IP address. Change <username> and <password> to the credentials that Nessus uses. smbclient //<Target_IP>/IPC$ -U <username>%'<password>' If this returns "smb: \>", then the credentials and permissions work. If this returns "session setup failed: NT_STATUS_LOGON_FAILURE", then: Check the credentials. Check that the account has sufficient privileges. Still Having Issues If you continue to have authentication issues after completing this process, open a case with Technical Support providing the following information: A detailed description of what troubleshooting steps have already been tried A Nessus DB. For more information, see Collecting nessus.db Scan Results from Tenable Products ADDITIONAL RESOURCES Microsoft - Net use ServerFault - Windows shares via command line with user/pass, without mapping the drive? TechRepublic - Use the PushD & PopD commands for quick network drive mapping in Windows 7 Nessus - Credentialed Checks on Windows smbclient man page0likes0CommentsUseful plugins to troubleshoot credentialed scans
Successful Login: Windows 24269 - WMI Available 10394 - Microsoft Windows SMB Log In Possible 10400 - Microsoft Windows SMB Registry Remotely Accessible 10428 - Microsoft Windows SMB Registry Not Fully Accessible Detection 57033 - Microsoft Patch Bulletin Feasibility Check 20811 - Microsoft Windows Installed Software Enumeration (credentialed check) 26921 - Windows Service Pack Out-of-Date 34252 - Microsoft Windows Remote Listeners Enumeration (WMI) 35703 - SMB Registry : Start the Registry Service during the scan 35704 - SMB Registry : Stop the Registry Service after the scan 24272 - Network Interfaces Enumeration (WMI) 19506 - Nessus Scan Information (Settings)* *Note: For 19506, "Credentialed Checks: yes" in the output indicates a successful scan Successful Login: Linux 22869 - Software Enumeration (SSH) (General) 12634 - Authenticated Check: OS Name and Installed Package Enumeration (Settings) 25221 - Remote listener enumeration (Linux / AIX) 33851 - Network daemons not managed by the package system 19506 - Nessus Scan Information (Settings)* *Note: For 19506, "Credentialed Checks: yes" in the output indicates a successful scan Oracle Database 22073 - Oracle Database Detection 10658 - Oracle Database tnslsnr Service Remote Version Disclosure 11219 - Nessus SYN scanner* OR 14272 - Netstat Portscanner (SSH)* *Note: These port scanners are used to determine which port the Oracle Database service was found on Login Failure/Permission Failure 11149 - HTTP login page: Provides a means for HTTP login info, but it also returns login failures when an error occurs. 21745 - OS Security Patch Assessment Failed: See More Information below. 24786 - Nessus Windows Scan Not Performed with Admin Privileges: This means the account provided for Windows did not have administrator privileges on the scanned host. 26917 - Microsoft Windows SMB Registry : Nessus Cannot Access the Windows Registry: This means the target's registry was not available. This is most likely caused by the Remote Registry setting not being configured correctly either in the scan policy or on the target. 35705 - SMB Registry : Starting the Registry Service during the scan failed: Indicates failure to start the Remote Registry service on the target. 35706 - SMB Registry : Stopping the Registry Service after the scan failed: Indicates failure to stop the Remote Registry service on a target after a scan. More information for plugin 21745 - OS Security Patch Assessment Failed The plugin 21745 error "unable to create a socket" indicates that Nessus was unable to connect to the system. In this case, it means Nessus was unable to successfully complete the TCP handshake on port 445. This could be for a number of reasons: Nessus is unable to connect due to network issues A network or host- based firewall is blocking the connection attempts Due to network latency, a timeout is reached before the connection occurs The user that started the scan does not have permission to scan the given host and/or port If the user sees this error in plugin 21745 every time authentication fails for a given host, that likely means Nessus is having connection issues due to one of the conditions listed above. Nessus users have no host or port restrictions by default, so this can only occur if an admin explicitly put such a restriction in place. To determine if this is the case, view the rules file. To find the rules file: Log into Nessus as an administrator. Select Configuration > Advanced Settings. Scroll down to the rules setting. Note: If Nessus has too many open sockets during a scan, an error message may indicate this problem in nessusd.dump or nessusd.messages. Local Authentication These plugins authenticate to the remote host, gather the information necessary for local checks, and enable local checks. Their output and audit trails provide details of any problems that were encountered. 97993 - OS Identification and Installed Software Enumeration over SSH v2 (Using New SSH Library): Enables local checks over SSH. 12634 - Authenticated Check : OS Name and Installed Package Enumeration: Enables local checks over SSH. 10394 - Microsoft Windows SMB Log In Possible: Enables local checks over SMB. 19762 - SNMP settings: Enables local checks over SNMP. 73204 - Citrix NetScaler Version Detection: Enables local checks over SSH, SNMP, or NTP. 72816 - Palo Alto Networks PAN-OS Version Detection: Enables local checks over HTTP if not already enabled over SSH. 57399 - VMware vSphere Installed Patches: This gathers info via the HTTPS SOAP API which triggers other plugins to enable local checks. 57400 - VMware vSphere Installed VIBs: This gathers info via the HTTPS SOAP API which triggers other plugins to enable local checks. Third-party Local Checks These plugins gather information about the host from a third party and enable local checks. 80860 - Patch Management: Get Packages from Symantec Altiris: Enables "local" checks via Symantec Altiris. 65703 - Patch Management: HCL BigFix Get Installed Packages: Enables "local" checks via IBM BigFix (previously known as Tivoli Endpoint Manager). 84231 - Patch Management: Red Hat Satellite Get Installed Packages: Enables "local" checks via Red Hat Satellite 6. 84238 - Patch Management: Red Hat Satellite Server Settings: Enables "local" checks via Red Hat Satellite 5. 63062 - VMware vCenter Data Collection: Enables "local" checks via VMware vCenter. Windows Access Checks These plugins check for the required privileges/access for Windows local checks and set required KB entries in order for Windows local checks to be performed. 10400 - Microsoft Windows SMB Registry Remotely Accessible: Logs registry access issues that prevent local checks from being enabled. 10428 - Microsoft Windows SMB Registry Not Fully Accessible Detection: Tests registry access and sets "SMB/registry_full_access" if successful. 13855 - Microsoft Windows Installed Hotfixes: Logs registry and share access issues that prevent local checks from being enabled. 57033 - Microsoft Patch Bulletin Feasibility Check: Sets the flag "SMB/MS_Bulletin_Checks/Possible" based on the results on plugin 13855. Summarize Specific Auth / Local Checks Issues These plugins provide summaries of particular types of auth / local checks issues that have been reported by other plugins and report the plugins that encountered these issues. 102094 - SSH Commands Require Privilege Escalation: Reports commands that failed due to lack of privilege escalation or due to failed privilege escalation. Commands reported here may not have prevented local checks from running but may have caused the plugin associated with each command to fail to produce the expected output. This causes authentication to report as successful, but with insufficient access. 110695 - OS Security Patch Assessment Checks Not Supported: Reports that local checks were unavailable for the identified device or operating system and includes the report of the plugin that logged the unavailability of local checks. In this case, the credentials may be correct and login may have been successful, but checks cannot be run against the host for another reason, such as if the target is an OS type for which there is no plugin support. 150799 - Target Access Problems by Authentication Protocol - Maximum Privilege Account Used in Scan: Reports that log in was successful and that the credentials can escalate to the highest level of privilege possible on the host, but that the scanner still encountered permissions issues while scanning. For more information on this plugin, please see the related Research Highlight. Summarize Authentication Status These plugins provide summaries of the overall authentication status for the target. A given target should trigger at least one of these plugins. 141118 - Target Credential Status by Authentication Protocol - Valid Credentials Provided: Reports protocols with successful authentication. This identifies that the protocols specified were able to authenticate to the target successfully at least once. This may be paired with other plugins. 110095 - Target Credential Issues by Authentication Protocol - No Issues Found: Reports protocols with successful authentication and no reported privilege/access issues. 110385 - Target Credential Issues by Authentication Protocol - Insufficient Privilege: Reports protocols with successful authentication that also had privilege/access issues logged for the successful credentials. 104410 - Target Credential Status by Authentication Protocol - Failure for Provided Credentials: Reports protocols with only authentication failures. 110723 - Target Credential Status by Authentication Protocol - No Credentials Provided: Reports protocols that were detected in the scan as available for authentication but that did not have credentials provided to attempt authentication with. 117885 - Target Credential Issues by Authentication Protocol - Intermittent Authentication Failure: Reports protocols with successful authentication that also had subsequent authentication failures logged for the successful credentials. Notes: A given target usually triggers at least one of these unless no services are detected supporting protocols that Nessus uses for authentication. Audit trails should indicate this. Authentication status is reported per protocol. This means if there are multiple authentication protocols available on the target with different authentication statuses, it is possible to see both Authentication Success and Authentication Failure. For a given protocol, if both access/privilege problems were encountered and service/authentication problems were encountered, it is possible to see both plugins 110385 and 117885. Summarize Local Checks Status These plugins provide summaries of overall local checks status for the target. In the case of issues or errors logged by previous plugins, these plugins provide a list of the issues/errors logged along with the reporting plugin and protocol if available. 21745 - OS Security Patch Assessment Failed: Reports that local checks were not enabled due to an error/failure and lists the details of the errors/failures. Focus on "Local Checks Not Run" rather than the "Authentication Failure" section. While authentication failure is one failure that can cause local checks be disabled, there are many other types of errors and failures that prevent enabling local checks. 117886 - OS Security Patch Assessment Not Available: Reports that local checks were not enabled for an informational reason and lists details. 117887 - OS Security Patch Assessment Available: Reports that local checks were enabled. If available, this includes the account and protocol used for local checks. ADDITIONAL RESOURCES An additional list of plugins useful for troubleshooting Nessus scans can be found here.0likes0CommentsCollecting Debugs for Tenable Products
DESCRIPTION This article describes the process on how to generate a debug report in Tenable products. Please sanitize any IP addresses or other sensitive information prior to sending the debug report to Tenable Support, if required. STEPS Nessus Select the version you need for generating a Nessus debug. Nessus GUI The GUI feature was implemented on version Nessus 8.x.x and above. Open the Nessus GUI by going to, https://<nessus_ip>:8834 Open the Settings menu tab. On the top right, use the Download logs button to download the Nessus debug log files. Choose the type of debug options. Use the Download button to download a nessus-bug-report.tar.gz file. The file should begin downloading automatically. Windows CLI Note: During the collection of logs from a Nessus application or an Agent install, you may see occurrences of: [debug] Skipping collection; wrong OS. The Nessus debug command contains the commands for all potential operating systems it can be run on. This message indicates that the command it is skipping is meant for a different operating system. For example, if the command is run on a MacOS host, all Linux and Windows related commands will be skipped. Open Command Prompt with "Run as Administrator" option. Generate the debug:"C:\Program Files\Tenable\Nessus\nessuscli" bug-report-generator When prompted to run in full mode, select Y. Copy the file from: C:\ProgramData\Tenable\Nessus\nessus\logs\nessus-bug-report-archive.txt Linux CLI Note: During the collection of logs from a Nessus application or an Agent install, you may see occurrences of: [debug] Skipping collection; wrong OS. The Nessus debug command contains the commands for all potential operating systems it can be run on. This message indicates that the command it is skipping is meant for a different operating system. For example, if the command is run on a MacOS host, all Linux and Windows related commands will be skipped. Open a Terminal as 'root'. Using sudo will work as well. Generate the debug:/opt/nessus/sbin/nessuscli bug-report-generator When prompted to run in full mode, select Y. Copy the file from: /opt/nessus/var/nessus/logs/nessus-bug-report-archive.tar.gz Mac OS X CLI Note: During the collection of logs from a Nessus application or an Agent install, you may see occurrences of: [debug] Skipping collection; wrong OS. The Nessus debug command contains the commands for all potential operating systems it can be run on. This message indicates that the command it is skipping is meant for a different operating system. For example, if the command is run on a MacOS host, all Linux and Windows related commands will be skipped. Open a Terminal as 'root'. Using sudo will work as well. Generate the debug:/Library/Nessus/run/sbin/nessuscli bug-report-generator Copy the file from: /Library/Nessus/run/var/nessus/logs/nessus-bug-report-archive.tar.gz FreeBSD CLI Note: During the collection of logs from a Nessus application or an Agent install, you may see occurrences of: [debug] Skipping collection; wrong OS. The Nessus debug command contains the commands for all potential operating systems it can be run on. This message indicates that the command it is skipping is meant for a different operating system. For example, if the command is run on a MacOS host, all Linux and Windows related commands will be skipped. Open a Terminal as 'root'. Using sudo will work as well. Generate the debug:/usr/local/nessus/bin/nessus-bug-report-generator Copy the file from: /usr/local/opt/nessus/bin/nessus-bug-report-archive.tar.gz Tenable Vulnerability Management Note: this method requires that the scanner is online and communicating with Tenable Vulnerability Management. For offline scanners, please use one of the CLI methods on the scanner host. From the new interface, navigate to Settings > Sensor Management > Nessus Scanners. Click on the scanner in question. Click on the Logs tab. Click Request Logs on the upper right side of the screen. It may take up to a few minutes, but you will see the status of the request. When complete, click on the three dots on the right side and click the Download button in the dropdown menu. Nessus Agents Select the version you need for generating a Nessus debug. Nessus GUI (Only available for Nessus Agent 7.2 or later) Note: this method requires that the agent is online and communicating with its Nessus Manager. For offline agents, please use one of the CLI methods on the agent host. Open the Nessus GUI by going to: https://<nessus_manager_ip>:8834 Open the Sensors tab in the top left menu. Select the Agent in question. Select the Logs tab. Use the "Request Logs" button on the top right to begin the log process. Note: You should see the log being processed. Open the link once the log report has been completed. This will download the log report to the local computer. Windows CLI Note: During the collection of logs from a Nessus application or an Agent install, you may see occurrences of: [debug] Skipping collection; wrong OS. The Nessus debug command contains the commands for all potential operating systems it can be run on. This message indicates that the command it is skipping is meant for a different operating system. For example, if the command is run on a MacOS host, all Linux and Windows related commands will be skipped. Open Command Prompt with "Run as Administrator" option Generate the debug:"C:\Program Files\Tenable\Nessus Agent\nessuscli" bug-report-generator When prompted to run in full mode, select Y. Copy the file from: C:\ProgramData\Tenable\Nessus Agent\nessus\logs\nessus-bug-report-archive.txt Linux CLI Note: During the collection of logs from a Nessus application or an Agent install, you may see occurrences of: [debug] Skipping collection; wrong OS. The Nessus debug command contains the commands for all potential operating systems it can be run on. This message indicates that the command it is skipping is meant for a different operating system. For example, if the command is run on a MacOS host, all Linux and Windows-related commands will be skipped. Open a Terminal as 'root'. Using sudo will work as well. Generate the debug:/opt/nessus_agent/sbin/nessuscli bug-report-generator When prompted to run in full mode, select Y. Copy the file from: /opt/nessus_agent/var/nessus/logs/nessus-bug-report-archive.tar.gz Mac OS X CLI Open a Terminal as 'root'. Using sudo will work as well. Generate the debug:/Library/NessusAgent/run/sbin/nessuscli bug-report-generator Copy the file from: /Library/NessusAgent/run/var/nessus/logs/nessus-bug-report-archive.tar.gz Tenable Vulnerability Management Note: this method requires that the agent is online and communicating with Tenable Vulnerability Management. For offline agents, please use one of the CLI methods on the agent host. From the new interface, navigate to Settings > Sensor Management > Nessus Agents Click on the agent in question. Click on the Logs tab. Click Request Logs on the upper right side of the screen. It may take up to a few minutes, but you will see the status of the request. When complete, click on the three dots on the right side and click the Download button in the dropdown menu. Tenable Security Center Using the GUI Log in as an admin user. Go to System > Diagnostics. Click Create Diagnostics File. Leave all chapters selected. Sanitize if necessary. Click Generate File. When that completes, click Download Diagnostics File. The resulting ZIP file is the debug file. Using the CLI Open a Terminal as 'root'. Using sudo will work as well. Generate the debug:/opt/sc/support/bin/php /opt/sc/src/tools/debug.php -a Copy the file from: /opt/sc/debug.zip. Nessus Network Monitor Open root/admin command prompt on the host NNM is installed on. On Linux and MacOS, using sudo will work as well. Run the following script: Linux/opt/nnm/bin/debug.sh Windows"C:\Program Files\Tenable\nnm\debug" MAC OS X:/Library/NNM/bin/debug.sh Choose full for standard debug, limited for sanitized debug Copy the file from: /opt/nnm/bin/nnm-bug-report-archive.tar.gz Tenable OT Security Please refer to the following KB article for collecting a debug in Tenable OT Security: How to generate a system diagnostic in Tenable OT Security Tenable Core Support Report See How to Generate a SoS Report in Tenable Core Tenable Container Security Scanner Use the guide Configure and Run the Tenable CS Scanner Add the DEBUG_MODE Environmental Variable and send it to a file with:-e DEBUG_MODE=true 2>&1 | tee cs_error.logNote: This will print the output on the screen when run.For example:docker pull alpine:latest && docker save alpine:latest | docker run \ -e TENABLE_ACCESS_KEY=<API_ACCESS_KEY> \ -e TENABLE_SECRET_KEY=<API_SECRET_KEY> \ -e IMPORT_REPO_NAME=<REPO_NAME> \ -e DEBUG_MODE=true 2>&1 \ -i tenableio-docker-consec-local.jfrog.io/cs-scanner:latest inspect-image alpine_latest | tee cs_error.log Provide the cs_error.log to the Support case. Sensor Proxy Copy the following files from the host: /opt/sensor_proxy/nginx/logs/* /opt/sensor_proxy/logs/* Provide the logs to the Support case.0likes0CommentsTenable Security Center - "Plugins Out of Sync" warning explained
Rule out third-party interference If a scanner is repeatedly and persistently returning or stuck on a 'Plugins Out of Sync' or 'Updating Plugins' status, it is possible that plugin updates to the scanner are being interrupted or blocked. Common possible causes include: Scanner host restarting mid-update Issues or interference with the network connection between Nessus and TSC Antivirus or endpoint protection software blocking or modifying plugin files As some Nessus plugins utilize known exploit techniques to check for vulnerabilities, they can be flagged as threats by antivirus or endpoint protection software. Ensure that all files, folders, and processes listed in the following documentation are explicitly allowed by any endpoint protection software on the scanner host: File and Process Allowlist (Tenable Nessus) Additionally, confirm that there is no interference at the network level, and that plugin traffic to and from the scanner is not being blocked or altered by any intervening network device (such as an IDS/IPS, firewall, or proxy). If the issue still occurs, follow the troubleshooting steps below. Increase Scanner Timeout in TSC On the TSC server, check the current Scanner Timeout settings by running the following commands. Run all commands on the TSC host as root or using sudo: /opt/sc/support/bin/sqlite3 -header -table /opt/sc/application.db "select name,value from Configuration where name='ScannerStatusTimeout'" Example output where the ScannerStatusTimeout limit is set to 120 (seconds): +----------------------+-------+ | name | value | +----------------------+-------+ | ScannerStatusTimeout | 120 | +----------------------+-------+ To modify the value, and increase the limit (in this example to 300), run the following command: /opt/sc/support/bin/sqlite3 /opt/sc/application.db "Update Configuration set value='300' where name='ScannerStatusTimeout'" In some cases, more than 300 seconds may be needed. In very narrow band scenarios (Such as RF, or single channel ISDN) you may need to experiment, or test values up to the limit of 900 seconds. Warning: Do not exceed 900 seconds (longer than 15 minutes). This could cause an update loop to occur causing TSC to become unstable. Try to update the plugins for the affected scanner again in the TSC interface. Manually update the plugins on the affected scanner Obtain plugin download URL If you have root access on the TSC host, the plugin download URL can be obtained by running the following command: PluginSubscriptionLogin=`/opt/sc/support/bin/sqlite3 /opt/sc/application.db 'SELECT value FROM Configuration WHERE name = "PluginSubscriptionLogin"'` && PluginSubscriptionPassword=`/opt/sc/support/bin/sqlite3 /opt/sc/application.db 'SELECT value FROM Configuration WHERE name = "PluginSubscriptionPassword"'` && echo -e '\nDownload URL:\n\nhttps://downloads.nessus.org/get.php?f=all-2.0.tar.gz&u='$PluginSubscriptionLogin'&p='$PluginSubscriptionPassword'' The output should be as follows: https://downloads.nessus.org/get.php?f=all-2.0.tar.gz&u=e00036c8157ed2402d05491b1d90c5df&p=d7770d12a8acfeb28e5312b95b98a1bf Navigate to the URL in a browser to download the all-2.0.tar.gz file. If you do not currently have shell access on the TSC host, the plugin URL can be constructed with a diagnostic report. Continue reading below. Otherwise, jump to Updating the Scanner. In order to perform this step, you will need to generate a TSC diagnostic report to obtain the plugin download site. To download TSC diagnostics file: Log in TSC as an admin user In the top navigation, click System, then Diagnostics. Click Create Diagnostics file. Once it has been completed, click Download Diagnostics file. In this example, we will use the information found in the sc-configuration.txt file in the diagnostic report. You will need to find the following: PluginActivationCode 'FTXX-67XX-C6XX-21XX-XXXX' PluginUpdateSite 'downloads.nessus.org' PluginSubscriptionStatus 'Valid' PluginSubscriptionLogin 'e00036c8157ed2402d05491b1d90c5df' PluginSubscriptionPassword 'd7770d12a8acfeb28e5312b95b98a1bf‘ Note: The information above is an example only. This cannot be used for your downloads. Once you have this, craft this into a URL to download the all-2.0.tar.gz plugin update file. The URL is constructed using the following syntax: https://<PluginUpdateSite>/get.php?f=all-2.0.tar.gz&u=<PluginSubscriptionLogin>&p=<PluginSubscriptionPassword> For example: https://downloads.nessus.org/get.php?f=all-2.0.tar.gz&u=e00036c8357ed5102d02291b1d90c5df&p=d7770d12a8acfeb28e5312b95b98a1bf Using this URL, download the all-2.0.tar.gz file from it. Updating the Scanner NOTE: The Nessus scanner will still need to be able to communicate directly with TSC. This only resolves issues with the initial plugin push. Upload the all-2.0.tar.gz file to the Nessus scanner host, update with the acquired tarball, and edit the plugin_feed_info.inc in the /plugins directory: Linux service nessusd stop /opt/nessus/sbin/nessuscli update all-2.0.tar.gz FreeBSD service nessusd stop /usr/local/nessus/sbin/nessuscli update all-2.0.tar.gz Mac OS X launchctl unload -w /Library/LaunchDaemons/com.tenablesecurity.nessusd.plist /Library/Nessus/run/sbin/nessuscli update all-2.0.tar.gz Windows Place the all-2.0.tar.gz file in C:\Program Files\Tenable\Nessus then run the following commands from an Administrator command prompt: net stop "Tenable Nessus" "C:\Program Files\Tenable\Nessus\nessuscli.exe" update all-2.0.tar.gz Updating the plugin_feed_info.inc file This is needed to ensure a feed error does not occur when logging into Nessus installed on a Linux or Windows host. Add the following line to /opt/nessus/lib/nessus/plugins/plugin_feed_info.inc: PLUGIN_FEED_TRANSPORT = "Tenable Network Security Lightning"; The end result should look similar to this: PLUGIN_SET = "201705191930"; PLUGIN_FEED = "ProfessionalFeed (Direct)"; PLUGIN_FEED_TRANSPORT = "Tenable Network Security Lightning"; Rebuild the plugins Linux /opt/nessus/sbin/nessusd -R service nessusd start FreeBSD /usr/local/nessus/sbin/nessusd -R service nessusd start Mac OS X /Library/Nessus/run/sbin/nessusd -R launchctl load -w /Library/LaunchDaemons/com.tenablesecurity.nessusd.plist Windows "C:\Program Files\Tenable\Nessus\nessusd.exe" -R net start "Tenable Nessus Once you have run this and it completes, update the status on TSC and give up to 30 minutes for the scanners to reflect a working status. Further troubleshooting Since a stable fast network connection between Tenable products is mandatory for them to function correctly the following steps will help confirm if the current state of the connection between TSC and Nessus is sufficient to allow plugins to be transferred automatically. Construct the plugin download URL as per Putting the download URL together of this guide. It will look similar to this: https://downloads.nessus.org/get.php?f=all-2.0.tar.gz&u=e00036c8357ed5102d02291b1d90c5df&p=d7770d12a8acfeb28e5312b95b98a1bf Use curl to download the full plugin update to the TSC system and write it to a directory that is accessible over HTTP. curl -v 'https://downloads.nessus.org/get.php?f=all-2.0.tar.gz&u=e00036c8357ed5102d02291b1d90c5df&p=d7770d12a8acfeb28e5312b95b98a1bf' -o /opt/sc/www/html/all-2.0.tar.gz Once the plugins have been downloaded to TSC, download them to the scanner from the HTTP accessible location. The plugin timeout was changed to 900 seconds (15 minutes) in Increase Scanner Timeout in TSC. *nix systems Command curl -v -k 'https://myTSC/all-2.0.tar.gz' -o /tmp/all-2.0.tar.gz Expected Output: Windows You can navigate to https://<TSC_IP>/all-2.0.tar.gz or run the following Powershell command: Invoke-WebRequest -Uri "https://myTSC/all-2.0.tar.gz" -Headers @{"Upgrade-Insecure-Requests"="1";} Expected Output:0likes0Comments
About Tenable Connect Support
Support guides and resources to help you get the most out of the Tenable Connect community.33 Articles