This blog entry outlines a wide variety of audits and monitoring techniques that can be used to keep watch over the Secure Shell applications in use on your network. Examples for auditing SSH client and server configurations, vulnerabilities and logs will be discussed using Nessus, the Passive Vulnerability Scanner, the Security Center and the Log Correlation Engine.

This will be a three part blog entry where we will consider discovering the SSH applications, auditing their configurations and then monitoring their logs and network activity. This is part 1 of 3.

Discovering SSH Servers with Nessus Network Scans

Before any type of audit can be accomplished, an accurate inventory of all Secure Shell (SSH) servers should be preformed.

The Nessus vulnerability scanner can find SSH daemons running on many types of operating systems. When it finds an SSH daemon running, it will report several things.

Plugin #10881 "SSH protocol versions supported" will list the specific version of the Secure Shell protocol supported by the daemon with a report similar to the following:

The remote SSH daemon supports the following versions of the
SSH protocol :
. 1.33
. 1.5
. 1.99
. 2.0
SSHv1 host key fingerprint : c2:3f:77:2a:72:10:7d:7d:2a:49:8f:21:a4:d2:20:27
SSHv2 host key fingerprint : 1d:31:f3:6a:5b:c9:86:fa:93:ee:9c:d3:c9:c5:d2:10

This output also includes the SSH host key fingerprints of the daemon being scanned.

Plugin #10267 also identifies the detected SSH daemon and logs the specific SSH banner in use. It also audits which type of authentication methods are available as shown below:

SSH version : SSH-1.99-OpenSSH_3.6.1p2
SSH supported authentication : publickey,password,keyboard-interactive

Nessus will also attempt to enumerate any SSH daemon vulnerabilities that can be discovered through network analysis. There are many vulnerabilities associated with Secure Shell. At the time of writing this blog, searching for Nessus plugins that had the string "SSH" in them returned more than 100 unique plugins.

And lastly, Nessus will attempt to discover SSH servers regardless of which port they are on. Typically, SSH servers listen on port 22, but if a Nessus port scan or services probe is performed against non-standard ports, the SSH daemon will still be discovered. It has become common practice for administrators and/or hackers, to run an SSH daemon on a port other than 22 to "hide". Tenable has also encountered customers who have configured port forwarding firewalls such that connecting to a high port on the outside results in a network connection to port 22 on the inside to a certain server.

Using Credentialed Nessus Scans to Discover SSH Applications

If a credentialed patch audit of a host is also accomplished, Nessus will perform a patch audit of not only the SSH daemons, but any missing patches for SSH clients. There have been many client-side related vulnerabilities in SSH clients.

And lastly, if your credentialed scan occurs on Linux, the "Remote listeners enumeration" check, plugin #25221, will list all open ports and the name of the process which opened the network connection. This is another way to find SSH servers that may have been running on a a port other than 22, or were perhaps blocked by a firewall or ACL rule. 

Passive network monitoring with the PVS

The Passive Vulnerability Scanner can also observer Secure Shell connections. It accurately enumerates all SSH daemons and clients it observes in the network traffic. Here is an example listing of detected SSH applications and security issues from the "SSH (PVS)" plugin family as viewed under the Security Center:

Since the PVS sniffs network traffic it can see all ports. This makes it ideal to find SSH daemons running on ports other than 22. This also makes it ideal to identify security issues with SSH clients. In the above screen shot, there was a detect of a vulnerable "WinSCP" client. This detect was accomplished without any client side credentials of the Windows host running the WinSCP client.

Detecting Change

Once a baseline of known SSH servers and clients has been determined, it must be updated. There are two main ways to accomplish this - repeated Nessus scans and continuous PVS network monitoring.

For repeated Nessus network scans to look for new SSH servers, the Security Center can be used to schedule scans which discover new hosts, discover new SSH servers and also identify new SSH vulnerabilities. The Security Center can be set up to schedule these scans on a needed basis, and email and "new" results to asset system owners.

The PVS can also be used to find new SSH systems. Since the PVS is real-time, it can syslog any new type of SSH issue. The Security Center can be used to alert asset owners when new SSH servers are detected, or if new vulnerabilities have been discovered.

If more generic Nessus scans and PVS monitoring are ongoing, the Security Center can also manually be used to show "what is new". There is a filter in the Cumulative Vulnerability Database view which can specify a discovery filter. This parameter accepts a count of days such that all SSH vulnerabilities or audits discovered in the past 5 days could be displayed and analyzed.

For More Information

Part II of this post will consider auditing the configuration of SSH daemons and clients on UNIX systems. Part III will consider how netflow, firewall logs and other types of traffic can be used to audit SSH usage and abuse such as "leap frog" attacks.

Tenable has recently added several new APIs to the UNIX compliance checks. This blog entry discusses the new checks with several examples. These APIs are available to Direct Feed and Security Center users who have recently updated their plugins. Many of these checks will work for any UNIX operating system, however several of them are specific to RedHat Linux and its derivatives such as Fedora. 

New File Based Keywords and APIs

Checking File Attributes

This 'attr' keyword can now be used in conjunction with the FILE_CHECK and FILE_CHECK_NOT APIs to audit the file attributes associated with a file. Here is a short example:

<custom_item>
type : FILE_CHECK
file : "/bin/sh"
md5 : "d4228cff8f00b204e9812998ecf8427e"
description : "make sure the md5 of /bin/sh is correct"
# make sure the file is immutable (linux-only)
attr : 'i'
</item>

For more information about Linux file attributes, please refer to the man page for chattr.

Checking File Masks

The 'mask' keyword is opposite of the 'mode' keyword where one can specify a permission that should NOT be available for a particular user, group or other member.

Example:

mask : 022

This would specify any permission is acceptable for the file owner but no write permissions for group and other.

A mask value of 7 would mean that no permissions for that particular owner, group or other member are acceptable.

Globbing of File Names

File names can now also be globs. For example, file: "/var/log/*" can be used to specify any and all files in the the /var/log directory.

This feature is particularly useful when all the files with in a given directory need to audited for permissions or contents using FILE_CHECK, FILE_CONTENT_CHECK, FILE_CHECK_NOT or FILE_CONTENT_CHECK_NOT audit checks. 

Required Checks

This keyword is used to specify if the audited item is required to be present or not on the remote system. It gives auditors the flexibility to say "if this file is here, then it should be configured like this". It also lets auditors require that a certain file exist.

For example if 'required' is set to ‘NO’ and the check ‘type’ is ‘FILE_CHECK', then the check will pass if the file exists and permissions are as specified in the .audit file or if the file does not exist. On the other hand if 'required' was set to ‘YES’ the above check would fail.

CHKCONFIG

This audit check allows interaction with the 'chkconfig' utility on the remote RedHat system being audited.

This check consists of 5 keywords which are 'type', 'description', 'service', 'levels' and 'status'. All of these keywords must be specified to define a CHKCONFIG check.

This only works on Red Hat systems or a derivative of Red Hat system such as Fedora.

The following example verifies that the xinetd service is disabled in run levels 1 through 6.

<custom_item>
   type:CHKCONFIG
   description:"Make sure that xinetd is disabled"
   service:"xinetd"
   levels:"123456"
   status:OFF
</custom_item>

If xinetd were to be running in levels 1,2,3 and 6, then the example would look like:

<custom_item>
   type:CHKCONFIG
   description:"Make sure that xinetd is disabled"
   service:"xinetd"
   levels:"1236"
   status:OFF
</custom_item>

It should be pointed out that this audit does not check if the actual process is running or not, just if the process is configured to start at boot time or not.

GRAMMAR_CHECK

This audit check examines the contents of a file and matches a loosely defined grammar made up of one or more regular expression statements. If one line in the target file does not match any of the regular expressions, then the test will fail.

For example, in the bottom example .audit segment, if the file /etc/securetty contained the word "tenable" (a string that should not exist in this file) or was missing the word "vc/3", the audit would fail.

<custom_item>
type : GRAMMAR_CHECK
description : " Check /etc/securetty contents are OK."
file : "/etc/securetty"
regex : "console"
regex : "vc/1"
regex : "vc/2"
regex : "vc/3"
regex : "vc/4"
regex : "vc/5"
regex : "vc/6"
regex : "vc/7"
</custom_item>

This format would also be acceptable:

<custom_item>
type : GRAMMAR_CHECK
description : " Check /etc/securetty contents are OK."
file : "/etc/securetty"
regex : "console"
regex : "vc/[0-9]"
</custom_item>

In the latter case, if we knew the exact contents of a file, it would also be possible to perform an MD5 checksum. However, if we wanted to accept ranges of values, using multiple regular expressions offers greater flexibility.

RPM_CHECK

This audit check is used to check the version numbers of installed rpm packages on the remote system.

This check consists of 4 mandatory keywords which are 'type', 'description', 'rpm', 'operator' and the optional keyword 'required'.

The ‘rpm’ keyword is used to specify the package to look for and the ‘operator’ keyword is to specify the condition to pass or fail the check based on the version of the installed rpm package.

The 'operator' keyword accepts one of these four values:

• lt less than
• gte greater than or equal to
• gt grater than
• eq equal

This keyword only works on RedHat distributions.

Here are some examples, assuming iproute-2.4.7-10 is installed.

<custom_item>
   type : RPM_CHECK
   description : "RPM check for iproute-2.4.7-10 - should pass"
   rpm : "iproute-2.4.7-10"
   operator : "gte"
</custom_item>

<custom_item>
   type : RPM_CHECK
   description : "RPM check for iproute-2.4.7-10 should fail"
   rpm : "iproute-2.4.7-10"
   operator : "lt"
   required : YES
</custom_item>

<custom_item>
   type : RPM_CHECK
   description : "RPM check for iproute-2.4.7-10 should fail"
   rpm : "iproute-2.4.7-10"
   operator : "gt"
   required : NO
</custom_item>

<custom_item>
   type : RPM_CHECK
   description : "RPM check for iproute-2.4.7-10 should pass"
   rpm : "iproute-2.4.7-10"
   operator : "eq"
   required : NO
</custom_item>

<custom_item>
   type : RPM_CHECK
   description : "RPM check for iproute1"
   rpm : "webmin"
   operator : "eq"
   required : YES
</custom_item> 

Please note that although this API could be used to perform vulnerability audits for missing patches, there are already many different Nessus plugin families which perform security patch audits of many different UNIX systems.

XINETD_SVC

The “XINETD_SVC” audit check is used to audit the startup status of xinetd services. The check consists of 4 mandatory keywords which are 'type', 'description', 'service' and 'status'. The 'status' keyword

This check only works on RedHat Linux OSes and their derivatives.

Example Usage:

<custom_item>
type : XINETD_SVC
description : "Make sure that telnet is disabled"
service : "telnet"
status : OFF
</custom_item>

New "Builtin" UNIX Checks

These new APIs have been "built in" to the UNIX compliance checks grammar.

admin_accounts_in_ftpusers

This check audits if all administrator accounts (i.e users with a UID less than 500) are present in /etc/ftpusers.

Example usage:

<item>
name : "admin_accounts_in_ftpusers"
description : "This check makes sure every account whose UID is below 500 is present in /etc/ftpusers"
</item>

dot_in_root_path_variable

This check ensures that the current working directory (‘.’) is not included in the executable path of root user. Ensuring this prevents a malicious user from escalating privileges to superuser by forcing an administrator logged in as root from running a Trojan horse that may be installed in the current working directory.

Example usage:

<item>
name : "dot_in_root_path_variable"
description: "This check makes sure that root's $PATH variable does not contain any relative paths"
</item>

find_orphan_files

This check reports all files that are un-owned on the system.

By default the search is done recursively under the “/” directory which can make this check extremely slow to execute depending on the number of files present on the remote system. However, if needed the default base directory to search for can be changed by using the optional keyword "basedir".

It is also possible to skip certain files within a "basedir" from being searched using the optional keyword "ignore".

The timeout value (i.e the time after which Nessus will stop processing results for this check) is five hours and this value cannot be changed.

Two Examples:

<item>
name : "find_orphan_files"
description : "This check finds all the files which are 'orphaned'"
</item>

<item>
name : "find_orphan_files"
description : "This check finds all the files which are 'orphaned'"
basedir : "/tmp"
ignore : "/tmp/foo"
ignore : "/tmp/bar"
</item>

find_suid_sgid_files

This check reports all files with the set-user-ID (SUID) or set-group-ID (SGID) bit set. These files can be run by less privileged users but are executed with user's of higher privilege.

All files reported by this check should be carefully audited for any security issues especially shell scripts and executables that were not shipped with the system.

SUID and SGID files present the risk of escalating privileges of a normal user to the ones possessed by the owner or the group of the file.

If such files or scripts do need to exist then they should be specially examined to check if they allow creating file with elevated privileges.

Example Usage:

<item>
name : "find_suid_sgid_files"
description : "This check finds all the files which have their SUID or SGID bit set"
</item>

find_world_writeable_directories

This check reports all the directories that are world writeable and also have the sticky bit not set on the remote system.

Ensuring that the sticky bit is set for all world writeable directories ensures that only the owner of file with in a directory can delete the file which prevents any other user from accidentally or intentionally deleting the file.

Two Examples:

<item>
name : "find_world_writeable_directories"
description : "This check finds all the directories which are world writeable and whose sticky bit is not set"
</item>

<item>
name : "find_world_writeable_directories"
description : "This check finds all the directories which are world writeable and whose sticky bit is not set"
basedir : "/tmp"
ignore : "/tmp/foo"
ignore : "/tmp/bar"
</item>

find_world_writeable_files

This check reports all the files that are world writeable on the remote system.

Ideally there should be no world writeable files on the remote system (i.e. the result from this check should nothing). However in some cases depending on organizational needs, there may be a requirement for having world writeable files.

All items returned from this check must be carefully audited and files that don’t necessarily need world writeable attributes should be removed as follows:

chmod o-w world_writeable_file

Two Examples:

<item>
name : "find_world_writeable_files"
description : "This check finds all the files which are world writeable and whose sticky bit is not set"
</item>

<item>
name : "find_world_writeable_files"
description : "This check finds all the files which are world writeable and whose sticky bit is not set"
basedir : "/tmp"
ignore : "/tmp/foo"
ignore : "/tmp/bar"
</item>

writeable_dirs_in_root_path_variable

This check reports all the world and group writeable directories in the root users $PATH variable.

All directories returned by this check should be carefully examined and unnecessary world/group writeable permissions on directories should be removed as follows:

chmod go-w path/to/directory

Example usage:

<item>
name : "writeable_dirs_in_root_path_variable"
description : "This check makes sure that root's $PATH variable does not contain any writeable directory" </item>

Tenable was recently awarded certification to perform three different Center For Internet Security (CIS) Windows Domain Controller audits with the Nessus 3 scanner and Security Center. This blog entry discusses CIS, what the audit files look for, how customers should obtain the audit files and how this impacts PCI audits.

Center for Internet Security

The CIS is a non-profit organization that produces "best practice" guides for securing a wide variety of IT infrastructure such as operating systems, applications and network devices. The consortium takes input from operators, operating system vendors, governments and security experts to produce a set of "best practices" documents.

Product vendors such as Tenable that can perform a technical configuration audit can join the CIS organization and have their audit methodology and technology become certified.

For these new Windows audits, Tenable submitted a detailed methodology of how Nessus 3 and the Security Center performed and reported the specific audits required by the best practice guides.

CIS Windows Audit Polices

Three new audit files for Nessus 3 Direct Feed and Security Center users are now available. These audit Windows 2003 Domain Controllers that have been configured for Legacy, Enterprise and Specialized Security Profiles.

The Enterprise profile comprises all of the settings that the CIS best practices guide recommends. For example, it recommends that all communications for the Domain occur with "signed" packets. This feature was added in Windows 2003 and is not supported by older Windows domain controllers. The Legacy profile relaxes the security requirements that are not available to older release of Windows Servers. The Specialized Security profile is used for high-risk configurations that host sensitive data or require high availability. 

Some settings are the same across policies and some are different. For example, the minimum recommended password length for the Legacy and Enterprise policies is 8 characters, but it is extended to 12 for Specialized Security.

Example Video Demonstration

A demonstration video of both Nessus 3 and the Security Center performing and analyzing results from a Windows 2003 configuration audit is available here. The demo includes a short overview of CIS.

Obtaining these Checks

Any of the .audit files can be loaded into the Security Center for enterprise scanning or leveraged as part of a Nessus 3 Direct Feed scan. Polices are downloaded from the Tenable Support Portal. 

Security Center uses should download the polices they need and place them in the /opt/sc3/admin/nasl directory as owner 'tns'. They will then be available as a Compliance Audit policy for any Vulnerability
Scan Policy. Multiple .audit polices can be combined to be performed simultaneously during each scan.

Nessus 3 Direct Feed users should download the desired audit policies to their laptop or system where their Nessus client is operating. Nessus 3 clients can reference one or more audit policies for their credentialed scans.

Impact to PCI Assessments

PCI requirements include vulnerability auditing, firewall analysis, log analysis and configuration auditing among many other things. The PCI standard specifically points to CIS as a source for configuration auditing.

For More Information

The following list of links and blog entries are available for readers interested in Tenable solutions and compliance auditing.

• Center for Internet Security -- http://www.cisecurity.org
• Realtime compliance Paper -- Current and potential Tenable customers should request a copy of this paper which details how our unified approach to log analysis, configuration auditing and vulnerability management impacts PCI,  FISMA, SOX, NERC and compliance auditing and montioring.   
• Creating "Gold" Build Audit Policies -- This blog entry details how the Windows Nessus Policy Creator can be used to extract a Nessus configuration auditing policy from a properly configured Windows server.
• NIST Auditing -- Tenable products can also perform NIST configuration audits from the Secure Content Automation Program. This blog entry provides details about the polices available to perform these configuration audits.  The NIST SCAP web site is located at http://nvd.nist.gov/scap/scap.cfm.
• Security and IT Controls -- Gene Kim was interviewed by Richard Steinian about the positive impact that IT Controls (such as configuration management) can have on security and availability of IT resources.

Sensitive government and military organizations classify their documents with familiar terms like "TOP SECRET" and also less well known terms like "NOFORN" (which means the data can't be shared with any foreign nationals).

These terms and phrases are usually placed in the headers and footers of every page in electronic documents. Most organizations that deal with extremely sensitive data have mandatory requirements for documents to be labeled according to their classification levels.

Nessus Direct Feed users can scan network servers for these types of documents with a new audit policy available on the Tenable Support Portal. The "Classified Documents" .audit file searches Word and Adobe files for many common keywords used in the US government and NATO to indicate the classification level of the document.

Modifying the policy to audit for specific code words is also very simple. Below is an example simple search for the word "TOP SECRET":

<item>
        type: FILE_CONTENT_CHECK
        description: "Server is hosting TOP SECRET level documents"
        file_extension: "pdf" | "doc"
        regex: "TOP SECRET"
        expect: "TOP SECRET"
    max_size : "3k"
</item>

Often, classified programs receive their own codeword. Documents from a program named "TENABLE" would be labeled "TOP SECRET TENABLE". If we wanted to modify the default policy "TOP SECRET" policy to look for two or more specific program code we could run an audit with this type of logic:

<item>
        type: FILE_CONTENT_CHECK
        description: "Server is hosting TS codeword level documents"
        file_extension: "pdf" | "doc"
        regex: "TOP SECRET (NESSUS|TENABLE|UFO|ELVIS)"
        expect: "TOP SECRET"
    max_size : "3k"
</item>

The new regular expression would look for documents from the various programs named NESSUS, TENABLE, UFO and ELVIS. 

To learn more about how countries around the world classify their sensitive data, please read this Wikipedia entry. To learn more about the Nessus Direct Feed, please visit our web site or consider watching one of the Nessus demonstration videos.

We all receive and are annoyed by the amount of "SPAM" email in our in-box. One way to fight SPAM is to monitor large networks for evidence of compromised hosts that are being used to email out unwanted content. This blog entry shows how passive network analysis and log analysis can be used to look for specific types of events that can indicate SPAM originating from inside your network.

Watch for Changes in the number of Email "Clients"

The Passive Vulnerability Scanner (PVS) detects which hosts connect on port 25 (SMTP) and which hosts have email servers on port 25. Using the Security Center and the PVS, any organization can quickly obtain a list of all systems which connect to port 25 on the Internet and use email clients. By tracking the total number of email clients in use on a network, an organization can observe when there are large changes in this population.

For example, in the screen shot below, we've asked the Security Center to graph the number of unique hosts that communicate on port 25 (SMTP) over the past 90 days.

This graph shows that there have been many more SMTP clients in operation in the last month than has previously been in effect. This could be a zombie botnet making more SMTP connections than before. This could also mean that more users are sending email from more locations. This may also correspond to changes in DHCP lease policies where the same user population is making use of more IP addresses than before. The point is to look for a change, and then perform the investigation to see what has caused it.

Asset Based Behavior Analysis

Another method to search for internal SPAM sources is to look for systems sending email that shouldn't be sending email. For example, your web server most likely isn't your email system and it probably doesn't even have an email client installed on it.

Combining the Security Center's ability to classify network nodes into one or more "asset" groups and the PVS's ability to report which hosts have email clients on them can provide a list of which assets have email clients. Consider this example chart produced by the Security Center below:

In this list, it is understandable that there are no email clients on the "DNS Servers" or that there is one email client in the "POP Servers" list of assets. However, many of the other asset groups such as "FTP Servers", "SSH Servers" and "HTTP Servers" have multiple detected email clients.  Being able to drill into these asset lists and see which specific hosts are sending email can identify if a server has been compromised and is part of a botnet. It can also be used to see if a "server" resource is being used as a desktop system which may also violate corporate policy.

Log Correlation Engine Analysis

If the Log Correlation Engine is in use and receiving netflow, network sessions or firewall logs, performing some analysis on port 25 traffic can also be very enlightening. For example, in a corporate environment where all outbound email is authenticated and goes through a well known email server, listing outbound "Firewall Deny" events for port 25 can identify host trying to connect directly to the Internet. These may just be normal users trying to send mail to a non-corporate mail account, but this can also be an indicator of SPAM.

Below is an example screen shot of all port 25 traffic over the past 7 days at a large enterprise network:

Notice the dramatic increase in email connections observed towards the right side of the graph.

The LCE also has the ability to use Black Lists of IP addresses that are well known SPAM providers. The current blacklist.tasl script uses a publicly available list of well known SPAMing sites for correlated activity.

Detecting "The Bat!"

The PVS also has rules to detect the specific email clients in use by each end node. It performs this analysis to discover if there are any vulnerabilities associated with the email client in use. One of the email clients we look for is a client known as "The Bat!" which can be used for mass mailing.

Below is a screen shot of a listing of all client side email vulnerabilities discovered on a medium sized network, including two detects of "The Bat!" email client:

To analyze this further, choosing this vulnerability and then performing an asset summary could tell us which organizations or resources (such as one of our HTTP servers as compared to an office laptop) were using this potentially unwanted email client.

SOCKS4 and SOCKS5 Proxies

There have been several cases of malware which seeks out local SOCKS4 or SOCKS5 proxies in order to connect to the network. Both Nessus and the Passive Vulnerability Scanner can be used to detect these types of proxies. The PVS passively identifies SOCKS4 and SOCKS5 proxies and can look inside these protocols to see if there are any botnet command and control messages being passed.

For More Information

If you would like to learn more about the capabilities of the Passive Vulnerability Scanner, Log Correlation Engine and Security Center, consider watching one of the many demonstration videos available at the Tenable Network Security web site.

Over the past few years, there have been several vulnerabilities disclosed about the Snort network intrusion detection sensor. I recently had a Tenable customer inquire for a strategy of "scanning" to find these Snort systems. This blog discusses some basic and more advanced ideas and issues on how to approach this with Nessus and the Passive Vulnerability Scanner.

Network Scanning of Passive Listening Devices

Solutions like Snort sniff packets on a network interface for evidence of network abuse and log this data to SYSLOG, a local file or some sort of log agent.

Typically, there are no daemons or open ports that can be probed or fingerprinted which indicate that Snort is indeed installed. In many cases, best practice for running a network IDS also recommends that the monitoring interface not even have an IP address.

There have been tools and research in the past used to identify devices that are sniffing, but these don't specifically identify Snort. A good example of this is the AntiSniff tool written and released by the L0pht.

Using Credentials to Find Managed Snort Packages

If Snort is included or supported with your OS distribution, Nessus may likely have some client side checks to look for these security issues. At nessus.org, using the plugin search interface, there were eight different UNIX patch audits concerning Snort as shown below:

There are a few issues with looking for Snort this way though:

• Many Snort users obtain distributions directly from snort.org and not the operating system provider
• Some Snort users hand compile their distributions
• Relying on the patch from an operating system vendor might take longer than getting it directly from Snort.org.

Scanning for Snort Files

Nessus Direct Feed customers can look for evidence of Snort installations on UNIX systems with the following .audit file:

<check_type: "Unix">
<custom_item>
type: PROCESS_CHECK
  description: "Check snort process status" 
  name: "snort"
  status: OFF
</custom_item>
</check_type>

This audit simply checks if the 'snort' process is running and reports a failure if it is detected. This scan requires SSH credentials to perform the audit.

Passive Network Monitoring

The Passive Vulnerability Scanner can detect systems that send SYSLOG messages which contain "snort" logs. If your organization uses SYSLOG to send logs from your Snort sensors to a central location, PVS rule #3986 will identify those systems. The rule will also match a secondary log server which is forwarding log which contain Snort events as well.

In order to see these logs, the PVS would need to observe the SYSLOG traffic. If your PVS was on the perimeter of your network and your Snort sensors were further inside and logging to an internal host, it would not be able to observe the traffic.

For More Information

If running Snort alongside Tenable products is interesting to you, please consider these other blog entries:

• Vulnerability Based Snort IDS Management - Use the vulnerabilities found by Nessus and the PVS to manage the active rules on your Snort sensors.
• Automated audit policy creation for UNIX Nessus compliance checks - Discusses how to use the current settings in your configuration files to build a baseline template. Uses the snort.conf file as an example.
• Good and Bad Uses of Vulnerability Data for IDS Correlation - Discusses some of the nuances of correlating IDS events with vulnerabilities.

Tenable's research group recently released a WMI based plugin for Nessus 3 that can determine the active wireless SSID for remote Windows devices. This allows an organization to obtain a list of active wireless domains for all Windows devices on their network. This blog entry discusses the security and auditing ramifications of this plugin.

Example Report

Below is an example report generated by this Nessus plugin. The SSID of the laptop scanned was "mytestssid".

Synopsis :

It is possible to obtain the active associated wireless SSID of the remote
computer.

Description :

This script uses WMI to obtain the wireless network card and associated SSID
of the remote computer. The remote system must have an active wireless
connection for this detection to occur.

Solution :

Make sure any SSIDs that are discovered comply with corporate policy.

Risk factor :

None

Plugin output :

Network Card Type : Intel(R) PRO/Wireless 3945ABG Network Connection
Network SSID: mytestssid

Why is this useful?

There are two questions answered with this plugin:

• Do we have any "wired" devices that have also associated with a wireless domain?
• Which wireless domains are active on our network?

If wireless networks are authorized in your network, then they can be audited with this plugin. Collecting the active wireless domains on each host is very easy when scanning with a credentialed Nessus scan.

The most serious issue is to find a host on your network that has both associated with an external wireless access point and also has an internal "wired" connection. If your offices are near public wireless access points, access points from nearby businesses or even available access points inside your organization, you may have laptops that have a wired link and also be associated with an unauthorized access point. This could bypass your firewall or access control, provide direct access to a system that might not be patched or even expose files and network shares to attackers outside of your network.

If a Windows system is found with an active wireless device, it should also be questioned if this is authorized. Organizations that have an issue with management of mobile devices and networks would find it interesting to get an accurate list of all "SSIDs" in use. This plugin may find new or unauthorized SSIDs in use that your IT organization was unaware of.

Analyzing the Data with the Security Center

Once scans have been completed, the Security Center can easily be used to analyze the data. There are two basic techniques that can be applied - ad hoc analysis and creation of dynamic asset lists based on the detected SSIDs.

For ad hoc analysis, the Security Center can be used to navigate and browse the collected information. The "text" field can be used to highlight any matching systems with known SSIDs. For example, to obtain a list of all systems with an SSID that matched "SSIDTEXT", this would be typed into the text search box and plugin ID #25197 would be searched for as shown below:

All matching hosts can then be sorted by IP address, their MAC address, DNS name or Windows name and then have the entire set of matched data exported in a spread sheet or PDF report.

The Security Center can also use the content from Nessus and Passive Vulnerability Scanner discoveries and audits to create lists of computers based on certain parameters such as open ports, the output of a check and so on. These are known as "dynamic asset lists".

For analysis and reporting of discovered network SSIDs, there are two approaches that can be used:

• Create a dynamic asset list for each "known" SSID
• Create a dynamic asset list of "unknown" SSIDs

If you had an SSID of "CORPORATE", you could create a dynamic asset list that looked for the presence of plugin ID #25197 and the content "CORPORATE". If your set of corporate approved SSIDs all had the same sort of root text such as "CORP1", "CORP2", "CORP3" and so on, you may want to consider only testing for the pattern "CORP" or a regular expression of "CORP[0-9]{1,3}".

Once the scans have been completed and asset lists have been created, there are several types of analytics that can be performed such as asking:

• Are any IP addresses being used on SSIDs which are incorrect? This may provide insight to issues with poorly configured VLANS or DHCP servers. If incorrect IP addresses are being given out, this may also identify an access control issue.
• Are there any vulnerabilities or open services (such as FTP or P2P) in use on wireless nodes with WEP disabled? For public access, not using the "Wired Equivalence Protocol" is convenient for your guests, but if permanent services reside on those networks, they may be attacked.
• For critical asset groups such as your financial, human resources, demilitarized zones and so on, do any of their systems make use of wireless nodes? If so, are they authorized and properly secured.

For More Information

This Nessus plugin is currently available to Direct Feed and Security Center customers. Organizations interested in performing active and passive wireless assessments with Tenable technology should consider the following links and resources:

• Using Nessus to Detect Wireless Access Points - This paper details how Nessus can be used to scan for a variety of web, ftp and SNMP management interfaces for a variety of wireless access point devices.
• Passive Vulnerability Scanner - the PVS can also be used to sniff management active to/from a wireless access point. In addition, if the access point also has multiple users behind it with NATed IP addresses, the PVS will identify this device.
• Access Point Detection - Nessus plugin 11026.
• Asking Vista for its list of Interfaces - This blog entry details plugin #24904 which uses the LLTD protocol to ask Vista OSes for their list of network interfaces and wireless SSIDs.
• Network Interface Enumeration - Through WMI, Nessus can enumerate the list of active network devices, their assigned IP addresses and available routes on Windows computers.

Tenable's Chief Security Officer, Marcus Ranum, has launched a  security podcast named the "Rear Guard". Listeners can subscribe to the podcast feed here.

Marcus has previous offered a Tenable webinar on the "Six Dumbest Ideas in Computer Security" which is available here.

Tenable's research group has released a set of seven audit policies for the Vista operating system. These polices are based directly off of Microsoft's Windows Vista Security Guide. This blog entry discusses how to obtain these audit policies and how to perform an audit of a Vista  computer system.

Obtaining These Plugins

Security Center or Direct Feed users should log into the Tenable Support Center and then click on "Downloads", then "Download Configuration Audit Policies" and then select any of the following "MS Vista" policies:

• Windows Vista Default Security
• Windows Vista EC Desktop
• Windows Vista EC Domain
• Windows Vista EC Laptop
• Windows Vista SSLF Desktop
• Windows Vista SSLF Domain
• Windows Vista SSLF Laptop

The terms EC and SSLF refer to "Enterprise Client" and "Specialized Security Limited Functionality". EC computers are expected to participate in a domain and SSLF computers are for very secure "stand-alone" functions.

Tenable customers who do not have access to the Support Center should email support@tenablesecurity.com to obtain a login.

Using These Vista Audit Files

Nessus 3 users should save these audit policies to their laptop or computer from which they are running their Nessus client. Once saved, the audit policies can be used as part of a vulnerability or scan policy.

Security Center users should save these audit polices to the /opt/sc3/admin/nasl directory as user/group owners of 'tns'. Once saved, these audit policies will be available to be included within any existing or new Vulnerability Policy.

Scanning Vista Systems

To perform credentialed scans of Vista servers, please keep the following items in mind:

• Port 445 is blocked by default on many versions of Vista. Modifying this rule in the local firewall policy is required.
• The Remote Registry Service must be enabled.
• The username and password used should be for the "Builtin Administrator" and not a new user that has been added to the Administrator's group.

Below are images of which firewall rules and services are required to be enabled to perform remote credentialed scans of a Vista system:

Enabling Remote Registry Access	Enabling File Sharing

For More Information

Tenable has produced several different webinars and blog entires regarding performing audits of Windows operating systems:

• Creating "Gold Build" Audit Policies
• Windows Nessus Compliance Video
• Windows Nessus Compliance Webinar
• Asking Vista for its list of Network Interfaces

Readers interested in obtained a Direct Feed subscription or try the Security Center should visit Tenable's web site.