8 Frequently Asked Questions

8.1 Which Firewall Access Rules Are Necessary for the Communication Between the Greenbone Scan Cluster (GSC) and the VPN Gateway?

The gateway uses the following outgoing connections:

  • 443/TCP outgoing to GSC (45.135.106.140)

  • 443/TCP outgoing to Greenbone Cloud Service (217.72.202.36)

  • 443/TCP outgoing to update service (gpublic.azurecr.io)

If an external DNS server – like Google’s 8.8.8.8 – is configured, the ports 53/UDP and 53/TCP must be whitelisted.

8.2 Which Firewall Access Rules Are Necessary for the Communication Between the Greenbone Scan Cluster (GSC) and External Targets?

The Greenbone Scan Cluster (GSC) uses the IP address range 45.135.106.0/25 for scan traffic to external targets. The ports used are selected according to the port list configured when creating the target (see Chapters 6.2.1 and 6.9).

8.3 Which Technology Is Used for the VPN Connection?

An SSH Layer 2 based VPN is used for the VPN connection to the Greenbone Scan Cluster (GSC) (45.135.106.140) using 443/TCP.

8.4 What Has to Be Done if MAC-NAT Does Not Work?

With gateway version 1.5 or higher there are usually no problems.

If MAC-NAT does not work, the checkbox Use MAC-NAT has to be deselected when creating a gateway and the following settings have to be configured in VMware ESXi or Oracle VirtualBox:

In VMware ESXi:

  • Create a separate Port Group for the gateway and connect the gateway to it.

  • Change the settings Promiscuous mode and Forged transmits for the port group to Accept.

In Oracle VirtualBox:

  • In the network settings, open Advanced and change the setting Promiscuous Mode to Allow All.

8.5 What Happens to the User Account When the Subscription Ends?

When the subscription ends, the user can still log in and see all completed reports. The starting of new scans is no longer possible.

If the account is not used anymore, it is deleted after a certain time. The user will receive a notification beforehand.

8.6 Why is the Scanning Process so Slow?

The performance of a scan depends on various aspects. One possible reason is the time-consuming scanning of unused IP addresses.

To avoid this, a “Discovery” scan should be performed before the actual scan. This scan detects for each IP address whether it is active or not. Inactive IP addresses will not be scanned during the actual scan. Firewalls and other systems can prevent a successful detection.

Additionally, the duration of a scan is mostly determined by the network configuration and the amount of ports to be tested. For each port that is queried, the service behind it reacts at least with one log entry. Other criteria are the defense mechanisms that are activated by exhaustive port scans and initiate countermeasures or alerts. Even with normal scans, firewalls can simulate that all 65535 ports are active and as such slow down the actual scan with so called time-outs. In some situations with port throttling, scanning all TCP and UDP ports can take up to 24 hours or more for a single system. Since some countermeasures can increase the duration of a scan, throttling can be prevented by making configuration changes on the defense system. In suspected cases of a compromise or highest security breaches, a fully inclusive scan is unavoidable.

8.7 Why Do the Results for the Same Target Differ across Several Consecutive Scans?

The results of consecutive scans may differ due to the following reasons:

  • There was a loss of connection over unreliable network connections (between the scanner host and the target).

  • The network connection or equipment (between the scanner host and the target) was overloaded.

  • An overloaded target host and/or service stopped responding.

  • “Fragile” protocols (for example Remote Desktop Protocol) do not always respond as expected.

  • A previous probe/attacking request caused the service to not respond for a short period of time.

Although the scanner tries to reduce the occurrence of such situations by internal retry routines, they cannot be ruled out completely.

8.8 Why Does a VNC Dialog Appear on the Scanned Target System?

When testing port 5900 or configuring a VNC port, a window appears on the scanned target system asking the user to allow the connection. This was observed for UltraVNC Version 1.0.2.

Solution: exclude port 5900 or other configured VNC ports from the target specification. Alternatively, upgrading to a newer version of UltraVNC would help (UltraVNC 1.0.9.6.1 only uses balloons to inform users).

8.9 Why Does the Scan Trigger Alarms on Other Security Tools?

For many vulnerability tests, the behavior of real attacks is applied. Even though a real attack does not happen, some security tools will issue an alarm.

A known example is:

Symantec reports attacks regarding CVE-2009-3103 if the VT Microsoft Windows SMB2 ‘_Smb2ValidateProviderCallback()’ Remote Code Execution Vulnerability (1.3.6.1.4.1.25623.1.0.100283) is executed. This VT is only executed if VTs that may cause damage to the host system are enabled by the scan configuration. Otherwise the target system can be affected.