yorman

Is there any good reason NOT to block access to the login page to anyone with an amazonaws.com IP address?

People using a VPN hosted at AWS could have problems accessing your website.

I would check the access logs and count how many hits does your website have from the AWS network (before the attack started) and then decide if blocking that IP range is fine or not. There are also 3rd-party services, like web crawlers, that are hosted there. They may not be able to index your website if you block the entire IP list.

I don’t have an admin account with the name “admin” so someone is clearly just guessing

That is understandable. We used to have an option to allow the administrator to block any login attempt using an account that doesn’t exists. The option may still be available in the “Last Logins” page, but it has already been removed from our development repository and — if not released yet — will be gone in the next update of the code.

How can I check my server for mod_headers module?

It depends on what software you are actually using.

• If you are using the Apache web server, then execute apachectl -M
• Other versions of Apache also allow for apachectl -t -D DUMP_MODULES
• If you are using the Apache web server on CentOS, execute httpd -M
• If you are using Nginx, execute nginx -V and search _module
• Ask your hosting provider if you are using another web server

but Recomendations in Dashboard still are

This may be because your server doesn’t have the mod_headers module.

Or the results of the malware scanner are still cached, you have to wait 20 minutes for the cache to be reset, or you can reset it yourself from the “Data Storage” panel located in the plugin’ settings page. The file is called sucuri-sitecheck.php.

There is no documentation at the moment.

I will pass your inquiry as a feature request to my project manager. Building a database of changes that can be correlated against these alerts to have a better understanding of what is happening. I will work on this feature if they agree to implement it, but be aware that this will take a lot of time because there are many post-types, and they can change without previous notice, the database will be huge and will be outdated most of the time.

For now, I will answer your question…

The post-type jp_sitemap seems to be used by JetPack to store the content of your website XML map [1] and because the data is stored in the same table as the WordPress posts, every modification is reported the same way. These changes include, new entries in the sitemap, entries being marked as draft, entries being marked as published, entries being marked as trashed, entries being marked as deleted and so on.

You can opt-out from receiving these alerts using the “Alert Settings” section located in the alerts panel found in the plugin’ settings page. There you will find all the post-types registered by the plugins installed in your website, you can disable and enable one or more of them at any time.

[1] https://en.wikipedia.org/wiki/Site_map

Is there an advantage to erasing the contents versus deleting?

No, there is no advantage.

Depending on how the malware was injected in the first place, leaving the empty files in their current location may be a good idea. I have seen some malware try to check if the website was already infected to reduce the work time. Some of them do this by checking if the files exist, if yes then the re-infection is skipped.

However, I have also seen other type of malware that also checks the size of the files, because they are now empty it will trigger the reinfection. Even leaving some random content inside those files may not work at all because other type of malware also checks the hash of the file, to verify if the malicious code is correct.

Should I now go ahead and delete these files?

This is a matter of personal choice. If you decide to leave them there, consider to also remove all permissions (read, write, execution) so they cannot be checked, overwritten or executed respectively. Just remember to patch whatever security hole allowed the infection in the first place.

By definition, a “Internal Server Error” is a complete failure of the server caused by the execution of erroneous code. There are many-many things that could cause such an error, so it’s difficult to give you a good answer. Consider what changes were applied to the server or the website before the error appeared.

Taking in considering the previous conversation, I think your website was wrongly integrated with the plugin that you deleted. Causing the entire application to throw an unrecoverable error that your web server cannot handle, and so it decided to throw a “500 Internal Server Error”.

You should revert any hard integration that your website have with that plugin.

If there is no hardcoded integration, it is probable that during the deletion something got modified in the code and a syntax error was introduced. You will have to inspect the “error_log” files and fix whatever error was thrown by your web application.

Let me know if you need more information.

I did step [1] and [2}, but errors are the same.

This is because you haven’t fixed the errors that the scanner is reporting.

I just inspected the source code of this page [1] and I am seeing the PHP warning. Fix the errors in your code before clearing the cache, otherwise you will keep seeing them being reported in both the plugin and SiteCheck.

[1] http://slopiewnie.cba.pl/pl/7-2/