16. Architecture

This chapter covers the architecture and the communication protocols used by the Greenbone Security Manager. Some protocols are mandatory and some protocols are optional. Some protocols are only used in specific setups.

16.1. Protocols

The GSM requires several protocols to fully function. These protocols provide the feed updates, DNS resolution, time, etc. The following protocols are used by a stand alone system or a GSM master to initiate connections being a client:

_images/gos_acting_as_client_2000x1125.png

GSM acting as client

  • GSM is client
    • DNS - Name resolution
      • connecting to 53/udp and 53/tcp
      • mandatory
      • not encrypted
      • may use internal DNS server
    • NTP - time synchronization
      • connecting to 123/udp
      • mandatory
      • not encrypted
      • may use internal NTP server
    • Feeds (see below)
      • direct
        • connecting to 24/tcp or 443/tcp
        • direct Internet access required
      • via proxy
        • connecting to internal HTTP-Proxy supporting CONNECT method on configurable port
      • connecting to apt.greenbone.net and feed.greenbone.net
      • mandatory on stand-alone and master appliances
      • Protocol used is SSH
      • encrypted and bidirectionally authenticated via SSH
        • Server: public key
        • Client: public key
    • DHCP
      • connecting to 67/udp and 68/udp
      • optional
      • not encrypted
    • LDAPS - User authentication
      • connecting to 636/tcp
      • optional
      • encrypted and authenticated via SSL/TLS
        • Server: certificate
        • Client: username/password
    • Syslog - Remote Logging and alerts
      • connecting to 512/udp or 512/tcp
      • optional
      • not encrypted
    • SNMP Traps for alerts
      • connecting to 162/udp
      • optional
      • just SNMPv1
      • not encrypted
    • SMTP for E-Mail alerts
      • connecting to 25/tcp
      • optional
      • not encrypted
    • SSH for Backup
      • connecting to 22/tcp
      • optional
      • encrypted and bidirectionally authenticated via SSH
        • Server: public key
        • Client: public key
    • Cisco Firepower (Sourcefire) for IPS integration
      • connecting to 8307/tcp
      • optional
      • encrypted and bidirectionally authenticated via SSL/TLS
        • Server: certificate
        • Client: certificate
    • verinice.PRO
      • connecting to 443/tcp
      • optional
      • encrypted via SSL/TLS
        • Server: optionally via certificate
        • Client: username/password

The following connection are accepted by a GSM acting as a server.

_images/gos_acting_as_server_2000x1125.png

GSM acting as server

  • GSM is server
    • HTTPS - Web interface
      • 443/tcp
      • mandatory on stand-alone and master appliances
      • encrypted and authenticated via SSL/TLS
        • Server: optionally via certificate
        • Client: username/password
    • SSH - CLI access and GMP
      • 22/tcp
      • optional
      • encrypted and authenticated via SSH
        • Server: public key
        • Client: username/password
    • SNMP
      • 161/udp
      • optional
      • optionally encrypted when using SNMPv3

In a master/sensor setup the following additional requirements apply. The master (client) initiates two additional connections to the sensor (server):

_images/gos_master_sensor_comm_2000x1125.png

GSM master and sensor

  • SSH for Updates and Feeds and GMP

    • 22/tcp

    • mandatory

    • encrypted and bidirectionally authenticated via SSH

      • Server: public key
      • Client: public key

16.2. Security Gateway Considerations

Many enterprises deploy security gateways to restrict the Internet access. These security gateways may operate as packet filters or application layer gateways. Some products support deep inspection and try to determine the actual protocol used in the communication channels. They might even try to decrypt and analyze any encrypted communication.

16.2.1. Standalone/Master GSM

While many protocols used by the GSM are only used internally, some protocols require access to the Internet. These might be filtered by such a security gateway. When deploying the GSM as standalone appliance or master the GSM needs to be able to access the Greenbone security feed. The Greenbone security feed may be access directly via port 24/tcp or 443/tcp or using a proxy. In all cases the actual protocol used is SSH. Even when using the port 443/tcp or a HTTP proxy the protocol used is SSH.

A deep inspection firewall might detect the usage of the SSH protocol running on port 443/tcp and could drop or block the traffic. If the security gateway would try to decrypt the traffic using man-in-the-middle techniques the communication of the GSM and the Feed server will fail. The SSH protocol using bidirectional authentication based on public keys will prevent any man-in-the-middle approach by terminating the communication.

Additional protocols which might need Internet access are DNS and NTP. Both DNS and NTP may be configured to use internal DNS and NTP servers.

16.2.2. Sensor GSM

If security gateways are deployed between the master and the sensor the security gateway must permit SSH (22/tcp) and GMP (9390/tcp) connections from the master to the sensor.