Support X-Forwarded-For headers
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,
Answer
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.
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
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.
In light of the events this past week, this request needs to be a top priority.
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).
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/
@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.
@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.
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.
100% agree with above, we are already running SC on prem behind an NGINX reverse proxy.
We used custom locations and IP filtering to block all access to login/admin except from whitelisted addresses. However the downside of this is that we have lost the public IP info form within SC.
We really need this implemented ASAP.
@swhite I understand that everyone at Connectwise has probably been very busy the past week. It would be great to get an update to see if this has had any further consideration. For those of us running behind a reverse proxy, this is vital at this point.
I just noticed that this is even mentioned in Mandiant's Remediation + Hardening Guide from, on page 7:
● Enable X-Forwarded-For Request Header Logging. If a load balancer or reverse proxy server is
placed in front of ScreenConnect server(s), ensure that the X-Forwarded-For field is enabled to
capture the true external IP address associated with inbound requests.
Thanks for linking to this from a Connectwise source. This appears to be sanctioned by CW if they're hosting the document so I hope this gets implemented soon.
@SConsulting That's interesting. Hopefully that means it's already in the works, but likely is just an assumption by Mandiant that they already supported it. Hopefully it's coming soon. It really is essential at this point and should take precedence over any other UI enhancements or features.
I found it strange that they explicitly mentioned it in the document. Either assumption or the guide was written mainly on general best practices.
Hi Everyone,
I am waiting for feedback from my architecture team, as you can imagine they have had a busy couple of weeks, so their responses have been delayed. As soon as I have more information, I'll post it here.
Hi everyone,
Our architecture team has some ideas on how this could be implemented in the product, but we'll need to do some additional discovery to determine scope and risk. If we determine it is something we can accomplish, we'll schedule it for development, but as of now no timeframe for that.
I understand full implementation of this will be tricky. Particularly when it comes to trusting the proxy enough for ScreenConnect to act on the relayed headers.
But please, PLEASE, at least add the x-forwarded-for header IP to the logs. Tag it as an information only, proxy-reported IP. A simple text entry with no action. That much should be a very simple addition.
Are there any updates on this? I too would like to see this feature implemented.
I'm looking for this feature as well, I can't believe this was requested 3 years ago and there doesn't seem to be any movement on it.
I'm just going to bring up SCConsulting's earlier comment,
I just noticed that this is even mentioned in Mandiant's Remediation + Hardening Guide from, on page 7:
● Enable X-Forwarded-For Request Header Logging. If a load balancer or reverse proxy server is
placed in front of ScreenConnect server(s), ensure that the X-Forwarded-For field is enabled to
capture the true external IP address associated with inbound requests.
It's been almost a year now since Connectwise posted this Hardening guide that includes a bullet point to enable a feature that doesn't exist. Has there been ANY progress on getting this added? Even just the logging aspect?
Customer support service by UserEcho
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.