16. Performance

When operating the Greenbone Security Manager (GSM), a considerable amount of data can be transmitted by the target systems. The available scan results are also analyzed, filtered and processed by the GSM. On larger GSM types this occurs generally at the same time and by many users and processes.

This chapter covers the diverse questions regarding performance and discusses optimization options.

16.1. Scan Performance

The speed of a scan depends on many parameters. This section points out the most important settings and makes some recommendations.

16.1.1. Selecting a Port List for a Scan

Which port list is configured for a target and as such for the tasks and the scans has a large influence on the discovery performance and on the scan duration.

Evaluating those two aspects when planning the vulnerability scanning is required. Ports and Port Lists

Ports are the connection points of network communication. Each port of a system connects with the port on another system.

Every system has 65535 TCP ports and 65535 UDP ports. Additionally, there is the special port 0.

In a connection between two TCP ports data transmission occurs in both directions. For UDP ports data transmission only occurs in one direction. Due to the fact that data received by UDP are not necessarily confirmed, the testing of UDP ports usually takes longer.

Ports 0 to 1023 need to be highlighted as so called privileged or system ports and cannot be opened by user applications.

At the IANA (Internet Assigned Numbers Authority) standard protocol ports can be reserved which are then assigned a protocol name like port 80 for http or port 443 for https.

At IANA over 5000 ports are registered.

All ports of all systems of all internet accessible systems were analyzed and lists of the most used ports were created. Those do not necessarily reflect the IANA list because there is no obligation to register a specific service type for a respective port.

Typically, desktop systems have fewer ports open than servers. In general, active network components such as routers, printers and IP phones have only very few ports open: those they require for their actual task and for their maintenance.

The following port lists are predefined on the GSM:

  • All IANA assigned TCP 2012-02-10: All TCP ports assigned by IANA on 10th of February 2012
  • All IANA assigned TCP and UDP 2012-02-10: All TCP and UDP ports assigned by IANA on 10th of February 2012
  • All privileged TCP
  • All privileged TCP and UDP
  • All TCP
  • All TCP and Nmap 5.51 top 100 UDP: All TCP ports and the top 100 UDP ports according to Nmap 5.51
  • All TCP and Nmap 5.51 top 1000 UDP: All TCP ports and the top 1000 UDP ports according to Nmap 5.51
  • Nmap 5.51 top 2000 TCP and top 100 UDP: The top 2000 TCP ports and the top 100 UDP ports according to Nmap 5.51
  • OpenVAS Default: The TCP ports which are scanned by the OpenVAS scanner when passing the default port range preference Creating a new Port List

A new port list can be created as follows:

  1. Select Configuration > Port Lists in the menu bar.

  2. Create a new port list by clicking new.

  3. Define the port list (see figure Creating a new port list).


    Creating a new port list

  4. Click Create.

The following details of the port list can be defined:

Definition of the name. The name can be chosen freely.
An optional comment can contain additional information.
Port Ranges

Manual entry of the port ranges or importing of a list of the port ranges. When entering manually, the port ranges are separated by commas. When importing from a file, the entries can be separated with commas or line breaks. The file should use UTF-8 text encoding.

Each value in the list can be a single port (e.g. 7) or a port range (e.g. 9-11). These options can be mixed (e.g. 5, 7, 9-11, 13).

An entry in the list can be preceded by a protocol specifier (T: for TCP, U: for UDP), e.g. T:1-3, U:7, 9-11 (TCP ports 1, 2 and 3, UDP ports 7, 9, 10 and 11). If no specifier is given, TCP is assumed. Which Port List for which Scan Task

The choice of the port list always needs to be weighed up between discovery performance and scan duration.

The duration of a scan is mostly determined by the amount of ports to be tested and the network configuration. For example, starting with a certain amount of ports to be tested, throttling by the network elements or the tested systems could occur.

For the discovery performance it is obvious that services that are not bound to ports on the list, are not being tested for vulnerabilities. Additionally, malicious applications that are bound to such ports will not be discovered of course. The malicious application mostly open ports that are usually not being used and are far form the system ports.

Other criteria are the defence mechanisms that are being activated by often exhaustive port scans and initiate counter measures or alerts. Even with normal scans firewalls can simulate that all 65535 ports are active and as such slow down the actual scan of those ports that are being scanned for nothing, with so called time-outs.

Also to remember that for every port that is being queried the service behind it reacts at least with one log entry. For organizational reasons some services possibly should be scanned or at least at a specific time only.

The following table outlines which port list could be most meaningful for which task.

Task/Problem Port List
Initial Suspicion, Penetration Test, High Security, First scan of unknown systems in limited numbers
  • All TCP and All UDP
Background test of an environment with known or defined environment (servers) in large numbers or with high frequency
  • Specific List of Known Services
  • All IANA TCP
First scan of unknown systems in large numbers or with high frequency
  • All IANA TCP
  • Nmap Top 1000 TCP and Top 100 UDP

The final decision needs to be made by the person(s) responsible for the scans. There should be at least documentation of the targets or problem to justify the selection of the ports.

On the one hand one can play it safe, meaning always scan all ports, will not achieve the desired outcome because all systems simply can not be scanned in time or because it will interrupt business operations.

On the other hand super fast, meaning only scan all privileged ports, will seem inadequate for unknown systems with high security requirements if during a later incident a vulnerability is being discovered that was rather easy to be identified. Examples for this are database services.

Also to be remembered, some systems do not use a static port allocation rather than constantly changing them even during operation. This, of course, makes it more difficult for a specific port list. Scan Duration

In some situations with port throttling scanning all TCP and UDP ports can take 24 hours or more for a single system. Since the scans are being performed in parallel, two systems will of course only take marginally more time than a single system. However, the parallelizing has its limits due to system resources or network performance.

However, all IANA TCP ports do usually take no more than a couple of minutes.

Since some counter measures can increase the duration of a scan, there is the option to prevent throttling by making configuration changes on the defense system.

All in all at the end one will learn over time network ranges to be scanned and how they will react to scans and routine tasks can be optimized in that regard.

In suspected cases of a compromise or highest security breaches a fully inclusive scan is unavoidable. Total Security

For port scans the basic principle that no total security exists is also true. This means that even when All TCP and All UDP are being used the pre-set timeout of the port testing can be too short to coax a hidden malicious application into a response.

Or especially with a large amount of ports it comes directly down to defense through infrastructure. Less could sometimes even mean more.

If an initial suspicion exists an experienced penetration tester who combines the use of the actual scan tools with experience and professionally related intuition and has a good command of detailed parameterization should be consulted.

16.1.2. Scan Configuration

The scan configuration has an impact on the scan duration as well. The GSM offers four different scan configurations for vulnerability scans:

  • Full and fast
  • Full and fast ultimate
  • Full and very deep
  • Full and very deep ultimate

Both the Full and fast and Full and fast ultimate scan configurations optimize their process using already found information. This allows for the optimization of many NVTs and in doubt do not need to be tested. The two other scan configurations ignore already discovered information and therefore will execute all NVTs. This includes those NVTs as well that are not useful based on previously discovered information.

16.1.3. Tasks

During the progress of a scan a progress bar is being created. This progress bar should reflect the progress of the scan in percent. In most cases this is a rough estimate since it is difficult for the GSM to project how the systems or services that haven’t been scanned yet behave compared to the already scanned systems and services.

This can be understood best when looking at an example. Assumed is a network with 5 hosts: A scan is being configured for this network. The scan will be performed in sequence. Due to the fact that the IP addresses at the beginning of the network are not being used the scan will run very quickly and reaches 95%. Then however, systems are being discovered that use many services. The scan will slow down respectively and since all these services are being tested. The progress bar only jumps very little. To adjust for this behaviour in the scanner dialog the Order for target hosts can be adjusted. The setting Random makes sense.

16.2. Backend Performance

The web interface accesses the GSM utilizing the GMP protocol. Some operations require more time than others. To allow a speed analysis and examination of the GMP backend every web page displays the time required to prepare the data at the bottom of the web page.


The processing times of the backend are displayed.

16.3. Appliance Performance

The overall performance of the GSM can be monitored with the integrated monitoring by selecting Extras > Performance in the menu bar. Here the resource utilization of the GSM for the last hour, day, week, month and year can be displayed.

The performance of a configured sensor can be displayed on the master as well.


The processing times of the backend are being displayed.

Here the following points are important:

A high amount of processes is not critical. However, primarily only sleeping and running processes should be displayed.
System Load
An ongoing high utilization is critical. Hereby a load of 4 on a system with 4 cores is considered acceptable.
CPU Usage
Here especially a high Wait-IO is critical.
Memory Usage
The GSM uses aggressive caching. The usage of most of the memory as cache is okay.
A use of the Swap memory points to a potential system overload.