Log for denied logins?
I tightened up my VPS security recently with Host Access Control -- allow my office IP, deny all others.
Now my host's tech people can't log into WHM even if I add their IPs to the allow list, or even change all the denys to allows.
Do I need to restart any of these servers before they will notice table changes?
Is there a log somewhere I could look at that would tell me "so and so just tried to login to WHM, and was denied for REASON"?
-
If you have configured a rule for WHM (whostmgrd) service in Host Access Control to allow only your IP and deny all then it will be only accessible to only your IP address. You will also need to add allow rule for your tech people's IP address. Failed login attempts to cPanel/WHM are logged /usr/local/cpanel/logs/login_log
file.0 -
Thanks very much for the log location. I'm keeping it in my cheat sheet. So the relevant log line seems to be: [2021-02-21 18:38:01 -0700] info [whostmgrd] 1.186.48.58 - root "GET /cpsess5753725629/login/?locale=en&session=root%REDACTED%3acreate_user_session%REDACTED HTTP/1.1" FAILED LOGIN whostmgrd: brute force attempt (user root) has locked out IP 1.186.48.58 This despite me having allowed this IP in Host Access Control. Do I have to restart the WHM server after changing Host Access Control to get it to notice the change? Another thought -- it's possible the tech managed to trigger the brute force lock even before mentioning to me that they were logging in... so that by the time I "allowed" them, it was too late. Is there anything I can do manually to remove this lockout status? 0 -
when you run utmpdump /var/log/btmp
you get ALL LOG of access faileds0 -
You can use the below command to whitelist IP in cPHulk #/scripts/cphulkdwhitelist 1.186.48.580 -
You can use the below command to whitelist IP in cPHulk
#/scripts/cphulkdwhitelist 1.186.48.58
I assume this is the same as whitelisting them in cPHulk in the WHM interface, which I did do at the time (in addition to allowing them in Host Access Control) but to no avail. I suppose next time I need to invoke tech support, I'll have to tail login_log in real time and see what is going on there.0
Please sign in to leave a comment.
Comments
5 comments