g0tr00t
Forum Replies Created
-
@damnsharp Was the website transferred to a different hosting location? It’s possible that the WP installation still exists on the old host which is why it would show a different IP address for the website. If you are able to view the full email headers of the alert email then it should show the server used to send out the email. Look in the Received: field of the email headers for its source ??
@damnsharp It sounds like the uninstall of the plugin was not successful and so there are database entries that are still existing. The easiest way to fix this would be to re-install the plugin through wp-admin and then deactivate it and remove it through the wp-admin interface.
@damnsharp Were you able to verify that the directory /wp-content/plugins/sucuri-scanner/ was removed?
@rahulkshinde @kgagne Can you provide the URL for the WP installation that is being scanned?
Sometimes it is necessary to whitelist the IP addresses the SiteCheck service uses to scan the website as the web host may interpret the scan as an attack/reconnaissance.
#IPs to whitelist
52.203.142.240
34.229.141.32
35.175.20.111
52.87.213.12
184.73.40.53
18.206.213.51@damnsharp Did you remove the actual directory from /wp-content/plugins/ ?
@bambambam Per Wordfence:
“…an unauthenticated attacker could send a POST request to wp-admin/admin-ajax.php with an array parameter, ‘allPopupData’, containing a number of key-value pairs including a popup’s ID (visible in the page source) and a malicious JavaScript payload, which would then be saved in that popup’s settings and executed whenever a visitor navigated to a page where the popup was displayed.”
So basically they just had to browse your website, notate the popup ID on pages that it was active, and submit a crafted POST with their desired Javascript payload.
@jonrehr What’s the domain name? It can be difficult to determine without seeing the actual error message being generated and when it occurs.
You can always try temporarily renaming the main .htaccess file to something like .htaccess-bk and then temporarily renaming the plugin directory that you want disabled so for Sucuri’s plugin it would generally be /wp-content/plugins/sucuri-scanner/ renamed to something like /wp-content/plugins/sucuri-scanner-bk/.
@jess888 You just need to whitelist the files after verifying they are not malicious ??
It’s flagging them because they are not part of the core WordPress, so you should back up, remove any that aren’t necessary OR whitelist them if they are intended to be there. Hope this helps!
Forum: Plugins
In reply to: [Sucuri Security - Auditing, Malware Scanner and Security Hardening] Forbiden@inodinesh Do you happen to have a screenshot of the block warning? Otherwise I’d recommend submitting a ticket so they can fix this for you.
@pattayaspam What feature was requiring premium?
Your domain robchrisman.com is resolving to the IP address 50.87.151.32 that appears to be owned by Bluehost when you run a whois for it. BlueHost and HostGator are both owned by EIG, so this may be the reason behind it if you don’t own a BlueHost account.
@landed I would just block the country unless you expect legitimate traffic from there.
@hedley You can try adjusting the Settings – API Service Communication – Malware Scan Target option to account for the non-standard directory.
@consultant1027 Can you share the domain name? Anything showing up in the server logs when grepping for the IPs that SiteCheck uses to scan?
@westerndeal I believe this scan error on /wp-includes/css/ URLs will occur based on how your hosting server is configured for incoming requests to the /wp-includes/css/ URL.
For example, some of the larger hosts under the EIG brand will serve a 403 error page when direct requests are made to the URL /wp-includes/css/. In addition this page also contained a non-HTTPS URL so that will also generate warnings due to the HTTPS/HTTP mix in the page results.
Are you blocking HTTP requests through CloudFlare or some other method? That could be causing the 503 error.
Adding a custom error page that uses fully HTTPS resources should fix the problem, but without the domain it’s hard to determine.