WrenMaxwell

Category: Website Security

  • WordPress wp-admin missing gui

    When moving WordPress sites around on servers and from a staging setup to live, we sometimes get bitten with “wordpress wp-admin missing gui” where the public view of the site is working fine, but the wp-admin areas shows up as plain text or simple html. You may not have seen it before, but plain white background and all the dashboard selections are simple links, like the theme is missing.

    Having gone through this several times in the last 4 or 5 weeks, I have decided I need to document what I tried and what worked in the end for the latest site issue. It could be different things and while I did not make a note the last few times, I’ll come back here in future if something different happens.

    We use CPanel for all our hosting servers and the WordPress Toolkit is installed.

    The task was a simple swap from staging to live which I do on a regular basis, and do it manually, as I have done for numerous years. However this time the dreaded “wordpress wp-admin missing gui” struck!

    Skipping the intervening hour of trying a multitude of settings, I discovered that this site was impacted by one of the WordPress Toolkit security settings. Which one, I do not know, as the final outcome was to revert or reset all the security settings and then enable 1 by 1 waiting to see which one failed, and none did!. Bah humbug.

    The outcome is then likely that somewhere in those settings, as I had copied the site manually into the public_html, had some setting that tied it back to the staging location, and ultimately crashed the theme. I expect that clearing the security settings (Revert) and re-enabling in one hit would have addressed the issue, but as with many things, we try incremental changes. If it happens again, I will try that first.

  • ClamAV Archive.Test.Agent2-9953724-0 False Positive

    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)

  • You do not have permission to access this document

    A Joomla site has been working fine but is now displaying an error when trying to save new content. The error displays as “You do not have permission to access this document.”

    It is an Apache Web Server error and not a Joomla error. Considering that Joomla has not changed it will be related to server changes or Apache updates.

    We had made a server change to address Apache Security Headers recently. Those changes were working ok with other sites and with the public view of this Joomla site.

    The .htaccess file for the Joomla website was the first thing to check. That revealed we had added some specific headers relating to those security headers back in 2021 to address an different issue.

    #Added 20211201 following Joomla recommendations after upgrade to 3.10.3
<FilesMatch "\.svg$">
  <IfModule mod_headers.c>
      Header always set Content-Security-Policy "script-src 'none'"
  </IfModule>
</FilesMatch>

<IfModule mod_headers.c>
    Header always set X-Content-Type-Options "nosniff"
</IfModule>

    In this case, the .htaccess site specific instructions clashed with the recently modified server instructions.
    Removing the .htaccess specific commands allowed the system to process the new Articles correctly.

    Conclusion

    If you have an error in Joomla “You do not have permission to access this document.” for your Joomla article, it is an Apache error.

    Check your .htaccess and your server configuration for potential Apache issues first.

    Need help with your Joomla or WordPress site? WrenMaxwell provides support and secure website hosting services. Contact Us at any time.

  • Should I publish an email address on my website?

    “Should I publish an email address on my website?”

    NO! Never, Never, Never, Ever publish an email address.

    Spam email is a constant issue for anyone managing email.

    Any action that reduces the chances of spam or scam email getting to your account is a good thing.

    Spam Email

    To address the question we need to understand what spam email represents. It is about the impact it can have on you and your business.

    Spam mail in this context includes all the Unsolicited and Untrusted email that exists on a daily basis.

    Types of spam email include those selling the latest sex, diet, or hair growth/removal treatments (these used to be called ‘snake-oil’). Along with the more dangerous malware, ransom-ware, and virus laden emails.

    All of these are a risk to your email and your time at a minimum. Accidentally clicking a scam email can be extremely costly.

    “..in 2021… …average total cost of recovery from a ransomware attack… ..increased to $2,340,000 per incident.”

    https://australiancybersecuritymagazine.com.au/average-ransomware-recovery-cost-in-apj-increases-from-us1-16-million-to-us2-34-million/

    If those ‘big numbers’ are too big and you think you are too small or not worth targeting, you are wrong.

    Scamming, phishing, emails are looking for your identity and your banking or credit card details. Even smaller values in hundreds or a few thousand dollars is their target along with the ability to get your identity and take out a large loan in your name.

    Even for smaller businesses or personal accounts the risk exists. Imagine losing all your data on your computer. Imagine your identity being stolen. There are potential risks in every email you receive, even from senders that you recognise.

    Spam accounts for 14.5 billion messages globally per day.

    https://www.spamlaws.com/spam-stats.html

    Spam email is a risk to you and your business. It consumes a mountain of resources in dealing with it.

    Publish My Email Address it is Important

    It is a fallacy to say “Its important that this email address is highly visible as this is how customers will contact us”. Use a contact form.

    Customers that are using the website will use whatever means provided to contact the business. Provide them with a contact form and they will use that method.

    Is there a method for the email address to be visible only to humans? No. Scammers use scripts that read the code of a webpage and not what a human viewer reads.

    Using example [at] your-business [dot] domain is often suggested as an option for a human to read and mentally convert the [at] and [dot] but the email harvesting scripts included code to recognise these options and convert them to a usable email address.

    Other methods include time-consuming java-script coding, or making jpg images, or other coding solutions.

    Do not waste the time and effort doing that. A contact form removes the need completely.

    Use a Contact Form

    A contact form is quicker, easier, safer.

    There are lots and lots of scripts, templates, and tools to create and manage Contact Forms.

    WrenMaxwell provides WordPress website hosting and utilises WordPress Contact Form Plugins.

    Your designer can add a simple Contact Us page in minutes and replace any email address with a simple ‘Click to Contact Us’ link to that new page and its contact form.

    In terms of designer time and cost, it should be minimal and part of their standard process.

    For analytics of your customer contact through your website a Contact Form provides a tracking process that does not exist if using just a published email address. This is a topic relating to CRM and how to analyse the success of your website.

    Conclusion

    “Should I publish an email address on my website?”

    Never publish an email address. Always use a Contact Form plugin or script.

    A Contact Form, along with additional website security and server-based security measures will reduce the amount of spam or scam emails that get to your inbox.

    Need help with your WordPress website?

    WrenMaxwell provides WordPress support and secure hosting.

  • Apache Headers for Website Security

    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. 

    Header always edit Set-Cookie (.*) "$1;HttpOnly;Secure;SameSite=Strict"

    The HttpOnly may seem a little off in this day of Https:// everywhere, but that is the purpose of the Secure setting. In detail:

    • $1; is the original cookie, which Apache will edit to append these 3 settings:
    • HttpOnly; specifies that the cookie cannot be read through a client browser
    • Secure; adds the ‘s’ to http: and safely encrypts the cookie
    • SameSite=Strict; Cookies will not be sent in 3rd party requests, i.e. only used within the same site.

    All that said, I am still having issues getting this recognised on a CPanel server. Time to ask the audience!

    Read more on this at https://owasp.org/www-community/HttpOnly.

    X-Content-Type-Options

    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. 

    Header set X-Content-Type-Options nosniff

    For more details check out Mozilla Developer MDN document for X-Content-Type-Options.

    X-Frame-Options

    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. 

    Header set X-Frame-Options: "SAMEORIGIN"

    Setting “SAMEORIGIN” says to only allow iframes to be used within the site and not from any external location. For more details check out Mozilla Developer MDN document for X-Frame-Options.

    Strict-Transport-Security or HSTS

    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.

    The joys of new protocols!

    References:

  • Cancel Prompt for htpasswd htaccess displays website

    Searching for a topic like “Cancel Prompt for htpasswd htaccess displays website” generally gives a lot of results with unrelated information and this one was not an exception. Plenty of instructions on ‘how to configure’ but relatively few on what to do if it fails.

    The cause of this dilemma was that a CPanel configuration for Directory Privacy was displaying the protected website home page if Cancel was selected 3 or more times when the htaccess password prompt was displayed.

    Directory Privacy, the CPanel interface option for configuring htaccess and htpasswd files for Apache websites, provides a ‘user friendly’ method to add specific user names and passwords to block public viewing of a website via a web browser.

    In this instance my search terms eventually led me to this explanation https://core.trac.wordpress.org/ticket/42120 which is credited to a number of others for the solution.

    To keep it simple, if you are experiencing a web page that is meant to be protected by .htaccess / .htpasswd, but it is being displayed if the Cancel option is selected at the password prompt, then check your .htaccess rule.

    1. Edit the .htaccess file in your home folder or website root (assumes that it is the whole site being protected)
    2. Find the line RewriteRule . /index.php [L]
    3. Replace with RewriteRule ./ /index.php [L]

    This worked in my case and as always your mileage may vary.