The title of this post is a very shortened version of the key words and the frustration that consumed hours of my day.
CPanel Cannot Change Passwords after Migration should be expanded to read, “After migrating from one CPanel server to another, a users email account could not have the Password reset.”
Even then, the process of Resetting the password, from the admin WHM side, and accessing the users Cpanel Account to Email admin section, and using Manage for the user and hitting up the Change password option, completed all ok. It ‘looked’ like it was changing the password.
But, trying to Check Email from that screen prompted for the users email address and password and repeatedly stated that it was an Invalid Login.
I then tried many times with multiple email accounts for that user. Then I tried another account and it was ok.
So what was happening with this specific account ?
After messing around a bit, I then tried to change the accounts CPanel password, just to confirm that I could login to CPanel for the user, but the following message appeared:
The password for 'usersaccountname' could not be changed because: Sorry, the user “usersaccountname” is currently suspended. Changing the user’s password would unsuspend the account.
Huh???
Checked the List Accounts panel and the account was not shown as suspended, i.e. no pink highlight.
So I issued this command to unsuspend the CPanel account:
# /usr/local/cpanel/scripts/unsuspendacct usersaccountname --retain-service-proxies
But got an error:
An error occurred while attempting to unsuspend “usersaccountname”. The user “usersaccountname” is not in a suspended state.
Another “Huh??” so I tried to Suspend the account to see what was reported:
# /usr/local/cpanel/scripts/suspendacct usersaccountname
User 'usersaccountname' is already suspended. Provide '--force' argument if you wish to do this.
So the account is suspended but not completely. The next step was to –force the suspension as suggested.
# /usr/local/cpanel/scripts/suspendacct usersaccountname --force
Changing Shell to /bin/false...Done
Locking Password...Done
<...snip...>
usersaccountname's account has been suspended
The above ‘forced’ the partly suspended account to be suspended and then I requested unsuspend and it worked. Following that process:
# /usr/local/cpanel/scripts/unsuspendacct usersaccountname --retain-service-proxies
Unsuspending outgoing email....Done
<...snip...>
Unsuspending websites...
Unsuspending FTP accounts...
usersaccountname's account is now active
Unsuspending mysql users
Keep service proxying settings for this account...Done
usersaccountname's account has been unsuspended
Subsequently accessing the users email via webmail worked. The changed email passwords had actually been saved, but the mixed up ‘suspended’ state was preventing the access from taking place.
This could be summarised as “For CPanel rejecting Webmail Passwords, check for suspended state via command line” and hopefully you can avoid hours of pain.
Like many others we rely on multiple AntiVirus tools and one of them is the ubiquitous ClamAV on our Linux hosting servers. Earlier today we started being hammered with ClamAV notices of viruses being identified. Some research later and we are confident the ClamAV Archive.Test.Agent2-9953724-0 is a False Positive.
(quarantined to /home/quarantine/cxsuser/client-account/backup_2022-06-25-0330_Clientaccount_f4f78444ae93-themes.zip.1656132445_1) ClamAV detected virus = [Archive.Test.Agent2-9953724-0]
Various internet sources confirmed that ClamAV had indeed released an update signature file which included a ‘Test’ signature, namely ‘Archive.Test.Agent2-9953724-0’. A subsequent update, released within 24 hours addressed the false positive and, hopefully, prevents any future signature file from containing Test signatures.
# /usr/local/cpanel/3rdparty/bin/freshclam
ClamAV update process started at Sat Jun 25 15:09:55 2022
daily database available for update (local version: 26582, remote version: 26583)
Current database is 1 version behind.
Downloading database patch # 26583...
Testing database: '/usr/local/cpanel/3rdparty/share/clamav/tmp.73d24b3a72/clamav-52f6105711bb0d74294d4d1c535e77c0.tmp-daily.cld' ...
Database test passed.
daily.cld updated (version: 26583, sigs: 1987677, f-level: 90, builder: cmarczewski)
main.cld database is up-to-date (version: 62, sigs: 6647427, f-level: 90, builder: sigmgr)
bytecode.cld database is up-to-date (version: 333, sigs: 92, f-level: 63, builder: awillia2)
Apache Security headers are a method to incorporate some security settings into websites to reduce the risk of various hacking attacks. The following sections provide some of the more common headers that should be set.
One proviso with all of these settings is that we assume the end-users browser is relatively current and recognises or honours the header setting instructions. Likewise you should be using a current Apache server release.
The same (similar) headers can also be used with nginx but that is beyond the scope of this article.
ServerSignature Off
The first option to set is turning off the details of the server operating system.
ServerSignature Off
ServerTokens Prod
The reason for doing this is to hide information relating to the server from potential hackers. Advertising your servers operating system and version release allows them to look at specific vulnerabilities that might exist.
Clarification with this. There is no option to show the Server as ‘blank’ in the selection process. The combination above will still show as Apache, but will not include versioning details etc.
Also note that if you are using a CPanel server, you already have these options in the settings at WHM(Home) -> Service Configuration -> Apache Configuration -> Global Configuration.
Set-Cookies
The set-cookies header is important as one of the main cross-site-scripting attacks are looking for session cookies that are used by many websites to manage the site user connections.
Managing MIME-types, like text/html, in the website pages should be accepted as configured by the website. The purpose is to block content ‘sniffing’ that may provide a method for a hacker to execute some code that should not be executed on the site.
The X-Frame-Options setting is to manage the use of iframes to embed site content into another site. The goal is to prevent what is commonly known as click-jacking, where a foreign website can embed your website within an iframe. This means the foreign site can look like your site but have additional, and probably malicious code running in the background.
This header relates to having a SSL secure certificate for your website, i.e. using https:// rather than plain http:// to access the site. The max-age is effectively the time-to-live for the setting before it will be checked again. In the example 2592000 is one month. Longer max-age settings are recommended for use with the preload option. Try 31536000 for one year.
Header always set Strict-Transport-Security "max-age=2592000; includeSubDomains; preload"
The ‘preload’ is not an official setting but is commonly accepted. There are conditions to using the preload option. For more details check out Mozilla Developer MDN document for Strict-Transport-Security. I tend to leave preload out at this time as it entails some obligations that will consume more time.
Summary
Adding Apache security headers to a WHM / Cpanel server for all client sites is something that should be done by the server administrator. If you are a CPanel account holder and your site fails the header report you should hit-up your web host for an explanation or find a host that has these things configured already.
All in one block, (in no particular order) your security headers could look like this:
# Global Security Headers
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains;"
Header always edit Set-Cookie (.*) "$1;HttpOnly;Secure"
Header always set X-Frame-Options "sameorigin"
Header setifempty Referrer-Policy: same-origin
Header set X-XSS-Protection "1; mode=block"
Header set X-Permitted-Cross-Domain-Policies "none"
Header set Referrer-Policy "no-referrer"
Header set X-Content-Type-Options: nosniff
Header set Permissions-Policy "geolocation=(),midi=(),sync-xhr=(),microphone=(),camera=(),magnetometer=(),gyroscope=(),fullscreen=(self),payment=()"
#Header set Content-Security-Policy: "default-src *"
</IfModule>
Using the above, with the Content-Security-Policy enabled, the free script tool over at https://securityheaders.com will show a nice big A+ and lots of green ticks. Noting that it is not checking the Set-Cookie option.
Content-Security-Policy Wildcard
Content-Security-Policy is a more comprehensive header and supercedes some of the headers described here. Lots more work to be done with this setting as it is targetting individual sites rather than shared hosting servers. If its enabled the setting above actually does nothing other than get a green tick in the security report at https://securityheaders.com. It also breaks many WordPress sites as while the default-src is the ‘fall-back’ position for most of the ‘-src’ options in CSP, in-line scripts are governed by the script-src parameter and it does not accept ‘*’ as a value, so the ‘fall-back’ breaks and browsers will not load the site with errors like:
While default-src says accept all with the *, script-src does not and will not work.
As a result I have commented that line out for my servers today while I look at this in more detail.