Using Nessus to Scan Hosts Behind a Firewall

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 Tenable.sc or Tenable.io, 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.

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 network address translation (NAT). 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 dynamic host configuration protocol (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, too.

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 affected 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 vulnerabilities. The firewall itself may also affect 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 SMB) on the remote scanned host (and access to the associated port), you can perform a full patch audit of the system.

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, which is becoming more and more common. In addition, if the devices are limited in CPU or memory resources, 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 firewall policy 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 that the firewall will interact with your scan results.

Asking to be a "friendly foe" with an access control firewall

If you are using a Nessus scanner 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 8834. 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 8834 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.

If using Tenable.sc, note that your console will need to be able to talk to the Nessus scanner on TCP 8834.  If using Tenable.io, your Nessus scanner will need to talk outbound to *.cloud.tenable.com on TCP 443.

Scanning one or more hosts behind a 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 affected 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 peak 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 8834 traffic to 192.168.20.10, your Nessus client would make a TCP connection to 1.1.1.1 on port 8834.

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.

If using Tenable.sc, you can use separate repositories to segment out data from systems sharing the same IP space.  In Tenable.io, you can use the Networks feature.  In either scenario, you can also use Nessus Agents installed on the systems behind the NATs.

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 Microsoft Office, Chrome and Java.

Minimizing impact

Before anyone starts scanning firewalls or scanning hosts through a firewall, they should do a little research with the network administrators and see if there have been any reported issues of port scans, malformed packets, ping sweeps, vulnerability scanners, .etc having performance issues. If highly utilized, causing an interruption to the operation of the firewall 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 even poorer performance. To read more about suggestions for improving scan accuracy and performance when scanning through firewalls, check out this blog post. 

Additional resources

• Cloud Sensors (Tenable.io)
• Repositories (Tenable.sc)
• Networks (Tenable.io)
• Welcome to Nessus Agent (Nessus Agents)
• 4 Ways to Improve Nessus Scans Through Firewalls