yorman

What situations would warrant clearing any cache?

When you update a post or page, you will want to clear the cache so your users can see the changes.

Security-wise, if your website was previously infected with malicious code, you’ll want to clear the cache once the pages are clean, this way your server will not serve infected scripts to your users.

I just watched a video about clearing cache with Sucuri and wondered what its purpose was?

Sucuri offers a paid subscription to a service called “Web Security Firewall” [1] which filters all the bad traffic of your website before it goes to your hosting. It also provides several other features that you can use to increase the performance of your website, one of these features is caching.

We offer a mechanism to clear this cash from the plugin. I believe the video that you watched was explaining how to use this tool. Users who are not paying for a subscription to the premium services don’t have access to these options.

There are some free plugins in the market that offer basic caching [2] and they all provide a mechanism to clear the cache that they generate. Please refer to the documentation of the corresponding plugin that you want to install.

Let me know if you need more information.

[1] https://sucuri.net/website-firewall/
[2] https://wordpress.org/plugins/search/cache/

This is mostly a problem with shared hosting providers.

In order to offer advanced features to their premium clients, they enable extra features in the server that, due to misconfigurations, end up being enabled for non-premium customers as well. In this case, TLS has been globally enabled by DreamHost, and even though your website is not being served via HTTPS, the URL is still responding to the request, which confuses some web browsers that are trying to load the most secure version of the website to the users.

DreamHost is serving a generic “Site Not Found” page here [1] but they are sending a “200 OK” HTTP status code instead of a “404 Not Found”. This confuses the web browsers even more. That’s why the Sucuri scanner is sending a warning, because even though the HTTPS version of your website doesn’t exists, DreamHost is making people believe that it does, but it also is showing that the SSL certificate is invalid (for obvious reasons).

I suggest you to talk with DreamHost to fix their setup.

They shouldn’t be serving an error page with a “200 OK” status code.

As for the “404 Not Found” that your are seeing in the plugin, it will disappear once this misconfiguration in your server is fixed. Please keep in mind that both the plugin and Sucuri Sitecheck keep a cache for 24 hours, it will automatically refresh after that.

Let me know if you need more information.

[1] https://davidkrutprojects.com/

Your website probably has too many files, when the Sucuri scanner tries to inspect them all searching for malware, your server stops the operation after the maximum execution time (which is a value set by your hosting provider) is reached.

Talk with your hosting provider to either increase the value for this setting, or to go the plugin settings’ page and select directories that you don’t want to scan, that way the scanner will take less time to run and the server will not kill the script.

Let me know if you need more information.

Yes.

1. Go to the plugin “Settings” page,
2. In the top menu, click on the “Alerts”,
3. Scroll to find the “Post-Type Alerts” panel,
4. Click on the “Show Post-Types Table” button,
5. Select the “post-type” that you want to receive alerts for
6. Done

Can you please scan your website one more time using this [1].

Let me know if you can see more details there. If yes, then the empty payload in the plugin may be a bug in the code. However, if you cannot see any information about the payload the website linked below, that means the plugin is working as intended and is not showing a payload because there is no payload to show.

[1] https://sitecheck.sucuri.net/

Line 387 in the “base.lib.php” file is part of this function [1].

The function tries to locate the main “.htaccess” file to check if it has been infected with any piece of malicious code. Because of how WordPress works, this file can be located in three different directories:

• rtrim(ABSPATH, '/'),
• dirname(ABSPATH),
• dirname(dirname(ABSPATH)),

If your website is installed at /var/www/html/example.com/html/ then ABSPATH will be equal to that path and then the plugin will try to find the access control file in these three different locations (and stops once it finds it):

• /var/www/html/example.com/html/.htaccess
• /var/www/html/example.com/.htaccess
• /var/www/html/.htaccess

It seems that you don’t have any access control file at the root of your WordPress installation or the file is not readable, that’s why the plugin is trying to read the content of the parent directory. You can either create an empty file in the first location, or you can force the file scanner to ignore these directories from the “Scanner” panel located in the plugin’ settings page.

Let me know if you need more information.

[1] https://github.com/Sucuri/sucuri-wordpress-plugin/blob/ceaf0d2e4ff46c4ec32a2c069f2138643809e52e/src/base.lib.php#L370-L394

Alright, I thought you were asking for a copy of the logs because it was urgent, that’s why I suggested you to ask your hosting provider for a copy of the access logs.

I personally don’t think adding the rest of the information to the “Failed Logins” page is a good idea, it will just clutter the page with redundant information. I will explain… Currently, the plugin logs this information:

• Username
• IP Address
• Date and Time
• Web Browser

Here is an example:

Information   | Value
--------------|----------------------------------------------
Username      | foo
IP Address    | 192.168.16.1
Date and Time | November 3, 2018 5:34 pm
Web Browser   | Mozilla/5.0 (KHTML, like Gecko) Safari/537.36

And this is what I can see in the “access_log” file:

Information   | Value
--------------|----------------------------------------------
IP Address    | 192.168.16.1
Identd        | -
Username      | -
Date and Time | [03/Nov/2018:17:34:45 +0000]
Request       | "POST /wp-login.php HTTP/1.1"
HTTP Status   | 200
Response Size | 1884
Referer       | "http://wordpress.test/wp-login.php"
Web Browser   | Mozilla/5.0 (KHTML, like Gecko) Safari/537.36

If you compare both logs, the one from the plugin and the one from the server, they are pretty much the same, the data that is missing is ignored because it’s redundant, like this:

• Identd is ignored because it’s always empty,
• Request is ignored because it’s always the same. The request is always executed with the “POST” method and the target is always pointing to the “wp-login.php” file,
• HTTP Status is ignored because it’s always the same, “200 OK” which means the request was accepted and processed by the web application, otherwise it wouldn’t even be in the plugin logs,
• Response Size is ignored because the amount of bytes transfered back to the web browser is irrelevant,
• Referer is ignored because it doesn’t provides significant information, it can always be faked by the client, so adding this information to the plugin logs would just add noise.

I will consider this a feature request and work on it right now, but be aware that the other maintainers of the code may disagree with this feature and decline the update. I would suggest to leave this ticket open for a few weeks, if more people are interested in this feature I will add it.

Meanwhile, you can tell the Amazon support agent that the requests are always using the “POST” method. The “Referer” is irrelevant because it can be faked. The “HTTP Status Code” is “200 OK”. The “Size of the Response” is irrelevant as well as the “Identd”. The only piece of the puzzle that cannot be inferred from the plugin logs is the name of the file that’s receiving the request, but I don’t think you need that in order to block someone’s attempts to break into your website.

There is no need for us to collect that information because you can already get a copy of those logs from your hosting provider. The file is usually called “access_log” and is stored inside a directory called “logs” just above the document root of your website. If you cannot locate them in your account, you can simply ask your hosting provider for a copy of the most recent access logs and they will definitely send it to you.