In my working life I have had various roles as security consultant. One of these roles was working in an operational security team. Now that I have found a new job as security specialist, I am again seconded to a company within an operational security team. One of my specialties is Vulnerability Management and Vulnerability scanning and I have found out (call it the hard way) that this is never an easy task. Although from the outside, it appears to be a rather ‘simple’ solution, Vulnerability scanning is a complex topic with many touch points throughout an organization. Difficulties I had always taken for granted but are not as common as I had expected. Therefore I am starting a series of blog-posts to explain vulnerability scanning, starting with what I would consider the basics.

Defining a scanning approach

To determine a suitable scanning approach, you must first know what kind of scanner you are working with. So far, I have had the opportunity to work with various scan tools such as nmap, Tenable Nessus, Ncircle IP360 (now tripwire), Lumeta’s IPSonar and several other scanners. Each of these tools has its own use and purpose. Some of these scan-tools are multi-purpose and in most cases, there is even a certain overlap in functionality. When selecting a scanner it is important to determine what the purpose of your scanning will be.

External scanning

External scanning is to mimic the approach of an external attacker. It will only use the externally opened ports to determine if a vulnerability can be identified. During an external scan, the scan engine will probe for open ports, for each port determine what service is running check against the vulnerability scanner’s database if the presented version has any known vulnerabilities. Depending on the settings in the vulnerability scanner, the scanner can attempt to exploit a potential vulnerability but this might also crash the service. If the version appears to be vulnerable, based on the scanner’s database, it will be included in the report. Although this mimics the approach of an external attacker, it can also easily miss out on services that are provided on non-standard ports and give a false sense of security. Another downside of this approach is that it may lead to false positives. A good example is when running this type of scan against a Debian or Red Hat server. These suppliers are known to patch vulnerabilities without changing the external presented version numbers. Hence it may still run Apache version 2.4.15 while the latest Apache version is 2.4.34. This Debian or RedHat version however, having all the security patches of 2.4.34 in place, is not vulnerable at all for the known vulnerabilities.

Internal scanning

Another approach is internal scanning. This is much more difficult to configure as it may also uphold other expectations. After all, you are scanning behind the firewall, so you should be able to see everything, right? Wrong! As at least enterprise networks are commonly segmented by techniques such as VLANs, separated by Firewalls, or in other means not directly connected throughout the entire inner side of the organization, it may be that your scan engine still ends up partially blind. There are two main approaches that I have seen for configuring internal scanners.

Approach 1: Open up the firewall

The first approach is to simply open up the firewalls. This means that all ports on the targets that you want to scan should be made accessible to the scan engine’s IP. This is quite easy to realize when you only have one scan engine and only few segments to scan. It becomes more cumbersome when you want to scan multiple subnets though, and it may also cause quite a strain on the firewalls and other network equipment between your scanner and your target.

Approach 2: One scan engine per segment

This may come across as a more expensive approach, and it highly depends on your type of scanner if this is feasible. I’ve had the possibility to work with the Tenable ScanCenter and Rapid7 Nexpose systems which supported this. It only required few ports to be opened in the firewall for communication between the scan manager or console and the scan engines. By positioning the scan engines within the network segments that we wanted to scan, the load on the network was kept to a minimum as it was all traffic within that one specific segment. No router or firewall was impacted by it.

Scanning methods

Once you have determined if you want to have an internal-only, external-only, or hybrid approach and where you want to place the scan engine(s), you have to start defining the desired scanning methods.

Performing network discovery scans

The very first step in vulnerability scanning is to identify what you want to scan. For this purpose, nearly each of the mentioned tools can be used. Nmap is preferred by many penetration testers as it integrates ping-sweeps together with port-scanning. Also, the fact that nmap is both open-source and free to use makes this a very attractive tool. Several commercial vulnerability scanners also implement a version of nmap for discovery scanning and include options in their user interface for tweaking options as if it is run on the command-line. One of the more expensive and also comprehensive tools is Lumeta’s IPSonar scanner which is specialized in discovery scanning or as they call it, network situational awareness. Most important objective of this type of scan is to become aware of all systems in your network that may be subject to vulnerability scanning. More importantly so, to identify those targets that you most definitely want to exclude from automated scanning because it may impact the operations (devices such as SCADA systems, PLCs and other devices that could be impacted when scanned with a port scanner or a vulnerability scanner)

Performing port-scanning

Once you have identified all devices within a specific network range it is time to start scanning the devices for vulnerabilities. A device may have any port between 0 and 65535 open, listening to a specific protocol such as TCP or UDP. Since scanning can be performed from any location, both inside and outside the network, knowing the path between your scanner and the target system is important. When scanning all 65535 ports with a TCP connection scan on multiple targets, it may even saturate a firewall if connections are not closed timely. Therefore doing these types of port scans are best to be done as an initial identification scan. After that, they can be performed for example once a year to validate if the current scan profile is still suitable.

Next steps

Once you have identified the targets, determined which ports are open and which services are running on them. Now it is time to configure the actual vulnerability scan or even multiple scans. More on this in a next article