@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-AddressCF-Connecting-IP
I think the ask here is relatively small - please give us the HTTP headers in the logs and triggers.
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 StoryAs 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 header2. 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 wellExample 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
Please continue to support and update the linux stream.
I think this issue can be closed since ScreenConnect updated its internal linux web server and it now supports modern TLS encryption algorithms.
This happens because the credentials used to install screenconnect do not have sufficient privileges. Try logging in as a domain admin or some udf group with the right local admin privileges.
Customer support service by UserEcho