openvas on google kubernetes service accessed using internal load balancer

[rakeshzingade]

I have deployed openvas on google container engine. I have created internal LB service to access its UI. I am able to access the UI login page but on login it shows me logged in successful & starts loading graphs. After few secs it redirects me to login page again. With the message "Cookie missing or bad. Please login again."

Unable to figure out the issue.

Following are few traces: gsad running as:

/usr/sbin/gsad --mlisten 127.0.0.1 -m 9390 --gnutls-priorities=SECURE128:-AES-128-CBC:-CAMELLIA-128-CBC:-VERS-SSL3.0:-VERS-TLS1.0 --port=443 --no-redirect --allow-header-host=openvas

No issues/errors/messages logged in to /var/log/openvas/gsad.log or any other log even upon setting up --verbose option.

On browser in debug mode I am seeing 401 Unauthorized error on following omp command https://openvas/omp?cmd=get_aggregate&xml=1&filter=&filt_id=&aggregate_type=task&data_column=&group_column=severity&subgroup_column=&token=e338ba17-2352-4c75-ac0e-40aa5b2d8629

In Application tab of browser debug "Cookies" value initially shows correct token after few secs it shows empty value.

If I deploy same openvas docker image on my local vm it works perfectly as expected. But the same docker image deployed on google kubernetes produces above behavior of redirecting to login page

[jd-rk9]

chown 401 directory?

[harishanchu]

I'm also facing the same issue.

[samos123]

Facing the same issue although I'm just running the docker container on a GCP VM directly exposed through the host VM with no load balancer involved. So it seems to be an OpenVAS related issue.

[raffaeleguidi]

same issue here, deploying in rancher. I guess the problem is the container exposes https only and there's a problem in putting a reverse proxy in front of it with another layer of SSL. It would be so simpler if you could just switch HTTPS_OFF.

[fredairic[bot]]

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.

[DavidHaltinner]

I found a workaround for now. I am using this in an OpenShift Kubernetes environment.

The issue lies in the source NAT'ing that the kubernetes service does, if you disable that source NATing by using a NodePort or a ExternalIP instead of the load balancer type, and you set externalTrafficPolicy: Local , it then works.

So in essence, the container should allow this source NATing somehow in order to work in a kubernetes based environment.

[fredairic[bot]]

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.

[ksandermann]

Facing the same issue on a Kubernetes environment running on Vsphere. I came up with the same workaround of using a NodePort behind a HAProxy tcp-forward. This way Ingresscontrollers and tls-termination cannot be used.

[sabueso]

Same issue here: it's easily reproducible pulling the atomicorp/openvas image, and exposing the container to 443 port.

[fredairic[bot]]

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.

[moxli]

the problem still occurs

[fredairic[bot]]

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.

[itsecforu]

Has anyone solved this problem?

[DavidHaltinner]

I've been using my workaround for a few months. Switch the service to a NodePort, then set externalTrafficPolicy: Local Don't bother with any router then. Connect straight to the node port.

I would still like to see an actual fix, but this workaround has been OK for my specific environment.

[fredairic[bot]]

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[bot]]

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.

[moxli]

Hey everyone,

I faced this issue once again (I already commented on this issue almost exactly one year ago^^).

I was able to find a solution for my specific problem. Hopefully this can help some of you.

First of all I would like to describe the root issue.

GSAD does verify the user based on the X-Real-IP header. https://github.com/greenbone/gsa/blob/e1a59fcc6fc2d3aa16c890141d16b739c00a2a13/gsad/src/gsad_http.c#L877-L901

This header check can also be disabled with the gsad startup parameter --ignore-x-real-ip(Do not use X-Real-IP to determine the client address.). https://fossies.org/linux/gsa/gsad/doc/gsad.8

When using a GKE ingress or service this header is not set to the actual IP of your client device and therefore GSAD blocks the post request. Since GSAD does not allow us to configure the used header (we get X-Forwarded-For* e.g.) one solution I found was that I could use nginx sidecar to write the correct value to X-Real-IP.

*Unfortunately even if we could configure it to X-Forwarded-For we would not be able to use it since this header actually has both the client and ingress IP. This data is from a tcp dump.

root@openvas-0:/# tcpdump -i any -w test.pcap port 9392
root@openvas-0:/# grep -a X-Forwarded-For test.pcap
X-Forwarded-For: <client ip>, <GKE ingress ip>

I would like to describe my working setup now. I was looking for a safe way to expose my OpenVAS running in a GKE cluster via a public IP. Since a vulnerability scanning tool is the perfect place to find exploitable systems I did not want to rely on the GSAD authentication. The perfect solution in my case was the Google IAP(proxy).

My setup looks like this:

Client <> Google IAP <> GKE Ingress <> OpenVAS Service <> Nginx Sidecar <> OpenVAS/GSAD

I have described it further in the following gist: https://gist.github.com/moxli/02397491b90fee26edd8f5036948ea2a

[frakman1]

I just ran the docker run command on my Mac and have this same issue.

$docker run -d -v $(pwd)/data:/var/lib/openvas/mgr/ -p 443:443 -p 9390:9390 --name openvas mikesplain/openvas

Modifying the gsad startup parameter --ignore-x-real-ip doesn't work. I still get this problem.

[moxli]

I was not trying to say that disabling this option will fix the issue.

Setting the parameter (--ignore-x-real-ip) is more of a security setting. The X-Real-IP header can be set by anybody and with this header it's way easier to hijack a users session.

If you steal someones sessions GSAD still checks the source IP of the user and the login will fail if the IP does not match. By default GSAD will check the X-Real-IP header and use it for the source IP. Since this header can be set at anytime by anyone it's easy to bypass the IP check by setting it to the IP of the user you stole the session from. By setting this parameter the system ignores the X-Real-IP header in the IP check.

[frakman1]

Thank you for the explanation. I understand the risk in normal situations with a Man In The Middle attack, but I don't understand why the error is happening in the first place in this case. The website is being accessed from the same machine that the user was logged in from. This isn't the first time docker is used for a webapp and I've never seen this issue with other webapps, so what is the reason for the error Cookie missing or bad. Please login again here?

@mikesplain Please re-open this issue until it is resolved.

[frakman1]

I went on to install openvas 9 on a fresh Ubuntu 18 and saw the same behavior. It comes and goes. It even happens with a fresh installation of Google Chrome so it's definitely some flakiness in the GSAD webpage component and not due to it being in docker.