Many UNIX applications and system settings are contained in proprietary text configuration files. Auditing these for unauthorized changes or configurations can be very cumbersome and time consuming. Nessus 3 Direct Feed and Security Center users have the ability to audit UNIX servers against a configuration policy without an agent. Being able to automatically prove that all remote systems and applications have a certain configuration setting or that they have not changed from a known good configuration has tremendous value for compliance monitoring and system management.

Today, Tenable released a UNIX utility named "Configuration to Audit" (c2a) which considers a text based configuration file and produces a Nessus 3 .audit file. The c2a tool can be used to quickly create .audit files suitable for Nessus 3 Direct Feed or Security Center users. These .audit files can be used to test for specific configuration file settings as well as MD5 checksums.

This blog entry discusses c2a tool usage and provides example use cases for Nessus and Security Center users with a Snort configuration file.

Creating an MD5 .audit File

Nessus can remotely audit many different aspects of a UNIX server. For our first example, we will audit the MD5 checksum values of three files on a demo system which runs the Security Center, Snort and the Passive Vulnerability Scanner. The configuration for each of these files are located here:

• /etc/snort/snort.conf
• /opt/sc3/daemons/daemons.cfg
• /opt/pvs/etc/pvs.conf

These file names are placed in a text file named files.txt and the c2a tool is run with the following results:

[root@megalon c2a]# ./c2a.pl -md5 -f ./files.txt -o test1_md5.audit
c2a.pl, v1.0 (conf to audit)
(c) 2006 - Tenable Network Security
Creating .audit file based on inputfile ./files.txt
Processing :/etc/snort/snort.conf
Processing :/opt/sc3/daemons/daemons.cfg
Processing :/opt/pvs/etc/pvs.conf

Finished creating .audit files based on ./files.txt
Please check test1_md5.audit for output.

The content of the test1_md5.audit file is as shown:

#
# This file is auto-generated with c2a.pl script
# Copyright 2006 Tenable Network Security Inc
#

<check_type : "Unix">

<custom_item>
        #System :       "Linux"
        type    :       FILE_CHECK
description     :       "Check MD5 for /etc/snort/snort.conf"
        file    :       "/etc/snort/snort.conf"
        md5     :       "823b28cbc726f68538abdb0451f29a01"
</custom_item>

<custom_item>
        #System :       "Linux"
        type    :       FILE_CHECK
description     :       "Check MD5 for /opt/sc3/daemons/daemons.cfg"
        file    :       "/opt/sc3/daemons/daemons.cfg"
        md5     :       "3403c4c155a94c4c915ac0b01d4a60dc"
</custom_item>

<custom_item>
        #System :       "Linux"
        type    :       FILE_CHECK
description     :       "Check MD5 for /opt/pvs/etc/pvs.conf"
        file    :       "/opt/pvs/etc/pvs.conf"
        md5     :       "3b4a4b0b7a3cdf7fa3aff3c54f5e6ad4"
</custom_item>

</check_type>

This .audit file can now be used within the Security Center or Nessus 3 to scan a UNIX system for their MD5 checksums of those three files. Here are screen shots of the test1_md5.audit file being loaded into a Nessus 3 Windows GUI, as well as passing results for a scan of the box with the correct MD5 values:

MD5 Audit Results	Loading UNIX .audit File

If a directory of files is required to be monitored, simply specify the directory in the list of targets given to the c2a.pl script. The c2a.pl script will recognize the entry as a directory and then recursively loop through each file and subdirectory and create a unique MD5 entry for each. For example, in the above files.txt, if we had added "/opt/nessus/etc", it would have created an MD5 value for each file in that directory.

Note on Solaris, the MD5 tool may not be installed by default.
 

Auditing UNIX Configuration Files

Most UNIX applications have one or more text configuration files. The c2a tool can be used to extract the variables when any existing configuration file, and then also make a second pass to extract the values for each variable to produce a UNIX .audit file.

Two passes are necessary because not all text configuration files have the same format. Some have different characters (other than "#") that indicate comments. Some  have a  "variablename =  value"  format while others have a "variablename value" format.

The c2a tool is ideal for processing configuration files that have unique line-by-line content. If your configuration file has multi-line functionality, such as an XML config file, c2a is not ideal.

The basic process to create a UNIX .audit file from a given configuration file is as follows:

1. Extract the variable names to create a variable mapping for the c2a.map file. This involves selecting a regular expression that will identify the variable names and their values and then running the cmv.pl tool to create a temporary map file.
2. Manually edit the temporary map file to avoid any variables that should not be audited and then append it to the c2a.map file.
3. Add in the regular expression you used with your map name to the c2a_regex.map file.
4. Add in the name of your regular expression and file name to the input.txt file.
5. Once this is all in place, create a UNIX .audit file by running the c2a.pl tool.

The resulting UNIX .audit file can be applied to any Nessus 3 scanner or Security Center installation.

NOTE: Please keep in mind that the easiest way to detect change is to get MD5 values of all your remote files, and then test for a new MD5 value. The c2a tools and Nessus can indeed look inside text files and see if certain value are set, but you should only be performing these audits if that is indeed what you require for an audit. We will now look at two examples with Snort.

Snort Configuration File Example

In the next two sections, we will generate some .audit files for a Snort IDS configuration file. Snort is a good example of auditing a remote system configuration file because it has a text configuration file and has specific settings that dramatically change the operation of the application.

This blog entry won't recommend specific settings for Snort (a good link on the subject is here though), but if your organization decides on a central set of configurations, the c2a tool can help audit them to ensure compliance.

Extracting 'var' Variables from a snort.conf File

Most Snort deployments install the configuration file to /etc/snort/snort.conf. Looking at the file, there are many settings which are specified with "var variable-name value" such as:

var TELNET_SERVERS $HOME_NET

We will start by extracting these variables and then move onto other snort.conf keywords such as 'preprocessor' and 'include'.

A regular expression to extract the variable names specified by the 'var' keyword in a snort.conf file is  '(var .+) (.+)'.  We can use the cmv.pl tool and this regular expression to create a SNORTVAR.map file and then add it to the c2a.map file as shown below:

[root@megalon c2a]# ./cmv.pl -r '(var .+) (.+)' -r SNORTVAR -f /etc/snort/snort.conf
[root@megalon c2a]# more SNORTVAR.map
SNORTVAR=var HOME_NET
SNORTVAR=var EXTERNAL_NET
SNORTVAR=var DNS_SERVERS
SNORTVAR=var SMTP_SERVERS
SNORTVAR=var HTTP_SERVERS
SNORTVAR=var SQL_SERVERS
SNORTVAR=var TELNET_SERVERS
SNORTVAR=var SNMP_SERVERS
SNORTVAR=var HTTP_PORTS
SNORTVAR=var SHELLCODE_PORTS
SNORTVAR=var ORACLE_PORTS
SNORTVAR=var AIM_SERVERS
SNORTVAR=var RULE_PATH
[root@megalon c2a]# cat SNORTVAR.map >> c2a.map

We must then add the regular expression used to create this map file to the c2a_regex.map file and create a line for SNORTVAR in our input.txt file as shown below:

[root@megalon c2a]# cat c2a_regex.map
HTTP=([a-zA-Z0-9_-]+) (.*$)
SENDMAIL=([a-zA-Z0-9_-]+)=(.*$)
SYSCTL=([A-Za-z0-9\._-]+) = ([0-9]+)
NESSUS=([A-Za-z0-9\._-]+) = (.+)
VSFTPD=([A-Za-z0-9_]+)=([A-Za-z0-9]+)
SNORTVAR=(var .+) (.+)
[root@megalon c2a]# cat input.txt
# Given below is a list default locations
# of audit files that will be audited by
# c2a.pl when -audit option is selected. If
# the default locations do not reflect the
# settings on your system, please edit the
# same

SNORTVAR=/etc/snort/snort.conf

Once this is all in place, we can run the c2a.pl tool and look at the initial part of the resulting snort-var.audit file:

[root@megalon c2a]# ./c2a.pl -audit -f input.txt -o snort-var.audit
c2a.pl, v1.0 (conf to audit)
(c) 2006 - Tenable Network Security
Processing SNORTVAR=/etc/snort/snort.conf


Finished creating .audit files based on input.txt
Please check snort-var.audit for output

[root@megalon c2a]# more snort-var.audit
#####################################################
# This file is auto-generated with c2a.pl script
# Copyright 2007 Tenable Network Security Inc
# Date: Fri Feb 16 16:33:31 2007
# User: root
# Hostname: megalon
#####################################################

<check_type : "Unix">

#############################################################
# List of values to be audited in /etc/snort/snort.conf
#############################################################

<custom_item>
        #System :       "Linux"
        type    :       FILE_CONTENT_CHECK
description     :       "Check if var HOME_NET entry in /etc/snort/snort.conf is correct. "
        file    :       "/etc/snort/snort.conf"
        regex   :       "var HOME_NET.*"
        expect  :       "var HOME_NET any"
</custom_item>

The full snort-var.audit file can be obtained here:  [Download snort-var.audit]

There is nothing special about this .audit file as it just audits the default "var" settings of a snort.conf file and is intended purely as an example.

Extracting 'preprocessor' and 'include' Settings from a snort.conf File

The snort.conf file also has other values. Many of these are settings for the Snort 'preprocessor' and also signature 'include' settings. Here is a short snippet of 'include' and 'preprocessor' settings for a typical snort.conf file:

• include classification.config
• include reference.config
• include $RULE_PATH/local.rules
• include $RULE_PATH/bad-traffic.rules
• preprocessor http_inspect: global \
• preprocessor http_inspect_server: server default \
• preprocessor rpc_decode: 111 32771
• preprocessor bo
• preprocessor ftp_telnet: global \

There are two things we need to realize now.

First, unlike the 'var' processing we did previously where each unique variable also had a unique value, with 'include' and 'preprocessor' we have the same keyword used over and over with different values. To capture the entire string, we will use some regular expression logic and then have the c2a.pl tool create a full snort-conf.audit file.

Second, those "\" characters in the snort.conf file mean there is a multiple lines for each keyword. For example, the 'http_inspect_server:' value actually looks like this:

preprocessor http_inspect_server: server default \
    profile all ports { 80 8080 8180 } oversize_dir_length 500

Since the c2a.pl script doesn't consider multiple lines, either the snort.conf file needs to be rewritten to take advantage of putting the settings on one line, or the auditor needs to realize that only one line can be audited.

The following steps show command line entires to create a snort.audit file which can test for all settings of a snort.conf file:

The regular expression '(^preprocessor (.+))' finds all snort.conf lines that make declare one of these variables. We place the entire regular expression in parentheses to tell the c2a tool  we want each line uniquely tested for.

[root@megalon c2a]# ./cmv.pl -r '(^preprocessor (.+))' -t SNORTPP -f /etc/snort/snort.conf
[root@megalon c2a]# more SNORTPP.map
SNORTPP=preprocessor flow: stats_interval 0 hash 2
SNORTPP=preprocessor frag3_global: max_frags 65536
SNORTPP=preprocessor frag3_engine: policy first detect_anomalies
SNORTPP=preprocessor stream4: disable_evasion_alerts
SNORTPP=preprocessor stream4_reassemble
SNORTPP=preprocessor http_inspect: global \
SNORTPP=preprocessor http_inspect_server: server default \
SNORTPP=preprocessor rpc_decode: 111 32771
SNORTPP=preprocessor bo
SNORTPP=preprocessor ftp_telnet: global \
SNORTPP=preprocessor ftp_telnet_protocol: telnet \
SNORTPP=preprocessor ftp_telnet_protocol: ftp server default \
SNORTPP=preprocessor ftp_telnet_protocol: ftp client default \
SNORTPP=preprocessor smtp: \
SNORTPP=preprocessor sfportscan: proto  { all } \

Notice in the above matches, some of the lines contain a "\" which indicates that the line wasa multiple-line entry in the snort.conf file. For 'include' lines, the same type of regular expression is used:

[root@megalon c2a]# ./cmv.pl -r '(^include (.+))' -t SNORTSIGS -f /etc/snort/snort.conf
[root@megalon c2a]# more SNORTSIGS.map
SNORTSIGS=include classification.config
SNORTSIGS=include reference.config
SNORTSIGS=include $RULE_PATH/local.rules
SNORTSIGS=include $RULE_PATH/bad-traffic.rules
SNORTSIGS=include $RULE_PATH/exploit.rules
SNORTSIGS=include $RULE_PATH/scan.rules
SNORTSIGS=include $RULE_PATH/finger.rules
SNORTSIGS=include $RULE_PATH/ftp.rules
SNORTSIGS=include $RULE_PATH/telnet.rules
SNORTSIGS=include $RULE_PATH/rpc.rules
SNORTSIGS=include $RULE_PATH/rservices.rules
SNORTSIGS=include $RULE_PATH/dos.rules
SNORTSIGS=include $RULE_PATH/ddos.rules
SNORTSIGS=include $RULE_PATH/dns.rules
SNORTSIGS=include $RULE_PATH/tftp.rules
SNORTSIGS=include $RULE_PATH/web-cgi.rules
SNORTSIGS=include $RULE_PATH/web-coldfusion.rules
SNORTSIGS=include $RULE_PATH/web-iis.rules
SNORTSIGS=include $RULE_PATH/web-frontpage.rules
SNORTSIGS=include $RULE_PATH/web-misc.rules
SNORTSIGS=include $RULE_PATH/web-client.rules
SNORTSIGS=include $RULE_PATH/web-php.rules
SNORTSIGS=include $RULE_PATH/sql.rules
SNORTSIGS=include $RULE_PATH/x11.rules
SNORTSIGS=include $RULE_PATH/icmp.rules
SNORTSIGS=include $RULE_PATH/netbios.rules
SNORTSIGS=include $RULE_PATH/misc.rules
SNORTSIGS=include $RULE_PATH/attack-responses.rules
SNORTSIGS=include $RULE_PATH/oracle.rules
SNORTSIGS=include $RULE_PATH/mysql.rules
SNORTSIGS=include $RULE_PATH/snmp.rules
SNORTSIGS=include $RULE_PATH/smtp.rules
SNORTSIGS=include $RULE_PATH/imap.rules
SNORTSIGS=include $RULE_PATH/pop2.rules
SNORTSIGS=include $RULE_PATH/pop3.rules
SNORTSIGS=include $RULE_PATH/nntp.rules
SNORTSIGS=include $RULE_PATH/other-ids.rules
SNORTSIGS=include $RULE_PATH/virus.rules
SNORTSIGS=include $RULE_PATH/experimental.rules

Both map files are added to the c2a.map file.

[root@megalon c2a]# cat SNORTSIGS.map >> c2a.map
[root@megalon c2a]# cat SNORTPP.map >> c2a.map

The SNORTSIGS and SNORTPP map names are added to the input.txt file:

[root@megalon c2a]# cat input.txt
# Given below is a list default locations
# of audit files that will be audited by
# c2a.pl when -audit option is selected. If
# the default locations do not reflect the
# settings on your system, please edit the
# same

SNORTVAR=/etc/snort/snort.conf
SNORTPP=/etc/snort/snort.conf
SNORTSIGS=/etc/snort/snort.conf

The regular expressions for SNORTSIGS and SNORTPP are added to the c2a_regex.map file:

[root@megalon c2a]# cat c2a_regex.map
HTTP=([a-zA-Z0-9_-]+) (.*$)
SENDMAIL=([a-zA-Z0-9_-]+)=(.*$)
SYSCTL=([A-Za-z0-9\._-]+) = ([0-9]+)
NESSUS=([A-Za-z0-9\._-]+) = (.+)
VSFTPD=([A-Za-z0-9_]+)=([A-Za-z0-9]+)
SNORTVAR=(var .+) (.+)
SNORTPP=(^preprocessor (.+))
SNORTSIGS=(^include (.+))

The tool is then run to produce a snort.audit file:

[root@megalon c2a]# ./c2a.pl -audit -f ./input.txt -o snort.audit
c2a.pl, v1.0 (conf to audit)
(c) 2006 - Tenable Network Security
Processing SNORTVAR=/etc/snort/snort.conf
Processing SNORTPP=/etc/snort/snort.conf
Processing SNORTSIGS=/etc/snort/snort.conf

Finished creating .audit files based on ./input.txt
Please check snort.audit for output

The resulting scan results with a Nessus 3 scanner look like this:

A PDF of the HTML report produced by Nessus 3 of the scan can be obtained here:

Download snort-audit.pdf

The actual snort.audit file generated for this demo is located here:

Download snort.audit

If you inspect the file, you will see several preprocessor entries which were the first part of a multiple line snort.conf entry.

Other Uses for the c2a.pl tool

Tenable has included several entries in the c2a.map and c2a_regex.map files to enable auditing of Sendmail, the Very Secure FTP Daemon (VSFTPD), Apache, the Red Hat /etc/sysctl.conf file and Nessus. More may be added in the near future. If you'd like to submit new mappings to Tenable to share with other Nessus users, please send them to nessus-support@tenablesecurity.com.

With that in mind, the c2a.pl script can be used to help create a Nessus .audit files for several live UNIX applications. Consider the following ideas:

• If your organization has many UNIX based firewalls, a .audit file can be generated to audit the common and required settings that each firewall is supposed to have.  For example, if all firewalls are supposed to have filtering of RFC 1918 addresses, the actual firewall rules can be tested for.
• If many different custom applications are being run out of CRON, the various CRONTABs can be audited to make sure that the right applications are being run at the correct time.
• For centralized logging, remote UNIX systems can have their SYSLOG, SYSLOG-NG and LOGROTATE configurations checked.

Manual Tweaking of the .audit files

Lastly, the output of the c2a.pl script  can also be manually edited. For example, consider combining the MD5 checksum rules with the FILE_CONTENT_CHECK rules into one rule.  The output  generated by the c2a.pl script also assumes that a configuration file is always in one place. Consider modifying the "file" keyword to specify other locations where a configuration file may be located.   

Lastly, if you have content that you don't want in your remote file configurations, consider manually adding in checks for that with the  FILE_CONTENT_CHECK_NOT keyword. This can help you perform audits for settings that should be present and should also not be present.   

Working with the Security Center

Although each of the above examples focused on direct Nessus usage, any of the .audit files generated with  the c2a.pl tool can be loaded into the Security Center's /opt/sc3/admin/nasl directory and then used to perform credentialed audits of remote UNIX system and application configurations. We've previously blogged about doing this with Windows UNIX checks and it is very similar for the UNIX .audit file audits.

For More Information

Anyone interested in learning more about the Direct Feed ($1200/year per scanner) can do so here. The Security Center ($15,750 for 500 systems) is available for the Red Hat operating system and can manage multiple Nessus scanners, perform configuration audits for compliance reporting, process network IDS logs and also manage multiple Passive Vulnerability Scanners and Log Correlation Engines.

In addition to auditing UNIX servers, Nessus 3 can also be used to audit Windows servers. To learn more about auditing Windows servers, please refer to these blog posts:

• Auditing Windows 2003 Servers for Disabled USB Drives and AutoRun CD-ROM
• Creating "Gold Build" Audit Policies
• Nessus 3 Agentless Compliance Checks

Tenable's 80+ page Real-Time Compliance Monitoring paper is available to current and potential customers and discusses for logging, network monitoring, vulnerability scanning and configuration auditing can help monitor PCI, SOX, FISMA, NERC and many other compliance standards.

Obtaining the c2a Tool

The c2a tool, and all other UNIX and Windows compliance utilities, plus many example .audit files can be obtained here.

The Nessus 3 Direct Feed was updated today with enhanced functionality for Windows compliance checks. This blog entry discusses the new features and has example .audit text to illustrate them, including a test case for the recent Microsoft update for 2007 Daylight Savings Time. These changes only effect Windows audits.

Multiple Potential Compliance Values for AUDIT_POLICY Items

Both the "value" and "value_data" keywords can now accept multiple values within an "AUDIT_POLICY" context. If any of these values are present in the audited system, then the system passes the audit. Values are separated with "|" characters. Here is an example for a simple built-in test as well as a custom item test:

<item>
  name: "Audit logon events"
  value: "Failure" | "Success, Failure"
</item>

<custom_item>
   type: AUDIT_POLICY
   description: "Audit logon events"
   value_type: AUDIT_SET
   value_data: "Failure" | "Success, Failure"
   audit_policy: AUDIT_LOGON
</item>

Both examples would pass a Windows server if auditing only logged login failures, or if logging of login failures and successes were performed.

REG_BINARY Support

A new value type of POLICY_BINARY is now available to test REG_BINARY registry settings. Using the regedit.exe tool, if you encounter a binary registry setting which requires testing, strip out the spaces and add it in to the "value_data" content.

Below is an example custom item for testing the application of the recent Microsoft 2007 Daylight Savings Time update. It uses a POLICY_BINARY setting to test for a value of "00 00 03 00 02 00 02 00 0000 00 00 00 00 00 00".

<custom_item>
  type: REGISTRY_SETTING
  description: "2007 Daylight Savings Patch Applied"
  value_type: POLICY_BINARY
  value_data: "00000300020002000000000000000000"
  reg_key: "HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation"
  reg_item: "DaylightStart"
</item>

Service Checks support CAN_BE_NULL or CAN_NOT_BE_NULL Flags

Prior to this update, a "reg_option" value of CAN_BE_NULL or CAN_NOT_BE_NULL was only supported on Registry Setting, Registry Permissions, File Permissions, File Content Checks and File Content Check NOTs audits.

This release now supports a new optional "svc_option" tag with values of CAN_BE_NULL or CAN_NOT_BE_NULL for service policy audits. This is useful for cases where the lack of a service running doesn't violate being compliant, or specifying that a certain service has to be running.

Optionally Ignoring Access Control List Inheritance

This release also includes more flexibility when auditing access control list (ACL) inheritance. The following ACLs can currently be audited:

• file_acl
• registry_acl
• service_acl

Each of these can now contain an "acl_inheritance" value of:

• not inherited
• inherited
• not used

This can force an audit of a file, registry or service ACL to not care, if the actual list was inherited or to specifically state the ACL inheritance type.

Receiving The Latest Plugins

Security Center and Nessus 3 Direct Feed users should update their plugins after reading this blog to receive the new functionality. If your Security Center is performing daily updates of plugins, then a manual plugin update will be required if you wish to use the new functionality immediately.

For More Information

Anyone interested in learning more about the Direct Feed ($1200/year per scanner) can do so here. The Security Center ($15,750 for 500 systems) is available for the Red Hat operating system and can manage multiple Nessus scanners, perform configuration audits for compliance reporting, process network IDS logs and also manage multiple Passive Vulnerability Scanners and Log Correlation Engines.

To learn more about auditing Windows servers, please refer to these blog posts and webinar:

• Auditing Windows 2003 Servers for Disabled USB Drives and AutoRun CD-ROM
• Creating "Gold Build" Audit Policies
• Nessus 3 Agentless Compliance Checks
• Nessus Compliance Checks (webinar)

Tenable's 80+ page Real-Time Compliance Monitoring paper is available to current and potential customers and discusses for logging, network monitoring, vulnerability scanning and configuration auditing can help monitor PCI, SOX, FISMA, NERC and many other compliance standards.

Today Tenable announced a partnership with Enterasys Networks that enables customers of both companies to operate Nessus and/or the Passive Vulnerability Scanner (PVS) directly on the Dragon sensor. Customers who have existent or planned Tenable and Enterasys security solutions should consider this deployment option. This blog entry discusses several deployment scenarios as well as interaction between Tenable and Enterasys security solutions.

Ease of Deployment and Integration

If your organization has multiple Dragon sensors in place, both Nessus and the PVS can be deployed on these devices. Typically, a Dragon IDS sensor is optimally deployed for passive network monitoring with a PVS as well as active vulnerability scanning with Nessus.

If your organization has a Tenable Security Center, Nessus scanners and Dragon sensors, but has not deployed the Passive Vulnerability Scanner, deploying them on the Dragon sensors can provide immediate benefits. Adding passive vulnerability data to your Security Center will increase the accuracy of your discovered assets and vulnerabilities. It will also increase the accuracy of the correlation between the IDS events detected by Dragon and the vulnerabilities on your network.

If you organization is engineering a network monitoring solution, deploying Dragon, Nessus and the PVS on one platform simplifies the architecture and maximizes your resources.

Tenable engineers have developed unique installation packages for Nessus and the PVS which install directly onto the Dragon IDS appliance. Enterasys customers should contact Tenable's sales staff to obtain download information for these packages.

Performance

The ideal use case is to deploy the PVS and/or Nessus on a Dragon sensor in passive mode which isn't currently reaching maximum CPU usage. If your Dragon sensor is inline in "prevention" mode, adding on Nessus and/or the PVS is not advised. Neither Nessus or the PVS were designed for inline analysis.   
Enterasys and Tenable Product Interaction

The Security Center receives IDS events from the Dragon management console. These events undergo realtime vulnerability correlation such that real attacks that are likely to succeed are immediately highlighted. The accuracy of this correlation is greatly enhanced with realtime network vulnerability monitoring by the PVS.

The Security Center can also extend the information discovered by Dragon securely to different political or business groups within your organization. This allows groups to gain access to IDS events targeting just their network or assets without the need to deploy a dedicated sensor. Each group can view their security data through a web interface, create custom reports and produce animations and visualizations in a three dimensional user interface. 

For even greater event correlation, the Tenable Log Correlation Engine (LCE) accepts IDS events from Dragon sensors and can correlate these with netflow, system logs, firewalls and many other devices. The LCE has many specific TASL correlation scripts which correlate IDS events with network change, new device behaviors, known hacker compromise techniques and worms/botnet communication patterns.

For More Information

Tenable has several webinars and white papers available online which discuss VA/IDS correlation and well as event correlation in general.

• Correlating IDS events with Vulnerabilities Webinar
• Good and Bad uses of Vulnerability Data for IDS Event Correlation Blog
• Network Based Anomaly Detection Webinar
• VA/IDS Correlation White Paper
• Event Correlation White Paper

Please contact Tenable's sales and support groups for more information on obtaining the Nessus and PVS builds for the Dragon appliances.

Nessus 3.1.2, the first public BETA of what will become Nessus 3.2, has been released for the Linux, FreeBSD and Solaris operating systems. 

Download Nessus 3.1.2

There are many new features available including:

• Experimental IPv6 support
• Improved bandwidth throttling
• Extended nessusd.rules functionality to add support for ports and plugins
• New command 'nessuscmd' which lets you do a quick command-line scan
• Improved NASL engine including an API to write custom WMI checks
• Easy-update : Nessus can now update its own engine by doing /opt/nessus/sbin/nessus-update

This blog entry discusses these new features and how BETA testers should provide feedback. Over the next few weeks, we will discuss these topics (such as IPv6 and the new WMI library) in much more detail.

Experimental IPv6 support

Nessus 3.2 supports IPv6 natively. It allows you to scan any IPv6 host provided that the host it runs on has an IPv6 stack enabled. To scan an IPv6 host, simply type its IP address. If the host is on the local network (fe80::XXXX) you can also specify the interface to use when doing the scan. For example,  enter "fe80::20d:93ff:abcd:efab%eth0" to scan the host fe80:20d:83ff:abcd:efab on the local network connected to eth0.

Note that it is not possible to specify a range of addresses, as scanning each of them would not make sense. For example, scanning fe80::1/64 is an astronomical number and would take a very long time to enumerate each IPv6 address.

Nessus 3.2 has the ability to send a multicast ping query to determine the IPv6 hosts of your local network. Simply enter "link6%eth0" and nessusd will discover all the IPv6 enabled hosts.

Finally, if you scan the same host with both IPv4 and IPv6 addresses (ie: you enter a target of 192.168.1.1 and fe80::4242) then in the final report the same host will appear twice : once as an IPv6 system, and once as an IPv4 host. This is actually not much different than scanning the same physical system that has a "real" IPv4 address and perhaps a second network interface with another IPv4 address.

Improved Bandwidth Throttling

max_simult_tcp_sessions

In order to avoid flooding a network, Nessus now has the ability to define a maximum number of TCP connections in parallel, on a per-nessusd or per-scan basis. In nessusd.conf, setting the following option :

global.max_simult_tcp_sessions = 50

will guarantee that the system running your nessus scan will never establish more than 50 tcp sessions in parallel (wether there is one, ten or one hundred scans going on at the same time).

In your .nessusrc, adding the option :

max_simult_tcp_sessions = 20

will guarantee that your scan will not establish more than 20 sessions in parallel. If you have two scans running with this setting, then your system might end up doing 40 tcp sessions in parallel.

The "max_simult_tcp_sessions" setting is scan based whereas the "global.max_simult_tcp_sessions "is scanner based.

global.max_hosts

It is also possible to configure nessusd on a per-nessusd basis so that a maximum number of hosts are being scanned in parallel. It works like the current "max_hosts" settings, but on a per scanner basis, meaning that if you set "global.max_host" to 20 in nessusd.conf and have 10 scans running, eventually each scan will only scan 2 hosts in parallel.

Extended nessusd.rules

The grammar of the nessusd rules has been extended to let you forbid/allow nessusd to connect to some ports. In nessusd.rules, you can now prevent the connections to some ports. For instance, adding :

    reject 0.0.0.0/0:9100

will prevent the connection to any HP printer on port 9100. The ports can be entered as ranges as well, such as:

    reject 192.168.0.0/24:1-1024

This would prevent scans from connecting to ports 1 to 1024 on the subnet 192.168.0.0/24.

Please note that these rules only apply to TCP ports, not UDP and also that these rules do not work with IPv6 host addresses yet.

Plugin usage can also be limited such as:

    plugin-reject 10335
    plugin-accept 10000-40000

These rules can be set in the nessusd.rules file, on a per user basis or supplied by the end-user (as this is currently the case in Nessus 3.0).

New command 'nessuscmd'

The nessuscmd program (whose name might change -- suggestions are welcome) is a simple utility designed to perform a quick scan of a host or network for a small set of plugin IDs. For instance, if you want to scan your local subnet to determine which hosts have a default SNMP community set, do:

/opt/nessus/bin/nessuscmd -i 10264 192.168.0.0/24

More info can be obtained by doing :

/opt/nessus/bin/nessuscmd -h

Astute readers should find some similarity between some of the switches of nessuscmd and nmap.

Improved NASL engine

New functions

A few new functions have been added, in particular a plugin may now reduce the selected set of plugins while the scan is running. For instance, one may want to make sure that if the remote host is considered as being sensitive (ie: it's the payroll db server, a SCADA device, etc...) then one wants to programatically disable all plugins except one family or two which are known not to have any side effect. The functions to manage the plugin selection are :

• disable_all_plugins()
• enable_plugin_family(<name>)
• disable_plugin_family(<name>)
• enable_plugin_id(<id>)
• disable_plugin_id(<id>)

Note that a script can only reduce the set of selected plugins. If you do a scan with only the plugin #12345 being enabled, you can't have it enable plugins which were selected by the end user. However, you could do a plugin like :

if ( remote_host_is_the_payroll_server() )
{
  # Only audit the MSFT bulletins against the remote host

  disable_all_plugins(); # First : disable every other plugin
  enable_plugin_family("Windows : Microsoft Bulletins");
}

Support for pre-compiled libraries

NASL 3.2 supports the inclusion of pre-compiled libraries (we call this .nlib files). From within a NASL script, one can import a .nlib file by doing :

import("libName.nlib");

The only .nlib file available at this time is our WMI library. More information about performing WMI audits of Windows hosts with this library is available at http://cgi.tenablesecurity.com/tenable/WMI.html Tenable has also previously blogged about utilizing WMI audits for vulnerability scans here.

Nessus Program Easy-update

It's now very easy to upgrade your Nessus installation to the newest version of the engine. Simply make sure you are registered and type : /opt/nessus/sbin/nessus-update and Nessus will update itself. This feature is currently supported in Linux and FreeBSD, but not Solaris yet.

Miscellaneous Features

Scan pausing is now supported (with the command-line client, put the client in background by doing ctrl-Z to pause the scan and type 'fg' to resume it. GUI support will follow soon). Note that if you disconnect from nessusd while a scan is paused, the scan will be lost.

If a tested host is disconnected in the middle of a scan, nessusd should detect it and stop scanning that particular system (and tell you about it in the nessusd.messages logs).

Feedback

Please send your feedback, crash dumps, suggestions and complaints directly to Tenable's Director of Research, Renaud Deraison.

When deploying the Log Correlation Engine (LCE), Tenable's support group often is asked which is better for network monitoring: using netflow from a router or performing some sort of direct network monitoring. This blog entry will help users choose a strategy and discuss some of the technical and political aspects associated.

Netflow and Direct Sniffing

If you only have access to netflow or direct network sniffing, you should not feel as if your monitoring is lacking because you are doing one or the other.

Both of Tenable's LCE agents, the Tenable Network Monitor (TNM) and the Tenable Netflow Monitor (TFM), produce a record of each network session. This record includes ports, source and destination IP addresses and total number of bytes transfered. Each of these records is consumed by the LCE for normalization, statistical profiling and for event correlation by many different TASL scripts.

There are minor differences between the TFM and the TNM. The TNM uses the libpcap library and can accept any type of valid "pcap" packet filter. The TFM also performs filtering, but it is not as sophisticated as the TNM. The TFM, as of release 2.0.2, also differentiates client and server bandwidth, whereas the TNM logs aggregate bandwidth for each session.

The TFM is available for RedHat ES3 and ES4 and it can receive netflow records from multiple sources. The TNM is available for RedHat ES3, Fedora and FreeBSD, and must be deployed on a system that has a network interface exposed to network traffic.

Leveraging "Sniffing Platforms"

If you have deployed the Passive Vulnerability Scanner (PVS) on RedHat ES3 or ES4, you should consider deploying the TNM on the same system. Tenable has monitored many large networks with servers that ran both the PVS and the TNM with very good results. Compared to the PVS, the performance requirements for the the TNM are negligible.

If your organization has deployed UNIX based NIDS such as Snort, Dragon, Bro or even dedicated network monitoring applications such as TCPDUMP or NTOP, these may also be a candidate to deploy the TNM on.

Leveraging Netflow

The TFM supports netflow records (version 5 and 9) from Cisco devices. A single TFM can accept records from multiple devices.

Since netflow is a UDP based protocol, any CPU contention at the TFM or network congestion between the routers and the TFM could cause some session loss. The TFM does have logic to reconstruct full session data if some netflow records have been missed.

The Business Case for Network Monitoring

As a security auditor or network security monitor, considering network sessions alongside system logs and NIDS events is relevant for a variety of "compliance violation" and "compromise alerting" activities.

If the organization providing access to the network (such as a routing, infrastructure or backbone group) does not have a security component, presenting them with data through the Security Center and the Log Correlation Engine may be very useful to them. If they are already collecting netflow data, perhaps for performance and availability monitoring, sending an addition stream of network session information to a TFM may not be difficult.

If direct sniffing of a data center or network is desired, you will likely need to use switch span ports, network taps or tap concentrators. This is very dependent on your network architecture, the technology of your routers and switches and how reliable your monitoring must be. For more information on this topic, readers should consider the TaoSecurity blog which discusses various aspects of this in depth as well as vendors such as NetOptics.

Filtering for Performance

As with any log aggregation and analysis exercise, you should consider the purpose of the monitoring and what sort of traffic is required. If not, you will likely over-log and record data that isn't relevant. You may also dramatically increase your storage requirements.

If the purpose of network monitoring is to identify hosts, where they connect to, which ports they browse on and what ports are being served, the LCE can tell you this, but you may be better off with the Passive Vulnerability Scanner (PVS).

For example, let's say a new application listens and browses on TCP port 7003. A user of the Log Correlation Engine may run a report for all sessions on port 7003 and then sort by IP address or network. All network sessions would need to be stored by the LCE for it to perform these tasks. However, with the PVS, it maintains a list of all ports that are both open and browsed. The application may have made 1,000,000 network connections on port 7003, and the PVS will only log this once, whereas if the LCE is tracking these, then all 1,000,000 sessions will be stored.

For More Information

Readers who would like to learn more about log analysis should consider the Tenable paper "Security Event Management" as well as the "Network and Behavioral Anomaly Detection" webinar.

For credentialed scans of Windows systems, Nessus can detect the presence of many leading anti-virus solutions. This blog entry will discuss what sort of information can be reported, how this is relevant for compliance and vulnerability audits and the specific anti-virus solutions supported.

Auditing Anti-Virus Deployments

Nessus uses credentialed scans of Windows systems to audit the local files and registry settings to determine both the presence of an anti-virus solution, if it is indeed running and if it is up to date.

For supported anti-virus solutions, a separate Nessus plugin is used to specifically identify that software and determine if the signatures are up to date. At Tenable, our research group monitors vendor signature updates for each solution and then updates the corresponding Nessus plugin. To take advantage of this sort of auditing, your Nessus scanners should be subscribed for either the Registered Feed or the Direct Feed.

There are many reasons why an anti-virus solution can't receive an updated list of new signatures. Some of these could be due to licensing issues, expiring demos or even network connectivity issues such as DNS or firewall changes. In some cases, mal-ware or a new virus may have gotten into a system and explicitly attacked the existing anti-virus solution.

For IT organizations that wish to minimize complexity, detecting unauthorized anti-virus solutions present on the corporate network is very useful. Having multiple anti-virus solutions on one system can lead to performance, compatibility and stability issues.

Compliance and Vulnerability Auditing

For compliance, if an organization has selected one or more anti-virus solutions, being able to audit this with Nessus can prove to an auditor that a solution is indeed installed, in use and up to date. Residing solely on software enumeration won't let you know if an anti-virus has been installed, but has been disabled. It also won't let you know if the license or network connectivity is up to date.

Depending on the function of a system that is being scanned by Nessus, not having an anti-virus solution may be considered a vulnerability. Also, if it is assumed that a system is protected by an anti-virus solution, but in fact the solution isn't running, or does not have the latest signatures then it isn't really protected.

Detected Anti-Virus Applications

At the time of this writing, the following anti-virus solutions are detected as installed, running and up-to-date by Nessus:

• #24232 BitDefender Check
• #20284 Kaspersky Anti-Virus Check
• #12107 McAfee Anti Virus Check
• #21608 NOD32 Antivirus System Check
• #12106 Norton Anti Virus Check
• #12215 Sophos Anti Virus Check
• #20283 Panda Antivirus Check
• #21725 Symantec Anti Virus Corporate Edition Check
• #16192 Trend Micro Anti Virus Check
• #24344 Windows Live OneCare AntiVirus Check

Nessus also has plugin #16193 which aggregates the results from these other plugins. It is useful if you are in a multiple anti-virus solution environment and just want to find hosts that have a solution installed and operational.

The above plugins only report an issue if a problem is found with the detected anti-virus solution. Plugin #16193 reports if a system does have a known working anti-virus solution.

Additional Tenable Solutions

The Security Center can be used to aggregate scan results and place systems without anti-virus, or non-operating anti-virus solutions into a unique asset list. These lists can then be used for reporting, scanning, IDS event monitoring and anomaly detection with the understanding that systems without AV are more likely to become infected.

If the Passive Vulnerability Scanner is also in use, then the asset lists could be further qualified to only discover systems without anti-virus solutions that are browsing on the Internet. Windows systems that browse the Internet without some sort of anti-virus solution are may be more likely to become infected. The Passive Vulnerability Scanner also has the ability to monitor the update process for several different anti-virus solutions and identify them without the need for scanning.

For Additional Information

The following is a list of various white papers, Tenable blog posts and Nessus checks that relate to detecting both anti-virus solutions as well as virus infections: 

• The Antivirus Challenge (PDF)
• Hunting Symantec Worms (Blog Post)
• Detecting Compromised Windows Hosts Infected (Blog Post)
• #11329 The remote host is infected by a virus (Nessus Check)

The Passive Vulnerability Scanner (PVS) has the ability to discover network services which have the characteristic of being "interactive" or being "encrypted". The PVS can analyze traffic in real-time and recognize when the size and frequency of packets is indicative of an "interactive" session. The PVS can also look at the traffic's randomness and determine if the data is encrypted. This blog post helps PVS users understand how to analyze this data, where false positives can occur and what these events mean.

Native PVS Event IDs

The Passive Vulnerability Scanner has several thousand plugins which detect a wide variety of client and server applications. It also has several "built in" plugins which detect many low-level items. These are:

• #00000 Detection of open port The PVS has observed a SYN-ACK leave from a server.
• #00001 Passive OS Fingerprint The PVS has observed enough traffic about a server to perform a guess of the operating system.
• #00002 Client Side Port Usage The PVS has observed client-side network browsing traffic from a host.
• #00003 Show Connections The PVS has logged a unique network trust relationship of source IP, destination IP, and destination port.
• #00004 Internal Interactive Sessions The PVS has detected one or more interactive network sessions between two hosts within your focus network.
• #00005 Outbound Interactive Sessions The PVS has detected one or more interactive network sessions originating from within your focus network and destined for one or more addresses on the Internet.
• #00006 Inbound Interactive Sessions The PVS has detected one or more interactive network sessions originating from one or more addresses on the Internet to this address within your focus network.
• #00007 Internal Encrypted Session The PVS has detected one or more encrypted network sessions between two hosts within your focus network.
• #00008 Outbound Encrypted Session The PVS has detected one or more encrypted network sessions originating from within your focus network and destined for one or more addresses on the Internet.
• #00009 Inbound Encrypted Session The PVS has detected one or more encrypted network sessions originating from one or more addresses on the Internet to this addresses within your focus network.
• #00012 Host TTL Discovered The PVS logs the number of hops away each host is located.

Vulnerability IDs 4,5 and 6 look for "interactive" sessions inside, outbound and inbound to the network being monitored by the PVS. This allows to identify all types of "human typing" that is both legitimate and perhaps, illegitimate.

Similarly IDs 7,8 and 9 look for "encrypted" traffic inside, outbound and inbound to the network being monitored by the PVS. This will not only identify things like SSH and HTTPS services, but also services that are not natively recognized by other PVS rules.

Once the PVS flags a device as having a particular open port, encrypted session, interactive session or trust relationship, this will show up in the vulnerability report. Typically, network and security analysts are accustomed to seeing these sorts of alerts in logs or real-time. However, with the PVS, this data has state. If an e-commerce site has 1,000,000 SSL connections to port 443, the PVS will only have report one encrypted session record for that report.

Interactive Session Analysis

Based on the frequency and size of packets between two hosts, the PVS can identify a session that is interactive. By interactive, the PVS is looking for data that is sent by a user typing at the keyboard. Example sources of data include Telnet, chat and SSH. By default, the PVS will ignore ports with well known interactive services such as 23 for Telnet.

There are a variety of false positives that can occur with these algorithms. If there are network performance issues which cause packets for any service to flow at a trickle, it is possible that an incorrect match will result. However, most "slow services" still put 1500 bytes into their packets and this won't cause a match.

When matches do occur, they will be reported for analysis. When considering a large network for monitoring, this data can be very useful.

Port summaries for inbound, outbound and internal interactive traffic can indicate common services used. For example, one might be able to discover that all of the routers on a network have had a "telnet" service put on a high port.

When specific ports of interest are found, the results from recent Nessus scans as well as other PVS plugins should be considered. Both Nessus and the PVS are very good at identifying services.

Also, when analyzing the open ports, the system under consideration should be taken into account. For example, a router won't likely be participating in a P2P file sharing network or running a VoIP application whereas a desktop would.

If your Security Center has been configured with assets for your business and technology in use, choosing vulnerability IDs 4-6 and then conducting an Asset Summary query can give you an at-a-glance view of which assets have interactive sessions occurring.

For example, in this listing below, the only 3 "interactive sessions" reported have occurred for assets labeled "Clients", "FTP Servers" and "SMTP Clients". 

Encrypted Session Analysis

Based on the "randomness" of the monitored data, the PVS will report that a monitored system is communicating inbound, outbound and internally on certain ports with encrypted traffic.

There are several "naturally occurring" random data sources. Any time compressed files (.zip, .gz, .etc) are moved around on the network, there is a good change the network session will flag as being encrypted. We'll see in an example below how email can be the source of some "encrypted" sessions.

Analyzing the results of traffic is also accomplished with the Security Center. Port summaries, lists of matching IP addresses and reporting which assets have made "encrypted" sessions can shed light on what these detected services are doing.

Below is an example listing of a set of assets that have had at least one occurrence of PVS ID 7,8 or 9:

Two things should jump out to an analyst looking at this data:

• Of the 16 reported devices with encrypted sessions, many of these occurred on SMTP clients or servers. The PVS will trigger on messages that are encrypted with PGP or GPG. There content will also match on specific plugins designed to identify hosts sending PGP and GPG encrypted emails.
• There were 4 matches on the Symantec_Worm group. In a previous post, it was discussed how to create a dynamic asset list in the Security Center that matched hosts likely compromised with a worm targeting the Symantec AV engine. It is interesting that these hosts are also communicating on encrypted ports.

Configuring the PVS

While searching network sessions for encrypted or interactive data, the PVS can be configured to ignore specific ports or even hosts that have certain plugins already detected on them. On UNIX, this is accomplished by editing the pvs.conf file located in the /opt/pvs/etc  directory. The PVS Windows version has GUI elements to select specific plugins and ports to ignore.   

Conclusion

The PVS can be used to identify devices which are the source or destination of interactive or encrypted network sessions. This data can be used to look for policy violations or perhaps backdoors and rootkits.

Tenable Network Security has recently added the ability to query remote Windows systems via the Windows Management Instrumentation (WMI) protocol. This allows a credentialed Nessus 3 scan to perform some very advanced configuration audits of Windows systems. This blog entry discusses WMI, the initial checks developed by Tenable and how this can impact consultants and enterprise users of Nessus and the Security Center.

What is WMI?

WMI is a kernel level instrumentation technology for Windows. It allows  remote applications to query Windows systems for performance and configuration information. It also allows remote applications to set configuration data. The types of data that can be remotely queried and modified include:

• Publishing kernel instrumentation
• Configuring device settings
• Providing kernel-side event notification
• Publishing custom data
• Allowing administrators to set data security
• Accessing instrumentation by way of WMI

For more information about WMI, please visit Microsoft's web site on the technology.

Initial Set of Nessus Plugins

Tenable's Research team has published seven new plugins which make use of WMI queries. These plugins are listed here:

• #24269 WMI Available - Checks that a WMI query can be performed to the scanned Windows system.
• #24270 Computer Manufacturer Information - Obtains the specific make and model of the scanned device such as "Manufacturer : Dell Computer Corporation" and "Computer Model : Dimension 8300".
• #24271 SMB share files enumerated (via WMI) - This lists all remote files on the scanned server and is much faster than performing a similar query through SMB.
• #24272 Network Interface Enumeration - This plugin lists all network interfaces on the system and their IP addresses associated with them.
• #24273 Remote Copy of Windows Not Activated - Detects installed versions of Microsoft that have not been activated and will become disabled.
• #24272 USB Drives Enumeration - Lists all USB storage drives and their names.
• #24282 DEP is Disabled - The Data Execution Prevention technology that helps mitigate buffer overflows and system crashes is disabled.

Below is an example screen shot of a USB Drive audit from an OS X version of Nessus:

Availability

Tenable plans on developing many more checks of these types in the near future. These checks have been currently made available to Direct Feed customers and Registered Feed users will obtain them in seven days.

Nessus 3 is required to run these checks. It does not work with Nessus 2. If your organization is using a Managed Security Provider or Network Access Control product which makes use of Nessus 2, please ensure that they have licensed Nessus 3 from Tenable Network Security for their solution.

To the best of our knowledge, Tenable is the first company to ship a platform independent WMI implementation which does not require anything to be installed on the remote Windows system.

Couldn't Nessus do this before?

The remote patch auditing and configuration ability of Nessus 3 (for both patch auditing and configuration compliance checks) was performed over SMB. This allowed Tenable researchers to query patch information, open files, open registry settings and check the security settings of these devices. Through SMB alone though, there were many types of Windows information relevant to security that could not be queried. Tenable's implementation of WMI for Nessus 3 opens up many new types of checks.

Why is this important for consultants and enterprise users of Nessus?

The seven plugins released today should be very useful to both Security Center enterprise customers as well as consultants who scan large Windows networks. For Security Center users, considering the following possibilities:

• The data obtained by the make and manufacturer can be used to create dynamic asset lists. This can allow you to create asset lists based on specific manufacturer models, laptop vendors and so on.
  
• Network interface enumeration can be used to find Windows computers that have IP addresses not on your local network. This could allow you to also find a node that has both a wired connection with a valid IP and a wireless connection which has an unauthorized IP.
• Listing where all USB drives are located within an organization can also be of great use, especially in the hunt for sensitive data located in the wrong places or wrong organizations.

If you are a consultant or service provider and offer remote scans for Windows devices, these new checks can add great value to the gathered results. If your customers are asking for this sort of technology, you should also consider adding Nessus compliance checks to the offering, which is available through the Nessus Direct Feed.

I got the chance to virtually sit down with the folks at PaulDotCom for an interview. We discussed a variety of topics including vulnerability disclosure, Nessus usage, the early days of Dragon and Snort, advice for people entering the computer security industry and my background.

Anyone interested in the interview can obtain the MP3 audio here:
http://hydrogen.oshean.org/pauldotcom-SE-gula.mp3

The User Datagram Protocol (UDP) transfers data much differently than the Transmission Control Protocol (TCP). Services that run on UDP can make use of the client and server model that TCP uses, but it can also transfer data without an established connection and send data to multiple computers with a single packet. This blog entry discusses UDP port scanning, active services enumeration and passive network monitoring to identify UDP services and vulnerabilities.

Probing for "open" UDP Ports

A very common question that Nessus users ask of Tenable is why there isn't a UDP port scanner option for Nessus. The short answer is that Nessus performs UDP service enumeration for 1000s of different applications but doesn't perform generic UDP port scans.

There is nothing technically wrong with performing a UDP scan, but on most networks, there is a very good opportunity to report open UDP ports incorrectly.

Probing for UDP ports consists of sending a UDP packet to each port and then either waiting for no response, potentially a UDP packet response or an ICMP (Internet Control Message Protocol) "port closed" message. If no response is received the scanner can conclude that the port is open. If an ICMP "port unreachable" message is received, the scanner can conclude the port is closed.

There are several potential false positives and false negatives that can occur here:

For many networks, when performing scans of many ports on many systems at the same time, the actual probing packet might not make it to the target host due to network congestion. Since no response is received, the scanner might conclude the port is open. If no response is received, it might consider trying again, but this could also cause more packets to be used in the probe and cause a different probe packet to not reach it's target. A slang term for the "U" in "UDP" is unreliable.  Any router or switch along the way can drop the packet if it gets too busy.

Also compounding the issue, firewall rules between the scanner and the target might explicitly deny outbound ICMP messages. For UDP packets that make their way to a closed port and have the system respond with an ICMP port unreachable message, this packet might be dropped at the egress firewall or router. Since this ICMP message isn't received, the scanner may incorrectly assume that all is good and the UDP port is indeed open.

ICMP packets may also not be sent from a host because modern TCP/IP stacks have implemented rate limiting. Although responding to a UDP probe with an ICMP port unreachable packet may be the "right thing to do", if the number of ICMP packets being sent exceeds a rate limit, they won't be sent at all. This will cause the scanner to think the UDP port is indeed open.

UDP Application Enumeration with Nessus

Nessus discovers open UDP ports by simultaneously identifying the actual application using the port. It performs this by sending specific application probes for UDP protocols (such as SNMP or DNS) and then waiting for the correct application response. This is very accurate and leaves little ambiguity if a particular UDP application is reachable or not.

Nessus does not do service fingerprinting on UDP protocols.  In other words, when probing UDP port 53, we don't send in a SQL query, DNS query and then SNMP and wait for a response.  The majority of UDP services only reply to a well written query .

For UNIX systems being scanned by Nessus with credentials, the "netstat -an" command can be used to enumerate all open ports, including UDP ports.

Nessus also learns about UDP services through queries to the SunRPC and MSRPC portmappers. Each of these protocols provides very accurate listings of both UDP and TCP services and the processes that are listening on their ports.

UDP Service Enumeration with the Passive Vulnerability Scanner

Another interesting way of identifying UDP client and server applicants in use is to simply sniff the network traffic. Tenable's Passive Vulnerability Scanner identifies a wide variety of UDP based protocols and associated vulnerabilities in both the clients and servers. This has no impact on the network and is extremely accurate.