Recently, a Tenable customer asked me if we had any plans or capability to perform brute force password cracking with Nessus. For those familiar with Nessus, this wasn't about testing for default user accounts during a network scan. The customer was asking to obtain the encrypted password databases from Windows and UNIX and try to brute-force their contents offline to find weak passwords. This particular customer was running several different password cracking tools across several different operating systems.

When I asked what the requirement was, the customer said they wanted to enforce minimum password lengths, minimum password durations and certain complexity levels. I suggested that they use the sort of compliance checks that Nessus 3 can perform. All modern operating systems have pretty good password policy settings which can help enforce password complexity, how often a user has to change their password and so on.

Since this customer had the Security Center, they could produce one password policy that Nessus 3 can use to perform these password audits. Then, for each of the customer's different asset groups (Windows Servers, User Desktops, Firewalls, .etc) they can report which ones had password policy issues.

In the end, this was much less intensive for the customer to perform consistently and on a repeatable basis.

Tenable's research group recently added a Nessus 3 audit policy for Red Hat Linux. This allows Direct Feed users who are auditing missing security patches with SSH credentials to also ensure the system has been properly locked down.

The audit tests for several hundred different items such as the permissions of /var/log/messages and if any user accounts have poor permissions in their home directories. Audit files for Solaris, security recommendations from CERT and generic UNIX checks are also available in addition to many checks for a variety of Windows policies.

One of Tenable's advisors, Gene Kim, CTO of Tripwire and lead researcher of the IT Process Institute's "IT Controls Benchmark Survey", was recently interviewed by Richard Stiennon about how IT Controls not only help run networks more efficiently, but how they can make a network more secure.

The survey lasted several years and included input from 98 organizations. A focus of the survey was measuring metrics such as "change success rates", "percent of unplanned work", "projects completed", "managed applications", "server to admin ratios" and so on. Each organization was also interviewed to see which IT controls they had implemented. Based, on the results of the metrics, each organization was assigned into a "high performer", "medium performer" or "low performer" group. For example, a "high performer" on average had a "server to system admin" ratio which was 2.5 times greater than a "medium performer" and 5.4 times greater than a "low performer".

In other words, they had a lot more efficiency. The study attempted successfully to correlate the premiss that an organization that implemented IT Controls was better off than another one which didn't. The report focuses on which controls are the most effective at maintaining an efficeint network. However, the report also found some very significant differences in the security posture of a "high performer" as compared to a "low performer". These included:

• only 1/5th of intrusions turned into a loss event such as bad publicity or financial loss
• detection of the intrusion was with automated controls, as compared to something like a customer calling in with a complaint
• mean time to detect was minutes and for low performers, the detection time was measured in days and weeks

Another finding of the research was that all "high performers" had two controls implemented that none of the "low performers" had. These were:

• a process to monitor for unauthorized change
• defined consequences for intentional un-authorized change

Both of these are deterrents for system administrators, developers and end-users from making changes to their systems, applications and networks.

If you are a Tenable customer, our products can help look for many types of changes which occur on your network.

• The Security Center automatically can generate an email of any new vulnerabilities which have occurred between two successive active Nessus scans.
• The Passive Vulnerability Scanner can monitor network traffic for evidence of new systems and applications 24x7 with no impact.
• The Log Correlation Engine can look for evidence of changes to users, systems and network devices, as well as also parse logs from change detection software such as the PVS and Tripwire.
• The Log Correlation Engine can also alert if there is unauthorized activity outside of an official change management window.

There are many forms of IT controls. One of them is ITIL which stands for the IT Infrstructure Library. This library is very comprehensive. A very popular "best practices" guide named the "Visible Ops Handbook" has helped many organizations understand how ITIL can be implemented. Tenable has written a white paper named the "Network Security Implications of Visible Ops". This paper examines how active network scanning, passive network monitoring and log analysis can all be used to look for unauthorized change.

Tenable has also written an extensive paper which covers COBIT and ISO 17799 IT controls monitoring. This paper is named "Real Time Compliance Monitoring" and is available to existing Tenable customers and qualified potential customers. Please email sales@tenablesecurity.com if you are interested in this paper.

Tenable consistently gets questions as to when a user should perform a vulnerability scan with credentials. Nessus 3 can perform extensive host-based configuration and patch audits on most flavors of UNIX and Windows. This blog entry will help Nessus users understand when and why they should consider using credentials when performing scans.

Testing for Client Vulnerabilities 

Most network clients like Mozilla, Eudora and Outlook do not have network ports that are open for probing by a remote Nessus scanner. Some client applications, such as various P2P and communication tools, do have network ports that are open for analysis by Nessus. However, for 100% coverage of all local client vulnerabilities, a credentialed Nessus scan is the best choice.

If auditing client vulnerabilities is of interest, you might want to consider Tenable's Passive Vulnerability Scanner which can sniff this sort of information out of regular network traffic.

Testing for Compliant Configurations

If you are a Nessus 3 Direct Feed subscriber, or have the Security Center deployed, if you want to audit your UNIX and Windows configurations against a known "best practice" configuration, you need to have credentials.

Testing for Specific Patches

When a Nessus network check is written by Tenable, we have to consider the most common deployment case of a particular application. For example, if a vulnerability is discovered in an Apache web server, Nessus will report it. However, a pure scan on port 80 might not have enough information to conclude if the Apache server was installed on RedHat by an RPM, on FreeBSD through a package or even as an executable on a Windows server. The point is that although Nessus will likely recommend an upgrade to a newer version of Apache, for a well managed server, a network check might not point out the specific patch needed.

For 100% coverage of needed patches, you should configure your Nessus scanner with credentials. This will provide specific patches that need to be applied. This also allows your IT people who might not know about the particular application's security issues or revisions to conduct an upgrade within their regular patching process.

Testing from a Malicious Adversary's Point of View

Running a regular network scan from outside your firewall, across a VPN or between departments will show you exactly what an adversary or hostile insider might see. These scans should be performed without credentials (although you should consider what would happen if an insider or outsider does know your domain passwords). A full network scan should exercise all exposed ports and applications and expose them to an audit of the more than 11,000 plugins currently available to Nessus users.

Using Nessus to test an IDS, IPS or Smart Firewall

Using credentials to audit a system protected by a security device won't really exercise the device at all. Either it will likely pass the connection attempt or block it. However, Nessus can perform many types of reconnaissance, enumeration and identification of vulnerabilities on a network. The techniques Nessus uses are similar to the type of techniques an IDS or IPS may be configured to look for.

Also the load, variety and content of the scanning traffic is something that can be used to test the robustness of the security device. Be sure to make sure you try scanning both through the device as well as scanning the device itself.

Testing for Worms, Backdoors and Trojans

Tenable does write plugins for Nessus that do look for evidence of the major worms and trojans, but you should not consider a Nessus scan as a replacement for your SpyWare or Anti-Virus solutions. Having said that, some network scans to look for various "worm" ports such as Sasser's FTP server. Some local checks (such as Nessus plugin #11329) do attempt to identify registry settings and values set by different worms. For large scale scans, this can help identify some infected servers.  Credentials are need to perform these "local" audits.

Tenable has had many of our customers call in to discuss ways they can look throughout their enterprise to find the latest round of security issues from the last "Microsoft Tuesday". Here is a quick list of things you can look for with our products:

• Nessus can be used to perform a network scan for any Windows host effected by the MS06-040 patch. The scan does not need credentials, but the scanner does need to be able to communicate with the target on ports 445 or 139.
• If you do have domain credentials, plugin 22182 performs a patch audit looking for the applicability of the missing patch. Doing an audit with credentials will also allow for testing of the other "local" security issues besides MS06-040.
• If you've completed an active Nessus scan for MS06-040, the Security Center will correlate NIDS events (from Tipping Point, Snort, Dragon, etc.) that target vulnerable MS06-040 devices.
• For devices infected by Mocbot/Wargbot, Nessus plugin 11329 can detect this. This plugin requires credentials.
• For devices infected with the BOLO worm/trojan that exploits MS06-040 (and delivers the Mocbot trojan), if you have a Passive Vulnerability Scanner deployed on your perimeter, you can query your Security Center to list any devices which browse on port 445 and 18067. Any devices which browse on port 445 across your perimeter should be considered suspect for a wide variety of issues regardless.
• Lastly, if you have deployed the Log Correlation Engine, you can query it for activity on ports 445 and 18067 as well. Tenable has also released a TASL script which looks for Mocbot activity in any log source. The LCE also has many generic log correlation techniques such as looking for crowd surges and suspicious proxy connections in any log sources. We've blogged about the crowd_surge.tasl script previously and it has been updated to alert when there is a surge of visitors to sites tracked by the Internet Storm Center.

Tenable Network Security discovered a security flaw in software commonly used to backup important corporate data. After notifying Symantec of the problem, their engineers conducted a review of all effected products and have released a set of hotfixes. Tenable has also released a Nessus plugin which detects the missing patch.

This particular vulnerability effects enterprise networks which use the "Backup Exec" software to ensure their data is stored in a safe and central location. This also makes it convenient for an insider to attack one spot and obtain the data they are after.

Recently, Tenable was asked about detecting DNS servers that were configured to respond to DNS "recursion" queries. The issue is that a remote attacker could spoof a recursive DNS query with a source address of a network they wish to cause a denial of service for. The attacker spoofs a query with a small payload and causes the DNS server to reply with much more data. This floods the target network with answers to questions it never asked for.

In 2005, the US CERT organization put out a note titled "The Continuing Denial of Service Threat Posed by DNS Recursion" which detailed the attack technique and methods to secure various commercial and open source DNS servers. This vulnerability has been around for several years but according to CERT, is still actively used for DDOS attacks. Tenable has two methods to detect these vulnerabilities.

First is Nessus plugin #10539. This plugin detects DNS recursion in general. If you run Nessus from inside your network, then being able to perform such a query isn't necessarily an issue. However, if you have placed your Nessus scanner outside of your network, or are auditing a remote DNS server, being able to perform a recursive query is likely a problem. 

Second, Tenable's Passive Vulnerability Scanner has a rule to detect DNS servers which have responded to recursive DNS queries. The screen shots below show a view of DNS issues passively discovered under the Security Center.

The first screen shot lists all "port 53" vulnerabilities passively found. Vulnerability #03703 is the one identifying a recursive DNS server. Other information includes a list of machines with UDP port 53 open, and machines which "browse" on port 53. The second screen shot is the actual description which is worded as if the PVS was deployed internally.

Being able to passively monitor for such issues 24x7 without scanning is very useful, especially if a new DNS server is added or an undocumented change is made to a DNS serve before the next active scan. If the PVS is placed outside your network, or in a spot where it can see external DNS queries, then it will also see successful external recursive DNS queries.

Regardless if you are a large or small network, if you have DNS servers that do respond to recursive DNS queries from external sources, you may be contributing to someone else's DDOS attack and not even know it. The CERT note mentioned in their testing, 80% of all DNS servers were subject to this problem. Because there are so many DNS servers to use, attackers can launch their attacks using multiple DNS servers. Each site participating in the attack may only contribute a small percentage of the overall bandwidth, but the target network gets flooded.

Tenable Direct Feed and Security Center users have updated Nessus plugins to check for all vulnerabilities disclosed by the recent "Microsoft Tuesday" patches. The majority of these checks are for client-side issues and require local access with domain credentials. There were 12 local checks in total including two for Microsoft Office.

There is one highly critical remote flaw (MS06-040) which is a stack overflow. It is possible to exploit Windows 2000 and XP SP1 remotely if they are not protected by a firewall. Windows 2003 SP1 and XP SP2 may also be exploitable, but could just be subject to a denial of service attack. Tenable has developed Nessus plugin 22194 which can check for MS06-040 remotely without any credentials at all.

Tenable is also actively analyzing these patches for detection with the Passive Vulnerability Scanner.

Tenable released a TASL script for the Log Correlation Engine that can use netflow, sniffed network sessions, firewall logs and even network IDS logs to help identify botnets, maleware and zombie networks.

The basic premiss is that for certain protocols like SSH, Telnet, IRC and custom high-port control mechanisms, if we have a "large" user population suddenly all decide to visit an IP address on the other side of the world, this could indicate a "phone home" or some sort of control mechanism.

In our testing we've seen 100s of IP addresses all start to connect on a variety of ports. In some cases, we've seen user populations all descend upon Google and MySpace at the same time, but most of the time, we've been looking at a botnet of some sort. Seeing several 100 computers all connect to IRC at the same is an example most people are familiar with, but with this sort of correlation script, we're seeing odd ports targeted throughout the 0-65535 port range.

Consider the following example (sanitized) log:

This shows that host 210.51.x.x was visited at least once by 20 unique IP addresses from our "local" network. In each case the destination port was 62105. We've shared these logs with some experts for comment and many people have suggested that port 62105 is used in cases by the Skype application. These hosts involved in the session were not running Skype as determined by our Passive Vulnerability Scanner and Nessus scans.

Let's look at a different example:

The TASL script creates an event named "Crowd_Surge". In this example, one of the destination IP addresses for one of these events also was listed as a being tracked by the Internet Storm Center. The screen shot is an event summary of the last five days of all logs for the IP in question. The screen shot below is a port summary of all ports (destination and source) for the IP in question. Notice the large amount of port 9001.

The Internet Storm Center portal lists 9001 as Tor. If you are familiar with how Tor works, this pattern may make sense to you. However, the number of IP addresses involved with this log was several thousand.

As Tenable gets feedback from its customers about various observed traffic, we will post some results in this blog.

Today, the Tenable Research Team released a new version of mIDA, an IDA (Interactive Disassembler) plugin that allows one to extract Windows RPC server interfaces and to recreate the IDL definitions.

By using the disassembler engine, mIDA supports almost all RPC interfaces.

Version 1.0.6 introduced the following changes :

• Bugfixes (crash and better parsing of some structures)
• Support of MIDL compiler 7 used in Windows Vista
• NDR Library version 0x60001
• FC_SUPPLEMENT, FC_EXPR, FC_FORCED_BOGUS_STRUCT and the new range format

We would like to thank all people who sent us bug reports and feedback about previous versions and encourage everyone to do the same to help us improve this plugin.

You can download mIDA here

For first-time (and even veteran) Nessus users, Tenable support often gets questions about how to access the security of a host that is behind a firewall. Regardless if you are running Nessus for the first time, or deploying distributed Nessus scanners managed by the Security Center, knowing how to scan systems protected by firewalls is vital. This post will discuss several issues with scanning hosts behind firewalls and strategies Nessus users can use to overcome this. Although a relevant topic, we're not going to consider host-based firewalls, scanning load-balancers or scanning through VPN links in this post.

Access Control Devices vs. NAT devices

Before we get started, the term "firewall" is often used loosely. In some cases, this is a device that prevents certain types of network traffic from flowing between different network segments. For example, port 80 traffic could be denied from the 10.10.0.0/16 subnet heading out to the Internet. So performing vulnerability scans in this sort of environment involves knowing the security policy and being able to work with it.

In other cases, the "firewall" device is performing a network function called NAT for Network Address Translation. (It also does Port Address Translation (PAT) but we won't get into that). In this case, many IP addresses on one side of the firewall can share one or even a few IP addresses on the other side of the firewall. A small office might have a firewall that hands out DHCP addresses for 192.168.10.4, 192.168.10.10 and 192.168.10.12, but when each of these systems communicates through the firewall, it translates the IP addresses to an address on the public side. Scanning through a NAT environment is more tricky, but we will cover that to.

Scanning One Host Behind an Access Control Firewall

If you are on the "outside" of a firewall and want to scan a host "behind" it, your scan will be effected by the policy of the device. For example, if only port 80 traffic is allowed through the device, your scan will only be able to test for port 80 bugs. The firewall itself may also effect your scan results:

• Some firewalls may react to your scanning as hostile and simply block your IP.
• If your scan policy requires an ICMP ping, or a TCP ping on a specific port, and the firewall won't allow this, your scan won't run because it won't think a host is actually there.
• TCP/IP stack fingerprinting can come back with misleading results because many firewalls have odd combinations of silently dropping packets and responding to out of state TCP flags.
• A firewall may have limited CPU or memory power and have a limit to the number of simultaneous network sessions it can handle.

So with a single port open, your Nessus scanner will only be able to assess the vulnerabilities on that port. If more ports are open you may be able to scan for more vulnerabilities. If you have credentials (SNMP, SSH or DOMAIN) on the remote scanned host, you can perform a full patch audit of the system. This can lead to an intellectual argument of needing to reconcile vulnerable services with blocked firewall rules. For example, if we know IIS is vulnerable, but it is not open to the public, do we care?

Lastly, many people don't realize that the inverse of this situation (scanning from inside of a firewall) can also impact your results. Firewalls can have outbound rules. If they are limited in CPU/memory, they may also drop some of your connections.

Scanning Multiple Hosts Behind an Access Control Firewall

For scanning multiple hosts behind an access control firewall, the issues discussed are magnified. Scanning many hosts is technically no different than scanning one host. The firewall policy will dictate which ports you can scan and which you can't. Unfortunately, this requires that you know the policy of the firewall across all hosts to judge the impact to your scan. For large networks, this can be a very complicated task. Since you are sending more traffic, there is also a higher chance to have the firewall interact with your scan results.

Asking to be a "Friendly Foe" with an Access Control Firewall

If you are using Nessus in a friendly organization, it may be possible to ask your firewall administrators to punch a hole in their access control list to let your scanning IP right through. This may make your scans faster and have less impact on the firewall. It will also find more vulnerabilities if the targeted hosts have more ports than what the firewall was letting through. Keep in mind though, if the host you scanned only had port 80 open to begin with, being able to scan other ports on that device won't let you find new vulnerabilities, but you will have some confidence that the device isn't running file sharing or other services.

Placing a Nessus scanner behind an Access Control Firewall

For scanning large networks protected by a firewall, a Nessus scanner can be placed "behind" the firewall. The nessusd daemon by default listens to TCP port 1241. If you can have a Nessus scanner installed this way, then your firewall administrators just need to allow a rule to let you connect to the scanner from the outside. In this case, you'd be connecting to port 1241 on the real IP address of the deployed scanner. Since Nessus is available for many platforms, you may even be able to deploy it on existing servers.

Scanning One or more Hosts Behind an NAT Firewall

With NAT, there is no opportunity to really target an IP address "behind" the firewall device. For example, if a NAT firewall had a public IP address of 1.1.1.1 and an internal network with IPs in the 192.168.20.0/24 subnet, there is no way to "target" a specific address like 192.168.20.5.

Instead, if a NAT device is facilitating hosting a few services, it will likely have "port forward" rules. Perhaps in the above example, the NAT firewall could have a port forward rule such that sending email traffic to port 25 of 1.1.1.1 actually translated it to port 25 on 192.168.20.3. The system at 192.168.20.3 would see traffic from the Internet coming to it on port 25 from the original Internet IP address.

So for scanning, this means that if the Nessus scan targets the public NAT IP address (or addresses), the ports which are being forwarded to internal servers will be scanned. Devices which maintain NAT translation rules in addition to moving network traffic may experience a CPU/memory hit when processing scans. Scan results will be effected similarly to what was described for scanning an access control firewall. This may seem very odd, but in the example above, the Nessus scanner would be configured to scan the firewall's IP at 1.1.1.1 and any port forwarding rules would be translated to the internal network. This can give you some really interesting vulnerability results such as seeing a Sendmail banner on port 25 and IIS on port 80.

Setting up "Port Forward" rules to Perform Scans

If you need to scan particular ports or hosts behind a NATed firewall, you will need to set up port forward rules to scan the systems you need. For example, if you wanted to hit port 21 on an IP such as 192.168.20.77 from your Nessus scanner, the firewall administrator would need to set up this rule for you.

Not all NAT firewalls are the same. Some can only forward ports to one host. Others may be able to forward some ports to one host and other ports to other hosts. If the firewall is being actively used, a firewall administrator may not want to make changes during peek usage,

Placing a Nessus scanner behind an NAT Firewall

When placing a scanner behind a NAT firewall, you'll need to configure a port forward rule from the public IP address to the internal private address. For example, if the public IP address of the firewall was 1.1.1.1 and it had a port forward rule to send port 1241 traffic to 192.168.20.10, your Nessus client would make a TCP connection to 1.1.1.1 on port 1241. This is shown below in the screen shot:

When working with multiple NATed networks, this can get confusing. The firewall with the public IP address of 1.1.1.1 might be serving a network provisioned with a 192.168.20.0/24 networking scheme and another firewall with a public IP address of 1.1.1.2 could also have a 192.168.20.0/24 network behind it. You could configure the same scan that targeted 192.168.20.0/24 but use the scanner behind 1.1.1.1 to scan the first network and use the scanner behind 1.1.1.2 to scan the second.

Am I Still Vulnerable behind a firewall?

For the most part, if the person asking this question thinks that firewalls have magical capabilities to protect everyone and everything, then you want to answer an absolute "YES". Technically though, the scan will only audit the open ports that can be seen through the firewall. If credentialed scans can be leveraged, you may be able to understand the patch levels of a variety of client-side tools such as Outlook, Internet Explorer and Mozilla.

Minimizing Impact

Before anyone starts scanning firewalls or scanning hosts through a firewall, they should do a little research and see if there have been any reported issues of port scans, malformed packets, ping sweeps, vulnerability scanners, .etc having performance issues. If many people are using the firewall, causing an interruption can be disruptive to their productivity. Also, if there are any available CPU or load statistics, scanning a firewall that is already under-performing may cause it perform even poorer.

Today, Tenable released two new plugins for Nessus 3 that can audit the configuration of a remote UNIX or Windows system and report "compliant" or "not compliant" with a set of user-defined security policy configuration settings. We've also written policies based off of the publicly available hardening and best practice guides from the NSA, NIST, CERT and the Center for Internet Security. These plugins are available to any Nessus Direct Feed customer or Security Center user.

Along with the new plugins and audit policies, we also have released two tools that allow users to quickly build their own polices for scanning Windows hosts. The i2a.exe (inf to audit) Windows executable allows users to convert existing Windows policy files to a direct Nessus 3 audit file. Similarly, the Windows Nessus Policy Creator allows users to create audit policies based on the exiting configuration of their servers.

The actual audit files are text based, and easily modified with most text editors. The types of configuration audits performed by Nessus 3 include Windows user policies, file permissions, registry permissions, service permissions and specific security policies such as Kerberos and event auditing policies. For UNIX systems, user policies, file permissions, running processes and file content checks can be audited. Combinations of each of these types of audits can be combined to perform tests against 1000s of files, registry settings, users and so on, usually in less than a few seconds per host..

Full documentation for these compliance checks, tool download and example audit files can be found here.

So what are the uses for this technology? There are several:

• Consultants and Managed Service Providers can now use Nessus 3 to audit their customer's systems for compliance against a variety of "best practices" configurations.
• Consultants and Managed Service Providers can work with their customers to create custom audit polices for their environment and then alert when specific systems deviate from acceptable configuration settings.
• Security Center customers can now perform specific types of configuration audits against specific types of assets. For example, the Security Center can be used to test the Solaris DNS servers with one type of UNIX audit, and the Windows Exchange servers with a different one.

We've uploaded demonstration videos of running a compliance audit with Nessus 3 to our video demo page. Look for the videos titled "Compliance Audit" which is the Security Center example, and "Nessus 3 Compliance Audit" which shows a Nessus 3 vulnerability scan, configuring a compliance scan and example usage of the two Windows audit policy creation tools.

We announced a partnership with Digital Bond to have Nessus checks developed to test a variety of SCADA protocols and devices today. You may remember from our previous announcement that we released several dozen Passive Vulnerability Scanner SCADA signatures based on Digital Bond's public snort IDS signatures.

These PVS rules were very popular with our customers in the power and manufacturing industries which led us to put together the paper "Protecting Critical Infrastructures - SCADA Network Security Monitoring". This paper outlined some of the real and perceived risks to performing security, and showed how following the Department of Energy's 21 steps for securing SCADA networks can be accomplished with Tenable solutions.

It seems that although the security teams of most companies with SCADA networks are just as up on the issues as any other vertical, the folks who actually run the SCADA network are often resistant to any outside monitoring. With one or more PVS sensors, some of our customers are getting a first real automated look at their SCADA networks. We're hoping to let them expand that monitoring later this year with actual active probes for Nessus that understand SCADA. 

So what will the work with Digital Bond result in? Here is a short list:

• non-destructive SCADA probes to identify SCADA applications
• vulnerability audits to identify SCADA devices with missing patches
• these checks will be available to any Nessus user subscribed to the Direct Feed and to all Security Center customers
• the checks will only work with Nessus 3

We expect to have initial SCADA checks for Nessus ready by November. In the mean time, if you are interested in SCADA security, I recommend that you subscribe to Digital Bond's BLOG, as well as review Tenable's SCADA paper mentioned above.