The Greenbone Security Manager allows for the building of a distributed scan system. Hereby it is possible that one GSM remotely controls another GSM for this purpose.
Thereby the controlling GSM is called master and the controlled GSM slave. As soon as two GSMs are configured as master and slave a user can individually configure a scan for the scan slave via the web interface of the scan master depending on requirements and permissions. Every GSM starting from the midrange models upwards can be used as scan master and control one or more slaves. Every GSM can function as a slave.
The scan slaves are independent GSMs. This is why the administrator must configure the feed updates and release updates locally on the slaves as well and ensure their execution. A scan slave also provides their own graphical interface and own management. This allows for it being able to be used completely independently, however some scans being executed from the master.
Additionally the slave can be configured as sensor. A scan sensor is a GSM that exclusively is being used for the function of scan slave and also completely being managed by the assigned master. This management includes automatic updates of the feeds as well as the automatic updates of release updates. A sensor does not require any network connectivity other than to a sensor master and after initial setup no further administrative tasks.
Scan sensors and slaves can be integrated into a scan master, in order to test those network segments for vulnerabilities that are not accessible in any other way.
Basically the master establishes the connection to the delegated scan slaves. The connection is established by using the OpenVAS management protocol (OMP) which uses TCP port 9390. Additionally for feed and release updates on a scan sensor port 22/tcp (ssh) is required.
Like with any other GSM the basic setup of a scan slave is being performed via the serial port. In addition to the network configuration and the administrative access two other basic parameters for the use as slave are required:
Configuring of a scan administrator on the slave that allows the master to control the slave. It is being enabled on the slave in the GOS-Admin-Menu under User and then Add Web Admin.
Activation of the remote OMP features.
This can be enabled in the GOS-Admin-Menu under Remote and OMP.
Alternatively it can enabled directly on the command line with the variable
set public_omp enabled
Please note: Activating the remote OMP features requires a reboot of the scan slaves.
Afterwards the slaves can be set up on the master and a task delegated to the slave.
For security reasons often it is not possible to scan network segments directly. Most of the time direct access of this segment to the Internet is not desired. In order for a sensor to have the latest NVTs available, in these cases it possible to transfer the Greenbone Security Feed from the master to the slave and as such allow for a feed synchronization with the sensor. After set up this occurs automatically. As soon as the master synchronized itself with the feed server it will transfer the information to the sensor as well.
To achieve this the master uses the SSH protocol. The following steps allow the master to log into the senor without the use of a password for the transfer of the information.
First the public key of the master (Masterkey) must be copied to the sensor. Then the master can automatically establish a SSH connection with the sensor.
For this display the key on the master.
Use the command
Copy the key that is being displayed to the clipboard:
gsm-master> show masterkey ssh-dss AAAAB3 .... root@gsm
Afterwards connect to the sensor and enter the command
masterkeydownload on the command line.
Then copy the key from the clipboard onto the command line and close the entry with
gsm-sensor> masterkeydownload Please paste the master key into the CLI , END with CTRL -D ssh-dss AAAAB3 .... root@gsm gsm-sensor> show sensormasterkey ssh-dss AAAAB3 .... root@gsm
Subsequently it is recommended to verify the especially when using a USB/Serial adapter. On older GOS versions (< 3.0.20) the last command is called show masterkey. Many such adapters transfer individual characters inaccurately.
Additionally the administrator must activate the SSH access on the sensor.
This can be done with the variable
ssh or via the GOS-Admin-Menu.
So that the sensor is not trying to access the feed directly this function must be deactivated. The administrator can find this setting in the GOS-Admin-Menu in Feed under Automatic Sync. Additionally the administrator must activate the feed synchronization through the master (Feed from Master). Finally the settings must be confirmed with a Commit.
Since the master establishes the connection to the sensors the sensors must be included into the management of the master. This option can be found on the master in the GOS-Admin-Menu under Sensors. Here activate the option Automatic Sensor Sync. Afterwards add the IP address of the sensor to the sensor list (Sensors). This is a list of IP addresses that are separated by spaces.
With a sensor check the reachability of sensors can be tested.
Using the GOS-Admin-Menu a manual synchronization of the NVT the the GOS-state is possible. This manual step is only needed if the automatic synchronization is not enabled. Both the feed and the GOS-updates are then synchronized to the sensors. The GOS-updates are just synchronized but not installed by default.
Use Sensors/Synchronize sensors to trigger the synchronization.
While the synchronization is in progress the menu options Synchronize sensors and Upgrade sensors are not available.
Once the manual synchronization has finished the sensors may be upgraded. This is triggered via Sensors/Upgrade sensors.
The slaves/sensors communicate using two protocols: OMP (slaves and sensors) and SSH (sensor only). These protocols must be allowed through possible existing firewall systems. Hereby the master always establishes the connection to the slave/sensor.
The feed update of the delegated scan sensors is being performed selectively either directly from the Greenbone Update Servers or through the master. For updates from the master to the scan sensor SSH (TCP per 22) is being used. If this option is not being used it has to be remembered that a possible firewall situated between the master and the scan sensor blocks this connection without notification (Drop or Deny setting). Instead the establishing of the connection should be allowed (Accept or Permit) or rejected (Reject) with notification as the master will always try to transfer the feed updates to the scan sensor.