yorman
Forum Replies Created
-
The plugin is reporting the results of the malware scan executed by an external web service owned by Sucuri that’s being hosted here [1]. If you go to this website and scan your domain, then click on “more details” you will see a box with additional information, including the “Redirects to…” stuff.
Usually, one or two redirects are okay. For example, when I scan my personal website, the scanner takes the HTTP version of the URL, but my website redirects the users to the HTTPS version, so SiteCheck reports one single redirection. Many other website do the same.
However, if I understand your comment, you are saying that the redirections are pointing to the same URL, multiple times. This only happens if your website is sending the malware scanner into an infinite loop, for example, redirecting users from HTTP to HTTPS and then back to HTTP which automatically redirects them to HTTPS again, and so on, forever. Eventually, after certain amount of redirections, the web servers stops them and kills the process, which is what eventually the scanner reports.
Please check with your web developer to see if the redirects are correct.
Marking as resolved, let me know if you need more information.
If you pass your mouse over the information icon beside the green “Submit” button, you will see a box with information explaining the meaning of each flag in the table.
Green flags mean that the file is not part of a normal WordPress installation and should be deleted at your own discretion.
The restoration action can only be applied to files that are part of a normal WordPress installation but appear to be modified. The plugin will download a fresh copy of the code from WordPress’ website and replace the one that you have in your server. But in this case, this action cannot be used because the files that are being listed haven’t been modified, they have been added.
Feel free to delete them or mark them as fixed if you don’t want to see the warnings again.
What’s the name of the file that is being flagged?
Error in event handler for (unknown): TypeError: Cannot read property ‘url’ of null
This error message is not WordPress nor Plugin related.
That error message is coming directly from an extension in your web browser.
I have installed the Sucuri plugin on a client site and the settings tab in the backend shows up blank without any content.
You need to inspect the
error_logfile that your web server is generating to see if there are errors in the PHP scripts. Then, if you find one associated with the Sucuri plugin, please send it to me so I can investigate.The delivery of the email alerts depends entirely of your SMTP server.
When the plugin sends an alert, the message goes through WordPress’s PHPMailer library, and after that it’s all WordPress and your SMTP server’s job to delivery the message to your inbox. It is difficult for me to provide an answer to explain why the mails are not being sent because your installation is using a custom configuration.
Oddly enough, I had lost track of my API Key, and the Recovery Email worked fine
That’s because the message with the recovery information is sent by Sucuri, not your web server. When you click the recovery button, the plugin sends an HTTP request to Sucuri asking for the API key. Sucuri then sends an email using their own SMTP server, that’s why you are getting the message without problems.
I suggest you to use this Docker image [1] to test the mail delivery.
Marking as resolved, feel free to re-open if you need more information.
Hello @megamenu that’s a very good investigation work, thank you.
I will add the logs as you suggest and keep investigating on my side as well.
I have added the logs here [1] we’ll have to wait for the project manager approval.
[1] https://github.com/Sucuri/sucuri-wordpress-plugin/pull/61/commits/2fe11c1
I’ve tried to hit wp-cron.php and i’ve also tried removing the plugin and reinstalling, the tasks come back instantly with the same age etc.
This is expected for some scheduled tasks that I call “special actions” like the ones installed by WordPress itself to auto-update the core files, check for themes and plugin updates and post draft cleanup. You can remove them, but once a WordPress page is loaded again, they will be re-installed. This is already mentioned in the description of that “Scheduled Tasks” panel.
I wouldn’t be surprised if other themes and/or plugins are following the same strategy to keep some of their actions running in the background per their own requirements. What I would do is, disable all the plugins except “Sucuri Scanner”, then try to remove all the scheduled tasks, all of them. After this, only the WordPress tasks (and one for Sucuri) should be in the table, if you see more than these, then the problem is with the database.
Alternatively, is there a way of forcing these tasks to execute so that they clear out? (I’ve tried to hit wp-cron.php, I also have a cron job setup to execute it every 2 mins).
If the scheduled task was configured to run at intervals, they will not be cleared, they will stay in the list indefinitely, until you decide to remove them (by uninstalling the plugin that installed it). Plugin developers can choose to install a run-once scheduled task, which is automatically cleared by WordPress after the first execution.
As I need to do this on multiple sites, hoping there is a easy way to do it that’s quick to bring things back to normality.
Manual work is guarantee, but this SQL statement may help you [1][2][3].
Marking as resolved with the assumption that the thousands of scheduled tasks installed in your website(s) are the product of a bug in one or more plugins that you have installed. Using the Sucuri plugin to delete these tasks will not suffice if the other plugins are not fixed.
Feel free to re-open the ticket if you need more information.
[1] https://wordpress.stackexchange.com/questions/175878/a
[2] https://wordpress.stackexchange.com/a/175880
[3] https://hackguard.com/blog/clear-cron-jobs-wordpressHello @megamenu thank you for your message and the screenshot.
The changes applied to the code to attempt to fix this problem are available here [1]. Scrolling all the way down the page you will see that @ycampo added a new register statement to link the uninstallation event (triggered by WordPress) with the function that is used to reset all the settings, logs, and hardening.
Meanwhile, the deactivation hook (which was the thing used before the fix) is now calling a function that only resets the scheduled task used to start the malware scanner in the background. You can see the function definition here [2] and the uninstallation function here [3].
The only conclusion that we can get from reading the code is that WordPress is, for some reason, triggering the uninstallation function. I wish I could reproduce this problem easily, but tracking bugs like this is difficult. I suggest you to add some logs inside both functions, link that to any possible HTTP request from the access logs and —if we are lucky— we may end up with more information to understand what is happening here. I will do the same on multiple servers with different configurations.
[1] https://github.com/Sucuri/sucuri-wordpress-plugin/commit/821e7c6
[2] https://github.com/Sucuri/sucuri-wordpress-plugin/blob/ceaf0d2/sucuri.php#L244-L255
[3] https://github.com/Sucuri/sucuri-wordpress-plugin/blob/ceaf0d2/sucuri.php#L257-L306Hello @omniafausta sorry for the confusion.
As you already found out, Sucuri —the maker of this plugin— is a subsidiary of GoDaddy Inc. which I assume is your client’s hosting provider. The company’s decision to install and activate the plugin by default may be part of an on-going campaign to improve the security of all the websites that GoDaddy serves.
I will let the GoDaddy Support Team answer your question.
Marking as resolved, feel free to re-open the ticket if you have more questions.
Hello @eatingrules that’s a good suggestion.
I will make sure it gets implemented and released in the next version.
Thank you.
None of those files are part of a normal WordPress installation.
The only action you can execute over them is the “delete” action.
If you don’t want to delete them but also don’t want to see them in the warning table, then choose the option “mark as fixed”. The scanner will ignore them during future scans.
What is his target? What is he TryIng?
You said that they are visiting your login page, we can guess that they want to log into your admin panel. Then you mentioned that they are trying to locate a file that is commonly used to upload other files into the website, we can guess that they want to upload a malicious file. Changing their IP address is just their attempt to circumvent any blocking that you may or may not be exercising.
To be honest, I wouldn’t be worried about them. I have seen websites receive millions of attacks per day, it’s not uncommon. They will keep trying different things until either a vulnerability is found or they get bored and move onto a different target.
What you can do is to make sure that they don’t get access to sensitive data nor to private parts of the website. It doesn’t matter if they are hitting your login or upload scripts thousands of times per second, as long as you keep the security of your website on shape. If you are concerned about the bandwidth consumption, you can block them, but they will simply change their IP address, your only option may be just to put a firewall in front to filter all the bad traffic.
Ask your hosting provider to see if they offer some sort of security services that you can buy to increase the security of your website. Or try one of the security services offered by different companies online [1][2][3].
Let me know if you need more information.
[1] https://www.akamai.com/uk/en/resources/waf.jsp
[2] https://sucuri.net/website-firewall/
[3] https://www.cloudflare.com/waf/Dealing with automated login attempts is a problem that WordPress websites will face forever, as long as there is a reachable login form. You can read more about the subject of brute force password attacks here [1][2][3].
Marking as resolved, let me know if you need more information.
[1] https://sucuri.net/website-firewall/stop-brute-force-attacks
[2] https://kb.sucuri.net/definitions/attacks/brute-force/password-guessing
[3] https://blog.sucuri.net/2016/12/ask-sucuri-how-to-stop-brute-force-attacks.htmlActually, It happened after installing sucuri. I want to know what is this?
It’s hard to say without knowing a bit more about your website.
The order in which the information is listed in the table (taking in consideration the amount of time since the session started) tells a little bit of the story, but this is still speculation:
- Someone logged in from
162.216.19.183using an unknown software, - At the same time, someone from
2600:3c03:0:0:f03c:91ff:fedb:9602logged in using the same credentials and an unknown software as well, - 7 seconds after, the first user logged in again without logging out first, this time using a software with the Microsoft Internet Explorer user-agent, WordPress is responsible for killing previous cookies when a new session is started, I don’t know why it didn’t happen this time,
- Something similar happened with the second user, they logged in using a software disguising as the Safari web browser from macOS, 8 seconds after the initial session was created, and same as the other user WordPress didn’t expire the previous cookies,
- This process, with the second user, was repeated three more times 9, 11 and 30 seconds after the original session started using an unknown software, then something behaving like Google Chrome and finally using something behaving like Microsoft Internet Explorer, respectively.
Thinking about it, and taking a wild guess, I would say that someone or something (like an automated software) was checking leaked credentials with different user-agents to see if the website behaves in a different way.
However, both IP addresses
162.216.19.183and2600:3c03:0:0:f03c:91ff:fedb:9602are associated with the web malware scanner that Sucuri SiteCheck uses. I don’t know why is it triggering a login report in your website. I will talk with the maintainer of the code and will update this ticket when I have more information.Thank you for your patience.
The first alert was triggered by Google’s web crawler after it scanned your website for new content. You also have a plugin called “Login Customizer” that seems to be working in a strange way. When Google’s web crawler scanned your website, it triggered an action in this plugin that forced an update in a post or page that they may be using to control the layout of a form that you previously designed.
The second alert was triggered by WordPress itself when you were inspecting the content of an existing post or page, or while idle during the creation of a new one.
I suggest you to review the content of those two posts with ID 1796 and 1797 to check if there is any malicious content, both in the text and source coming from the database.
Marking as resolved, let me know if you need more information.
- Someone logged in from