If you are faced with the task of finding network probes and attacks in an endless stream of IDS, firewall, netflow and application events, then using one or more honeypots to help find low-and-slow probes, stealthy attacks and internal abusers may be for you. This blog entry will discuss several different types of honeypot types, monitoring techniques, and how this can be implemented with the Tenable Security Center and Log Correlation Engine.

Honeypot "Simulators"

There are several specific applications that can be run on one or more systems to simulate multiple operating systems, servers and even networks. Examples of these include:

• honeyd
• nepenthese
• iDefense Multipot
• La Brea (as in the tarpit)

Each of these applications can simulate various technologies on your local network. They can be placed within DMZs, can be configured to make use of unused addresses space on your network or can be deployed as targets for internal intruders to stumble over.

The Log Correlation Engine can parse logs from each of these applications, plus a few commercial ones not listed here. The advantage of interacting with the raw logs from these devices is that each often has very detailed analysis of what occurs. For example, the Mulitpot from iDefense will actually interact with some worms and probes and report when new payloads for worms have been downloaded.

Live Sacrificial Honeypots

If simulating a target with an application isn't real enough for you, consider running copies of your operational systems, but designate them as your "honeypot". These could be real servers or additional virtual servers such as another running VMWare image.

If you specifically deploy these secondary systems, then monitoring them with the Security Center and Log Correlation Engine can be easily accomplished. The actual servers can be added to an Asset List named "Honeypot". Using that as a filter, all IDS events or logs can easily be analyzed. Discovering who is probing your honeypots from the outside or inside can be very enlightening.

Within the Log Correlation Engine, you can also configure certain types of alerts with the TASL scripting language to recognize when:

• internal systems connect to the Honeypot asset
• the honeypot systems actively reach out to the network, perhaps indicating a compromise or infection
• external systems scan both the Honeypot and then continue to scan other systems

When working with live honeypots, you should be conscious of how they "look" compared to the rest of your network. The Security Center can be used to measure the typical types of vulnerabilities and applications on your network. With this knowledge, you can keep your honeypot configured the same as the local network to "blend in" or can make it a more attractive target for an attacker, depending on your goals.

It should be noted that if you are running systems specifically to be broken into or be compromised, this may indeed be a liability for your organization. For example, consider what happens if an external attacker compromises a honeypot and then does a lot of damage to a third party. If this is your type of environment, you should consider running a simulated honeypot like we've discussed about above or perhaps identifying live systems that are operational, but seldom used such as disaster recovery or fail-over servers.

Honeypot "Services" and Firewalls

Running a separate application to simulate a honeypot or running stand-alone systems may not be necessary to capture evidence of intruders. If your network already has active applications, consider presenting additional services to either the outside world or local networks.

For example, consider a Windows IIS web server that does not usually run SSH on port 22. Using a third party application that opens a port on 22 and just listens for connections is interesting. Tools like Multipot can be configured to listen on various ports like this. If you are confident in the security of the extra application, you could simply run it and then use the Log Correlation Engine to monitor the logs and alert whenever there is a connection.

This concept can be extended to firewalls as well. Consider a network that has a firewall policy to log a "deny" event for any network request that isn't already allowed to a server. Looking in these "deny" logs can find all sorts of external and internal probes for ports which should not be probed. The Log Correlation Engine can be used to alert for "deny" firewall events from places like a DMZ or to filter for internal probes to a DMZ. This can help identify abuse, low and slow probes or determined attackers.

Lastly, if you have a firewall that supports port forwarding, you can present many different external IP addresses and services to the outside world. Consider a network that may have multiple real IP addresses on the "outside", but is using port forwarding to serve a single web server. Instead of running multiple web servers, using multiple port forward rules to make it seem like you have more web servers could help act like a honeypot. The logs from the firewall, NIDS or monitoring log for these additional IP addresses can be processed by the Log Correlation Engine for analysis as well.

Honeypot Users

If your application can log events about specific users, then you may want to consider adding specific accounts that should "never" be used. These accounts shouldn't be any different from other accounts already on your application. For example, don't add an account with a bad password or administrator privileges to "hope" that a remote intruder will exploit this.

Once this has been configured, consider how you would like to alert for the user activity. The Log Correlation Engine has many TASL scripts which look at user activity. If your application log is proprietary, you'll need to write custom PRM parsing rules and then modify an existing TASL script to alert when the user of interest is used.

The Honeypot that wasn't There

Another concept that is very easy to implement is to look for chunks of address space on your network that are not in use. With the Security Center, scanning with multiple Nessus scanners, or monitoring with the Passive Vulnerability Scanner, this is very easy to accomplish. These networks and IP addresses can be placed into a "dead space" type of Asset List. Once this is accomplished, you can either perform manual queries into the logs of your firewalls, netflow or NIDS and look for internal or external systems attempting to access these ranges. If you were so inclined, you can modify existing TASL scripts to alert when connections to these networks or asset list occurs.

Support In Tenable Products

Tenable customers interested in implementing these concepts should consider the following:

• The Security Center can be used to create Asset Lists to represent one or more honeypots
• There are existing PRM rules for honeyd, nepenthese, La Brae and Mulitpot
• The honeypot.tasl script can look for combinations of specific destination IP address and ports
• Asset based alerting scripts such as asset_webserver.tasl can be modified for your "honeypot" assets
• TASL scripts that parse user activity logs such as new_user.tasl can be modified to look for honeypot user accounts

Nessus 3 was recently tested by Network Computing Magazine. Their analysts used Nessus 3 subscribed to a Direct Feed to audit the configuration of a remote Windows system. We felt the article was very accurate and made several references to the documentation and tools which can help users quickly create custom policies.

One of the tools mentioned in the article was the Windows Nessus Policy Creator (WNPC). The WNPC allows a user to create an audit file for Nessus 3 from a "gold" system and then audit other systems with this audit file. We've written about this tool previously and readers can also see a video of the tool here if they like.

The analysts doing the testing for the article also wrote about some of the issues they ran into while configuring a remote Windows system for analysis. If you have a non-domain Windows system and want to enable this sort of auditing, follow these steps:

1. In the Microsoft Management Console, open the Group Policy and select Security Settings.
2. Open Network access: Sharing and security model for local accounts element and the select Properties.
3. In this dialog, select Classic - local users authenticate as themselves and click OK to save this.

The above content was extracted from the paper, "Nessus Credentials Checks for UNIX and Windows".

You can read the full article here and in the September 21, 2006 printed issue of Network Computing Magazine.

If you've invested a lot of money into a commercial patch management system or perhaps you've grown your own, how do you know how effective it is? With Nessus's agent-less host based patch audits, it can effectively be used to understand how effective your patching solution has been. It can also be used to identify hosts which are not being patched or are under management. Lastly, we will discuss how to determine how effective your patch management system has been. This post considers both users who just use Nessus as well as Security Center customers.

Why do patches fail?

There are many reasons that patches fail. Here are just a few and some corresponding examples:

• Too Secure - a UNIX or Windows server can be configured such that the remote user account or local user agent that is pushing the patch doesn't have enough rights.
• Bad Network Settings - a server with out of date network settings like a stale DNS server or stale local router may look like it is alive, but a patch could fail to install because of poor network access. Firewall rule changes can effect some systems as well.
• Patch Dependencies - a patch management system which did not take into account the required dependencies of patch might not realize that the patch didn't get installed.
• Lack of disk space - if patches are all sent to a certain partition or drive and that drive is out of space, the patch might not run. Self extracting patches might run into this issue as well.
• No Bandwidth - if your network can't handle pushing 1000s of 10 megabyte files to your systems at the same time, this may impact a patch being delivered and ultimately being installed.

Testing for Network Vulnerabilities

A basic Nessus scan without credentials will discover vulnerabilities in systems that run a service. Many clients, such as iTunes, run services which can be identified the same way an Apache or Exchange server can be found.

At the network layer, Nessus will identify the underlying application and their vulnerabilities, but not necessarily an operating system level patch. For example, a vulnerable version of Apache may be found, but Nessus may not know that the underlying operating system is Windows, RedHat, SuSE or OS X. Nessus will recommend that the vulnerable service be upgraded, but won't specify the exact patch for the underlying operating system.

Testing for Bad Credentials

Nessus scans can be configured to use a variety of UNIX and Windows credentials. Nessus plugin #21745 will alert when a system was attempted to be access with a set of credentials and when they failed. This can help identify systems with the wrong security settings.

If users have the Security Center deployed, each separate asset group can be configured with their own set of credentials. This can help automate patch testing, but also find when a host credentials within a given asset list were changed or are no longer valid.

Testing for Unmanaged Systems

Nessus Direct Feed users can perform custom checks for a wide variety of files, file content and registry values. These values can be used to identify a corporate managed asset, as well as evidence that a system is running a certain type of patch agent. For example, the following Nessus 3 .audit content will look for the presence of a certain version of Adobe:

<custom_item>
type: REG_CHECK
description: "Check the key HKLM\SOFTWARE\Adobe\Acrobat Reader\7.0\AdobeViewer"
value_type: POLICY_TEXT
value_data: "HKLM\SOFTWARE\Adobe\Acrobat Reader\7.0\AdobeViewer"
reg_option: MUST_EXIST
key_item: "EULA"
</item>

If your managed systems ran an agent, had certain registry settings or files that indicated it was managed, you could use something similar to scan those systems to ensure they had the proper settings. These checks do require credentials and work for UNIX and Windows systems.

Testing for Missing Patches

All Nessus users can audit Windows and UNIX systems for missing patches. To scan for missing patches, your Nessus scanner needs to be configured with the credentials of the networks you are auditing. If using Nessus to perform these sorts of scans is a new concept to you, please read the paper "Nessus Credential Checks for UNIX and Windows". This explains how to configure Nessus and the target hosts to perform these audits.

Unlike a patch management system, Nessus is simply logging into the audited device and pulling a list of patches. Although this process does require network access and proper security settings, it is ultimately less complex than installing a patch. Since there are less things that can go wrong, perform this sort of audit with Nessus will likely help identify systems that are missing patches.

How effective is your patch management system?

Lastly, from a security and network management system, there are several questions worth asking to help judge the effectives of the patch management system.

• Are all security patches being applied? Your organization may or may not require 100% coverage of all security patches. If they do, using Nessus and the Security Center can help prove that the patch system is or isn't working. If less than 100% coverage is acceptable, doing an external audit like this can help identify security risks that have not been accounted for by the patch process.
• How quickly are patches applied? Your organization may require all patches to be installed in a given amount of time. Nessus and the Security Center can help test for discrepancies with this policy and report the overall progress.
• Are new hosts under the patch management program? As new servers or even desktops are added to the infrastructure, being able to detect that they are falling further and further behind in their patch cycle is something accomplished with the Security Center.
• What about embedded devices? Both Nessus and the Security Center can help find patch issues in embedded devices like routers, switches and printers. Tenable has seen many organizations deploy a very comprehensive desktop patching program only to ignore vital devices like their firewalls and printers.

Regardless of what you are tracking, the Security Center can be used to show just about any type of vulnerability or configuration issue mapped over time. The above image shows a trend for the past 90 days (today being on the left) where there has been a significant reduction in measured vulnerabilities. This graph can easily be produced with the click of the button for specific ports, Nessus families or various asset groups. The Security Center also has a 3D tool (click here for a video) which can be used to show where various issues are at in the network.

Mapping Patching into Network Management

Tenable Network Security is a strong believer in network controls. Besides Nessus and the Security Center, we also offer other products to perform log analysis and passive network monitoring. All of our products can be used to identify managed and unmanaged devices, unauthorized change and conformity to corporate configuration guidelines.  All of this has direct impact on the effectives of any patch management infrastructure. For more information about network controls, consider downloading the "Network Security Implications of 'Visible Ops'" paper or request a copy of the "Realtime Compliance Monitoring" paper by emailing sales@tenablesecurity.com.

Yesterday, Tenable's research group released Nessus plugin #22449 which can detect Windows systems that are missing a set of patches covered in Microsoft bulletin MS06-055. This patch fixes security issues related to Outlook and Internet Explorer's use of the Vector Markup Language APIs. Systems with this vulnerability are exposed to exploitation from visiting hostile web pages or receiving email designed to exploit the flaws in VML. The plugin is a patch audit and requires domain credentials to analyze the remote system. This plugin is available to all Direct Feed subscribers and Security Center users.

A common question our support group receives from Direct Feed customers is how to limit Nessus probes to specific ports. This post will discuss the reasons Nessus sends packets to various ports and how scans can be configured to limit access to specific ports or ranges of ports.

Limiting The Port Scan

The first item someone should decide in an effort to minimize the ports touched by a Nessus scan is to enter in specific ports for scanning. Most Nessus clients have a default scan policy setting of "default". This causes the Nessus port scanner used to scan all TCP ports in the /etc/services file. Users can enter in more specific ranges and ports such as "21-80", "21,22,25,80" or "21-143,1000-2000,60000-60005". This will cause the port scanner to target just those ports during the port scan.

During the port scan, the Nessus TCP scanner will also use the ports involved to determine the round trip time for packets to the target host. If a small number of ports is used, the scanner may choose other ports to determine the RTT.

Choosing Host Enumeration

If an ICMP probe (a ping) is enabled to discover active hosts, then no specific ports are probed. However, if a "TCP Ping" is used to discover a host, then ports will be probed. Both options can be enabled and are not exclusive. It should also be noted that there is another host enumeration for "ARP pinging" which will find hosts on the local LAN.

Considering Un-scanned Ports Closed

After a host is discovered and the desired ports are scanned, Nessus will attempt to run the enabled plugins against the target. If a plugin runs which attempts to connect to a specific port and the "Consider Unscanned Ports Closed" setting is enabled, Nessus won't even run the plugin. However, if this setting isn't enabled, Nessus may start to probe ports that were not specified by the port scan.

Understanding UDP Port Probes

For port scanning, the UDP protocol is very unreliable. Nessus does not have a UDP port scan option and instead runs UDP plugins directly if they are enabled in a scan.

UDP is unreliable because if a port is open, the host is NOT supposed to send a response and if a port is closed, the host is supposed to return an "ICMP Port Unreachable" packet. Since UDP packets can be dropped or a host or network firewall can stop a packet, a scanner that does not get a response for a UDP probe can be fooled into thinking the port is open. Even for closed ports, if a network has implemented outbound ICMP filtering as a security measure, the scanner won't see the "ICMP Port Unreachable" messages.

Because of this, Nessus is designed to work directly with the applications that occur over UDP. Often these applications involve single packet queries and this is more efficient than scanning and then attempting to speak to the application. For example, rather than attempting scan for systems with port 111 open on UDP which is probably the RPC portmapper service, it is more efficient to simply send in the equivalent of the "rpcinfo -p" command and wait for a valid portmapper response.

Using Passive Technology

Tenable customers who have deployed a Passive Vulnerability Scanner (PVS) enjoy continuous monitoring of their network as well as some advantages over active scans. Since the PVS operates 24x7, it can see activity on the network that might not be present during an active scan. The PVS will also find what ports a host "browses" on. For example, if a web server is open on port 80 and 443, it might also browse the network on port 53 for DNS lookups and port 80 to reach out to the web and grab updates.

Tenable has received many requests to extend the API for the agent-less Nessus compliance checks. In response to our customers, we've added several new functions to the compliance plugins which are immediately available to all Security Center and Direct Feed users. The documentation for these new APIs has been updated here, and this post describes the new APIs available for UNIX and Windows configuration auditing.

For the Windows operating system, Nessus can now perform the following checks:

• FILE_CHECK - tests for the presence of a specific file
• REG_CHECK - tests for the presence of a specific registry entry
• FILE_CONTENT_CHECK - test for the presence of specific content in a given text file
• FILE_CONTENT_CHECK_NOT - test for the lack of presence of specific content in a given text file

For example, to test for the presence of a given file on Windows systems, consider the following:

<custom_item>
type       : FILE_CHECK
description: "Check the file win.ini exist"
value_type : POLICY_TEXT
value_data : "%SystemRoot%\win.ini"
file_option: MUST_EXIST
</item>

This text would cause Nessus 3 to search for the file win.ini under the %SystemRoot% directory and report a PASS (informational severity) if the file existed or a FAIL (severity reported as a hole) if it didn't exist.

In addition to these checks for Windows systems, the API for UNIX operating systems was extended to perform checks against the MD5 values of specific files. Here is an example setting:

<custom_item>
type       : FILE_CHECK
description: "/etc/passwd has the proper md5"
required   : YES
file       : "/etc/passwd"
md5        : "c1b38ca2f4656d91041b24b3fb762b7a"
</custom_item>

This tests the file /etc/passwd for a specific MD5 value and alerts if it changes.

Tenable will shortly begin to take advantage of these APIs in the next few updates and additions to the current set of compliance audit files available to customers. There were no changes to the existing APIs and none of the current audit files need to be modified or updated.

Tenable has released an update to the blacklist.pl script and corresponding lce_tasl.prm library and TASL script. The new script uses input from the Internet Storm Center, Spamhaus and BleedingSnort to create a list of IP addresses and networks which may be of interest to your network. Any time the Log Correlation Engine detects one of these remote IP addresses or networks interacting with your network systems, an alert is generated. This can help find when your computers are interacting with SPAM or Botnet networks, or when you you have been scanned by a known hostile network. 

Previously, Tenable had released a PERL script which would periodically receive updates from the SANS Internet Storm Center and then use the isc-blacklist.tasl script along with netflow or sniffed TCP sessions (from the TNM or TFM agents). As of today though, the isc-blacklist.tasl has been replaced with the more generic blacklist.tasl and the original blacklist.pl script has been upgraded.

The new process allows for the blacklist.pl script to periodically go to three sources to obtain a list of IP addresses and networks that have been determined to be "hostile" or "malicious".

• The Internet Storm Center tracks IP addresses and networks which perform broad Internet scanning.
• Spamhaus releases their top 25 list of SPAM generators for free.
• The Bleeding Snort project also reports IP addresses and networks involved with large-scale Botnet command and control. This sub-project there is known as the ShadowServer Foundation.

This architecture lends itself to being more easily extended. As new lists of "bad" networks are published, they can be added to the blacklist.pl script without modification to the blacklist.tasl script.

The blacklist.pl script can be configured to connect to each of these sources and build a template list of "known bad" IP addresses and networks. The blacklist.tasl script uses this list of "known bad" sources and destinations and subscribes to your network and netflow sessions. When an IP address hits your network, a single alert is generated to minimize alerting for every scan, connection or email sent. Below are some example screen shots of this technology running in a variety of environments.

This network had 2462 "Blacklist_Conenction" events in the last 24 hours.

A sanitized list of some connection events going to many ports, including 6667, commonly used for IRC.

When the TASL script fires, it uses the data about the host obtained by the blacklist.pl script and a DNS lookup to generate the following type of log message:

Blacklist_Connection src - X.X.X.X dst - 1.2.3.4 , following is known about 1.2.3.4 , source of information - http://www.shadowserver.org , message - BleedingSnort-Bot , dns_lookup - example.network.dns.address.com

These messages can be used by other TASL scripts as well as LCE's statatisitcal engine.

Installing The blacklist.pl Script

Download the latest blacklist.tasl, blacklist.pl script from the Tenable Support site. Also make sure to update your LCE (Thunder) plugins to get the latest version of the lce_tasl.prm file.

Once this is accomplished, uncompress and untar the blacklist file distribution someplace on your LCE. There will be a file named blacklist.cfg inside the distribution and this needs to be edited.

The first part of the blacklist.cfg file specifics URLs to public sources of IP addresses or networks of interest. There are settings for ISC, BleedingSnort and Spamhaus. The format of these settings is as follows:

IP Address,Source of information,Message or info about the IP address,Country/Location,Email address to contact to report abuse,dns

If you have access to other sources of IP addresses, you can add it like this:

1.2.3.4,tenable.com,RIAA Abuser List,US,test@test.com,S2-ESR-69-61-191-47.someplace.com

This allows you to extend the actual "Black Lists" file with IP's other than the ones listed on the above three sources.   

The second parameter is the THUNDER_SERVER= keyword. The IP address of the Thunder Server (Log Correlation Engine) should be added. If the blacklist.pl script is installed on the same server, then 127.0.0.1 should be used. If this is running on a different server, then the remote IP address of the LCE should be used.

Lastly, the script will lie dormant for a period of time and then reach out to the Internet to update the lists of networks. This period is specified by the FREQUENCY keyword in an amount of seconds. Whenever there is a new list of networks, a special message is sent to the LCE which causes the blacklist.tasl script to re-hash it's list of networks.

Note: If you happen to manually edit the list you need to restart the LCE.

I have several webinars scheduled over the next few weeks which will be of interest to readers.

The Future of Vulnerability Management - October 3, 7 and 17

This talk will help folks understand many of the converging technology and compliance trends, and how it will effect their future. I review many of the different types of technologies and techniques that are in use today to discover, audit and manage vulnerabilities. The talk then discusses how these map into IT Controls, their effectiveness  and what this means for our jobs and overall network security.

Please register for the webinars at the following URLs:

Oct 3, 11:00 EST
https://www.gotomeeting.com/register/759264977

Oct 10, 11:00 EST
https://www.gotomeeting.com/register/800578374

Oct 17, 11:00 EST
https://www.gotomeeting.com/register/981647110

IT Security - September 22

This Friday, Sept 22, I am on a panel with several colleagues in the information security field. We've each prepared brief opening remarks about recent trends in security policies, threats and technologies in order to set the stage for questions from the participating audience. If you'd like to listen or participate, please register here. The webinar is sponsored by D&E Communications. 

For several years, Tenable's management products have been able to perform realtime correlation of IDS events with existing vulnerabilities and to also "push" just the relevant signatures to your Snort sensors. This entry will briefly discuss the advantages of IDS event and vulnerability correlation and then will walk a user through the deployment of the IDSUpdate script for managing Snort sensor rule configurations.

Accurate IDS Event Correlation with Vulnerabilities

The Security Center can be used to perform Nessus scans as often as you want, with as many scanners as you have and with the correct credentials to perform patch audits. It can also use one or more Passive Vulnerability Scanners to obtain vulnerability information in near real time. As IDS events arrive at the Security Center, each event is analyzed to see if it is related to a particular vulnerability, and if the vulnerability is present on the target system and target port. This is very accurate for attack detection because:

• highly accurate patch audit data is used
• realtime passive vulnerability data is used
• correlation is not dependent on the underlying OS or even application
• multiple cross references of CVE, Bugtraq, Nessus and other IDs are used

Managing A Snort Sensor Rule Set

The Security Center supports many leading IDS technologies including Snort. In Snort's case, Tenable also offers the ability to manage the signatures on the Snort sensor(s). The IDSUpdate tool allows Snort sensors to be tuned with only the signatures for the applications on their network.

Why would someone want to "turn off" signatures on an IDS sensor when they already have IDS/VA correlation? The answer is for performance and efficiency. Since the Security Center already "knows" about all of the vulnerabilities on a given network segment, it can remove Snort signature rules for attacks that may never occur, and even if they did, are not relevant. A Snort sensor running with less signatures will also have more horsepower to analyze traffic and have less chance of being overloaded.

Configuring A Deployment

An organization running the Security Center and gathering Snort IDS events is already half-way there. Each time the Snort rules are updated (with either the Sourcefire VRT rules and/or the Bleeding Snort rules), the Security Center is automatically building the pre-correlated signature libraries.

For your Snort sensors, download the IDSUpdate tool from the Tenable Support site and install it on your Snort sensor(s). It will untar into a directory named "IDSUpdate" and have an IDSUpdate.pl and IDSUpdate.cfg file. The config file has many parameters to be configured. Here is an example live IDSUpdate.cfg file: 

#############################################################
# Frequency of update polling (in minutes)
# Set to 0 to cycle once.
FREQUENCY=360

#############################################################
# IDS Engine Type
#############################################################
IDS_ENGINE=SNORT

#############################################################
# Snort specific information
#
# SNORT          - full path to the snort binary.
# SNORT_CONF     - full path the snort.conf file.
# SNOR_RULES_DIR - full path to the rules directory.
# SNORT_PID      - location of the running snort process ID
#############################################################
SNORT=/usr/sbin/snort
SNORT_RULES_DIR=/etc/snort/rules
SNORT_CONF=/etc/snort/snort.conf
SNORT_PID=/var/run/snort_eth1.pid

#############################################################
# Full pathname to required files
# Current requirements - wget and gunzip
#############################################################
WGET=/usr/bin/wget
TAR=/bin/tar
GUNZIP=/bin/gunzip
MD5SUM=/usr/bin/md5sum

#############################################################
# Archive URL
#############################################################
ARCHIVE_URL=http://192.168.210.33/sc3/html/snort.tar.gz
ARCHIVE_USERNAME=username
ARCHIVE_PASSWORD=password

#############################################################
# Log file
# If not present, logs will print to screen.
#############################################################
LOG_FILE=IDSUpdate.log

#############################################################
# Daemon mode
# Activate using "on"
#############################################################
DAEMONIZE=on

#############################################################
# Holds the last update string to indicate when a new package 
# is ready. This will be updated automatically.  Clear and 
# restart IDSUpdate to refresh immediately.
#############################################################
LAST_MD5=8a67a766d84324ed13002dc83d2553d5

The keywords in red are ones that are blank by default, or should be confirmed for your distribution of Snort. A valid username and password for the Security Center is required for this tool to obtain the new signatures.

The ARCHIVE_URL keyword specifies the location of the snort rules on the Security Center. If your Security Center is configured for SSL connectivity, change the URL to include https. The file snort.tar.gz will always contain ALL of the latest Snort rules. If the Security Center is subscribed to one of the Sourcefire VRT libraries, then this will contain effectively all of those. If the Security Center is subscribed to the Bleeding Snort rule set, then it is all of those. Lastly, if a Security Center is subscribed to both VRT and Bleeding Snort, snort.tar.gz will contain an aggregate of both rule sets.

For correlated rule sets, a separate file is produced for each unique Security Center customer, based on the customer ID. For example, customer 10's Snort rules would be named snort-10.tar.gz. In the above configuration file, these would be available at a URL of:

http://192.168.210.33/sc3/html/snort-10.tar.gz

Having separate Snort libraries for each Security Center customer allows you to place different Snort sensors at different places in the network for very specific monitoring.

So how does this work?

Each time the Security Center either obtains new IDS rules from the Sourcefire VRT or Bleeding Snort, it produces a new set of signature libraries. The Security Center does this on a daily basis, but administrators and security managers can force an update.

Each time the Security center obtains a new active Nessus scan (with or without credentials) or a passive scan from a Passive Vulnerability Scanner, it produces a new set of Snort signature libraries.

Each Snort sensor running the IDSUpdate tool downloads the signature set from the Security Center and compares it's MD5 checksum to the previous one. If there is a difference, the new rules are put in place and Snort is restarted. New downloads from the Security Center occur with a frequency set by the FREQUENCY variable in the configuration file.

For More Information

Tenable has two white papers available on this topic located in our Security Event Management Whitepapers section. The "Security Event Management" paper details how vulnerability and IDS correlation maps into log analysis and anomaly detection. The "Correlating IDS Alerts with Vulnerability Information" paper details the benefits and false positives which occur with this technique.

Many of Tenable's customers have told us that their provisioning, network management or change control processes require that "like" servers be configured the same way. For example, an organization might run twelve Exchange servers and twenty MS SQL servers. It is good IT practice to configure these systems the same way. If this is a new concept to you, we're talking about configuring similar settings, such as lock out policies, how often passwords should be changed, what sort of software has been installed and so on. If your organization is audited for any reason, it may fall upon you to show that your systems are configured in a manner that is consistent with your own policies.

The WNPC tool is designed to be operated on one "gold" system and then to extract the configuration of that system to produce an audit file for Nessus Direct Feed users. The tool is available as a Windows executable. When it is run, there is a very simple interface which allows for cut n' pasting of the text policy values or for saving to a specific Nessus 3 ".audit" file.

Below is an example screen shot of the Windows Nessus Policy Creator in action:

Any of the .audit files can then be used with Nessus 3 for scanning hosts to see if they are compliant. By "compliant" we mean that a host is configured as expected as compared to this "gold" system. The WNPC tool collects several thousand audit points for access control settings in the registry and file system. It also audits all security policy settings such as password complexity, event logging and lock out policies.

There are many use cases for this technology:

• Security Center users can create per-asset configuration policies and then scan those particular assets for those particular configuration settings.
• Consultants using Nessus 3 and the Direct Feed can quickly create policies for a customer and then scan their other assets for deviations from that policy.
• Policies can be created from "factory" default settings as a baseline, and then an audit of systems in the field can be conducted to detect what has been changed.
• IT Organizations can work with the Windows operating system directly to "harden it" to their liking and then use the WNPC to create the audit policy automatically.

For more information, to read the compliance check documentation and to obtain the Windows Nessus Policy Create tool, please visit the Nessus 3 Agent-less Compliance Checks page.

Tenable's Security Center and Log Correlation Engine were reviewed in the September 2006 print issue of SC Magazine in a section named "Group Test: Event Management". The article about Tenable leads off with a great quote, "The Tenable Security Center has massive capability wrapped in a single, easy-to-navigate interface". The article makes several really good comments about our product's features. However, the only draw-back the article points out was that we were priced more expensive than the other products evaluated. The article comments: "Priced at the high end of the spectrum, the Tenable Security Center offers a powerful tool with a price tag that is higher than that of some full appliances."

As tested, our overall price was $74,000 because we included our fully licensed Log Correlation Engine at a cost of $50,000. The SC Magazine evaluation didn't really stress a large number of total log entires for evaluation and we could have easily submitted our 5 million event LCE license at a cost of $9995. This would of placed our total cost around $34,000, which is much more competitive with the other products tested.

I encourage everyone to read through the article and specific products tested. As you do this, please keep in mind:

• Although the article was focused on SIM and log analysis, our products as tested included full vulnerability and compliance auditing features. This provides a great deal more value for customers who don't want to run separate products or train users in multiple vendors.
• Tenable's Log Correlation Engine licensing doesn't penalize you for the number of agents used, the maximum number of events per second or require you to purchase or obtain a separate SQL database
• We felt there were many other vendors that aggregate logs and do intelligent things with them missing from the evaluation. We would have very much liked to have seen ArcSight, Cisco MARS or LogLogic for example.
• We would have also liked the testing to include log sources beyond IDS/IPS and firewalls. Tenable has made great efforts to include support for anti-virus, honeypot, netflow and dozens of other categories with hundreds of different supported solutions.

Note: this review is now available online.

Nessus has more than 11,000 plugins which can be used to audit networks with host based checks and network checks. There are also many different options that Nessus users can configure to optimize their scans. One of these options is to enable or disable "safe checks". The "safe checks" setting allows Nessus users to enable a set of plugins within Nessus' library of vulnerability checks which Tenable feels can have negative effects on the network, device or application being tested. This post will explain why disabling "safe checks" for testing pre-production equipment is a good idea, why enabling "safe checks" for production testing is recommended and why some network plugins for Nessus can have adverse effects.

The "safe checks" setting effects network check plugins. These are plugins which make some sort of network check other than leveraging credentials such as SSH, Windows domain or SNMP. When Tenable writes a network check, we try to make the check as "nice" as possible. The goal is to accept no damage or interruption of the target system except perhaps a log entry from the probe. Usually, Tenable is able to produce not only a host-based patch audit for a given vulnerability, but if there is a network service involved, also produce a network check which does not require credentials. In some cases though, if a network vulnerability has been patched, there may not be an elegant way to check for this without credentials. 

For these network checks, Tenable may still be able to write a check that finds the vulnerability, but also has some sort of negative impact on a target, such as crashing a network daemon. When this happens, Tenable's policy is to write the check anyway, but mark the plugin as "unsafe". These checks will only become enabled when the "safe checks" setting has been disabled. Please keep in mind that the majority of the time, Tenable is able to write a Nessus network check which can accurately test a remote network service without impact.   

When Tenable encounters Denial of Service (DOS) checks and various vulnerabilities in non-robust targets such as embedded devices, we almost always mark these plugins as unsafe checks. Tenable regularly encounters vulnerabilities in embedded devices such as routers and printers. Often these devices have network services, but if they are pushed too hard with any sort of testing, the service or the actual device may crash. For example, Tenable recently was testing a network storage device and found that multiple queries to URLs outside of the "admin" page eventually DOSed the web service. The only way to really test this class of vulnerabilities is to try them.

Historically, some older Nessus plugins do have behavior changes based on the "safe checks" setting. For example, if "safe checks" is enabled, the apache_2_0_45.nasl (Nessus plugin #11507) will perform it's audit based solely on the banner, otherwise it will perform a query. While it's not all that common in newer checks, Tenable does occasionally use the "safe checks" setting such as in Nessus plugin #22204, which checks for last month's flaws in Ruby on Rails. Usually though, the "safe checks" setting is completely enabling or disabling a plugin we feel is suspect.

So as a rule of thumb:

• If you are scanning multiple hosts or entire networks, "safe checks" should be enabled. This will minimize any negative side effects of the scanning and also decrease your scanning time.
• If you are auditing one or more hosts in a pre-production environment, disabling "safe checks" will perform a slightly more complete audit, but at the risk or performing a test which might have negative impact on the tested systems.
• If you are auditing a network device, an embedded device that is operational and want a complete audit, consider setting up a test network with the devices of concern and run a Nessus scan with "safe checks" disabled.
• Enabling "safe checks" is no guarantee that a poorly written or managed network component, application or system won't have an issue with the next ICMP ping packet, SYN scan or web query. If you'd like to minimize impact to your network, you should consider performing your scans entirely with credentials or using Tenable's Passive Vulnerability Scanner.

Tenable's research team has released a Nessus 3 audit policy file which can be used to audit the configuration of Apache web servers running on various UNIX platforms. The policy can be customized to your specific Apache distribution. It can audit many aspects of the httpd.conf file. For example, it has the ability to easily automate testing for which user the httpd process is running under, which ports it is bound to and what log format should be enabled. Since the actual configuration file is used, Nessus can perform this analysis even when the Apache server isn't running.

For completeness of report, Nessus's file content features are designed to ensure that if a certain setting is supposed to be set, it will pass if it is set, fail if it is not set and also provide a warning if the setting doesn't exist. For example, consider this section from the Apache .audit file:

<custom_item>
#System           : "Linux"
type              : FILE_CONTENT_CHECK
description       : "Check if ServerSignature entry in httpd.conf is correctly set"
file              : "httpd.conf"
search_locations  : "/usr/local/apache/conf:/usr/local/etc/httpd:/etc/httpd"
regex             : "ServerSignature *"
expect            : "ServerSignature Off"
</custom_item>

This check looks into the httpd.conf and searches for the string "ServerSignature" followed by a word. If that string is found, it then tests for the complete string of "ServerSignature Off". The check will return the following Nessus severity levels based on the following conditions:

• hole - The "ServerSignature" value is present, but it is not set to "Off".
• warn - The "ServerSignature" value is not present, so there is no way to ensure we are compliant.
• info - The "ServerSignature" value is set to "Off".

This .audit file can be used with Nessus 3 scanners that have been subscribed to the Direct Feed, or that are being managed by a Security Center. The policy can be downloaded under the "Sample Application Audit Files" section from the Nessus 3 Agent-less Compliance Checks page.