SecurityRiskAdvisors / VECTR

VECTR is a tool that facilitates tracking of your red and blue team testing activities to measure detection and prevention capabilities across different attack scenarios
1.39k stars 164 forks source link

CAS throwing error when using reverse proxy. #58

Closed miguelagfreitas closed 4 years ago

miguelagfreitas commented 4 years ago

Hello,

I've been trying to set up a proxy to redirect traffic to VECTR. Under a normal installation, with the pre-installed certificates, everything works fine.

However, by adding a proxy to the situation, although I am correctly changing the VECTR_EXTERNAL_HOSTNAME to my external hostname, CAS is throwing the "Application Not Authorized to use CAS" error.

Version is sra-vectr-runtime-5.5.7-ce. Using the pre-installed certificates on VECTR, and my proxy has its own certificate for TLS.

Infortunatelly, I'm not familiar with the CAS solution, and don't really know how to pinpoint the error.

Could you please give me some pointers?

Thank you.

carlvonderheid commented 4 years ago

Can you try set both the VECTR_HOSTNAME and VECTR_EXTERNAL_HOSTNAME to the FQDN of the expected domain for your VECTR instance?

Can you confirm the redirect from the proxy to your VECTR host is the FQDN and not the IP address?

If your proxy is running on a different host than VECTR, you'll need to make sure that the VECTR_EXTERNAL_HOSTNAME is resolvable from the server VECTR is on.

miguelagfreitas commented 4 years ago

Both VECTR_HOSTNAME and VECTR_EXTERNAL_HOSTNAME are set to the FQDN of VECTR instance. The proxy is running on the same host.

Additionally, the redirect is rule is to the FQDN as well.

miguelagfreitas commented 4 years ago

I've pinned the problem down to the serviceId field in the /etc/cas/services/vectrservice-1.json file. The problem here is that the serviceId field expects the exposed docker instance port:

"serviceId": "https://FQDN:8081/sra-purpletools-webui/app\\?client_name=CasClient"

While my proxy is listening on port 443, redirecting to 8081 internal.

This results in the following URL for authentication:

https://FQDN/cas/login?service=https%3A%2F%2FFQDN%2Fsra-purpletools-webui%2Fapp%3Fclient_name%3DCasClient

However, this doesnt match the serviceId field, as it does not contain the internal exposed port. By manually changing this, it seems to be working correctly:

https://FQDN/cas/login?service=https%3A%2F%2FFQDN:8081%2Fsra-purpletools-webui%2Fapp%3Fclient_name%3DCasClient

Is there any way to set this field correctly in the setup process?

Thank you, Miguel

thebleucheese commented 4 years ago

Good catch, we missed that extra logic in our configuration template.

In your VECTR deploy dir you should see a user/ directory. If you create a directory confdtemplates/ inside user/ and put the file inside the attached zip in <vectr_deploy_dir>/user/confdtemplates/ you can modify it to fit your use case for now. This will overwrite the existing configuration template on container startup.

We have some logic in there you can see that fixes this issue for port 80/443 when that's set as the VECTR_PORT but we probably need an override for that when using an external load balancer or reverse proxy. We'll try to get a fix in for that once we've tested all the scenarios we need to cover.

vectrservice-1.zip

Additional notes: The following features are currently undocumented/unsupported until this newer deployment model of the application is more mature, but you can also add custom startup shell scripts to <vectr_deploy_dir>/user/startup/vectr Scripts in this directory will be executed with run-parts and will be run after confd configuration is applied, after certificates are created, but before any container services are started. This is an effort to support more advanced configurations. The confdtemplates override above should enable you to make the changes you want, however. You shouldn't need to create any custom shell scripts. In case you want to see the logic for the existing container configuration it's in /opt/vectr/release/scripts/docker-entrypoint.d/1_configure inside the Tomcat container.

mikkos1 commented 4 years ago

@thebleucheese I'm having exactly same issue with AWS ALB in the front of VECTR instance. I've tried the suggested solution but that file doesn't seem to have any impact to the serviceId.

LB listens on port 443 and forwards requests to VECTR instance 8081 (also tried 443 on this side). If I modify the request manually by adding VECTR instance port, it works.

Image version is the most recent one (5.5.7).

How that file should be exactly modified?

thebleucheese commented 4 years ago

The easiest option for right now is to hard-code the serviceId in the vectrservice-1.tmpl file to your instance's URL without the port. This file can then be placed in <vectr_deploy_dir>/user/confdtemplates/

In this example I removed the logic in the service template.

{
  "@class": "org.apereo.cas.services.RegexRegisteredService",
  "serviceId": "https://FQDN/sra-purpletools-webui/app\\?client_name=CasClient",
  "name": "VECTR",
  "id": {{getv "/vectr/port" "8081"}},
  "theme": "sra-theme",
  "attributeReleasePolicy": {
    "@class": "org.apereo.cas.services.ReturnAllAttributeReleasePolicy"
  },
  "accessStrategy": {
    "@class": "org.apereo.cas.services.DefaultRegisteredServiceAccessStrategy",
    "enabled": true,
    "ssoEnabled": false,
    "delegatedAuthenticationPolicy": {
      "@class": "org.apereo.cas.services.DefaultRegisteredServiceDelegatedAuthenticationPolicy",
      "allowedProviders": [ "java.util.ArrayList", [ "Microsoft", "Office365" ] ]
    }
  }
}
mikkos1 commented 4 years ago

@thebleucheese a-ha, the port removal did the trick. Thanks! :)

chrisnewmanuk commented 4 years ago

I had the same issue and the override config from @thebleucheese worked a treat

mill25joe commented 4 years ago

Hello, I believe I am having the same issue but cannot seem to get it to work. My AWS/Cloud Team wants me to use Tomcat Default port 8443 and has set up in my .env HOSTNAME=FQDN PORT=8443 VECTR_External_HOSTNAME=ALB_CName COMPOSE_PROJECT_NAME=CompanyVectr

I have created /user/confdtemplates/vectrservice-1.tmpl { "@class": "org.apereo.cas.services.RegexRegisteredService", "serviceId": "https://MyVectFQDN/sra-purpletools-webui/app\\?client_name=CasClient", "name": "VECTR", "id": {{getv "/vectr/port" "8443"}},

Without the vectrservice-1.tmpl I get an expired cert error, with the .tmpl I get a Not Auth to use CAS

thebleucheese commented 4 years ago

I think you need to change your service.tmpl serviceId URL from "MyVectrFQDN" to "ALB_CName" ... the VECTR_EXTERNAL_HOSTNAME is what your browser actually sees when accessing the site. CAS does some redirects, but they're in browserspace. That serviceID is what tells your browser where it needs to redirect during the authentication flows and it whitelists it so that CAS will accept it. Right now it's likely redirecting from your Load Balanced CName but with the settings you have, it's expecting the internal FQDN.

We're in the process of reworking our Authentication so hopefully that will resolve most of the configuration challenges that exist with CAS.

initstring commented 4 years ago

@thebleucheese - THANK YOU! The .tmpl file did the trick for me as well. I've installed Vectr inside GCP using IAP w/ an SSL proxy in case that's helpful for anyone else.

Much appreciated!

mill25joe commented 4 years ago

Thank you, @thebleucheese. I ended up changing the serviced URL to the CNAME:8443 and got it to work.

"serviceId": "https://ALB_CNAME:8443/sra-purpletools-webui/app\\?client_name=CasClient",

carlvonderheid commented 4 years ago

This should be fixed in the new 5.5.8 release.

We added the variable VECTR_EXTERNAL_PORT to the .env file. This should be used along with VECTR_EXTERNAL_HOSTNAME to define the listening port and FQDN of your proxy.

VECTR_EXTERNAL_HOSTNAME=PROXY_FQDN VECTR_EXTERNAL_PORT=8443

initstring commented 4 years ago

@carlvonderheid Removing the custom .tmpl file and adding the VECTR_EXTERNAL_PORT into .env on an upgraded version actually causes the issue to repeat itself. Adding back in the tmpl file fixes things. This is using a fairly special setup with GCP and IAP with no public IP address.

We're fine to use with the manual patch, but just wanted to update you.

Thanks!

carlvonderheid commented 4 years ago

This might be worth jumping on a zoom meeting so we can take a look. Assuming you're up for this, can you send your contact info to vectr@securityriskadvisors.com and we will set up a meeting? Just put Dev Team Request in the subject line.

Thanks!