Recent Content
How Does Tenable Vulnerability Management Identify an Asset as Unique
APPLIES TO Tenable Vulnerability Management OPERATING SYSTEM(S) N/A INFORMATION Identification is the process of matching a set of attributes collected by a sensor (e.g. Nessus) to an existing asset. If Tenable Vulnerability Management is unable to find an existing asset that matches the incoming host, it is treated as a new asset and added to Tenable Vulnerability Management. The following section explains how Tenable Vulnerability Management matches hosts to assets. DETAILS Each identification request is based on a list of key-value pairs representing properties that have been observed/collected. Tenable Vulnerability Management uses a subset of these properties, called Identification Attributes (IA), in an attempt to determine whether an asset has been previously seen. Our current list of IAs is below. These are ordered from authoritative to speculative, based on their ability to accurately link a host to an existing asset. Globally Authoritative Identifying Attributes Network Scoped Identifying Attributes AWS EC2 Instance ID Azure VM ID GCP ID (Composite of Project/Zone/Instance IDs) BigFix Asset ID Tenable Hardware Tag (Tenable UUID) Security Center Host UUID Microsoft Entra ID Hardware ID Microsoft Entra ID Device ID Active Directory ObjectSid Active Directory Distinguished Name Windows Defender Security Agent ID Crowdstrike Agent ID Qualys Agent ID Carbonblack Device ID Network Device Serial Identifier BIOS UUID MAC Address NetBIOS Name FQDN (including rDNS) IPv6 Addresses Primary IPv4 Address Other IPv4 Addresses Operating Systems Family* Internal IDs generated by cloud computing platforms (Amazon Elastic Cloud Compute, Microsoft Azure, Google Compute Engine, etc.) are 100% authoritative and unique. If the Tenable Vulnerability Management asset tracking system matches assets using one of these identifiers, the decision is guaranteed to be correct. Every asset should have at most one value for an identifier in this class. Network Scoped Identifying Attributes are considered to be "scoped" to the network, meaning that for an asset to be considered as unique with the same MAC Address, NetBIOS Name, FQDN or IPv4 the asset will need to belong to the same Tenable Vulnerability Management defined Network as well. For more information, refer to the Tenable Vulnerability Management documentation on Networks.1like0CommentsConfiguring a new Tenable One container
Applies To Tenable One Operating System(s) N/A Description This article contains links to documentation that is required when configuring a new Tenable One container. Information Configuring the New Environment When configuring a new Tenable One environment, begin by referring to the Tenable One Platform Deployment Guide This documentation provides step-by-step instructions for deployment in a new container, including provisioning, activation of point products, user management, and so on. Follow the instructions within this guide first to get your new environment configured. Tenable Agents To link Tenable Agents to the Tenable One environment, please follow the documentation below. For instructions on linking an agent, please see Install Tenable Agent and navigate to the relevant OS. If the agent was previously linked to another Tenable One environment, please ensure that it is unlinked from that environment before linking. For more information on unlinking an agent, please see Unlink a Tenable Agent. Note: If access to the previous Tenable One environment is not available, these instructions will need to be completed on a per-host basis.0likes0CommentsTenable Core Account Expiry
APPLIES TO Tenable Core OPERATING SYSTEM(S) TenableCore DESCRIPTION Tenable Core, a lightly customized version of Oracle Linux 8, is hardened in accordance with security best practices including some elements of the CIS Level 1 benchmarks. One benchmark in particular has the potential to lock users out and expire their account: Default Security Configuration Standards 5.4.1.4 Ensure inactive password lock is 30 days or less This requirement means that user accounts will be automatically disabled after a period of 30 days of inactivity following password expiration. In order to prevent this, Tenable Core users should log into the cockpit (8000) or SSH at least once every 365 days and update their account password to prevent it from expiring, which in turn prevents the account from becoming locked out. INFORMATION Please log into Tenable Connect to view the following additional resources and access more support. If your account has already expired due to the above requirement, the following knowledge base article will help to resolve it: Unable to Sign Into Tenable Core "Authentication failed: internal-error" For a physical hardware hosted Tenable Core instance, this may require a keyboard and monitor hooked up or serial access. If needed, steps 10-15 of the following article can be used to attach to the serial console for direct interaction: Installing a new platform via USB for Tenable OT Security Hardware Appliances For Tenable OT Security environments, please see Leveraging the Remote Unlock Feature in Tenable Core for instructions on how to remotely unlock administrative accounts on Tenable Core machines.1like0CommentsWebinar: Customer Product Update Webinars - August 2025
Check out the latest monthly Customer Update Webinars below and save your spot! Recordings will be posted after the live webinar has concluded. Tuesday, August 12, 2025 Nessus Customer Update - 1 pm ET / 10 am PT How to: Using credentialed scanning to discover AI software. Wednesday, August 13, 2025 Tenable Vulnerability Management - 1 pm ET / 10 am ET How-to: Assessing network conformance with common compliance benchmarks. Thursday, August 14, 2025 Tenable One Customer Update - 11 am ET/ 8 am PT This month, we'll explore how you can leverage Tenable Cloud Security data within Tenable One. Tenable Security Center - 1 pm ET / 10 am PT How-to: Generating trending dashboards in Tenable Security Center.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.1like0CommentsPhases 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)1like0Comments
About Tenable Connect Support
Support guides and resources to help you get the most out of the Tenable Connect community.36 Articles