UI authentication problems (Cookie missing or bad)

Building from Source and Advanced Topics
1

I have a Community Edition built from source. I can login into UI, but occasionally it logs me out. And sometimes I can login again right after, sometimes I can’t.
The response is:
Authentication required: handler_send_reauthentication:479 (GSA 22.07.0)
Cookie missing or bad. Please login again.

What I have tried:

  1. use different browsers (chrome, firefox), incognito and usual mode
  2. clear cookies
  3. connect by nginx proxy, connect without proxy by IP and port (192.168.111.111:9392)
  4. set logs level of gsad to maximum (128)
  5. change gsad systemd unit file (/etc/systemd/system/gsad.service), add --timeout=1440 to the ExecStart line

Still have this problem.
The only suspicion I have is VPN (I can’t connect to greenbone server without VPN)
I saw people discuss a similar problem and blame “too large MTU”

Please help me. If too large MTU can be relevant in my case please explain why and how to solve it.

1 Like
2

Hi,

this is caused by using nginx as a proxy. See Stuck on Login loop on the Login page - #3 by bricks

1 Like
3

Unfortunately not. I’m connecting by IP:port bypassing nginx and have the same problem.

4

This means that the session cookie is not available or has a mismatch. Check the network console in your browser if it is send to gsad. The cookie is named GSAD_SID.

1 Like
5

In other words problem may be in my browser? I have tried to clear cookies , reload a page and login again. Nothing.

I’m checking developing tools/network in my browser.
There are normal (200) request, Set-Cookie: GSAD_SID=###########; expires=Wed, 07 Feb 2024 ##:##:## GMT; max-age=###; path=/; HTTPonly; SameSite=strict
and a bad one (401), Set-Cookie:
GSAD_SID=0; expires=Wed, 07 Feb 2024 ##:##:## GMT; path=/; HTTPonly; SameSite=strict

6

It’s somewhere in your http request/response path which includes the browser of course.

That’s the response from gsad. You need to look at the next request to gsad.

That’s the response of gsad if the session id doesn’t match. You need to look at the request for this reponse.

See https://github.com/greenbone/gsa/issues/2973#issuecomment-857582302

2 Likes
7

I’ve check connection without VPN and problem was solved!
So, any ideas why our VPN (we use cloudflare zero trust) may cause cookies issue?

8

There are many reasons. Judging simply from it’s name, Cloudflare Zero Trust likely applies various security policies that can include inspecting and filtering HTTP headers. Also, VPNs and load balancers can affect how traffic is routed, potentially causing session persistence issues if the session association is lost. You need to verify the settings with CloudFlare Zero Trust. :slight_smile:

1 Like
9

And if in doubt: Contacting the support of this provider would be another option.

1 Like
10

Have taken a into this as we’ve been seeing the same issue, in our case we are using -

  • Cloudflare Zero Trust (using 2x for failover/load balance)
  • Traefik (using 2x for failover/load balance)
  • gsad on Docker

The issue for us was that we could sometimes login, get a few pages and then we’d get logged out in a way that is consistent with the various descriptions -

The description on the Azure ticket (73) describes a solution that involves adding the X-Real-IP header but does not explain why this works.

A hint for us came when we noticed different source (internal) ip-addresses logged when users authenticated - it appears the gsad session is bound with the observed client IP address and when you have a load-balancer in front of gsad the internal client-address that connects can change which in turn then invalidates the auth session token.

Have taken a look through the gsad code but do not know the code well enough to be able to pinpoint and confirm this - but empirically setting the X-Real-IP address in our setup does indeed resolve the issue.

Several things we tried -

  • We tried setting the X-Real-IP using a Cloudflare transform rule - does not work out because CF treat this header as protected
  • We tried using Traefik header manipulation rules - does not work out because Traefik does not do dynamic rewrites

We ended up using a Traefik plugin to rewrite the X-Real-IP header using the CF-Connecting-IP header as the input value - this is similar to writing an Nginx rule or applying an upstream load-balancer rule that assigns a X-Real-IP that does not jump around.

Happy days.

11

A hint for us came when we noticed different source (internal) ip-addresses logged when users authenticated - it appears the gsad session is bound with the observed client IP address and when you have a load-balancer in front of gsad the internal client-address that connects can change which in turn then invalidates the auth session token.

I’m having similar problems after switching our users to ZScaler ZPA.
Is there any way to relax the client IP binding?
Thanks

12

I do not think so. Again I don’t know this code base but it does look like a login-session is bound to client_address - if someone else knows better please correct me.

@BarryG in your case, you may want to consider placing Nginx in front of Greenbone that takes the Zscaler XFF header and writes it to X-Real-IP, where the X-Real-IP header name is hard coded into the gasd code - would be nice if this header was configurable.

This is where the gsad code makes it look like client_address is bound to the login session object -

2 Likes
13

Thanks.
We found that our ZPA traffic was bouncing across multiple ZPA instances/regions, so we were able to pin it down, for the GVM web service, to a single instance and thus eliminated this problem (at the cost of a single point of failure for this traffic).

14

Nonetheless, IMHO, this should be a configurable feature. If there is a feature request or bug tracker I should submit this to, please link it.
thanks

15

Feature requests like this can be opened in the GitHub issue tracker of the component in question (unlikely that this will get noticed by the responsible development team here). For the topic above this would be:

1 Like