Welcome to our community!

Support X-Forwarded-For headers

CJTC

3 years ago
updated 2 months ago
Considering for Future Release

Due to insurance and industry requirements we are required to host CW Control behind an approved WAF/Proxy. But in doing so all WEB activity is logged with the WAF/proxy IP instead of the endclient IP. This decreases the value of the built-in CW Control logging and triggers functionality.

Support has confirmed that CW Control does not currently support X-Forwarded-For (XFF) which is a de-facto web standard for passing client IPs through web Proxies. Can we get this header feature added? https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-For

I was told Control is unable to read the header response so I wouldn't be able to manually enable it via "Security Toolkit" > "ExtraSecurityHttpHeadersList".

Thanks,

Pinned replies

Sean White Team Member

3 years ago
Answer
Considering for Future Release

Thanks for your request, after speaking with our Architecture team I have registered this request for future consideration.

The key concern is that the product would have to become much more aware of the reverse proxy sitting in front of it in order to properly handle the traffic in a secure manner.

Reply Link

Replies 27

Oldest first
Newest first Oldest first

Sean White Team Member

3 years ago
Answer
Considering for Future Release

Thanks for your request, after speaking with our Architecture team I have registered this request for future consideration.

The key concern is that the product would have to become much more aware of the reverse proxy sitting in front of it in order to properly handle the traffic in a secure manner.

Reply Link

Cory Silva

1 year ago

In light of the recent CVE I think this should get a lot more attention. I appreciate you guys coming out with the 23.9.8 patch quickly, but we need more tools in our toolbox to mitigate attacks.

User Story
As a MSP who is under constant slow distributed attacks it would be nice to use fail2ban at the proxy or waf level so that I can mitigate attacks.

Acceptance Criteria:
1. Log x-real-ip or x-forwarded-for header
2. Trigger actions should have access to these header values for mail and http requests

3. Splunk extension should have access to these header values as well

Example Usage:
1. Attacker attempts one login attempt every minute from a single IP address.
2. Screenconnect logs the failed attempt including the attackers ip address via headers mentioned above.

2a. MSP configures trigger or splunk extension to forward this security event to another system.

3. In this other system MSP can take this log and implement some fail2ban or similar logic for this IP and rest a little easier. (this will facilitate both on-prem and cloud architectures)

Service Flow:
www ---443---> firewall ---443---> reverse proxy ---8040---> ScreenConnect ---443---> SIEM ---> firewall block

Reply Link

Scott H.

1 year ago

I'll second (or third?) the request that this be given immediate attention. You don't even have to go all-in on the integration and proxy trust. I'd be happy if you just logged the x-real-ip or x-forwarded-for header and included it in the audit report. Call it a "proxy reported IP" line or something.

Reply Link

Chris M

1 year ago

In light of the events this past week, this request needs to be a top priority.

Reply Link

Davison

1 year ago

As others have stated, ConnectWise needs to seriously up their game when it comes to security. Support for basic identifying headers is something that should have been standard long ago. Without this the audit logs are virtually useless for anyone hosting an instance behind a proxy. It also means that we can't block or allow anything based on IP either.

PLEASE, PLEASE listen to your customers who are trying to help you make the product better. Now that you have dropped Linux and Mac server support years ago there needs to a consistent push to increase security (and to offer features that customers can use to enhance security even further).

Reply Link

SConsulting

1 year ago

Due to the recent CVE this definitely needs to be implemented ASAP. We use Cloudflare WAF to protect the web interface of Screenconnect and without support for XFF headers, we don't see the real IP addresse in the audit logs. Furthermore, the IP restriction feature for the host and admin pages doesn't work, as it only sees the connecting IPs of Cloudflare's infrastructure.

It'd be best if you could make the proxy IP header a custom variable so, it can be set to something other than X-Forwarded-For. For example, Cloudflare delivery the connecting IP in the header CF-Connecting-IP which is more secure as it can't be spoofed:

https://developers.cloudflare.com/fundamentals/reference/http-request-headers/

Reply Link

Cory Silva

1 year ago

@SConsulting has a good point. We probably just need all headers, since the Cloud CDN/WAFs all have they own headers. Plus these services have many other useful headers like geolocation that could easily enable other alerting.

CloudFront-Viewer-Address
CF-Connecting-IP

Fastly-Client-IP
etc....

I think the ask here is relatively small - please give us the HTTP headers in the logs and triggers.

Reply Link

Davison

1 year ago

@SConsulting support for custom variables in headers is a great idea, but it's important to also support the proper parsing of X-Forwarded-For. It's critical to grab the last X-Forwarded-For header and the rightmost value in the list (if there are multiple IPs). This would be the most effective at preventing any spoofed value from passing through if you don't have access to a custom header.

See: https://adam-p.ca/blog/2022/03/x-forwarded-for/

Reply Link

FurrerW

1 year ago

It seems irresponsible at this point to not implement this basic feature.

Reply Link

MilesR

1 year ago

With recent events occurring, this request needs to be implemented as soon as possible. It is irresponsible to not do so with the uptick of cyber-attacks happening lately.

Reply Link