openvas deploy into openshift v3.5

[gvv90]

Hi, Mike.

I'm getting this error during deploy on openshift.

I will describe the tasks I did:

1. Push docker image to my local repository.
2. Create a project in openshift with that image.
3. Create a persistent volume attached to /var/lib/openvas/mgr/.
4. Create a route to get the service. (Port 443 and 9390)

The pod is running but when I'm trying to connect to the console I can't. I'm getting: "502 Bad Gateway
The server returned an invalid or incomplete response".

I will atach the errors.

Thank you.

==> /var/log/openvas/openvassd.messages <==
[Fri Dec 15 17:48:30 2017][858] openvassd 5.1.1 started
[Fri Dec 15 17:49:43 2017][1451] Client closed the communication
[Fri Dec 15 17:50:00 2017][858] Received the Terminated signal
[Tue Jan 9 00:52:23 2018][25] openvassd 5.1.1 started
[Tue Jan 9 00:52:55 2018][118] Client not present

==> /var/log/openvas/openvasmd.log <==
md main:MESSAGE:2018-01-09 16h18.31 utc:367: OpenVAS Manager version 7.0.1 (DB revision 184)
md main: INFO:2018-01-09 16h18.31 utc:367: rebuild_nvt_cache_retry: Reloading NVT cache
md main: INFO:2018-01-09 16h18.31 utc:368: update_or_rebuild_nvt_cache: Rebuilding NVT cache
base gpgme:MESSAGE:2018-01-09 16h18.34 utc:368: Setting GnuPG dir to '/var/lib/openvas/openvasmd/gnupg'
base gpgme:MESSAGE:2018-01-09 16h18.34 utc:368: Using OpenPGP engine version '2.1.11'
md main: INFO:2018-01-09 16h18.38 utc:368: Updating NVT cache.

==> /var/log/openvas/openvassd.messages <==
[Tue Jan 9 16:19:23 2018][385] Client closed the communication

==> /var/log/openvas/gsad.log <==
gsad main:WARNING:2018-01-09 19h01.10 utc:48: MHD: Error: received handshake message out of context
gsad main:WARNING:2018-01-09 19h01.10 utc:48: MHD: Error: received handshake message out of context
gsad main:WARNING:2018-01-09 21h10.07 utc:48: MHD: Error: received handshake message out of context

[mikesplain]

Hi @gvv90, can you provide some more details?

• Full log of the container running
• CPU and Memory allotment provided to the vm

Thanks!

[gvv90]

Here Is the information:

[root@localhost ~]# oc project openvas
Already on project "openvas"
[root@localhost ~]# oc logs openvas-2-x8324
Testing redis status...
Redis not yet ready...
Redis ready.
Checking for empty volume
Restarting services

• Restarting openvas-scanner openvassd
  ...done.

• Restarting openvas-manager openvasmd
  ...done.

• Restarting openvas-gsa gsad
  ...done.
  Reloading NVTs
  Rebuilding NVT cache... done.
  Checking setup
  openvas-check-setup 2.3.7
  Test completeness and readiness of OpenVAS-9

  Please report us any non-detected problems and
  help us to improve this check routine:
  http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss

  Send us the log-file (/tmp/openvas-check-setup.log) to help analyze the problem.

  Use the parameter --server to skip checks for client tools
  like GSD and OpenVAS-CLI.

Step 1: Checking OpenVAS Scanner ...
OK: OpenVAS Scanner is present in version 5.1.1.
OK: redis-server is present in version v=3.0.6.
OK: scanner (kb_location setting) is configured properly using the redis-server socket: /var/run/redis/redis.sock
OK: redis-server is running and listening on socket: /var/run/redis/redis.sock.
OK: redis-server configuration is OK and redis-server is running.
OK: NVT collection in /var/lib/openvas/plugins contains 56942 NVTs.
WARNING: Signature checking of NVTs is not enabled in OpenVAS Scanner.
SUGGEST: Enable signature checking (see http://www.openvas.org/trusted-nvts.html).
OK: The NVT cache in /var/cache/openvas contains 56942 files for 56942 NVTs.
Step 2: Checking OpenVAS Manager ...
OK: OpenVAS Manager is present in version 7.0.1.
OK: OpenVAS Manager database found in /var/lib/openvas/mgr/tasks.db.
OK: Access rights for the OpenVAS Manager database are correct.
OK: sqlite3 found, extended checks of the OpenVAS Manager installation enabled.
OK: OpenVAS Manager database is at revision 184.
OK: OpenVAS Manager expects database at revision 184.
OK: Database schema is up to date.
OK: OpenVAS Manager database contains information about 56942 NVTs.
OK: At least one user exists.
OK: OpenVAS SCAP database found in /var/lib/openvas/scap-data/scap.db.
OK: OpenVAS CERT database found in /var/lib/openvas/cert-data/cert.db.
OK: xsltproc found.
Step 3: Checking user configuration ...
WARNING: Your password policy is empty.
SUGGEST: Edit the /etc/openvas/pwpolicy.conf file to set a password policy.
Step 4: Checking Greenbone Security Assistant (GSA) ...
OK: Greenbone Security Assistant is present in version 7.0.2.
OK: Your OpenVAS certificate infrastructure passed validation.
Step 5: Checking OpenVAS CLI ...
OK: OpenVAS CLI version 1.4.5.
Step 6: Checking Greenbone Security Desktop (GSD) ...
SKIP: Skipping check for Greenbone Security Desktop.
Step 7: Checking if OpenVAS services are up and running ...
OK: netstat found, extended checks of the OpenVAS services enabled.
OK: OpenVAS Scanner is running and listening on a Unix domain socket. OK: OpenVAS Manager is running and listening on all interfaces.
OK: Greenbone Security Assistant is running and listening on all interfaces.
OK: Greenbone Security Assistant is listening on port 443, which is the default port.
Step 8: Checking nmap installation ...
WARNING: Your version of nmap is not fully supported: 7.01
SUGGEST: You should install nmap 5.51 if you plan to use the nmap NSE NVTs.
Step 10: Checking presence of optional tools ...
OK: pdflatex found.
OK: PDF generation successful. The PDF report format is likely to work.
OK: ssh-keygen found, LSC credential generation for GNU/Linux targets is likely to work.
OK: rpm found, LSC credential package generation for RPM based targets is likely to work.
OK: alien found, LSC credential package generation for DEB based targets is likely to work.
OK: nsis found, LSC credential package generation for Microsoft Windows targets is likely to work.

It seems like your OpenVAS-9 installation is OK.

If you think it is not OK, please report your observation
and help us to improve this check routine:
http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss
Please attach the log-file (/tmp/openvas-check-setup.log) to help us analyze the problem.

Tailing logs
==> /var/log/openvas/gsad.log <==
gsad main:MESSAGE:2017-12-15 17h41.11 utc:881: Starting GSAD version 7.0.2
gsad main:MESSAGE:2017-12-15 17h41.11 utc:881: main: Locale for gettext extensions set to "C", gettext translations are disabled.
gsad xslt:WARNING:2017-12-15 17h41.11 utc:881: init_language_lists: Failed to open locale directory "/usr/share/openvas/gsa/locale": No such file or directory
gsad main:MESSAGE:2018-01-09 22h03.12 utc:47: Starting GSAD version 7.0.2
gsad main:MESSAGE:2018-01-09 22h03.12 utc:47: main: Locale for gettext extensions set to "C", gettext translations are disabled.
gsad xslt:WARNING:2018-01-09 22h03.12 utc:47: init_language_lists: Failed to open locale directory "/usr/share/openvas/gsa/locale": No such file or directory

==> /var/log/openvas/openvasmd.log <==
base gpgme:MESSAGE:2018-01-09 22h03.28 utc:84: Setting GnuPG dir to '/var/lib/openvas/openvasmd/gnupg'
base gpgme:MESSAGE:2018-01-09 22h03.29 utc:84: Using OpenPGP engine version '2.1.11'
md main: INFO:2018-01-09 22h03.29 utc:84: Updating NVT cache.
md otp:MESSAGE:2018-01-09 22h03.29 utc:84: Waiting for scanner to load NVTs: 28850 / 56942.
md main: INFO:2018-01-09 22h03.39 utc:101: update_or_rebuild_nvt_cache: Rebuilding NVT cache
base gpgme:MESSAGE:2018-01-09 22h03.40 utc:101: Setting GnuPG dir to '/var/litop - 09:31:00 up 62 days, 20:42, 3 users, load average: 0.83, 0.44, 0.42

The information about the machine Is:

Type: physical
Openshift installation: Standalone (single node)
Memory: 32Gb
CPU: Core i7 3th Gen.

[gvv90]

I had created a route to acces openvas console:

[root@localhost ~]# oc describe route openvas
Name: openvas
Namespace: openvas
Created: About an hour ago
Labels:
Annotations: openshift.io/host.generated=true
Requested Host: openvas-openvas.router.default.svc.cluster.local
exposed on router router about an hour ago
Path:
TLS Termination:
Insecure Policy:
Endpoint Port: 443-tcp

Service: openvas
Weight: 100 (100%)
Endpoints: 10.128.1.118:9390, 10.128.1.118:443

[root@localhost ~]# curl -I https://10.128.1.118
curl: (60) Peer's Certificate issuer is not recognized.
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.

[mikesplain]

This may be related to the hostname issue discussed here: #169

[rblaine95]

I'm currently trying to deploy this onto OpenShift Origin 3.9 and, so far, haven't gotten it to get past the Rebuilding NVT cache stage as it keeps restarting with no error log.

Here's the template manifest I'm using:

#------------------------------------------------------------------------------#
kind: Template
apiVersion: v1
metadata:
  name: openvas
  labels:
    application: openvas
objects:
#------------------------------------------------------------------------------#
- kind: ServiceAccount
  apiVersion: v1
  metadata:
    name: openvas
#------------------------------------------------------------------------------#
- kind: DeploymentConfig
  apiVersion: v1
  metadata:
    name: openvas
    labels:
      application: openvas
  spec:
    strategy:
      type: Rolling
    triggers:
    - type: ConfigChange
    replicas: 1
    selector:
      name: openvas
    template:
      metadata:
        labels:
          name: openvas
      spec:
        containers:
        - name: openvas
          image: mikesplain/openvas:${VERSION}
          ports:
          - containerPort: 443
            protocol: TCP
            name: web
          - containerPort: 9390
            protocol: TCP
            name: management
          imagePullPolicy: Always
          livenessProbe:
            httpGet:
              path: /
              port: 443
              scheme: HTTP
            successThreshold: 1
            failureThreshold: 10
            timeoutSeconds: 5
            periodSeconds: 5
            initialDelaySeconds: 30
          readinessProbe:
            httpGet:
              path: /
              port: 443
              scheme: HTTP
            successThreshold: 1
            failureThreshold: 10
            timeoutSeconds: 5
            periodSeconds: 5
            initialDelaySeconds: 30
          resources:
            limits:
              cpu: ${CPU_LIMIT}
              memory: ${MEMORY_LIMIT}
          terminationMessagePath: /dev/termination-log
          env:
          - name: PUBLIC_HOSTNAME
            valueFrom:
              fieldRef:
                fieldPath: metadata.name
          - name: OV_PASSWORD
            value: ${PASS}
          volumeMounts:
          - name: data
            mountPath: /var/lib/openvas/mgr
        serviceAccountName: openvas
        restartPolicy: Always
        dnsPolicy: ClusterFirst
        volumes:
          - name: data
            persistentVolumeClaim:
              claimName: openvas-data-pvc
#------------------------------------------------------------------------------#
- kind: PersistentVolumeClaim
  apiVersion: v1
  metadata:
    name: openvas-data-pvc
    labels:
      application: openvas
  spec:
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: 10Gi
#------------------------------------------------------------------------------#
- kind: Service
  apiVersion: v1
  metadata:
    name: openvas-svc
    labels:
      application: openvas
  spec:
    ports:
    - port: 443
      name: web
      targetPort: 443
      protocol: TCP
    - port: 9390
      name: management
      targetPort: 9390
      protocol: TCP
    selector:
      name: openvas
    type: ClusterIP
    sessionAffinity: None
  status:
    loadBalancer: {}
#------------------------------------------------------------------------------#
- kind: Route
  apiVersion: v1
  metadata:
    name: openvas-route
    labels:
      application: openvas
  spec:
    port:
      targetPort: web
    to:
      kind: Service
      name: openvas-svc
    tls:
      termination: Passthrough
      insecureEdgeTerminationPolicy: Redirect
#------------------------------------------------------------------------------#
parameters:
- name: PASS
  displayName: Admin Password
  from: "[a-zA-Z]{10}"
  generate: expression
- name: VERSION
  displayName: OpenVAS Version
  value: "9"
- name: CPU_LIMIT
  displayName: OpenVAS CPU Limit
  value: "60"
- name: MEMORY_LIMIT
  displayName: OpenVAS Memory Limit
  value: 5Gi

I run the deployment with an openvas Service Account which has the privileged Security Context Constraint, which allows the deployment to to host mount and use anyuid.

[rblaine95]

Seems like it was the liveness/readiness probes that were breaking the deployment.
After I took them out I got an SSL error, it was the hostname environment variable.
Fixed by setting the hostname variable to the value of the ROUTE_HOST variable

#------------------------------------------------------------------------------#
kind: Template
apiVersion: v1
metadata:
  name: openvas
  labels:
    application: openvas
objects:
#------------------------------------------------------------------------------#
- kind: ServiceAccount
  apiVersion: v1
  metadata:
    name: openvas
#------------------------------------------------------------------------------#
- kind: DeploymentConfig
  apiVersion: v1
  metadata:
    name: openvas
    labels:
      application: openvas
  spec:
    strategy:
      type: Rolling
    triggers:
    - type: ConfigChange
    replicas: 1
    selector:
      name: openvas
    template:
      metadata:
        labels:
          name: openvas
      spec:
        containers:
        - name: openvas
          image: mikesplain/openvas:${VERSION}
          ports:
          - containerPort: 443
            protocol: TCP
            name: web
          - containerPort: 6379
            protocol: TCP
            name: redis
          - containerPort: 9390
            protocol: TCP
            name: management
          imagePullPolicy: Always
          resources:
            limits:
              cpu: ${CPU_LIMIT}
              memory: ${MEMORY_LIMIT}
          terminationMessagePath: /dev/termination-log
          env:
          - name: PUBLIC_HOSTNAME
            value: ${ROUTE_HOST}
          - name: OV_PASSWORD
            value: ${PASS}
          volumeMounts:
          - name: data
            mountPath: /var/lib/openvas/mgr
        serviceAccountName: openvas
        restartPolicy: Always
        dnsPolicy: ClusterFirst
        securityContext:
          privileged: true
          fsGroup: 0
        volumes:
          - name: data
            persistentVolumeClaim:
              claimName: openvas-data-pvc
#------------------------------------------------------------------------------#
- kind: PersistentVolumeClaim
  apiVersion: v1
  metadata:
    name: openvas-data-pvc
    labels:
      application: openvas
  spec:
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: 10Gi
#------------------------------------------------------------------------------#
- kind: Service
  apiVersion: v1
  metadata:
    name: openvas-svc
    labels:
      application: openvas
  spec:
    ports:
    - port: 443
      name: web
      targetPort: 443
      protocol: TCP
    - port: 9390
      name: management
      targetPort: 9390
      protocol: TCP
    - port: 6379
      name: redist
      targetPort: 6379
      protocol: TCP
    selector:
      name: openvas
    type: ClusterIP
    sessionAffinity: None
  status:
    loadBalancer: {}
#------------------------------------------------------------------------------#
- kind: Route
  apiVersion: v1
  metadata:
    name: openvas-route
    labels:
      application: openvas
  spec:
    host: ${ROUTE_HOST}
    port:
      targetPort: web
    to:
      kind: Service
      name: openvas-svc
    tls:
      termination: Passthrough
      insecureEdgeTerminationPolicy: Redirect
#------------------------------------------------------------------------------#
parameters:
- name: PASS
  displayName: Admin Password
  from: "[a-zA-Z]{10}"
  generate: expression
- name: VERSION
  displayName: OpenVAS Version
  value: "9"
- name: CPU_LIMIT
  displayName: OpenVAS CPU Limit
  value: "60"
- name: MEMORY_LIMIT
  displayName: OpenVAS Memory Limit
  value: 5Gi
- name: ROUTE_HOST
  displayName: OpenVAS Hostname route
  value: openvas.apps.example.com

[rblaine95]

Is it really necessary for OpenVAS to rebuild the NVT Cache every time it gets run?
Is there any way to persist the NVT Cache so that it only gets run once?
How about multi-threading the process?

[fredairic]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 30 days if no further activity occurs. Thank you for your contributions.

[fredairic]

This issue has been automatically closed because it has not had recent activity. Issue creator may reopen if the issue still exists. Thank you for your contributions.