A third party network security scanner has found our UCP vulnerable to Slowloris. [Edit by xrobau: Fixed link]
Has anyone else re-mediated such a vulnerability?
Our security vendor’s tool recommends various Apache modules in order to patch the vulnerability. We are using the FreePBX distro, so I am hesitant to make too many changes that could compromise future updates (or vice versa).
If a Dev is watching, should I submit a bug fix/feature request? I wanted to check the community before doing that.
Here is the vendor’s solution text:
This attack can be mitigated by; 1) limiting the number of inactive concurrent web server connections a single user may be allowed to maintain, or 2) setting a minimum threshold of data per second a web server connection is allowed to maintain without being dropped.
Examples of applicable apache modules useful for implementing suggested remediation include:
mod_reqtimeout
mod_qos
mod_cband
mod_limitpconn
mod_evasive
mod_security
mod_antiloris
This should not be submitted as a bug fix or feature request without a POC. Often times these scanners create an over abundance of results. In this case the result is talking about Apache. Not UCP. The same attack could be done against index.html with nothing in it.
If you can make a POC then we are all ears.
Summary: There is NO vulnerability.
You also notice that the Wikipedia article says “Apache 1.x and 2.x” are all vulnerable (not FreePBX UCP) and “While there are no reliable configurations of the affected web servers that will prevent the Slowloris attack, there are ways to mitigate or reduce the impact of such an attack. In general these involve increasing the maximum number of clients the server will allow, limiting the number of connections a single IP address is allowed to make, imposing restrictions on the minimum transfer speed a connection is allowed to have, and restricting the length of time a client is allowed to stay connected.”
Note that (for those that don’t want to read the Wikipedia page) Slowloris is a denial of service attack. Not a security vulnerability. It allows a malicious attacker to consume all available sockets on an apache server, making it difficult for normal users to log in.
As Slowloris requires a complete syn/ack path, the source address can’t be spoofed, and can easily be blocked by the FreePBX System Firewall.
As one of the security nerds here, I understand that you believe that this is an issue, but I don’t - at the moment - think that it requires remediation, because a lot of FreePBX and UCP sessions are long running and the remediation against slowloris is to explicitly kill those sessions.
I am, of course, willing to be convinced otherwise!
I did not intend to imply that FreePBX or the UCP were specifically the focus. Our application of Apache is by using the UCP from the Distro and I didn’t want to get dismissed as “oh, that’s Apache’s problem”. I realize this is essentially a low impact issue, for our company at least, but not addressing a known issue can come back to hurt you later. Also, sometimes the powers that be expect a clean security report, regardless of the impact.
For various reasons our System Firewall is currently disabled, but I have plans to iron out the issue in a test environment. Perhaps this is a motivation to escalation that timeline.
In terms of adjusting the Apache values, are there any settings involved in this issue that can cause UCP problems? Or is it basically just being aware of dropping sessions?
As rob previously said. Limiting session length can cause issues with UCP or freepbx admin. You’ll have to decide yourself what you want to set it to in apache.