Vulnerability scanning – types of scanners and their purpose

When working with scanning tools, you must first determine what type of scanner you are working with. There are several types of scanners to choose from including (but not limited to)

  • Port scanners
  • Web application security scanners
  • Network vulnerability scanners
  • Host based vulnerability scanners
  • Database security scanners
  • Source code vulnerability scanners.

So far, I have had the opportunity to work the first four types. This includes 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. In most cases, the tools cover a certain overlap in scanning functionality. When selecting scan tooling, it is important to determine what the purpose of your scan will be. In the next sections, each type of scanner is described and an overview of its purpose is provided.

Port scanners

A port scanner is the most basic form of a scanner. But albeit basic, the functionality provided by the various tools can be highly advanced and complex. In its most simple form, a tool such as telnet can be used to verify if a service is provided on a certain port. Telnet is by default present on a lot of systems and works as a basic command in the form telnet <target IP or hostname> <port>. Using telnet however, would mean a lot of manual labour since each target has 65535 ports on which potential services can be offered. This is where the more advanced tools such as nmap or commercial tools such as GFI LanGuard or IPSonar’s Lumeta scanner come in.

These more advanced port scanners can perform various types of scanning. Both protocol based and packet based configurations are possible. This allows for TCP and UDP connection scans, scans which simply try to setup a connection. Creating a connection requires packets to be sent over the network in a specific order to open (SYN, SYN-ACK, ACK) or close (FIN, ACK-FIN, ACK) a connection. These connection attempts can however be blocked by firewalls. Therefore most port scanners also support to send these packets in different or fully separated order which can help to detect firewall rules in place.

This is just a small portion of what a good port scanner can do. There are numerous articles on the internet about port scanners and how to work with them. Although the idea of a port scanner may appear quite basic, do not underestimate the power of a good port scanner for vulnerability management!

Web application security scanners

The most heard in the news today, are breaches which involve websites leaking data. LinkedIn, FaceBook, Twitter, all have fallen victim to attacks on their websites. Where many systems can be shielded from the internet using firewalls, network segmentation etc., a website (or at least part of it) is meant to be publicly accessible. A web application vulnerability scanner scans each page you provide it with against vulnerabilities.

It depends on the type of scanner which vulnerabilities are reported. This can be limited to OWASP top 10 vulnerabilities such as SQL Injection or Cross Site Scripting (XSS). Other scanners also include to scan the underlying webserver for software vulnerabilities or configuration flaws such as outdated SSL configurations.
Examples of these scanners are the proprietary IBM Rationale’s AppScan, Netsparker’s ‘sponsored’ Nikto, and the open source w3af scanner.

Network vulnerability scanners

One of the most well known types of vulnerability scanners is perhaps the network vulnerability scanner. Examples of these scanners are Tennable’s Nessus scanner, Tripwire/Ncircle’s IP360 scanner and the open source equivalent called OpenVAS. Irrespective of its brand or version, the basic way a network vulnerability scanner works is as follows.
First it sends out some packets over the network to identitfy if a system is alive and has open network ports. Once these ports are identified, it will gather version information of the services provided. Based on these version numbers, the software providing the service is validated against a database of known vulnerabilities. It depends on the type of vulnerability scanner and its configuration what happens next. The scanner may be able to brute-force itself into the service to see if any known passwords are used. A scanner can also be provided with credentials to log in to a system and perform a number of host-based verifications. Finally, the scanner may run some exploit code against the potentially vulnerable service to see if the vulnerability can be exploited.


Vulnerability scanners are usually provided with a brute-force testing module. This module can perform brute-force tests against detected services or full systems. Brute-force check can be performed either based on default lists (usually containing a large number of built-in and default accounts), dictionary lists or lists specifically provided by the administrators. These provided lists can contain a number of well known organization-specific passwords which should never be used (e.g. T3nableNe$$us).

Credentialed scanning

Mostly, vulnerability scanning is performed on periodic basis. In some cases it is performed as part of a penetration test where user accounts are provided upfront. In these cases the vulnerability analyst may choose to perform testing from a credentialed perspective. The benefits of such a test are that they are host based, cause less traffic can perform various configuration verifications and identify missing patches on a system.


Eventually, if a scanner is configured to do so, it may test if the vulnerability can be abused (exploited). Exploitation of vulnerabilities may potentially crash a service or even bring down an entire system. Therefore, if the desire for such tests is mentioned, these steps should always be taken with great precaution.
Irrespective of which approach is taken (if any) it will produce a (usually quite lengthy) report of all detected vulnerabilities which then requires follow up by an analyst to filter out potential false positives.

Host based vulnerability scanners

A network based vulnerability scanner can be blocked or limited in its functionality by a firewall. Therefore, one of the types of scanners to consider is a host based vulnerability scanner. The benefits of such scanners is that they do not generate much network traffic. Furthermore they have direct access to both the file system on a host and its configuration files and running services. Therefore, this may provide a more complete overview of vulnerabilities. Host based scanners come in various configurations, agent-less, agent-server and stand-alone.


In todays connected world, most network-based vulnerability scanners also have some form of host based scanner implemented. All they require is a credential to login remotely with the appropriate permissions (usually local administrator or root).


The second way of scanning hosts is the agent-server setup. With this solution, a small piece of software (the agent) is installed on the server. The agent then gathers all the facts locally and sends the results of a scan back to the central server. Nowdays, more vulnerability scanners take this approach as the hosts are becoming more secured and system administrators are less willing to let scan-tooling remotely access their machines.


As a last resort, if no outbound connections are allowed or possible, a stand alone scanner can be considered. A stand-alone scanner has to be installed on a specific system for executing the vulnerability analysis. The benefit of this setup is that it can be run on completely isolated systems as no network connection is required. The downside of these scanners is that using them may produce a lot more work since every host needs to have the scanner installed and executed and the results to be gathered afterwards. An example of a host based stand alone vulnerability scanner is the linux hardening scantool Lynis.

Database security scanners

Databases are usually considered to be the gems of the environment. They contain the data a hacker is after including lots of information about your company. Therefore including databases in a vulnerability scan would be a wise thing to do. Database vulnerability scanners usually test for bad security settings, missing patches and other known security risks. Also, when used in combination with the right credentials, a database vulnerability scanner can check for weak passwords. If no credentials are provided, a database vulnerability scanner can provide brute-force or dictionary based checking of passwords.

Source code vulnerability scanners

All software, whether its an application a database or an operating system is programmed in a certain language (source code) and then, if required, compiled in order to run. Since programs are all prone to vulnerabilities, this begins with the source code itself. While building an application, Integrated Design Environments provide numerous tools such as compilers which already check for programming errors. In addition to these tools, source code scanners can also check for some more logical errors in programming code. Examples of these scanners are tools such as Microsoft’s FXCop, HP’s Fortify Code analyser and Veracode’s VeraCode scanner.

There is a large variety of vulnerability scanners you can choose from. When making the selection, again a large number of considerations is to be taken care of. Should it be scanning just for open ports, known vulnerabilities, from an authorized or unauthorized perspective. Should it be scanning within your databases or should it verify source code security. Although most network vulnerability scanners nowadays combine a large number of these functionalities. Once you have chosen a product, it has to be setup and configured. With all the mentioned considerations and configuration options, this is more and more become an expertise that not many people have.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.