8. Managing the Web Interface

8.1. Managing Users

The Greenbone Security Manager (GSM) allows for the definition and management of multiple users with different roles and permissions. When initializing the GSM, the first user – the web/scan administrator – is already created in the GOS administration menu. With this user, additional users can be created and managed.

Roles
The GSM user management supports a role based permission concept when accessing the web interface. Various roles are already set up by default. Additional roles can be created and used by an administrator. The role defines which options of the web interface can be viewed and modified by the user. The role enforcement is not implemented in the web interface but rather in the underlying GMP protocol and so affects all GMP clients. Read and write access can be assigned to roles separately.
Groups
In addition to roles the GSM user management supports groups as well. This serves mainly for logical grouping.

Groups and roles may be used to assign permissions to several users at once.

Each user is assigned an IP address range containing the allowed or denied targets. The GSM appliance will refuse to scan any other IP addresses than the ones specified. Similarly, the access to specific interfaces of the GSM appliance can be allowed or denied.

The user management is completely done with the GSM. External sources for the user management are not supported. However, to support central authentication and to allow password synchronization the GSM can be integrated with a central LDAP or RADIUS server. The server will only be used to verify the password during the login process of the user. All other settings are performed in the user management of the GSM.

8.1.1. Creating and Managing Users

Users can be created as follows:

Note

Only administrators are allowed to create and manage additional users.

  1. Log in as an administrator.

  2. Select Administration > Users in the menu bar.

  3. Click new.

  4. Define the user (see figure Creating a new user).

    _images/newuser.png

    Creating a new user

    The following specifications have to be made:

    • Login Name

      This is the name used for logging in. When an LDAP or a RADIUS server is used for central password management, the user needs to be created with the identical name (rDN) as used by the server. The name can contain letters and numbers and can be at most 80 characters long.

    • Password

      This is the password used for logging in. The password can contain any type of character and can be at most 40 characters long.

      Note

      When using special characters, note that they have to be available on all used keyboards and operating systems.

    • Roles (optional)

      Each user can have multiple roles. The roles define the permissions of a user when using the GMP protocol. While it is possible to add and configure additional roles, by default the roles Admin, User, Info, Observer, Guest and Monitor are available. For further details see Chapter Managing Roles.

    • Groups

      Each user can be a member of multiple groups. Permissions management can be performed using groups as well (see Chapter Managing Permissions).

    • Host Access

      The user can specify which systems should or should not be considered in a scan. The restrictions also apply to administrators but they are allowed to remove them themselves. Normal users (User) and roles without access to the user management cannot circumvent the restrictions. Basically either a whitelist (deny all and allow) or a blacklist (allow all and deny) is possible.

      • Whitelist
        The scanning of all systems is denied in general. Only explicitly listed systems are allowed to be scanned.
      • Blacklist
        The scanning of all systems is allowed in general. Only explicitly listed systems are not allowed to be scanned.

      Tip

      In general the whitelist methodology should be used. This ensures that users do not scan systems lying beyond their responsibility, located somewhere on the Internet or reacting to malfunctioning scans by accident.

      System names as well as IPv4 and IPv6 addresses can be entered. Individual IP addresses as well as address ranges and network segments can be specified. The following listing shows some examples:

      • 192.168.15.5 (IPv4 address)
      • 192.168.15.5-192.168.15.27 (IPv4 range long form)
      • 192.168.15.5-27 (IPv4 range short form)
      • 192.168.15.128/25 (CIDR notation)
      • 2001:db8::1 (IPv6 address)
      • 2001:db8::1-2001:db8::15 (IPv6 range long form)
      • 2001:db8::1-15 (IPv6 range short form)
      • 2001:db8::/120 (CIDR notation)

      All options can be mixed and matched and entered as a comma-separated list. The netmask in the CIDR notation is restricted to a maximum of 20 IP addresses for IPv4 and 116 IP addresses for IPv6. In both cases the result is a maximum of 4096 IP addresses.

    • Interface Access

      This refers to the input box Network Source Interface when creating a new task (see Creating a Task). If a task is bound to a certain network interface by its configuration and a user has no access to this network interface, the user is restricted from running the task successfully. A comma-separated list of network adapters can be entered. Similar to Host Access a whitelist or a blacklist methodology is possible (see above).

  5. Click Create.

    → The user is created and displayed on the page Users.

  6. Click on the name of a user to display the details (see figure Details of a user).

    _images/addeduser.png

    Details of a user

All existing users can be displayed by selecting Administration > Users in the menu bar when logged in as an administrator.

For all users the following actions are available:

  • delete Delete the user. Only users which are currently not logged in can be deleted.
  • edit Edit the user.
  • clone Clone the user.
  • download Download the user as an XML file.

Click on the name of a user to open the details page of the user. The same actions are available there.

8.1.2. Simultaneous Login

It is possible that two users are logged in at the same time.

If the same user wants to log in more than once at the same time, the login must be performed from a different PC or with a different browser. Another login in the same browser invalidates the first login.

8.1.3. Creating a Guest Login

The guest user is only allowed to access the page SecInfo (see chapter SecInfo Management).

To allow the guest access, a user can be created and assigned the role Guest (see Chapter Creating and Managing Users).

Having knowledge of the password the guest user can now log in and is presented with the SecInfo dashboard.

To allow a guest to log in without needing a password, this feature has to be activated in the GOS administration menu (see Chapter Enabling a Guest User).

8.1.4. Creating a Super Administrator

The role Super Admin is the highest level of access.

The role Admin is allowed to create, modify and delete users. Additionally, it can view, modify and delete permissions but is subordinated to those permissions as well. If any user creates a private scan configuration but does not share it, the administrator cannot access it. The administrator would have to assign respective permissions to the resource created by the user to himself which is quite tedious.

The role Super Admin is more suited for diagnostic purposes. The super administrator is excluded from permission restrictions and allowed to view and edit any configuration settings of any user.

The super administrator has to be created in the GOS administration menu (see Chapter Creating a Super Administrator)

Note

The super administrator can only be edited by the super administrator.

8.2. Managing Roles

The web interface supports the creation and configuration of own user roles. Modifying the default roles is not possible but they can be copied (cloned) and subsequently modified. This ensures consistent behaviour when updating the software.

To access the role management click Administration > Roles in the menu bar.

The following roles are available by default:

  • Admin
    This role has all permissions by default. It is especially allowed to create and manage other users, roles and groups.
  • User
    This role has all permissions by default except for user, role and group management. This role is not allowed to synchronize and manage the feeds. In the web interface there is no access to the page Administration.
  • Info
    This role (Information Browser) has only read access to the NVTs and SCAP information. All other information is not accessible. The role can modify personal setting, e.g. change the password.
  • Guest
    This role corresponds with the role Info but is not allowed to change the user settings.
  • Monitor
    This role has access to system reports of the GSM (see Chapter Appliance Performance).
  • Observer
    This role has read access to the system but is not allowed to start or create new scans. It has only read access to the scans for which it has been set as an observer.
  • Super Admin
    This role has access to all objects of all users. It has no relation to the SuperUser in the GOS administration menu. This role cannot be configured in the web interface but in the GOS administration menu (see Chapter Creating a Super Administrator)

8.2.1. Creating and Managing Roles

Additional roles can be created.

Note

Only administrators are allowed to create and manage additional roles.

When an existing role closely reflects the demands, a new role can be created by copying the existing role.

  1. Log in as an administrator.

  2. Select Administration > Roles in the menu bar.

  3. In the row of an existing role click clone.

    → The details of the new role are displayed.

  4. Click edit.

  5. Define the role (see figure Editing a copied role). Permissions can be added or deleted.

    _images/role_cloned.png

    Editing a copied role

  6. Click Save.

  7. Click list.

    → The page Roles is opened.

When a role with only limited functionality should be created, it can be started with a new, empty role.

  1. Log in as an administrator.

  2. Select Administration > Roles in the menu bar.

  3. Create a new role by clicking new.

  4. Define the role.

  5. Click Create.

    → The role is created and displayed on the page Roles.

  6. In the row of the newly created role click edit.

  7. Define the permissions of the role.

  8. Click Save.

Note

Some permissions are required:

  • authenticate and get_settings
    These permissions are necessary to log in to the web interface.
  • write_settings (optional)
    This allows a user to change its own password, time zone and other personal settings.

A user can have more than one role to group permissions. The roles are assigned when creating a new user (see figure Creating a new user with multiple roles, see Chapter Creating and Managing Users). If more than one role is assigned to a user, the permissions of the roles will be added.

_images/user_multiple_roles.png

Creating a new user with multiple roles

All existing roles can be displayed by selecting Administration > Roles in the menu bar.

For all roles the following actions are available:

  • trashcan Delete the role. Only self-created roles can be deleted.
  • edit Edit the role. Only self-created roles can be edited.
  • clone Clone the role.
  • download Download the role as an XML file.

Click on the name of a role to open the details page of the role. The same actions are available there.

8.2.2. Granting Read Access to Other Users

By default, only administrators can grant other users read access to tasks and reports. Regular users cannot share their tasks and reports with other users.

If users want to assign read access for their tasks and reports to other users they require the permission get_users. This permission is not granted by default but can be added as follows:

  1. Log in to the web interface as an administrator.

  2. Select Administration > Roles in the menu bar.

  3. Create a new role by clicking new.

  4. Enter GrantReadPriv in the input box Name.

  5. Click Create.

    → The role is created and displayed on the page Roles.

  6. In the row of the newly created role click edit.

  7. In the drop-down-list Name in the section New Permission select get_users (Has read access to users) (see figure Selecting permissions for a new role).

    _images/grantreadpriv2.png

    Selecting permissions for a new role

  8. Click Create Permission.

    → The permission is displayed in the section General Command Permissions (see figure A new permission is added to a role).

    _images/new_permission_added.png

    A new permission is added to a role

  9. Click Save.

  10. Select Administration > Users in the menu bar.

  11. In the row of the user which should be assigned the newly created role click edit.

  12. In the input box Roles add the role GrantReadPriv.

  13. Click Save.

Note

Additionally, the permissions get_groups — granting read access to a group — and get_roles — granting read access to a role — are available and follow the same principle as described above.

8.3. Managing Groups

Groups are used to logically assemble users. An unlimited number of groups can be created. Permissions can be assigned for the groups (see Chapter Managing Permissions). By default, no groups are set up.

A group is created as follows:

Note

Only administrators are allowed to create and manage additional users.

  1. Log in as an administrator.

  2. Select Administration > Groups in the menu bar.

  3. Create a new group by clicking new.

  4. Define the group (see figure Creating a new group).

    The following specifications have to be made:

    • Name
      The name of the group can contain letters and numbers and can be at most 80 characters long.
    • Comment (optional)
      A comment describes the group in more detail.
    • Users
      The members of the group can be entered in the input box Users, separated by a space or comma. The entry can be at most 1000 characters long. Alternatively, group memberships can be managed in the user profile (see Chapter Creating and Managing Users).
    _images/group.png

    Creating a new group

  5. Click Create.

    → The group is created and displayed on the page Groups.

  6. Click on the name of a group to display the details.

8.4. Managing Permissions

Select Configuration > Permissions to display all permissions assigned on the system. If multiple roles are created, there can easily be hundreds of permissions. Each permission relates to exactly one subject. The permission enables the user to perform the associated action.

Subjects can be:

  • Users
  • Roles
  • Groups

There are two types of permissions:

  • Command permissions

    Command permissions are linked to the Greenbone Management Protocol (GMP). Each command permission applies to a specific GMP command. The name of the permission is the relevant command. A command permission is either a command level permission or a resource level permission.

    • Command level
      When no resource is specified, a command level permission is created. A command level permission allows the subject to run the given GMP command.
    • Resource level
      When a resource is specified, a resource level permission is created. A resource level permission allows the subject to run the given GMP command on a specific resource.
  • Super permissions

    (see Chapter Super Permissions)

8.4.1. Creating and Managing Permissions

Note

Usually, permissions are assigned in the web interface using the role management (see Chapter Managing Roles).

Creating and managing permissions using the page Permissions is only recommended to experienced users looking for a specific permission.

A new permission can be created as follows:

  1. Select Configuration > Permissions in the menu bar.

  2. Create a new permission by clicking new.

  3. Define the permission.

    Note

    The subjects for which permissions can be assigned depend on the role of the currently logged in user. Users can grant permissions to other users, whereas administrators can grant permissions to users, roles and groups.

  4. Click Create.

    → The permission is created and displayed on the page Permissions.

  5. Click on the name of a permission to display the details.

All existing permissions can be displayed by selecting Configuration > Permissions in the menu bar.

For all permissions the following actions are available:

  • trashcan Delete the permission. Only administrators can delete permissions.
  • edit Edit the permission. Only administrators can edit permissions.
  • clone Clone the permission. Only administrators can clone permissions.
  • download Download the permission as an XML file.

8.4.2. Creating Permissions from the Resource Details Page

When accessing a resource details page, e.g. the detail page of a task, permissions for the resource can be granted directly on the details page as follows:

  1. Open the details page of a resource.

    Example: Select Scans > Tasks in the menu bar. Click on the name of a task.

  2. In the section Permissions click new.

  3. Define the permission.

  4. Click Create.

    → The permission is created and displayed in the section Permissions on the resource details page.

There are two types of permissions that can be granted directly on the resource details page:

  • read
    Granting the permission read means allowing to view the resource on list pages and on its details page.
  • proxy
    Granting the permission proxy means allowing to view and modify (but not delete) the resource.

Some resource types include additional permissions:

  • Tasks
    When granting the permission proxy for a task, the permissions to start (start_task), stop (stop_task) and resume (resume_task) the task are added automatically.
  • Alerts
    When granting the permission proxy for an alert, the permissions to test the alert (test_alert) is added automatically.
  • Report formats, agents and scanners
    When granting the permission proxy for a report format, an agent or a scanner, the permissions to verify the report format (verify_report_format), the agent (verify_agent) or the scanner (verify_scanner) is added automatically.

For some resource types it can be selected whether the permissions should also be granted for related resources (see figure Creating a permission from the resource details page).

  • Tasks
    For tasks this includes alerts and their filters, the target as well as its related credentials and port list, the schedule, the scanner and the scan configuration.
  • Targets
    For targets this includes credentials and the port list.
  • Alerts
    For alerts this includes the filter that is used on the report.

Note

Permissions can also be created only for the related resources.

The details of the related resources can be displayed by clicking the links below the drop-down-list.

_images/permissions_detailspage_dropdown.png

Creating a permission from the resource details page

8.4.3. Super Permissions

Any resource created on the GSM (e.g. scan, configuration and target) is either global or owned by a specific user. Global resources are identified by view_other.

Non-global resources can initially be viewed and used only by their owner. Individual permissions are necessary to make the resources available to other users which is quite tedious.

To avoid that, users, roles and groups can be assigned with super permissions. This makes all objects of other users, roles or groups accessible.

A user can get super permissions for:

  • User
  • Role
  • Group
  • Any

These super permissions allow complete access to any resource of the respective user, role, group or effectively all resources.

Note

The super permission Any cannot be set explicitly. It is restricted to the super administrator (see Chapter Creating a Super Administrator) and can only be set by creating such.

A user can only set super permissions for self-created objects. Only the super administrator can grant super permissions to any other user, role or group.

  1. Open the detail page of the user/role/group for which super permissions should be assigned by clicking on the name of the user/role/group on the page Users/Roles/Groups.

    → The resource ID can be found in the upper right corner (see figure ID of a resource).

    _images/resource_ID.png

    ID of a resource

  2. Note or copy the ID.

  3. Select configuration > Permissions in the menu bar.

  4. Create a new permission by clicking new.

  5. In the drop-down-list Name select Super (Has super access).

  6. Select the radiobutton of the subject type that should have super permissions (see figure Creating a new super permission).

  7. In the according drop-down-list select the user/role/group that should have super permissions (see figure Creating a new super permission).

  8. Enter or paste the previously determined resource ID into the input box ID (see figure Creating a new super permission).

    _images/superperm.png

    Creating a new super permission

  9. Click Create.

    → The super permission is created and displayed on the page Permissions.

  10. Click on the name of the super permission to display the details.

Tip

Super permissions simplify the permission management on the GSM. They can easily be assigned for entire groups. This allows all users of a group to access all resources that are created by other members of the group.

8.4.4. Sharing Individual Objects for Other Users

Every user can share indefinite self-created objects. The user must be assigned the permission get_users. Otherwise, the user will not have permission to determine the name of other users (see Chapter Granting Read Access to Other Users).

An object can be shared as follows:

  1. Open the detail page of the object which should be shared by clicking on the name of the object on the respective page.

    → The object ID can be found in the upper right corner (see figure ID of an object).

    _images/objectid.png

    ID of an object

  2. Note or copy the ID.

  3. Select Configuration > Permissions in the menu bar.

  4. Create a new permission by clicking new.

  5. In the drop-down-list Name select the permission for the object to be shared.

    • Filter: get_filters
    • Scan configuration: get_configs
    • Alert: get_alerts
    • Note: get_notes
    • Override: get_overrides
    • Tag: get_tags
    • Target: get_targets
    • Task with report: get_tasks
    • Schedule: get_schedules
  6. Select the radiobutton of the subject type the object should be shared with (see figure Share objects with other users).

  7. In the according drop-down-list select the user/role/group the object should be shared with (see figure Share objects with other users).

  8. Enter or paste the previously determined object ID into the input box ID (see figure Share objects with other users).

    _images/share_objects.png

    Share objects with other users

  9. Click Create.

    → The permission is created and displayed on the page Permissions.

  10. Click on the name of the permission to display the details.

8.5. Using a Central User Management

Especially in larger environments with multiple users it is often difficult to achieve password synchronization. The effort to create new or reset passwords is often very high. To avoid this, the GSM supports the usage of a central password store using LDAP or RADIUS.

The GSM will use the service only for authentication on a per user basis, i.e. users who should be able to authenticate by the service have to be configured for authentication and to exist on the GSM as well.

Note

Prerequisite for using central authentication is the naming of the users with the same names as the objects in the LDAP tree or the RADIUS server.

8.5.1. LDAP

For the connection to an LDAP tree the GSM uses a very simple interface and a simple bind operation with a hard coded object path. The LDAP authentication is done as follows:

  1. Log in as an administrator.

  2. Select Administration > LDAP in the menu bar.

  3. Activate the checkbox Enable.

  4. Enter the distinguished name (DN) of the objects in the input box Auth. DN.

    Note

    The wildcard %s replaces the user name.

    Examples for the Auth. DN are:

    • cn=%s,ou=people,dc=domain,dc=de
      This format works for any LDAP server with the correct attributes. The attribute cn (common name) is used. Users in different sub trees or different recursive depths of an LDAP tree are not supported. All users logging into the GSM must be in the same branch and in the same level of the LDAP tree.
    • uid=%s,ou=people,dc=domain,dc=de
      This format works for any LDAP server with the correct attributes. The attribute uid (user ID) is used as a filter. It should be in the first place. The attributes ou=people,dc=domain,dc=de are used as base objects to perform a search and to retrieve the corresponding DN.
    • %s@domain.de
      This format is typically used by Active Directory. The exact location of the user object is irrelevant.
    • domain.de\%s
      This format is typically used by Active Directory. The exact location of the user object is irrelevant.
  5. Enter the LDAP host in the input box LDAP host.

    Note

    Only one system can be entered by IP address or by name.

    The GSM accesses the LDAP host using SSL/TLS. For verifying the host, the certificate of the host has to be uploaded to the GSM. Without SSL/TLS the LDAP authentication will not be accepted (see Chapter LDAP with SSL/TLS).

    _images/ldapauth.png

    Configuring an LDAP authentication

  6. Click Save.

    → When the LDAP authentication is enabled, the option LDAP Authentication Only is available when creating or editing a user. By default, this option is disabled.

  7. Create a new user or edit an existing user (see Chapter Managing Users).

  8. Activate the checkbox LDAP Authentication Only when the user should be allowed to authenticate using LDAP (see figure Enabling authentication using LDAP).

    _images/user_LDAP_auth_only.png

    Enabling authentication using LDAP

Note

The user has to exist with the same name in LDAP before the authentication with LDAP can be used. The GSM does not add, modify or remove users in LDAP and it does not automatically grant any user from LDAP access to the GSM.

8.5.2. LDAP with SSL/TLS

The GSM uses either the command StartTLS via LDAP on port 389 or SSL/TLS via LDAP on port 636. The LDAP server must make its services available to SSL/TLS.

The following references are helpful for the exact configuration of all available LDAP server:

To verify the identity of the LDAP server, the GSM has to trust its certificate. For this, the certificate of the issuing certificate authority must be stored on the GSM. To do so the certificate of the certificate authority must be exported as a Base64 encoded file. A Base64 encoded certificate is often using the file extension .pem. The file itself starts with ------BEGIN CERTIFICATE-------.

If the certificate authority is an intermediate certificate authority, the complete certificate chain needs to be imported. This is often true if an official certificate authority is used because the Root CA is separated from the Issuing Certificate Authority. In these cases the contents of the file looks like:

-----BEGIN CERTIFICATE-----
......
Issuing Certificate Authority
......
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
......
Root CA
......
-----END CERTIFICATE-----

The actual place where this certificate can be found may vary based on the environment.

  • Univention Corporate Server (UCS)

    Here the CA certificate is retrieved from the file /etc/univention/ssl/ucsCA/CAcert.pem. This file already contains the certificate in the correct format and must be uploaded when enabling LDAP.

  • Active Directory LDAP

    If the Active Directory LDAP service does not yet use LDAPS, the following article may be helpful: https://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-certificate.aspx The Active Directory LDAP — CA certificates can then be exported using the following procedure which must be performed from a desktop or server that has access to the Certification Authority console.

    • Open the Certification Authority console from any domain-joined computer or server.
    • Right-click the name of the certification authority and then select Properties.
    • In the CA certificates dialog box, choose the General tab, and then select the certificate for the certification authority that should be accessed.
    • Choose View Certificate.
    • In the Certificate dialog box, choose the Certification Authority tab. Select the name of the root certification authority and then choose View Certificate.
    • In the Certificate dialog box, choose the Details tab and then choose Copy to File.
    • The Certificate Export Wizard appears. Choose Next.
    • On the Export File Format page, select the Base-64 encoded X.509 (.CER) option.
    • Choose Next.
    • In the File to Export box, choose the path and name for the certificate, and then choose Next.
    • Choose Finish. The .cer file will be created in the location that was specified in the previous step.
    • A dialog box appears to inform that the export was successful. Choose OK to finish.

    The contents of the file must be uploaded when enabling LDAP.

If the LDAP authentication does not work, please verify that the entry in LDAP Host matches the commonName of the certificate of the LDAP server. If there are deviations, the GSM appliance will refuse using the LDAP server.

8.5.3. RADIUS

The RADIUS authentication is done as follows:

  1. Log in as an administrator.

  2. Select Administration > Radius in the menu bar.

  3. Activate the checkbox Enable.

  4. Enter the host name or IP address of the RADIUS server in the input box RADIUS Host.

  5. Enter the common preshared secret key in the input box Secret Key.

    _images/radiusauth.png

    Configuring a RADIUS authentication

  6. Click Save.

    → When the RADIUS authentication is enabled, the option RADIUS Authentication Only is available when creating or editing a user. By default, this option is disabled.

  7. Create a new user or edit an existing user (see Chapter Managing Users).

  8. Activate the checkbox RADIUS Authentication Only when the user should be allowed to authenticate using RADIUS (see figure Enabling authentication using RADIUS).

    _images/radiususer.png

    Enabling authentication using RADIUS