7. Scanning

This chapter covers the set up and execution of the actual scans of your systems for vulnerability management. The chapter describes basic first steps. Later sections show the more detailed use and configuration of scan configurations and the analysis of the results.

7.1. Simple Scan

This first section describes the first steps of the configuration of the first scan. Basically two options are available. The web interface of the GSM appliance, the Greenbone Security Assistant, provides a wizard that creates all required configurations for a first scan with only very little input. Alternatively these configurations can be created manually step by step. The following two sections cover both options. Ideally the individual steps should be followed directly on a GSM appliance.

gb_video These steps are also explained in a video at http://docs.greenbone.net/Videos/gos-3.1/en/GSM-FirstScan-GOS-3.1-en-20150716.mp4.

7.1.1. Wizard

When logging into the web interface of the GSM appliance for the first time after initial set up a wizard will be displayed immediately. By default, this will happen as long as less than four scan tasks were created. Afterwards the wizard can be started at any time by clicking the wizard icon.

To scan a system using the wizard directly it is enough to enter the IP address or system name. However, it is a requirement that the GSM appliance is able to resolve the system name.

_images/task-wizard.png

The task wizard simplifies the first steps

The task wizard then automatically performs the following steps:

  1. Creates a new scan target (Target) in the GSM.
  2. Creates a new scan task (Task) in the GSM.
  3. Starts the scan task immediately.
  4. Changes the view and reloads it every 30 seconds in order to monitor the progress of the task.

After the task is started the progress can be monitored. The Greenbone Security Assistant displays the overview page. The new task can be seen there as well.

_images/task-fortschritt.png

After the start the progress is being displayed.

The colours and the fill level of the status bar notifies about the status of the scan (see also section Starting a Task).

As soon as the scan is completed the column Severity notifies about the criticality of the vulnerabilities found. The prior column Solution Type solution_type shows the type of solution available. The most common type here is the VendorFix st_vendorfix.

_images/wizard-result.png

The results are already available before the scan is completed.

The task can be managed via the actions in the right column:

  • start Starting of a currently not running task.
  • stop Stopping of a currently running task. All discovered results will be written to the database.
  • resume Resuming of a stopped task.
  • trashcan Moving of a task to the trashcan.
  • edit Editing of a task.
  • clone Cloning of a task.
  • download Exporting of a task as xml object. The object can be imported again on another GSM.
_images/report-darstellung.png

A report can be displayed in different ways.

Even before the scan is completed the results can be viewed (see figure The results are already available before the scan is completed.). With the mouse simply click on the progress bar. The now displayed results are not complete yet of course. The progress can be continued to be monitored at the top right via the progress bar. This page, however, is not reloaded automatically.

In order to obtain different representations of the results, you can move the mouse over the title bar. It opens a pull-down menu where you can choose different representation formats.

_images/report-format.png

Furthermore a report can be downloaded in various different formats.

Furthermore the report can be exported in various different formats as well. The export formats are selected in the title bar as well. Afterwards the report can be downloaded by clicking the download button. Reports and report formats are discussed in more detail in section Reports.

7.1.2. Advanced Wizard

Next to the simple wizard the GSM also provides an advanced wizard that allows for more configuration options. This wizard allows for shortcutting the manual configuration of the individual parameters and still allows for a more granular configuration.

_images/advwizard.png

The advanced wizard offers more options.

This wizard can be started by clicking on the wizard icon wizard in the context menu. Here a wizard can be executed that allows for the modification of a task (Modify Task Wizard).

_images/iconadvwizard.png

The wizard context menu allows the execution.

7.1.3. Manual Configuration

The upcoming section covers the creation of a simple scan with its individual steps that the wizard performs as well. You can chose your own names that make sense for the scan targets (Targets) and the scan task (Task).

gb_video These steps are also explained in a video at http://docs.greenbone.net/Videos/gos-3.1/en/GSM-FirstScan-GOS-3.1-en-20150716.mp4.

7.1.3.1. Creating a Target

The first step is to define a scan target. This is called Target by the Greenbone Security Assistant.

First chose one or more systems in your network you want to scan. The IP address or DNS name is required. In both cases it is necessary that the GSM can reach the system. When using the DNS name the GSM appliance must be able to resolve the name.

_images/configuration-3.png

Selecting the targets.

_images/newtarget.png

Creating a new target.

Choose Targets from the menu Configuration. Select the New Target icon (the white star on blue background: new). This icon can be found in many places. It always stands for the creation of a new object within its respective context.

_images/newtarget2-31.png

Enter the details for the target.

A new window, in which the target can be configured in more detail, will open.

Enter the following information:

  • Name The name can be freely chosen. A very descriptive name should be chosen if possible. Possibilities are Mailserver, ClientNetwork, Webserverfarm, DMZ or the like, describing the entered systems in more detail.

  • Comment

    The optional comment allows to specify background information. It simplifies understanding the configured targets later.

  • Hosts

    Manual entry of the system or importing of a list of systems. When entering manually the following options are available:

    • Single IP address, i.e. 192.168.15.5
    • System name, i.e. mail.example.com
    • IPv4 address range, i.e. 192.168.15.5-192.168.15.27 or 192.168.55.5-27
    • IPv4 network in CIDR notation, i.e. 192.168.15.0/24 [1]
    • Single IPv6 address
    • IPv6 address range in long format, i.e. ::12:fe5:fb50-::12:fe6:100
    • IPv6 address range in short format, i.e. ::13:fe5:fb50-fb80
    • IPv6 address range in CIDR notation, i.e. fe80::222:64ff:fe76:4cea/120
    • multiple entries can be entered separated with commas

    When importing from a file the same syntax can be used. The entries can be stored in the file on multiple lines. When using long lists of systems to be scanned this way is usually the simpler one.

  • Exclude Hosts

    Systems that should be excluded from the lists mentioned above.

  • Reverse Lookup Only

    Only scan IP addresses that can be resolved into a DNS name.

  • Reverse Lookup Unify

    Should the reverse lookups get unified. If multiple IP addresses resolve to the same DNS name the DNS name will only get scanned once.

  • Port list

    The TCP and UDP protocols support 65535 ports respectively. Scanning all ports in many cases takes too long. Many ports are normally not being used. A manufacturer developing a new application often reserves the respective port with the IANA. For most scans it is often enough to scan the ports registered with the IANA. The registered ports differentiate from the privileged ports. Privileged ports are ports smaller than 1024 [2]. At the IANA, for example, ports 1433/tcp (MS-SQL) and 3306/tcp (MySQL) are also included in the list. Nmap uses a different list also and doesn’t check all ports either. OpenVAS uses a different default as well.

    The scan of TCP ports can be performed simply and fast. Operating system always reply to a TCP request and as such advertise a port as being open (TCP-ACK) or closed (TCP-RST). With UDP this is not the case. The operating system only responds reliably when the port is closed (ICMP-Port-Unreachable). An open port is deducted by the scanner by a missing response. This is why the scanner has to wait for an internal timeout. This behaviour is only true for systems not protected by a firewall. When a firewall exists the discovery of open or closed ports is much more difficult.

    If applications run on unusual ports and they should be monitored and tested with the GSM, the default port lists should be verified under Configuration submenu Port Lists. If necessary create your own list that includes your port. The default port lists can not be modified.

  • Alive Test

    Should the scan check if a target (Targets) is reachable. Options are:

    • ICMP Ping
    • TCP Service Ping
    • ARP Ping
    • ICMP & TCP Service Ping
    • ICMP & ARP Ping
    • TCP Service & ARP Ping
    • ICMP, TCP Service & ARP Ping

In the real world there are problems with this test from time to time. In some environments routers and firewall systems respond to a TCP Service Ping with a TCP-RST even though the host is actually not alive (see also Obstacles while Scanning).

Network components also exist that support a Proxy-ARP and respond to an ARP-Ping. This is why this test requires local customization to your environment.

  • SSH Credential

    Selection of a user that can log into the target system of a scan if it is a Linux or UNIX system. This allows for an Authorized Scan (see section Authenticated Scan).

  • SMB Credential

    Selection of a user that can log into the target system of a scan if it is a Microsoft Windows system. This allows for an Authorized Scan (see section Authenticated Scan).

  • ESXi Credential

    Selection of a user that can log into the target system of a scan if it is a VMWare ESXi system. This allows for an Authorized Scan (see section Authenticated Scan).

7.1.3.2. Creating a Task

The GSM controls the execution of a scan as Tasks. These tasks can be repeated regularly or run at specific times. The control is discussed in more detail in section Scheduled Scan. For now the basic creation of a task is covered in this section.

_images/newtask-3.png

Creation of tasks.

To access the tasks select menu option Scan Management from the menu bar. From there select the Tasks. On the following page select the white star new on blue background to create a new task. A web page opens on which you can configure the additional options of the task.

_images/task-31.png

Creation of a new task.

The following information can be entered:

  • Name

    The name can be chosen freely. A descriptive name should be used if possible. Possibilities to describe the entered task are Scan Mailserver, Test ClientNetwork, Check DMZ for new ports and systems or the like.

  • Comment

    The optional comment allows for the entry of background information. It simplifies understanding the configured task later.

  • Scan Targets

    Select a previously configured Target from the drop down menu.

  • Alerts

    Select a previously configured Alert. Status changes of a task can be communicated to the world via email, Syslog, HTTP or a connector.

  • Schedule

    Select a previously configured Schedule. The task can be run once or repeatedly at a predetermined time. It is possible to scan the network every Monday morning at 6:00 am for example.

  • Add results to Asset Management

    Selecting this option will make the systems available to the Asset Management of the GSM automatically (see chapter Asset Management). This selection can be changed at a later point as well.

  • Alterable Task

    Allow for modification of the task even though reports were already created. The consistency between reports can no longer be guaranteed if tasks are altered.

  • Auto Delete Reports

    This option may automatically delete old reports. The maximum number of reports to store can be configured. If the maximum is violated the oldest report is automatically deleted. The factory setting is Do not automaticall delete reports.

  • Scanner

    • OpenVAS Scanner

      By default only the OpenVAS scanning engine is supported. Additional scanning engines are the Palo Alto and W3AF scanning engines.

    • Scan Config

      The GSM comes by default with seven pre-configured scan configurations.

      • Discovery

        Only NVTs are used that provide the most possible information of the target system. No vulnerabilities are being detected.

      • Host Discovery

        Only NVTs are used that discover target systems. This scan only reports the list of systems discovered.

      • System Discovery

        Only NVTs are used that discover target systems including installed operating systems and hardware in use.

      • Full and Fast

        This is the default and for many environments the best option to start with. This configuration is based on the information gathered in the prior port scan and uses almost all NVTs. Only NVTs are used that will not damage the target system. Plugins are optimized in the best possible way to keep the potential false negative rate especially low. The other configurations only provide more value only in rare cases but with much more required effort.

      • Full and fast ultimate

        This configuration expands the first configuration with NVTs that could disrupt services or systems or even cause shut downs.

      • Full and very deep

        This configuration differs from the Full and Fast configuration in the results of the port scan not having an impact on the selection of the NVTs. Therefore NVTs will be used that will have to wait for a timeout. This scan is very slow.

      • Full and very deep ultimate

        This configuration adds the dangerous NVTs that could cause possible service or system disruptions to the Full and very deep configuration.

    • Slave

      Selection of a previously created slave that will be used by the performing scan. The scan can be delegated to another system which has better access to the target system.

    • Network Source Interface

      Here you can choose the source interface for the scan.

    • Order for target hosts

      Select how the specified network area should be searched. Options available are:

      • Sequential
      • Random
      • Reverse

      This is interesting if for example a network, i.e. 192.168.0.0/24, is being scanned that has lots of systems at the beginning or end of the IP address range. With the selection of the Random mode the progress view is more meaningful.

    • Scan Intensity

      Select the speed of the scan. The default values are chosen sensibly. If more NVTs run simultaneously on a system or more systems are scanned at the same time, there is the danger that a scan has a negative impact on the performance of the systems or network. These values maxhosts and maxchecks may be tweaked.

7.1.3.3. Permissions

Once the task is saved it will be displayed next (see figure A newly created task.).

_images/neuer-task.png

A new task after it is created.

When scrolling the window further down the permissions for the task can be managed.

_images/create-observer-task.png

Read permissions can be managed directly in the task.

Note

By default normal users can not create permissions for other users as they do not have read permission to the user database. To do this a user must specifically have the get_users permission. It makes most sense to create an additional role (see section GetUsers Role for Observers).

Select User, Group or Role respectively and enter the respective name. After clicking on new the permissions are entered.

This is now displayed in the task overview.

_images/create-observer-task.png

The read permissions of a task are displayed in the overview.

After logging in the user can see those tasks and can access the respective reports.

This is now displayed in the task overview.

_images/task-uebersicht.png

After logging in the observer can view the tasks but cannot change them.

7.1.3.4. Starting a Task

Once a task is saved it will be displayed next (see figure A newly created task.).

_images/neuer-task.png

A newly created task.

The task can be managed via the action icons in the title bar:

  • start Starting of a currently not running task.
  • stop Stopping of a currently running task. All discovered results will be written to the database.
  • resume Resuming of a stopped task.
  • trashcan Moving of a task to the trashcan.
  • edit Editing of a task.
  • clone Cloning of a task.
  • download Exporting of a task as xml object. The object can be imported again on another GSM.

Alternatively starting a task can be performed via the overview page that can be accessed by selecting Scan Management and then Tasks (see figure The control of the task is performed in the right column of the overview.).

_images/task-uebersicht.png

The control of the task is performed in the right column of the overview.

The status bar shows information about the status of a scan. The following colours and states are possible:

  • status-new The task has not been run since it was created.
  • status-run The task is currently running and 42% completed. The information is based on the number of NVTs executed on the selected hosts. For this reason the information does not necessarily correlate with the time spent.
  • status-requested The task was just started. The GSM is preparing the scan.
  • status-delete The task was deleted. The actual deletion process can take some time as reports need to be deleted as well.
  • status-stopr The task was stopped recently. However, the scan engine has not reacted respectively yet.
  • status-stop The last scan was stopped by the user at 15%. The latest report is possibly not yet complete. Other reasons for this status could be the reboot of the GSM or a power outage. After restarting the scanner the task will be resumed automatically.
  • status-error An error has occurred. The latest report is possibly not yet complete or is missing completely.
  • status-done The task has been completed successfully.
  • status-container The task is a container task.

7.1.3.5. Container Task

A Container Task can be used to import and provide reports created on other GSMs. When creating the Container Task the first report needs to be imported right away. Afterwards additional reports can be imported and, like in this example, be compared with a delta report as well.

_images/container-task.png

Container tasks are used to import external reports.

The reports need to be in the GSM xml report format.

7.2. Reports

The results of a scan are summarized in a report. Reports can be viewed with a browser and downloaded from the GSM in different formats. Once a scan has been started the report of the results found so far, can be viewed. Once a scan is complete its status changed to Done. From now on no additional results will get added. For more information on reports please refer to the Reports chapter as well.

_images/reportsummary-3.png

The report summary gives an overview over vulnerabilities found.

The report summary gives a quick overview over the current state. It shows if a scan is complete and how many vulnerabilities have already been found. From the summery a report can be downloaded directly in many different formats. The following formats are supported (see also section Report Plugins)

ARF: Asset Reporting Format v1.0.0
This format creates a report that represents the NIST Asset Reporting Format.
CPE - Common Enumeration CSV Table
This report selects all CPE tables and creates a single comma separated file.
CSV hosts
This report creates a comma separated file containing the systems discovered.
CSV Results
This report creates a comma separated file with the results of a scan.
GSR PDF - Greenbone Security Report (recommended)
This is the complete Greenbone Security report with all vulnerabilities.
GXR PDF - Greenbone Executive Report (recommended)
This is a shortened report for management.
HTML
This report is in HTML format.
ITG - IT-Grundschutz catalogue
This report is guided by the BSI IT-Grundschutz catalogue.
LaTeX
This report is offered as LaTeX source text.
NBE
This is the old OpenVAS/Nessus report format.

Details of a report can be viewed in the web UI as well.

_images/report-darstellung.png

Different views of the same report.

Since a report often contains a lot of findings, the complete report as well as only filtered results can be viewed and downloaded. In the default setting only the High and Medium risks are being displayed. This can be changed very easily.

_images/reportfilter.png

Report Filtering.

In the Filtered Results section shows the filtered results. As long as the scan is still running can cause rearrangements here.

To interpret the results please note the following information:

  • False Positives false_positives

    A false positive is a finding that describes a problem that does not exists in reality. Vulnerability scanners often find evidence that point at a vulnerability. However, a final judgment cannot be made. There are two options available:

    • Reporting of a potentially nonexistent vulnerability (False Positive).
    • Ignoring reporting of a potentially existing vulnerability (False Negative).

    Since a user can identify, manage and as such deal with false positives compared to false negatives, the GSM Vulnerability Scanner reports all potentially existing vulnerabilities. The GSM assists with several automatic and semi-automatic to categorize them.

    This problem is very common with Enterprise Linux distributions. If, for example, a SSH service in version 4.4 is installed and the software reports this version during a connection attempt, a vulnerability scanner, that knows of a vulnerability in this version, will report this as such. The vendor potentially already addressed the vulnerability and released version 4.4-p1 that is already installed. This version still reports to the outside version 4.4 so that the vulnerability scanner cannot differentiate. If the user knows of this circumstance an Override can be configured (see section Overrides and False Positives). The AutoFP function (see section Automatic False Positives) can assist here as well.

Note

Consider the new concept of Quality of Detection (see sections Reading of the Reports and Network Vulnerability Tests).

  • Multiple findings can have the same cause. Is an especially old software package installed often multiple vulnerabilities exist. Each of these vulnerabilities is tested by an individual NVT and causes an alert. The installation of a current package will then remove a lot of vulnerabilities at once.
  • Important are findings of the levels High high and Medium medium. Address these findings in order of priority. Before addressing medium level findings, high level findings should get addressed. Only in exceptional cases, when it is known that the high alerts need to be less considered (because the service cannot be reached through the firewall) should this approach be deviated from.
  • Low low and Log log are mostly interesting for detail understanding. This is why these findings are filtered out by default. These findings can hold very interesting information however and considering them will increase the security of your network and systems. For their understanding often a deeper knowledge of the applications is required. Typical for an alert at the log level is that a service uses a banner with its name and version number. This could be useful for an attacker during an attack if this version has a known vulnerability.
  • To simplify the remediation of vulnerabilities every alert offers a solution for problems directly. In most cases it will be referred to the latest vendor software package. In some cases a configuration change will be mentioned.
  • References explain the vulnerabilities further. Even though the alerts contain a lot of information external references are always listed. These refer to web sites on which the vulnerability was already discussed. Additional background information is available such as who discovered the vulnerability, what effects it could have and how the vulnerability can be remediated.

7.2.1. Reading of the Reports

The report contains a list of all of the vulnerabilities detected by the GSM (see figure List of discovered vulnerabilities)

_images/reportvuln.png

List of discovered vulnerabilities

To support the administrator with the analysis of the results the severity of a vulnerability (CVSS, see also section CVSS)is displayed directly as a bar.

To point the administrator to a simple solution the column Solution-Type solution_type displays the existence of a solution. The column will display if a vendor patch st_vendorfix exists or a workaround st_workaround is available. It will also be displayed if no solution for a vulnerability exists st_nonavailable. If the column of the respective vulnerability still appears empty then the respective NVT has not been updated yet.

The column Quality of Detection (QoD) provides information in regards to the reliability of the successful detection of a vulnerability. This assessment is implemented into all existing NVTs step by step (see section Network Vulnerability Tests). This column allows to be filtered as well. You can use the min_qod in the Powerfilter. By default only NVTs with a QoD of 70% are displayed. Vulnerabilities with a lower reliability of detection are not displayed in the report. The possibility of false positives is thereby lower.

In the respective vulnerability view, additional, more detailed information is available.

_images/php.png

Detailed information about the vulnerability and solution options.

7.3. Results

While the reports only contain the results of one single run of a task all results are saved in the internal database and can be viewed using Scan Managment/Results.

_images/allresults.png

By default the view is sorted by the creation time of the results. But the results may be sorted by severity, QoD, solution type or host as well. Additionally powerfilters (see section Powerfilter) may be used to view just the interesting results.

7.4. Authenticated Scan

An authenticated scan logs into a target system in order to test it. The scan uses credentials the scan user has saved on the GSM previously. These credentials are used to authenticate with different services on the target system. In some circumstances the results could be limited by the permissions of the users used.

A scan is minimally invasive. It means that the GSM only determines the risk level but does not make any changes on the target system. However the log in by the GSM is being logged in the protocols of the target system.

The GSM can use the credentials for different services. However, the most important ones are:

  • SMB

    On Windows systems the GSM can check the patch level and locally installed software such as Adobe Acrobat Reader or the Java suite.

  • SSH

    This access is used to check the patch level on UNIX and Linux systems.

  • ESXi

    This access is used for testing of VMWare ESXi servers locally.

The extent and success of the testing routines for authenticated scans depends on the heavily on the permissions of the account used for access. Especially on Windows systems unprivileged users are very restricted.

To create credentials access the submenu Credentials from the Configuration menu. The following information can be entered:

_images/credentials.png

SSH keys can be utilized with credentials as well.

  • Name

    An arbitrary name for the credentials.

  • Login

    The log in name with which the GSM authenticates on the system that is to be scanned.

  • Comment

    A freely selectable comment.

  • Autogenerate Credentials

    The GSM itself is creating a random password.

  • Password

    The password can be entered.

  • Key Pair

    If authentication is performed via SSH the private keys can be uploaded. Additionally an optional passphrase of the private key can be entered.

7.4.1. Requirements on Target Systems with Windows

7.4.1.1. General notes on configuration

  • The remote registry service must be started in order to access the registry

    You can achieve this by configuring the service to automatically start up. If you do not prefer the automatic start, you could configure manual start up. In that case the service will be started while the system is scanned by GSM and afterwards it will be disabled again. To ensure this behaviour the following item about LocalAccountTokenFilterPolicy must be considered.

  • It is necessary that for all scanned systems the file and printer sharing is activated. When using Windows XP, take care to disable the setting “Use Simple File Sharing”.

  • For individual systems not attached to a domain the following registry key must be set:

    HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\DWORD:
    LocalAccountTokenFilterPolicy = 1
    
  • On systems with domain controller the user account in use must be a member of the group Domain Administrators to achieve the best possible results. Due to the permission concept it is not possible to discover all vulnerabilities using the Local Administrator or the administrators assigned by the domain. Alternatively follow the instructions below under Configuring a domain account for authenticated scans.

  • Should a Local Administrator be selected – which we explicitly do not recommend – it is mandatory to set the following registry key as well:

    HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\DWORD:
    LocalAccountTokenFilterPolicy = 1
    
  • Generated install package for credentials: The installer sets the Remote Registry service to auto start. If the installer is executed on a Domain Controller the user account will be assigned to the Group BUILTIN/Administrators (SID S-1-5-32-544).

  • An exception rule for the GSM on the Windows firewall must be created. Additionally on XP systems the File and Printer Sharing must be set to enabled.

  • Generated install package for credentials: During the installation the installer offers a dialog to enter the IP address of the GSM. If the entry is confirmed the firewall rule is configured. The File and Printer Sharing service will be enabled in the firewall rules.

7.4.1.2. Configuring a domain account for authenticated scans

In order to use a domain account for host based remote audits on a windows target this must be performed under Windows XP Professional, Windows Vista, Windows 2003, Windows 2008, Windows 2012 Windows 7, Windows 8 or Windows 8.1 and also be part of a domain.

Taking security into consideration the following eight steps should be implemented to create these scans.

7.4.1.2.1. Step 1: Create a security group

First create a security group called Greenbone Local Scan:

  • Log into a domain controller and open Active Directory Users and Computers.
  • Now create the security group in the menu. Select Action > New > Group.
  • Call the group Greenbone Local Scan. It is important that the Global is selected for the Group Scope and Security as the Group Type.
  • Add the account, that is being used for the local authenticated scans under Windows by the Greenbone Appliance, to the group Greenbone Local Scan.
7.4.1.2.2. Step 2: Create a Group Policy

Now create a group policy with called Greenbone Local SecRights.

  • Open the Group Policy Management console.

  • Right click on Group Policy Objects and select New.

  • Enter Greenbone Local SecRights as the name of the policy.

    _images/win_group_policy.png

    A new Windows Group Policy Object for Greenbone scans.

7.4.1.2.3. Step 3: Configuration of the Policy

Add the group Greenbone Local Scan to the Greenbone Local SecRIghts policy and insert local administrators to the groups.

Please note that this setting still exists after the GPO has been removed (Tattooing GPO).

  • Click on the policy Greenbone Local SecRights and select Edit.

  • Open:

    Computer Configuration\Policies\Windows Settings\
    Security Settings\Restricted Groups
    
  • In the left pane right click on Restricted Groups and select Add Group

  • Now select Browse in the Add Group dialog, enter Greenbone Local Scan, afterwards click Check Names.

    _images/win_group_policy_check.png

    Check Windows Group Name.

  • Click OK twice to close the opened dialog.

  • Under This group is member of: click on Add.

  • Add the group Administrators. Additionally on non-English systems enter the respective name of the local administrator group.

    _images/win_group_policy_member.png

    Add Group Membership.

    _images/win_group_policy_member2.png

    Add another Group Membership.

  • Click OK twice.

Step 4: Configuration of the policy, to deny local log on systems of the Greenbone Local Scan group

Add the Greenbone Local Scan to the Greenbone Local SecRights group and deny the local log in of group members.

  • Click on the Greenbone Local SecRights and then select Edit.

  • Open:

    Computer Configuration\Policies\Windows Settings\Security Settings\
    Local Policies\User Rights Assignment
    
  • In the right pane double click on Deny log on locally

  • Set the checkmark in Define these policy settings:

  • Click on Add User or Group

  • Now select Browse, enter Greenbone Local Scan and then click on Check Names.

    _images/win_group_policy_deny.png

    Edit the policy for local log on.

  • Now click twice on OK to close the opened dialog.

  • Click OK.

Step 5: Configure the policy to deny the group Greenbone Local Scan logging into systems remotely

Add the Greenbone Local Scan to the Greenbone Local SecRights group and deny group members logging in via RDP.

  • Click the policy Greenbone Local SecRights and then select Edit.

  • Open:

    Computer Configuration\Polices\Windows Settings\Security Settings\
    Local Policies\User Rights Assignment
    
  • In the right pane double click on Deny log on through Remote Desktop Services.

  • Set the checkmark in Define these policy settings:

  • Click on Add User or Group

  • Now select Browse in the dialog, enter Greenbone Local Scan, then click on Check Names.

    _images/win_group_policy_deny2.png

    Edit Policy for remote log in.

  • Now click twice on OK to close the opened dialog.

  • Click OK.

Step 6 (Optional): Configure the policy to give only read permissions to the local drive for the Greenbone Local Scan group.

Restrict the permissions to the system drive in the Greenbone Local SecRights policy for the Greenbone Local Scan group. Please note that this setting still exists after the GPO has been removed (Tattooing GPO).

  • Click on the Greenbone Local Sec Rights policy and then select Edit.

  • Open:

    Computer Configuration\Polices\Windows Settings\Security Settings\File Systems
    
  • In the left pane right click on File System and select Add File….

  • In the Folder field enter: %SystemDrive% and click OK.

    _images/win_group_policy_read.png

    Specifying the %SystemDrive% folder.

  • Click on Add under Group or user names:

  • In the dialog that opens enter Greenbone Local Scan and click OK.

    _images/win_group_policy_read2.png

    Select the Greenbone Local Scan group.

  • Now select the user Greenbone Local Scan.

  • Deactivate all checkmarks under Allow and activate the checkmarks under Deny > Write.

    _images/win_group_policy_read3.png

    Deny Write access to the group.

  • Afterwards click on OK and confirm the warning message with Yes.

  • Now select Configure this file or folder then and Propagate inheritable permissions to all subfolders and files and then click on OK.

    _images/win_group_policy_read4.png

    Make the permissions recursive.

_images/win_group_policy_read4-de.png

Policy for read permissions on the system drive.

Step 7 (Optional): Configure the policy to give only read permissions to the registry for the Greenbone Local Scan group.

To achieve complete restriction is very difficult and possible with a lot of effort. If necessary critical branches can be secured additionally by adding the branches manually.

Please note that this setting still exists after the GPO has been removed (Tattooing GPO).

  • In the left pane right click Registry and select Add Key.

  • Select Users and click OK

    _images/win_group_policy_reg.png

    Select the USERS registry key.

  • Click on Advanced and then Add.

  • Enter Greenbone Local Scan in the dialog that opens and click on OK.

    _images/win_group_policy_reg2.png

    Select the Greenbone Local Scan group.

  • In the following dialog select for Apply to: This object and child objects

  • Under Permissions select Deny for Set Value, Create Subkey, Create Link, Delete, Change Permissions and Take Ownership.

    _images/win_group_policy_reg3.png

    Disallow edition of the registry.

  • Do not select anything under Allow!

  • Afterwards click OK twice and confirm the warning message with Yes.

  • Click OK again.

  • Now select Configure this key then and Propagate inheritable permissions to all subkeys and then click OK.

    _images/win_group_policy_reg4.png

    Propagate the new settings recursively.

  • Repeat the above mentioned steps also for MACHINE and CLASSES_ROOT by clicking on Registry in the right pane and then select Add key....

7.4.1.2.4. Step 8 (Optional): Linking of the Group Policy Object
  • On the right pane in the Group Policy Management console right click on the domain or Organizational Unit Link an Existing GPO and select Link an Existing GPO….

  • Now select the group policy object Greenbone Local SecRights.

    _images/win_group_policy_link.png

    Linking the policy.

7.4.1.2.5. Restrictions

Based on the fact that write permissions to the registry and system drive have been removed, the following two tests will no longer work:

  • Leave information on scanned Windows hosts OID 1.3.6.1.4.1.25623.1.0.96171

    This test, if desired, creates information about the start and end of a scan under HKLMSoftwareVulScanInfo. Due to denying write access to HKLM this is no longer possible. If you continue to desire this the GPO must be adjusted here respectively.

  • Windows file Checksums OID 1.3.6.1.4.1.25623.1.0.96180

    This test, if desired, when executed saves the tool ReHash under C:\Windows\system32 (for 32-bit systems) or c:\Windows\SysWOW64 (for 64-bit systems). Due to denying write access this is no longer possible. The tool must be saved separately or the GPO must be adjusted respectively.

    More information can be found in section File Checksums.

7.4.1.3. Scanning without domain admin and local admin permissions

Theoretically it is possible to build a GPO in which the user also does not have any local admin permissions. But the effort to add respective read permissions to each registry branch and folder as well, is enormous. Unfortunately inheriting of permissions is deactivated for many folders and branches. Additionally these changes can be set by GPO but cannot be removed again (Tattooing GPO). Also specific permissions could possibly be overwritten so that additional problems could occur.

To go this route does not make a lot of sense from a technical and administrative perspective.

7.4.2. Requirements on Target Systems with Linux/UNIX

  • For authenticated scans on Linux or UNIX systems regular user access is usually enough. The log in is performed via SSH. The authentication is done wither with passwords or an SSH key stored on the GSM.
  • Generated install package for credentials: The install package for Linux Debian or Linux RedHat is a .deb or a .rpm respectively, creating a new user without any specific permissions. A SSH Key that is created on the GSM is stored in the users home folder. For users of other Linux distributions or UNIX derivatives the key is offered for download. The creation of a user and saving the key with the proper file permissions is the responsibility of the user.
  • In both cases it needs to be made sure that Public Key authentication is not prohibited by the SSH daemon. The line PubkeyAuthentication no can not be present.
  • Already existing SSH keys protected by an optional passphrase can be used as well. It is recommended to use the RSA and DSA formats as created by the command ssh-keygen.
  • For scans that include policy testing root permission or the membership in specific groups (often wheel) might be necessary. For security reasons many configuration files are only readable by super user or members of specific groups.

7.4.3. Requirements on Target Systems with ESXi

By default, local ESXi users are limited to read-only roles. Either an administrative account or a read-only role with permission to global settings must be used.

The following steps will guide you through the process.

Start the Vsphere client.

_images/vsphere1.png

The vsphere client offers access to the roles.

On the Home screen click Roles.

_images/vsphere2.png

The roles are displayed.

Select the Role ReadOnly by right-clicking with the mouse. Clone the role. The list will now contain the Clone as well.

_images/vsphere3.png

The clone is added.

Rename the cloned role appropiately. In this case Greenbone Scan Role is used.

_images/vsphere4.png

The clone may be renamed.

Now modify the new role by right-clicking the role again with the mouse

_images/vsphere5.png

Modify the new Greenbone role.

Add the privilege Global > Settings to the role.

_images/vsphere6.png

Add Global>Settings to the role.

Finally assign the new role to the the scan user account used by the GSM. Choose the appropiate user from the list of local users and groups.

_images/vsphere7.png

Access the list of local users.

Go to the permissions tab and click the empty space. Choose Add Permission.

_images/vsphere8.png

Add a permission on the privileges tab.

Select the created role in the right column. Add the appropiate user in the left column and apply the change using the OK Button.

_images/vsphere9.png

Assign the role to the user.

7.4.4. Requirements on Target Systems with Cisco OS

The GSM may check network components like routers and switches for vulnerabilities as well. While the usual network services are discovered and checked via the network some vulnerabilities may only be discovered by an authenticated Scan. For the authenticated scan the GSM may use either SNMP or SSH. This section will cover both approaches.

7.4.4.1. SNMP

The GSM may use the SNMP protocol to access the Cisco network component. The GSM support SNMPv1, v2c and v3. SNMP uses the port 161/udp. The default port list does not include any UDP port. Therefore this port is ignored during the vulnerability test using Full and Fast and no SNMP check is enabled. To scan network components the port list should be modified to include at least the following ports:

  • 22/tcp SSH
  • 80/tcp 8080/tcp HTTP
  • 443/tcp 8443/tcp HTTPS
  • 2000/tcp SCCP
  • 2443/tcp SCCPS
  • 5060/tcp 5060/udp SIP
  • 5061/tcp 5061/udp SIPS
  • 67/udp DHCP Server
  • 69/udp TFTP
  • 123/udp NTP
  • 161/udp SNMP
  • 162/udp SNMP Traps
  • 500/udp IKE
  • 514/udp Syslog
  • 546/udp DHCPv6
  • 6161/udp 6162/udp Unified CM

The admin might want to setup special port list to be used just for such network components.

The GSM needs to access only very few objects from the SNMP tree. For least privilege access a SNMP view should be used to constrain the visibility of the SNMP tree for the GSM. The following two examples explain how to setup the view using either a community string or a SNMPv3 user.

To use a SNMP community string the following commands are required on the target:

# configure terminal

Using an access list the usage of the community may be restricted. The IP address of the GSM is 192.168.222.74 in this example:

(config) # access-list 99 permit 192.168.222.74

The view gsm should only allow accessing the system description:

(config) # snmp-server view gsm system included
(config) # snmp-server view gsm system.9 excluded

The last command links the community gsm-community with the view gsm and the access-list 99:

(config) # snmp-server community gsm-community view gsm RO 99

When using a SNMPv3 user including encryption the following configuration lines are required on the target:

# configure terminal
(config) # access-list 99 permit 192.168.222.74
(config) # snmp-server view gsm system included
(config) # snmp-server view gsm system.9 excluded

SNMPv3 requires the setup of a group first. Here the group gsmgroup is linked to the view gsm and the access-list 99:

(config) # snmp-server group gsmgroup v3 priv read gsm access 99

Now the user may be created supplying the password gsm-password and the encryption key gsm-encrypt. The authentication is done using md5 while the encryption is handled by AES128:

(config) # snmp-server user gsm-user gsm-group v3 auth md5 gsm-password priv aes 128 gsm-encrypt

To configure either the community or the SNMPv3 user in the GSM the admin needs to clone the scan configuration Full and Fast first. Then the SNMP parameters may be changed. They may be found at the bottom of the scan configuration.

_images/gsm-snmp.png

Setting the SNMP credentials.

7.4.4.2. SSH

The authenticated scan may be performed via SSH as well. When using SSH the usage of a special unprivileged user is recommended. The GSM currently only requires the command show version to retrieve the current version of the firmware of the device.

To setup a least privilege user which is only able to run this command several approaches are possible. The following example uses the Role-Based-Access-Control feature.

Tip

Before using the following example, make sure you understand all side effects of the configuration. If used without verification the system may restrict further logins via SSH or Console.

To use role based access control AAA and views have to be enabled:

> enable
# configure terminal
(config)# aaa new-model
(config)# exit
> enable view
# configure terminal

The following lines create a restricted view including just the command show version. The supplied password view-pw is not critical:

(config)# parser view gsm-view
(config-view)# secret 0 view-pw
(config-view)# commands exec include show version
(config-view)# exit

Now the user gsm-user with the password gsm-pw is created and linked to the view gsm-view:

(config)# username gsm-user view gsm-view password 0 gsm-pw
(config)# aaa authorization console
(config)# aaa authorization exec default local

If SSH is not yet enabled the following lines take care of that. Use the approriate hostname and domain:

(config)# hostname switch
(config)# ip domain-name greenbone.net
(config)# crypto key generate rsa general-keys modulus 2048

Finally enable SSH logins using the following commands:

(config)# line vty 0 4
(config-line)# transport input ssh
(config-line)# Crtl-Z

Now the credentials of the user need to be entered on the GSM. Navigate to Configuration followed by Credentials and create the appropiate user. Then link the credentials to the target to be used as SSH-credentials.

7.4.5. Autogenerate Credentials

To simplify the installation and creation of accounts for authenticated scans the GSM option Autogenerate Credential offers an install package for the respective target system. This package creates the user and the most important permissions for the authenticated scan and re-sets them again during uninstallation.

The install package is provided for:

  • Debian based systems deb
  • RPM based systems rpm
  • Windows exe
  • Public Key key

7.5. Scheduled Scan

Once tasks are created executing them manually can be annoying. The GSM offers the possibility to automate different tasks. This is done via Schedules. It can be found in the Configuration menu.

Directly after start up no schedule is pre-configured. The first schedule needs to be created by you. To do so select the new button.

_images/new-schedule.png

Schedules allow time controlled scans.

The Greenbone Security Manager refers to Schedules as automatic scans at a specific time. They can be run once or repeatedly. The intervals can be configured in much detail:

  • hourly
  • daily
  • weekly
  • monthly

The time zone is very important in a schedule. It can be selected from a drop down menu. For Eastern Standard Time (EST) you will likely choose America/New York. Finally the maximum duration of the scan can be limited. If the scan takes longer it will aborted. This way it can be ensured that the scan will always run with a specific time window.

_images/editschedule.png

When creating a schedule various information must is required.

Now the schedule can be defined and the following data can be entered:

Name
This is a descriptive name. Meaningful are entries such as Daily 5:15pm or Every 2nd monthly 4:15am.
Comment
Enter a comment again.
First Time
Enter the time of the first run.
Period
This is the interval between two runs. It can be selected between hourly, daily, weekly and monthly. If left blank the interval is a single instance.
Timezone
Select the time zone. UTC is standard.
Duration
This is the maximum duration a task can take for its execution. After expiration of the of the time allotted the task is aborted.

7.6. Notes

Notes allow adding comments to a Network Vulnerability Test (NVT). They will also be displayed in the reports. A Note can be added to a specific result, a specific task, a risk level, port or host and as such will only appear in specific reports. A Note can be generalized just as well so that it will be displayed in all reports.

7.6.1. Creating notes

To create a new note select the finding in the report you want to add a note to and click New Note new. Alternatively you can create a note without relation to a finding. However, the GSM can not suggest any meaningful values for the different fields in the following dialogue.

A new window opens in which exactly those criteria of the selected vulnerability are pre-set.

_images/newnoteedit-3.png

A new note

Individual values can be selected and unselected to generalize or the note even further or make it more specific. Additionally the note can be activated for a specific period of time. This allows adding of information to a note that a security update is uploaded in the next seven days. For the next seven days the note will be displayed in the report that the vulnerability is being worked on.

_images/noteresult.png

A note in a report

7.6.2. Generalizing Notes

Any note can be generalized. In this example a quite extensive generalization is configured, matching any target host, port and task.

_images/note-generalize.png

A generalized note

From this moment on the note is always shown in the results view if this NVT matches.

This applies for all previously created scan reports and for all future scan reports until the note is deleted.

7.6.3. Managing Notes

The created notes can be displayed under Scan Management and Notes. Here completely new notes can be added as well.

_images/note-management.png

Notes can be managed individually.

Among others it is being displayed if created notes are currently active. Additionally notes can be edited edit. To search for a specific note a search filter can be used respectively. This will make it easier to find a specific note when especially a great deal of notes is available. The search filter can be opened respectively end text entered appropriately or it can be entered directly into the filter window at the top. These filters can, of course, be saved for later use as well.

_images/note-search.png

Notes can be limited by a search filter.

7.7. Overrides and False Positives

The results of a report can not only be supplemented through meaningful or helpful data but the severity of the results can be modified. This is called Override by the GSM.

These overrides are especially useful to manage results that are discovered as a false positive and that have been given a critical severity but should be given a different severity (i.e. False Positive) in the future. The same is true for results that only have been given the severity Log but should be assigned a higher severity locally. These can be managed with an override as well.

The use of overrides makes also sense to manage acceptable risks. The risk of a vulnerability can be ranked new and as such the risks that, in your opinion, are not critical can be re-evaluated in the results.

7.7.1. What is a false positive?

A false positive is a result that describes a problem that does not exist in reality. Often vulnerability scanners find proof that point to a security issue. A final prediction is not possible, however. Two options are now available:

  • Reporting of a potentially non-existent vulnerability (False Positive).
  • Omission of the reporting of the potentially existing vulnerability (False Negative).

Since a user is able to recognize, manage and handle these as it is not the case with false negatives, the GSM vulnerability scanner reports all potentially existing vulnerabilities. The GSM assists with several automatic and semi-automatic to categorize them.

Note

Consider the new concept of Quality of Detection (see sections Reading of the Reports and Network Vulnerability Tests).

This problem is especially typical with Enterprise Linux distributions. If, for example, a SSH service in version 4.4 is installed and the software reports this version during a connection attempt, a vulnerability scanner, that knows of a vulnerability in this version, will report this as such. The vendor potentially already addressed the vulnerability and released version 4.4-p1 that is already installed. This version still reports to the outside version 4.4 so that the vulnerability scanner cannot differentiate. If the scan administrator knows of this circumstance an override can ensure that these results are no longer being displayed.

7.7.2. Creating an Override

Overrides like notes can be created in different ways. The simplest way to get to this option is through the respective scan result in a report. At the top right of each finding the Add Override icon new_override can be found.

Overrides have the same function as notes, however, they add the possibility to adjust the severity:

  • High
  • Medium
  • Low
  • Log
  • False Positive

Vulnerabilities with the level False Positive are not being displayed in the reports. But special reports for findings of this level can be created. As with overrides they can have a time limitation.

_images/overridenew-3.png

Overrides allow for the customization of the severity level.

Note

If several overrides apply to the same NVT in the same report the most recent override is actually used and applied.

7.7.3. Disabling and Enabling Overrides

Whereever overrides may change the display of the results, the overrides may be enabled or disabled. This may be done using the icon overrides_enabled in the title bar.

_images/enable-overrides.png

Overrides may be enabled and disabled.

7.7.4. Automatic False Positives

The GSM is able to detect false positives automatically and can assign an override automatically. However the target system must be analyzed internally and externally with an authenticated scan.

An authenticated scan can identify vulnerabilities in locally installed software. As such vulnerabilities can be identified that can be exploited by local users or are available to an attacker if he already gained local access as an unprivileged user for example. In many cases an attack occurs in different phases and an attacker exploits multiple vulnerabilities to increase his privileges.

An authenticated scan offers a second more powerful function justifying its execution. In many cases by scanning the system externally, it can not be properly identified if a vulnerability really exists. In doubt, the Greenbone Security Manager reports all potential vulnerabilities. With the authenticated scan many of these potential vulnerabilities can be recognized and filtered as false positives.

_images/autofp.png

Automatic False Positives

This problem is especially typical with Enterprise Linux distributions. If, for example, a SSH service in version 4.4 is installed and the software reports this version during a connection attempt, a vulnerability scanner, that knows of a vulnerability in this version, will report this as such. The vendor potentially already addressed the vulnerability and released version 4.4-p1 that is already installed. This version still reports to the outside version 4.4 so that the vulnerability scanner cannot differentiate. If an authenticated scan was performed the GSM can recognize that the version 4.4-p1 is installed and no longer contains this vulnerability.

Automatic false positives are enabled with the Report-Filter function (see section Powerfilter). This functionality gives the best results when using the Partial CVE match.

7.8. Scanning Web Applications

The Greenbone Security Manager supports scanning of web applications in two ways:

  • With our own Network Vulnerability Tests (NVTs, over 1500 are of some relevance for web applications).
  • With connected web applications scanners like the built-in scanner w3af

Using the NVTs, basically all that are relevant for web applications are already selected with the default scan configurations.

Alternatively you can narrow down the scope of the scan configuration to focus on web applications only. An example is available for download which just needs to be imported as a new scan configuration: http://download.greenbone.net/web-app-scan.xml

Note

If you are only interested in the actual web service, you can change the target’s port list to cover only port 80 and/or 443.

There are various fine-tuning preferences available for the scan configuration.

Footnotes

[1]The maximum netmask is /20. This equals 4096 addresses.
[2]In UNIX access to these privileged ports is only allowed for privileged users (i.e. root). Ports starting at 1024 are also available to unprivileged users.

7.9. Obstacles while Scanning

This section will highlight and explain several typical problems which might occur during a scan using the default values of the GSM. While the default values of the GSM are valid for most environments and customers, depending on the actual environment and the configuration of the scanned hosts they might require some tweaking.

The following sections will cover typical problems, explain why they occur and will give some advice to overcome these problems.

7.9.1. Hosts not found

During a typical Scan (either a Discovery Scan or a Full and Fast Scan) the GSM will by default first use the ping command to check the availability of the configured targets. If the target does not reply the ping request the target is presumed to be dead and will not be scanned by the port scanner or any NVT.

In most LAN environments this does not pose any problems because all devices will respond to a ping request. But sometimes (local) firewalls or other configuration might suppress the ping response. If this happens the target will not be scanned and will not be included in the results and the scan report.

To remediate this problem the both the target configuration and the scan configuration support the setting of the Alive Test (see Alive Test).

If the target does not respond to a ping request you may want to test a TCP Ping. If the target is located within the same broadcast domain you may want to try a ARP Ping as well.

7.9.2. Long Scanperiods

Once the target is discovered to be alive using the ping command the GSM uses a port scanner to scan the target. By default a TCP port list containing around 5000 ports is used. If the target is protected by a (local) firewall dropping most of these packets the port scan will need to wait for the timeout of each individual port. If your hosts are protected by (local) firewalls you may want to tune the port lists or your firewalls. If the firewall does not drop the request but rejects the request the port scanner does not have to wait for the timeout. This is especially true if you include UDP ports in the scan.

7.9.3. NVT not used

This happens especially very often if you use UDP based NVTs like NVTs using the SNMP protocol. If you use the default configuration Full and Fast the SNMP NVTs are included. But if the target is configured using the default port list the NVTs are not executed. This happens because the default port list does not include any UDP ports. Therefore the port 161/udp (snmp) is not discovered and excluded from further scans. Both the discovery scans and the recommended Full and Fast scan configuration optimize the scan based on the discovered services. If the UDP port is not discovered no SNMP NVTs are executed.

Please do not enable all ports per default in your port lists. This will prolong the scans considerably. Best practice is the tuning of the port lists to the ports which are used in your environment and are supported by your firewalls.