For those who run their own servers, the cPanel control panel has been a truly remarkable piece of software that allow non-technical users to perform even the very technical of tasks. But like many types of software, even this tried and true work horse shows a glitch here and there. This latest one threw our IT support team (including cPanel tech support, server management company and experts in various online forums) on a wild goose chase. WHM showed two unauthorized users have gained access to our server! Talk about a worst case scenario security breach! After some internal testing, it seemed that there was more to the cPanel alert than meets the eye.
Normal cPanel (domain owner control panel) users will never notice this reporting glitch but for those who have higher level access to WHM (the server administration panel that controls cPanel), you will rest assured knowing that when WHM is reporting your server has been hacked, it is definitely not the case.
WHM 11 has a feature called cPHulk Brute Force Protection that prevents malicious forces from trying to access your server’s services by guessing the login password for that service. In short, if it detects an IP or account trying to forcefully gain access to WHM or cPanel, it will shut them out for a pre-determined length of time. In addition to a list of banned IP’s, you will also find a table of IP addresses under “Logins” inside WHM >> Security >> Security Center >> cPHulk Brute Force Protection.
During a routine check-up, I noticed 2 IP addresses under the “Logins” table that I did not recognize. A DNSReport on those IP’s returned locations that were no where near our office. Even the reported user names do not match any that we have setup for server logins. As these IP’s were listed under the “Logins” table, panic began to set in.
With the intruder alarm sounding, emergency messages went out to the server management company, cPanel tech support and various tech forums asking for troubleshooting help. Responses were varied from the above and no one was able to pin point exactly what happened and why those 2 IP addresses were reported to have logged into our server.
As I put in a support ticket to cPanel, I also inquired about the “Status” column in the “Logins” table. Here is cPanel’s reply… which I now believe is incorrect information and was one of the factors that threw us for a ride.
Q: When does cPHulk log users under the login section?
A: It logs all logins by cpanel and whm for it.
Q: What does Status = 0 mean?
A: It logs all logins, and for the 0, it means number of retries attempted. Since you have logged in successfully, it is first attempt, so it be 0.
Armed with this info, we set out to discover how the so-called intruders were able to log in to our server.
Based on our own testing, I now know the information provided by the cPanel staff was incorrect. During the test sessions, we could not get Status to be anything but 0, even though there were multiple attempts to log in using the same bogus user ID. As we began to dig around, an IT friend of mine suggested that we test a failed log in to see if this was also logged. Sure enough, it turns out that the “Logins” table inside cPHulk ONLY logs unsuccessful login attempts! So the response from cPanel indicating that it cPHulk reports all logins was definitely incorrect. Thank goodness for that!
There is no other indication that our server was compromised. But based on the interpretation by cPanel tech support of the “Logins” stats inside cPHulk,it would have meant 2 un-authorized users have gained access to the core of our server. Currently, there is no indication of failed or successful logins inside cPHulk. As far a s I can tell, only unsuccessful logging attempts are reported. Most likely, the 2 IP’s in question were probably logged from a script or bot taking a blind stab at gaining access. In fact, 24 hours after the initial discovery, one of the IP’s was back trying to get in once again. This IP has now been blocked server wide at the firewall level.
cPHulk is a great tool. Unlike a firewall, it will still log an offending IP even though the hacking is subtle and not by brute force – as was with our case where the hack attempts were made once a day, every day. Essentially, it helped us isolate a repeat hacking attempt so we can permanently ban the offending IP from our server.
I hope cPanel enhances the already great feature of cPHulk in WHM by differentiating between successful logins and failed attempts in future releases. In the interim, the “Logins” table should be corrected to display “Failed Logins”. If you see any IPs listed under your cPHulk “Logins” table, not to worry. It actually means these IP addresses were not successful at logging in to your server!
UPDATE – June 10, 2008: If you are seeing cPHulk logging un-authorized logins to your server, it’s just a reporting glitch. After a few days of back and forth with technical support, here is a summary that I received from a cPanel Technical Analyst Manager. It should clear up all the confusion with cPHulk reporting. Looks like the above are bugs and will be dealt with in a future release.
1. I have confirmation from cPanel that even the most recent 11.23-Release build is still only logging failed logins. cPHulk is supposed to log both successful and unsuccessful logins. An internal (cPanel) bug report has been submitted to the development team to separate successful from unsuccessful login attempts.
2. The Status column is always 0 for now. This setting is for use in future versions. An internal cPanel bug report has been submitted with development to have this column removed until the setting is used properly.
UPDATE #2 – June 10, 2008: Response from cPanel; “The developers have removed the ‘Status’ column from the interface as well as made it more understandable regarding successful and unsuccessful logins. You should see these changes in newer builds as they make their way through the testing phases.”
Thanks to Todd S., Technical Analyst Manager at cPanel, for a detailed response.
Instead of using cPHulk I would suggest using a better firewall that has Brute Force built in.
Here is the best Firewall for cPanel:
http://configserver.com/cp/csf.html
Thanks for the tip Gary. CSF is definitely a great firewall. Unfortunately, there were some cPanel integration problems when we first installed it.
For users running the APF firewall, they can install BFD to add brute force protection at the firewall level.
APF firewall is a good idea, too — but don’t count on actually being able to examine all of the attempted logins. Some hosts get thousands per day — and this is a good reason to choose APF.
Chris
ZYON Cpanel Hosting
http://www.zyon.com
Im using CSF and im glad i got no problems with it so far.
From my experiences CSF have what it takes in its firewall. Great use in cpanel and so far me and my client are satisfied with it.
If you examine the code that populates the database table used to generate the report within WHM, you will find this block:
if ($is_hit) {
register_login(
$self->{‘dbh’},
‘user’ => $user,
‘ip’ => $ip,
‘service’ => $service,
‘status’ => 0,
‘logintime’ => $logintime,
);
}
If you notice, the status field is always set to 0, hence at this time it has no meaning within the application. You can find this code on your cPanel server at:
/usr/local/cpanel/Cpanel/Hulkd/Processor.pm
It does appear only failed login attempts are logged, rather than both failed and successful.
Thanks for sharing the great info Kenneth. You are correct about Status always being 0 (see update above). It’s great to hear others also seeing cPHulk only reporting failed logins even though it is under a “Logins” table.
I just received a lengthy reply from a Technical Analyst Manager at cPanel. It seems that cPHulk is has a reporting glitch. An internal bug report has been submitted to the cPanel development team. Scroll up to see details.
Why trust cpanel to be good with firewalls?
Use APF and BFD and stop being a GUI lazy person.
Letting the attacker keep attacking is stupid and a waste of bandwidth.
Plus it’s perl? What a CPU waste. It’s just looking through the logs like BFD does, and BFD runs faster.
BFD blocks them at iptables.
No way to whitelist the admin’s IP.
Documentation sucks.
love this post