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.
