New Topic

cPanel & WHM Feature Requests Topic Security

Category Security

Tags CloudFlare, x-forwarded-for, cphulkd

cPHulkd: Trust X-Forwarded-For as the origin ip address when the request originates from CloudFlare

Keith Poole (Agilis IT) shared this idea ago

Open Discussion

The current issue is that brute force attacks can occur on https://customerdomain.tld, which may be (always in our case) behind a reverse-proxy such as CloudFlare.

When these get brute force attacked, cpsrvd reports the logins to cphulkd via a Unix socket, but cphulkd only actions on the REMOTE_ADDR, ignoring X-Forwarded-For.

This then means that when the IP address is blocked, being the IP of the reverse-proxy provider, MANY services are interrupted until the temporary ban is lifted.

Merged Objects

Austin Lowery

cPHulk Support for trusting the X-Forwarded-For header from set of third party load balancers

NOTE:

This is almost the same request as found here:https://features.cpanel.net/topic/have-option-for-cphulkd-to-action-on-x-forwarded-for

Although that request does handle situations outside of CloudFlare. If needed, please merge this request into the original and include the more generic portions of the request so that the feature is not limited to just CloudFlare.

NOTE:

The following feature request is so broad that this feature request might be contained within it:https://features.cpanel.net/topic/built-in-load-balancing-replication-high-availability

Although I believe that feature request is for native cPanel load balancing rather than integration with third party load balancers such as CloudFlare, HAProxy, etc etc.

As a cPanel Systems Administrator

I want the ability to place a cPanel server behind a set of load balancers, but still maintain the ability to use cPHulk.

Because

cPhulk is a valuable part of the cPanel product that I do not want to give up in order to use my set of third party load balancers.

Problem

Currently, cPHulk is not capable of trusting the X-Forwarded-For header, and for good reason. The X-Forwarded-For header can be easily spoofed. This makes it so that if I have cPHulk enabled, and a brute force attack happens, cPHulk will see my load balancers as the source of the attack and block them. This results in all services being completely down in the event of a firewall block from cPHulk.

Suggested Resolution

This new feature would include the ability to specify a list of trusted request IP addreses.

This list would contain the IP addresses of the load balancers in my network.

If a request contains the X-Forwarded-For header, and it comes from one of these trusted IP addresses, cPHulk should trust and make use of the X-Forwarded-For header to determine the true source of the request.

I like this idea 1

Replies (4)

Caleb ●

I would like to add to this and request that cpHulk also include the X-Forwarded-For header in the notice emails that it generates. Even if cpHulk doesn't take actions on the X-Forwarded-For IP it should be included in notices so admins can have a clearer record that the request might have come from a proxy service.

Reply URL

cPanelChrisD ●

Performing actions based on the X-Forwarded-For header would be very dangerous because it is trivial to forge the header with any IP address that an attacker desires to use, including the white-listed IP address of an administrator allowing unlimited brute-force attacks on the server, or using the IP address of another user on the server resulting in a Denial of Service to that user. To prevent this problem you would need to be sure that all requests made to a service port come only from the reverse proxy and that it would not pass a forged X-Forwarded-For header to the back-end server.

Reply URL

Caleb ●

I think most of us well understand the implications of HTTP Headers. The fact remains that these headers are commonly used to expose and exchange information that can indeed be validated against other data that has some level of trust.

I for one would much rather see the "dangerous" information all in one place. As opposed to having to dig through the access log or build secondary automation to do it for me after the fact.

We already have a "whitelist" in cPHulk. That whitelist implies a certain level of trust, but that's an aside here. Why wouldn't an admin want to see this information in one place? Why wouldn't we want automation by which we could set "Trusted" networks to extract header information from?

Be it CloudFlare or a local install of nginx running proxy duty, or even just that old WHM option for Apache to run "Proxy sub-domains" for your cpanel account services... Another look at cPHulk and this feature request would be a reasonable request, I think.

Speaking to any security implications - these hypothetical options are only as dangerous as their default values make them. The safest defaults are always "disabled" until someone who knows what they're for comes along to configure them. And for anyone else a note warning them of this security implication should suffice.

URL

BobHoliday ●

X-Forwarded-For can be easily spoofed - a workaround would be to ONLY believe the X-Forwarded-For header value IF the originating IP is in the known CloudFlare IP ranges.

Reply URL

BobHoliday ●

Here's a potential workaround for the time being until cPanel do something more official...

https://www.aetherweb.co.uk/solved-cpanels-cphulk-cloudflare-and-x-forwarded-for/

Reply URL