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. .. _simple_scan: 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. 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. .. figure:: images-3.0/task-wizard.png :align: center :width: 100% The task wizard simplifies the first steps The task wizard then automatically performs the following steps: #. Creates a new scan target (Target) in the GSM. #. Creates a new scan task (Task) in the GSM. #. Starts the scan task immediately. #. 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. .. figure:: images-3.0/task-fortschritt.png :align: center :width: 100% 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 :ref:`start_task`). As soon as the scan is completed the column Severity notifies about the criticality of the vulnerabilities found. The prior column :index:`Solution Type` |solution_type| shows the type of solution available. The most common type here is the :index:`VendorFix` |st_vendorfix|. .. _fig:wizard_result: .. figure:: images-3.0/wizard-result.png :align: center :width: 100% 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. .. figure:: images-3.0/report-darstellung.png :align: center :height: 5cm A report can be displayed in different ways. Even before the scan is completed the results can be viewed (see figure :ref:`fig:wizard_result`). 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. .. figure:: images-3.0/report-format.png :align: center :height: 3.5cm 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 :ref:`reports_section`. 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. .. figure:: images-3.1/advwizard.png :align: center :width: 100% 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). .. figure:: images-3.1/iconadvwizard.png :align: center :width: 4cm The wizard context menu allows the execution. 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. Creating a Target ````````````````` The first step is to define a scan target. This is called :index:`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. .. figure:: images-3.0/configuration-3.png :align: center :width: 60% Selecting the targets. .. figure:: images-3.0/newtarget.png :align: center :width: 5cm Creating a new target. Choose :gos:webui:`Targets` from the menu :gos:webui:`Configuration`. Select the :gos:webui:`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. .. figure:: images-3.0/newtarget2-31.png :align: center :width: 10cm 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 [#CIDR]_ * 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 :abbr:`IANA (Internet Assigned Numbers Association)`. 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 [#1024]_. 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 :gos:webui:`Configuration` submenu :gos:webui:`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. 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 :ref:`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 :ref:`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 :ref:`authenticated_scan`). .. _creating_task: 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 :ref:`scheduled_scan`. For now the basic creation of a task is covered in this section. .. figure:: images-3.0/newtask-3.png :align: center :width: 6cm Creation of tasks. To access the tasks select menu option :gos:webui:`Scan Management` from the menu bar. From there select the :gos:webui:`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. .. figure:: images-3.1/task-31.png :align: center :width: 8cm 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 :index:`Target` from the drop down menu. * Alerts Select a previously configured :index:`Alert`. Status changes of a task can be communicated to the world via email, Syslog, HTTP or a connector. * Schedule Select a previously configured :index:`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 :doc:`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. * Scanner * OpenVAS Scanner By default only the OpenVAS scanning engine is supported. Additional scanning engines are the Palo Alto and W3AF scanning engines. * :index:`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. * :index:`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. .. _observer: Permissions ``````````` Once the task is saved it will be displayed next (see figure :ref:`fig:new_task`). .. figure:: images-3.1/neuer-task.png :align: center :width: 100% A new task after it is created. When scrolling the window further down the permissions for the task can be managed. .. figure:: images-3.1/create-observer-task.png :align: center :width: 100% 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 :gos:perm:`get_users` permission. It makes most sense to create an additional role (see section :ref:`getusers_role`). Select :gos:webui:`User`, :gos:webui:`Group` or :gos:webui:`Role` respectively and enter the respective name. After clicking on |new| the permissions are entered. This is now displayed in the task overview. .. figure:: images-3.1/create-observer-task.png :align: center :width: 100% 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. .. figure:: images-3.0/task-uebersicht.png :align: center :width: 80% After logging in the observer can view the tasks but cannot change them. .. _start_task: Starting a Task ``````````````` Once a task is saved it will be displayed next (see figure :ref:`fig:new_task`). .. _fig:new_task: .. figure:: images-3.1/neuer-task.png :align: center :width: 100% 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 :gos:webui:`Scan Management` and then :gos:webui:`Tasks` (see figure :ref:`fig:task_overview`). .. _fig:task_overview: .. figure:: images-3.0/task-uebersicht.png :align: center :width: 100% 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. .. _container_task: Container Task `````````````` A :index:`Container Task` can be used to import and provide reports created on other GSMs. When creating the :gos:webui:`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. .. figure:: images-3.0/container-task.png :align: center :width: 100% Container tasks are used to import external reports. The reports need to be in the GSM xml report format. .. _reports_section: 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 :doc:`reports` chapter as well. .. figure:: images-3.0/reportsummary-3.png :align: center :width: 12cm 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 :ref:`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. .. figure:: images-3.0/report-darstellung.png :align: center :width: 6cm 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. .. figure:: images-3.0/reportfilter.png :align: center :width: 100% 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 :index:`Override` can be configured (see section :ref:`overrides`). The AutoFP function (see section :ref:`AutoFP`) can assist here as well. .. note:: Consider the new concept of Quality of Detection (see sections :ref:`report_reading` and :ref:`NVTs`). * 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. .. _report_reading: Reading of the Reports ^^^^^^^^^^^^^^^^^^^^^^ The report contains a list of all of the vulnerabilities detected by the GSM (see figure :ref:`fig:found_vulnerabilities`) .. _fig:found_vulnerabilities: .. figure:: images-3.1/reportvuln.png :align: center :width: 100% List of discovered vulnerabilities To support the administrator with the analysis of the results the severity of a vulnerability (CVSS, see also section :ref:`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 :ref:`NVTs`). This column allows to be filtered as well. You can use the :gos:filter:`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. .. figure:: images-3.1/php.png :align: center :width: 100% Detailed information about the vulnerability and solution options. .. _results: 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 :gos:webui:`Scan Managment`/:gos:webui:`Results`. .. figure:: images-3.1/allresults.png :align: center :width: 100% 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 :ref:`Powerfilter`) may be used to view just the interesting results. .. _authenticated_scan: 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 :gos:webui:`Credentials` from the :gos:webui:`Configuration` menu. The following information can be entered: .. figure:: images-3.0/credentials.png :align: center :width: 100% 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. Requirements on Target Systems with Windows ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 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 :ref:`conf_auth_can`. * 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 **Domain 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. .. _conf_auth_can: 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. 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 :menuselection:`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``. 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. .. figure:: images/win_group_policy.png :align: center :width: 70% A new Windows Group Policy Object for Greenbone scans. 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``. .. figure:: images/win_group_policy_check.png :align: center :width: 70% 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. .. figure:: images/win_group_policy_member.png :align: center :width: 70% Add Group Membership. .. figure:: images/win_group_policy_member2.png :align: center :width: 50% 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 Settigns\ 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``. .. figure:: images/win_group_policy_deny.png :align: center :width: 100% 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``. .. figure:: images/win_group_policy_deny2.png :align: center :width: 70% 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. .. figure:: images/win_group_policy_read.png :align: center :width: 50% Specifying the ``%SystemDrive%`` folder. * Click on Add under ``Group or user names:`` * In the dialog that opens enter ``Greenbone Local Scan`` and click OK. .. figure:: images/win_group_policy_read2.png :align: center :width: 50% Select the ``Greenbone Local Scan`` group. * Now select the user ``Greenbone Local Scan``. * Deactivate all checkmarks under ``Allow`` and activate the checkmarks under :menuselection:`Deny > Write`. .. figure:: images/win_group_policy_read3.png :align: center :width: 50% 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. .. figure:: images/win_group_policy_read4.png :align: center :width: 30% Make the permissions recursive. .. figure:: images/win_group_policy_read4-de.png :align: center :width: 30% 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 .. figure:: images/win_group_policy_reg.png :align: center :width: 50% Select the ``USERS`` registry key. * Click on Advanced and then Add. * Enter ``Greenbone Local Scan`` in the dialog that opens and click on OK. .. figure:: images/win_group_policy_reg2.png :align: center :width: 50% 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``. .. figure:: images/win_group_policy_reg3.png :align: center :width: 40% 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. .. figure:: images/win_group_policy_reg4.png :align: center :width: 40% 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...``. 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``. .. figure:: images/win_group_policy_link.png :align: center :width: 50% Linking the policy. 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 HKLM\Software\VulScanInfo. 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 :ref:`compliance_file_checksums`. 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. 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 :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. 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. To avoid using a administrative account, clone the ``Read-Only`` role and then select ``Global > Settings``. Finally the scan user account must be assigned with this new role. Autogenerate Credentials ^^^^^^^^^^^^^^^^^^^^^^^^ To simplify the installation and creation of accounts for authenticated scans the GSM option :gos:webui:`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| .. _scheduled_scan: 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 :gos:webui:`Schedules`. It can be found in the :gos:webui:`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. .. figure:: images-3.1/new-schedule.png :align: center :width: 100% 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. .. figure:: images-3.0/editschedule.png :align: center :width: 9cm 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. .. _notes: Notes ----- Notes allow adding comments to a :index:`Network Vulnerability Test` (:index:`NVT`). They will also be displayed in the reports. A :index:`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. Creating notes ^^^^^^^^^^^^^^ To create a new note select the finding in the report you want to add a note to and click :gos:webui:`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. .. figure:: images-3.0/newnoteedit-3.png :align: center :width: 50% 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. .. figure:: images-3.0/noteresult.png :align: center :width: 100% A note in a report Generalizing Notes ^^^^^^^^^^^^^^^^^^ Any note can be generalized. In this example a quite extensive generalization is configured, matching any target host, port and task. .. figure:: images-3.1/note-generalize.png :align: center :width: 100% 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. Managing Notes ^^^^^^^^^^^^^^ The created notes can be displayed under :gos:webui:`Scan Management` and :gos:webui:`Notes`. Here completely new notes can be added as well. .. figure:: images-3.1/note-management.png :align: center :width: 100% 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. .. figure:: images-3.0/note-search.png :align: center :width: 100% Notes can be limited by a search filter. .. _overrides: 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 :index:`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. .. index:: False Positive 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 :ref:`report_reading` and :ref:`NVTs`). 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. 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 :gos:webui:`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. .. figure:: images-3.0/overridenew-3.png :align: center :width: 12cm Overrides allow for the customization of the severity level. 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. .. figure:: images-3.1/enable-overrides.png :align: center :width: 100% Overrides may be enabled and disabled. .. _autofp: 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. .. figure:: images-3.0/autofp.png :align: center :width: 100% 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 :ref:`Powerfilter`). This functionality gives the best results when using the ``Partial CVE match``. 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://greenbone.net/download/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. .. rubric:: Footnotes .. [#CIDR] The maximum netmask is /20. This equals 4096 addresses. .. [#1024] 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.