Eric Wheeler

Registered
Apr 11, 2018
4
0
1
USA
cPanel Access Level
Root Administrator
Hello all,

We are getting the same error in this 2 year old thread, so we are opening a new thread:



This is our version: 11.58.0.52

Apr 11 05:30:06 web1 dovecot: auth: Error: Cpanel::MailAuth: Brute force checking was skipped because cphulkd failed to process "[email protected]" from "IP '3.4.5.6'" for the "smtp" service.
Apr 11 05:30:08 web1 dovecot: auth: Error: Cpanel::MailAuth: Brute force checking was skipped because cphulkd failed to process "shaaspd" from "IP '1.2.3.4'5'" for the "pop3" service.
Apr 11 05:30:14 web1 dovecot: auth: Error: Cpanel::MailAuth: Brute force checking was skipped because cphulkd failed to process "[email protected]" from "IP '1.2.3.4'" for the "imap" service.



We have reset the cphulkd database and confirmed that we can log into cphulkd's database using the credentials in /var/cpanel/hulkd/password, so I am not sure what else to check.

What do we do next?

Thank you for your help!
 

cPanelLauren

Product Owner
Staff member
Nov 14, 2017
13,295
1,273
313
Houston
Hello @Eric Wheeler

Looking back through our internal cases CPANEL-1754 (which was noted in the other thread) was marked as something that we will not fix as it is not actually an issue. This error was found to be occurring during a failed login attempt making it a justified error.

Are you experiencing adverse behavior you believe to be related to this error?

Thank you,
 

Eric Wheeler

Registered
Apr 11, 2018
4
0
1
USA
cPanel Access Level
Root Administrator
Maybe you can help me understand, because I thought failed logins were supposed to be reported to cphulkd---but the error appears to indicate that cphulkd cannot be notified.

We are not having any adverse effects, but I want to make sure that cphulkd is correctly blocking password guessing attacks.
 

cPanelLauren

Product Owner
Staff member
Nov 14, 2017
13,295
1,273
313
Houston
Hi,

I agree that it does seem misleading and this was noted in the case as well. The best way to confirm this would be to go to WHM>>Security Center>>cPHulk Brute Force Protection -> History reports and attempt to compare these log entries with present blocks.

Thank you,
 

Eric Wheeler

Registered
Apr 11, 2018
4
0
1
USA
cPanel Access Level
Root Administrator
The cphulkd database shows this line:

[email protected] 222.120.247.207 mail pop3 2018-04-13 14:39:19 2018-04-13 20:39:19 198

And our logs show entries like this:

Apr 13 14:50:54 web1 dovecot: auth: Error: Cpanel::MailAuth: Brute force checking was skipped because cphulkd failed to process "[email protected]" from "IP '222.120.247.207'" for the "pop3" service.

Note that [email protected] does not exist in the cphulkd database. I am guessing that this error is telling us that it was for some reason unable to insert the entry into the database for this IP.

The question is, why?

Can you confirm whether cphulkd will "fail to process" the entry because the IP is already blocked?
 

cPanelLauren

Product Owner
Staff member
Nov 14, 2017
13,295
1,273
313
Houston
Hello,


Can you confirm that the IP address is blocked, it's not actually skipping per the internal case. From the internal case directly:

When mail authentication fails using a valid domain on the server, the cPHulkd error in the Dovecot mail log can cause confusion

In the WHM Manager >> Security Center >> cPHulk Brute Force Protection area under History Reports it does show the entry fine. It's just the error in /var/log/maillog is misleading.
Thank you,
 

Eric Wheeler

Registered
Apr 11, 2018
4
0
1
USA
cPanel Access Level
Root Administrator
Yes the IP is blocked, but as noted above in the previous post, the entry for "[email protected]" is missing from cPHulkd. Other users for that IP exist and are blocked, but not the one that the log references.

Shouldn't the log reference all failed attempts, even if the IP is already blocked?
 

cPanelLauren

Product Owner
Staff member
Nov 14, 2017
13,295
1,273
313
Houston
Hi @Eric Wheeler

I agree with you that it should, but it does appear that it's skipping adding the username in the event that the IP address is already blocked as you assumed previously. While the case does make note of the potential confusion the log entry makes if you would like for us to take a closer look I would encourage you to use the link in my signature to open a ticket.


Thank you,