Support X-Forwarded-For headers

Avatar
  • updated
  • 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
Avatar
0
Sean White Team Member
  • 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.

Avatar
0
Sean White Team Member
  • 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.

Avatar
3
Cory Silva

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





Avatar
3
Scott H.

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. 

Avatar
2
Chris M

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

Avatar
3
Davison

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).

Avatar
3
SConsulting

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/

Avatar
3
Cory Silva

@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.


    Avatar
    3
    Davison

    @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/

    Avatar
    2
    FurrerW

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

    Avatar
    2
    MilesR

    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. 

    

    Top contributors

    Avatar
    Avatar
    Avatar
    Avatar
    Avatar
    Avatar
    Avatar
    Avatar
    Avatar
    Avatar
    Avatar
    Avatar
    Avatar
    Avatar
    Avatar