yorman
Forum Replies Created
-
The file returns because the scanner is executed automatically, it creates a new cache every time it runs, so you can not delete it forever. Anyway, I can assure you that your website is clean now, if you are still seeing the warnings they are surely coming from some cache somewhere in the middle of the process, just ignore them for today, check again tomorrow and see if they are still there.
If the warnings are gone, please mark the ticket as resolved.
It’s also cache, the plugin stores a secondary cache for 20 minutes. You can either wait, or go to the settings page and delete a file called “sucuri-sitecheck.php” from a panel called “Data Storage”.
The results of the malware scan are cached for 48 hours.
There is a link at the end of the page that says “Force a Re-scan”.
I went ahead and clicked it for you, now it shows that your website is clean [1].
Do you still block those brute force login attack/Password Guessing for users…
The purpose of the tool was to reject any user authentication attempt if the username is not in the database. More specifically, if the administrator decided to delete the “admin” account then this tool would allow them to stop the unnecessary failed login alerts for the non-existing “admin” user.
The Sucuri Firewall [1] already provides several tools to do proactive blocking, by browser behavior, network range, IP address, user-agent, country, cookie, among others… I realized that offering a small tool in the plugin doesn’t makes sense when we are providing much better tools in the other service.
I believe the error is referring to timeouts in your web server.
When you request a new malware scan using the plugin or the Sucuri SiteCheck tool, the scanner initiates a connection with your website, it waits for 20 seconds and if the connection fails it stops the scan and considers the website as unavailable.
I built another tool here [1] that you can use to check how long does your website takes to respond to a HTTP request from different parts of the planet. If it says “Could not test website from this server.” it means that your web server took longer than 20 seconds to respond.
In conclusion, your website is too slow to be scanned.
Is there anything I can do to have it back?
No, there is no way to get that feature back.
We decided to deprecate it in the previous update because many people misunderstood the purpose of that tool.
Search the word
pub2srvorapu.phpin your entire website’s source code. You can use the Unix grep tool for that [1]. It is also a good idea to scan the entire database because some times malware can hide in the posts and options tables. Simple SQL queries will suffice, and once you find the source of the infection simply edit the entries and/or infected files.Be sure to patch your entire website after cleaning the infection. Otherwise, you will be in risk of a re-infection using the same vulnerability that allowed the attacker to inject the malicious code the first time.
[1] https://en.wikipedia.org/wiki/Grep
[2] https://sucuri.net/guides/how-to-clean-hacked-wordpressI just installed a fresh copy of the German version of WordPress 4.9.5 and cannot replicate the issue. This makes me believe that the problem that you are experiencing is related to some type of cache somewhere in the server.
What is bad ?
Pass your mouse over the text that says “Hover to see the Payload”.
Where can I change it ?
It depends on what type of malware your website is infected with.
There are thousands of different type of malicious code, each one requires different steps to clean it. Copy and paste the message that you get when you pass the mouse over the payload text and I can give you an idea of how to get rid of that infection.
That makes sense, I will pass this to my project managers, they will decide the priority. I will work on an improvement once I get the ticket back and release the changes in a future update. I will notify you when the changes are available.
Ah good to know, thank you for sharing 🙂
@nurikabe — @duckonwater — this was already fixed with commit #1e1d0ab [1].
[1] https://github.com/Sucuri/sucuri-wordpress-plugin/pull/54/commits/1e1d0ab
[…] require_once(): Failed opening required ‘src/template.lib.php’
This is not a bug in the code.
What this error is saying is that the file in quotes doesn’t exists.
Please upload the plugin to the web server one more time and verify that all the files listed in the Subversion repository here [1] are present in the plugin’s directory here [2]. Don’t forget to upload all the files in the sub-directories, specially the ones listed here [3]. Even if you already know all this, I want to make sure that we are both clear on what needs to be done before we move to the next step.
Fortunately, this seems to be the only site that is experiencing this issue.
This is also proof that there is no bug in the code.
If you have installed the plugin in multiple websites, and the error is only affecting one, this is reason enough to believe that the problem is actually in the web server where the errors are being triggered. Something in your Plesk installation is either deleting this PHP file or preventing the PHP interpreter to load it.
Make sure that all the files exist.
If the error persists, contact your hosting provider.
I am fairly certain that the problem is caused by a misconfiguration of the server.
[1] https://plugins.svn.wordpress.org/sucuri-scanner/trunk/
[2]/wp-content/plugins/sucuri-scanner/
[3] https://plugins.svn.wordpress.org/sucuri-scanner/trunk/src/Thank you for the update.
Even if you are not experiencing the issue with the new website, I will still investigate further when the ticket is passed back to me. Many of our customers are hosting their websites via WPEngine, I believe many of them can benefit from a fix if the bug re-appears in the future.
Lets mark this ticket as “resolved”, I will update if I find something new.
Why am I getting the failed login message?
Unfortunately, I am unable to answer your question right now.
When the plugin reports a failed or successful login, it does so because WordPress triggered the
"wp_login"or"wp_login_failed"action respectively. I just tried to reproduce the issue in my server and it doesn’t happens the same why as in your website, there must be something else going on in your environment that is causing the trigger to run, notice that it also says"Unknown"where the plugin should report your username, meaning that WordPress is actually missing the metadata for the account when passing the login attempt to the plugin.I will pass this ticket to my project manager and they will assign a priority. I will continue investigating when they pass the ticket back to me and will notify you when we have a solution for the error or an explanation to justify why it happens.