yorman
Forum Replies Created
-
Although “robots.txt” is considered a standard among web developers, no one is required to follow its specification, a programmer can create a crawler that will ignore the “Disallow” rules. In fact, specifying files and folders in that file could cause more problems than not because many web vulnerability scanners use its content to point to “interesting resources” to look at during an attack, for example, people creating a disallow rule for their “admin” directory are just explicitly telling people where such directory is.
My personal suggestion is to delete the entries from the “robots.txt” file and convert the redirects into “404 Not Found” responses, sooner or later the web crawlers will stop requesting these files. If you keep the redirection (which I assume is a 301 or 302) you are incentivizing the web crawlers (in this case GoogleBot) to retry the request next time, but if you respond with a “404 Not Found” they will eventually stop because the files clearly don’t exist anymore.
I am not versed into how GoogleBot works, so I cannot explain why the message “BLOCKED URL ERROR 220 Smartphone” is being returned by their mobile crawler, I am not sure if a simple redirection can cause that, but again I am not a SEO expert so who knows, maybe it’s a bug in their code.
Marking as resolved, feel free to re-open if you need more information.
The email address that you are seeing in the settings page is obtained from the settings which are stored in this file [1]. When you request the deletion of one or more entries from the list the plugin will go ahead and delete them from that file, until here everything is good.
However, once a new event is triggered in the website the plugin will try to send a notification with a warning about something suspicious, but since you deleted all email addresses it resorts back to use the email associated to the user account created during the installation of the website, which in this case happens to be yours.
This is why the email is reappearing after a while.
SOLUTION: Add a new email before you delete yours, it could be something like “noreply@example.com” and the plugin will stop sending the alerts to your inbox.
[1]
/wp-content/uploads/sucuri/sucuri-settings.phpI have resolved the issue; thank you for the report.
I couldn’t find any plugin in the WordPress market place [1] with that name. However, I found a premium plugin that seems to be the one that you are using, over here [2].
Unfortunately, since you are using a non-free plugin I cannot offer a solution because I do not have access to their product, I don’t know how their plugin works and without access to the code I cannot investigate the cause of the incompatibility; if you send me a copy of the code I may be able to help, otherwise it will be impossible for me to guess what is causing the problem.
Contact the developer of that “pregnancy” plugin for assistance.
[1] https://wordpress.org/plugins/search/pregnancy
[2] https://codecanyon.net/item/a/13325480I couldn’t answer before because this post was flagged as spam by the WordPress forums. Now it is public, but the original poster was able to find the information to answer his own question. For more information, if anyone is curious about this, please refer to this article [1].
[1] https://blog.sucuri.net/2015/10/brute-force-amplification-attacks-against-wordpress-xmlrpc.html
What are the criteria that Sucuri uses to identify ‘new files added?’
There are two criteria for two different tools.
WordPress Integrity
The integrity tool obtains a copy of the files included in the version of WordPress that you have installed from a public API service maintained by the WordPress organization. The plugin scans your project, and for every file that is not in the list obtained from the API it flags them as new/added.
Audit Logs
The plugin scans your entire project the first time you generate the API key, and assuming that your website is clean at the moment, it sends the list to the Sucuri API service. For every subsequent scan the plugin checks which files are currently in your project against the list of files that were sent to the API the first time, any difference is reported in the audit logs.
Flagged Files with Old Dates
Every file system has a metadata entry to store information about a file, this includes the size, modification date, parent directory, etc. It is fairly easy to change these dates with utilities like the
touchcommand in Unix. Below you can find an example that I took from my Mac computer:$ echo "" 1> file.txt $ ls -lhias -- file.txt 1B Sep 05 10:06 file.txt $ touch -t 199910311503 -- file.txt $ ls -lhias -- file.txt 1B Oct 31 1999 file.txt
Notice how I created a new file on September 05 at 10:06 am, and later used the
touchcommand to change the date to October 31, 1999 at 03:03 pm. Because there is no way to prevent this from a high level as it is with PHP, the plugin can simply show whatever the file system is reporting, a malicious user can create new files in your website and make them pass as old files to mislead. There is no way to explain this to the regular users in an easy way, so we just show the date for simplicity, but technically speaking, the date should be removed as it adds just to the confusion.Let me know if you need more information.
This is the code that powers that action [1].
Notice how line 735 has the message that you are seeing, and by the logic of the rest of the code, this message appears only in two cases, one is when the API key is not present or has an invalid format, you already determined that the key exists and is valid, so the only explanation is that the code in line 740 is failing which forces line 742 to be skipped so the error message is not replaced by the success message in line 743.
The line that is apparently failing is sending a HTTP request to the Sucuri Firewall API, so the problem here is not really with the plugin but with the other project. Please execute this command in your terminal emulation and let me know if there is any relevant information in the response. You can also contact me directly at
[removed](email removed to avoid spam) since this error involves sensitive information that we don’t want to expose to the public in this forum.# EXAMPLE : (firewall key) acbd18db4cc2f8/37b51d194a7513 # API_KEY : (first part) acbd18db4cc2f8 # API_SECRET: (second part) 37b51d194a7513 curl "https://waf.sucuri.net/api?v2" \ -d "k=API_KEY" \ -d "s=API_SECRET" \ -d "a=clear_cache" \ -s | python -m json.tool
[1] https://github.com/cixtor/sucuri-wordpress-plugin/blob/083973f/src/firewall.lib.php#L721-L752
@jb510 — I don’t believe in those numbers.
Take a look at Sucuri’s stats [1] it says +300,000 active installations but every time a new version is released only +25,000 downloads are reported for 1-2 days and then it goes down again to the average 3,000 downloads per day. If there really were +300,000 active installs, we would see the same amount of downloads either the same day a new version is released or across the week after that release. I don’t know where WordPress gets those numbers from, but they are certainly NOT accurate. In comparison, Postman SMTP has an average of downloads of 500 per day [2].
What I will do for now is to automatically disable those two options when the Postman SMTP plugin is active, I will remove the hidden status and include a message explaining why they cannot be enabled. Hopefully this will get a real fix in the future. Thank you for the suggestion.
[1] https://wordpress.org/plugins/sucuri-scanner/advanced/
[2] https://wordpress.org/plugins/postman-smtp/advanced/@deeveedee — @jb510 — thank you for your comment. I didn’t know how popular Postman SMTP was, but I guess I should send them a message and see if there is a way to fix this incompatibility, which I cannot fix alone in our code, they have to modify some things in their plugin as well in order to have a real solution. I will read their code to have a better understanding of why and how they are creating those temporary objects in the posts table, which is what is creating the infinite loop with the Sucuri plugin.
I haven’t received the copy of the blank mails that you are receiving.
Marking as resolved, feel free to re-open if you can provide more details.
Yes, that is what it means.
The entries in the log with the user
systemare the ones initiated by the website itself, without user interaction. To keep the same format as the other logs, the plugin uses the IP127.0.0.1; so yes, your assumption that “[…] these files have been added by a locally running process or by my hosting provider” is correct.Someone used FTP, SSH or the file manager available in your hosting account to create them, or the server itself created them; since this operation was performed outside of WordPress, the plugin has no way to know who exactly created them nor how, hence the use of the ambiguous “system — 127.0.0.1” references.
Marking as resolved, feel free to re-open if you need more information.
In your email client, there is an option or a button to “Show Message Source Code” or something similar, click it and send me the content of that option to
[removed](email removed to avoid spam) this will help me with the investigation.By default, the plugin sends the alerts using the plain text format, something that all email clients understand, there is an option to change the format to HTML to include colors and images which most email clients understand, but they render the content in different ways which makes it difficult for developers to test, this could explain why you are seeing just a blank message.
@rmsite — the message refers to a list of files that appears below the message itself, in a table, if you don’t see it is because the scanner is still loading in the background, just give it a couple of seconds to finish the scan, it shouldn’t take too much time but the performance depends on your own server.
Take a look at this animated image — http://i.imgur.com/TBXLoWT.gif
The option that you enabled/disabled — “WordPress Integrity Diff Utility” — has little to do with the message itself. This option just enables a new tool in the integrity panel to allow you to see the differences detected by the plugin on each WordPress core file, individually. Being enabled or disabled will not change the status of the warning message.
@caordawebsol — I misunderstood your original comment. This thread was originally created to report a problem in the audit logs, but your case is different, the integrity checks are powered by a file system scanner, a piece of code that reads the four main directories that a normal WordPress installation has, they are: the root directory, wp-admin, wp-includes, and part of the wp-content folder.
It is probable that your installation has too many foreign files in any of these directories, the plugin is taking too much time to read all these files. After X amount of seconds (where X is the value of “max_execution_time” in your PHP configuration) the server sends a signal and kills the script. The only solution for this would be to ignore some of the directories from the settings page (in the Scanner tab, you will find a panel to allow you to ignore some of the directories) otherwise the plugin will keep trying to read all the folders/files to analyze the integrity of your installation, and your server will keep killing the script because it is taking too much time.
@caordawebsol — sorry, I forgot to mention the file in my previous comment. This is the file that you should delete [1]; or instead of deleting the file, just download it into your computer, then just leave a couple of entries in it, then re-upload to your server, this way you will not lose all the security logs.
[1]
/wp-content/uploads/sucuri/sucuri-auditqueue.php
