Server's own IP in cpHulk reporting system cpaneld auth failure?

[Benjamin D.]

I've randomly stumbled upon my server's IP in cpHulk History Reports yesterday. So, my server is basically trying to bruteforce its way into one of its own cPanel accounts, it seems. After a quick find in all PHP files, I found that a cPanel account was trying to do just that by using curl to make requests.

I would like to know what kind of issue this could eventually cause to my server since its own IP appears in cpHulk once every 5 minutes? If the server were to get blacklisted and its IP auto-inserted into CSF Firewall, what would happen then?

 

[cPanelWilliam]

Hello,

If the server's IP becomes blocked in cPHulk/LFD, it could cause issues with local authentication to services such as dovecot/SSH. However, you can whitelist the server's IP address in cPHulk to prevent this. Since you said the authentication attempts occur every 5 minutes, the authentication attempts may be from chkservd. Does cPHulk indicate which service is being authenticated to every 5 minutes? If so, the log file for that service may contain additional insight as to why the authentication attempts are failing.

 

[ResellerWiz]

After a quick find in all PHP files, I found that a cPanel account was trying to do just that by using curl to make requests.

Have you contacted the client to inquire as to why they have a script doing this?

 

[Benjamin D.]

Hi ResellerWiz. Yes, they're updating one of their DNS entries every 5 minutes and from what they claim, this probably began to occur after they changed their cPanel account password and forgot to adjust their script, which they did now and cpHulk has stopped logging failures.

Nonetheless, I'm now questioning how cPanel protects itself from such an "attack". cPanelWilliam's suggestion to whitelist the server's own IP looks extremely risky to me. Wouldn't that instantly grant to a free ticket to anybody to brute force their way into any of the cPanel accounts on that machine, including root?

 

[ResellerWiz]

In this scenario I don’t think it’s a good idea to whitelist the servers IP, because if for some reason you’re not keeping a close eye on authentication errors, a user could attempt to brute force other accounts on the server, which is obviously not good for security and could also lead to degraded server performance.

 

[Benjamin D.]

The effects of one customer successfully brute forcing another customer's cPanel account (or even the root account) would be devastating. That's why I made this thread. I would like to know how cPanel mitigates this issue. It's very simple for a customer to use PHP to make a bunch of repeated CURL requests from and to the server's own IP. What prevents one from brute forcing their way into any customer's cPanel account? And even if they didn't make it, what prevents a customer from blacklisting the server's own IP? (which as cPanelWilliam suggested, would cause downtime to one or more services, albeit much less devastating than a customer rooting into the server's main cPanel account of course, but still undesirable)

 

[ResellerWiz]

The effects of one customer successfully brute forcing another customer's cPanel account (or even the root account) would be devastating. That's why I made this thread. I would like to know how cPanel mitigates this issue. It's very simple for a customer to use PHP to make a bunch of repeated CURL requests from and to the server's own IP. What prevents one from brute forcing their way into any customer's cPanel account? And even if they didn't make it, what prevents a customer from blacklisting the server's own IP? (which as cPanelWilliam suggested, would cause downtime to one or more services, albeit much less devastating than a customer rooting into the server's main cPanel account of course, but still undesirable)

cPanel is an automation tool, not a security app.

While cPanel can help with some aspects of server security, it does not offer a complete security solution.

Proactive security apps such as Imunify360 can offer additional protection, but they too are not perfect.

Server security is a non-stop part of administrating a server and should never be considered "one and done" with an app or "server hardening".

 

[Benjamin D.]

It's just that cPanel is not a free product and it's not your offline Word processor app either. It's supposed to be what server administrators use to manage services that are exposed to the entire world 24/7. We've paid thousands of dollars for cPanel licenses over the years and we, as customers, expect the product to be above a certain quality threshold. If, like you suggest, server security "should never be considered "one and done" with an app" then cPanel should not take our money without perpetually improving either. What is cPanel going to do about this security issue? Instead of forcing that ugly Jupiter theme on customers, perhaps they could tackle the real/important issues first.

Also, as a server management solution, allowing cPanel to brute force into itself is kind of ridiculous. I would have expected at least a way to mitigate the issue. It's like they didn't think their product through, which, for a multi-million dollar business is kind of weird.

 

[ResellerWiz]

It's just that cPanel is not a free product and it's not your offline Word processor app either. It's supposed to be what server administrators use to manage services that are exposed to the entire world 24/7. We've paid thousands of dollars for cPanel licenses over the years and we, as customers, expect the product to be above a certain quality threshold. If, like you suggest, server security "should never be considered "one and done" with an app" then cPanel should not take our money without perpetually improving either. What is cPanel going to do about this security issue? Instead of forcing that ugly Jupiter theme on customers, perhaps they could tackle the real/important issues first.

Also, as a server management solution, allowing cPanel to brute force into itself is kind of ridiculous. I would have expected at least a way to mitigate the issue. It's like they didn't think their product through, which, for a multi-million dollar business is kind of weird.

Control panels in general are meant to be used as an automation tool to make server administrators jobs easier, not to completely do their jobs for them.

The brute force issue you are trying to make seem like a cPanel issue, is possible on other control panels as well, so it is not unique to cPanel and not cPanel issue. It is a client issue. Which means you may need to vet your clients better, because this is not something a typical client would do.

Honestly, as a server administrator, if you're proactively monitoring your servers (as you should be doing), this should be a non-issue to begin with.

 

[Benjamin D.]

I'm kind of stumped by your messages. It makes it look like you're defending cPanel for not fixing their security flaws. I don't understand, isn't cpHulk a cPanel product that's precisely supposed to protect the server against brute force attacks or am I missing something here? https://support.cpanel.net/hc/en-us/articles/4406663082519-What-is-cPHulk-

Anyway, can a cPanel developer tell me what cPanel thinks of this matter?

 

[ResellerWiz]

I'm kind of stumped by your messages. It makes it look like you're defending cPanel for not fixing their security flaws. I don't understand, isn't cpHulk a cPanel product that's precisely supposed to protect the server against brute force attacks or am I missing something here? https://support.cpanel.net/hc/en-us/articles/4406663082519-What-is-cPHulk-

Anyway, can a cPanel developer tell me what cPanel thinks of this matter?

cpHulk is for protecting the server from external brute force attacks, not internal.

 

[cPRex]

I reached out to the developers about this issue and I'm not sure there is a great solution. @ResellerWiz is correct that cPanel is an automation tool, and not a one-stop security solution. We try, but there is no "security" tool that will ever be 100% effective.

The problem here is that you have the worst case scenario - some already has access to your server and is performing malicious activity. That fact alone eliminates a vast majority of security tools, which focus on outside threats getting in. But for someone already on the server, they've already beaten 99% of the game.

We do recommend whitelisting the local IP so you don't get locked out of your own server, but as you mentioned, this would open up the potential for further local attacks. The best thing you can do in this situation would be to address the problem or ban the user as necessary once you've detected the odd behavior. In this case I would say that cPHulk did its job - it logged the data, the server admin reviewed the log, you found the odd activity, and took action.

I don't have a better solution for this at this point, and I'm not sure there is one that could be easily implemented. The potential for false positives from any type of additional cPHulk actions (ban? autosuspend?) is high for this type of activity, although this is something we would never want to enable by default and leave up to the server admin, if such a thing existed.

 

[Benjamin D.]

Hi cPRex!

What do you mean by " some already has access to your server and is performing malicious activity. " ? Yes, it's a customer that has access to the server, because he's got hosting. ResellerWiz must have a couple of those people called customers too. I don't understand how "they've already beaten 99% of the game" by being a simple customer. It's not like they have access to SSH or passthru commands in PHP. It's just WEB/CURL REQUESTS made to the cPanel API. It's not like they were hacking anything. cPanel literally opens and documents that interface. If cPanel can't make it somewhat secure, then what's the point of opening this interface to the world?

 

[cPRex]

cPanel also opens and documents Apache, MySQL, PHP, and every other service on the machine. It doesn't mean they can't be abused or that everything will be perfectly secure.

My point was that most attacks are from *outside* the server, but your user already has privileged access by having an account.