yorman
Forum Replies Created
-
Can I delete this or clear it?
Yes, you can delete the file, it’s safe.
Is it normal to have the file grow to this size?
It’s not normal. The file is used to store the store failed user authentication attempts AFTER they are sent to the inbox assigned to receive the email notifications.
If the file is not being automatically reset after the email, it is either because the login attempts are too many and your SMTP server is not able to send the emails fast enough.
Or because the number of attempts is at least one-less of the maximum that you defined in the settings page, per hour, the plugin assumes that there are not enough attempts to report a brute-force attack and so it copies the logs into the old file and resets the main one.
This is not a bug per se, the plugin offers an option in the settings page called “Data Storage” that allows the admin user to reset the content of the security logs and cache created by the plugin. I will mark this ticket as resolved. Feel free to re-open if you need more information.
Thank you for the feature request.
I will copy this into my internal TODO list and ask one of my project managers to assign a priority. If they agree to implement this security alert I will try to make it available before the next version of the Sucuri plugin is released.
Do you mean look for DISALLOW_FILE_EDIT using phpMyAdmin?
No, the “DISALLOW_FILE_EDIT” constant is a piece of code defined in a PHP file somewhere in your website. When you use the Sucuri plugin to disable the plugin and theme editors, the plugin modifies the global configuration file “wp-config.php” to define that constant inside, but you said that you are unable to enable the editor again, which means that the Sucuri plugin was not used to disable it in the first place, so you have to search that constant in the other files that compose your website.
if anyone else has this problem, a workaround is using the plugin
Thank you for the workaround. I hope people don’t need to resort to install another plugin to “fix” this problem as having a 3rd-party editor opens a whole universe of security issues depending on how the code for that editor was actually implemented.
Consider this from a user perspective. User inherits admin position of website
This is what started the whole problem.
When you inherited the “admin” position of this website you should have received all the information related to the infrastructure of that project, including all the services that are being used (which in this case includes the Sucuri Firewall).
When you say “User determines […] this and that” you are saying that after having made assumptions about the project and associated services because there was a lack of proper training before the “admin” position was inherited. Otherwise, you wouldn’t have assumed anything.
For all intents and purposes, the only way for me to figure out that my host must be running a separate sucuri firewall, unconnected to the sucuri plugin, is through a snotty plugin developer.
I apologize for my attitude.
Receiving a bad review before requesting support is something that I take in a bad way. After spending a couple of minutes in the forums associated to the plugin [1] you will notice that I am the only one answering questions.
Again, I apologize and will take your feedback to my upper managers so they can improve the user experience in the interfaces, specially the ones associated with the Sucuri Firewall. I will try to do my best explaining the functionality in the plugin, but I am not a native English speaker so this may not be possible until I can get help from one of my co-workers.
That link to the firewall description does nothing to inform a user that the plugin without an API connected is not actually performing any firewall actions. For all I could figure out, the free version of the plugin must have a basic firewall that if you wanted to white list something, would need to pay for a subscription in order to connect the api to control.
Fair enough. I will fix the information in that page.
From my perspective, in order to fix my site, I needed to pay. Maybe Sucuri should figure out how not to be mistaken for ransomware. A simple ‘If you are receiving this message contact your host’ or something notifying that somewhere in my stack someone was already paying for the firewall.
I get your point about “ransomware”.
I will ask one of my co-workers who speaks native English to fix the wording of these pages.
Your response to my support ticket was much more professional and less condescending
I apologize once again and hope you can find a solution to the problem that you are facing. Since you are managing a website that is being protected by the Sucuri Firewall, but are new to the security interface, I suggest you to contact one of my co-workers in chat [2] (at the bottom of the page) they will be happy to help you getting that PHP file whitelisted to get rid of that error. You can also send an email to info@sucuri.net if you prefer to have a copy of the conversation.
[1] https://wordpress.org/support/plugin/sucuri-scanner/
[2] https://sucuri.net/This blockage comes directly from the Sucuri Firewall and not from the Sucuri WordPress plugin.
If you are seeing this error, it means that your website is being protected by the Sucuri Firewall and so you have to configure your account to allow the execution of that specific PHP file which is probably located in the content directory. You can apply these changes from here [1] following these instructions [2].
If you do not have access to your Sucuri Firewall account, we can assume that whoever created your website (maybe a web agency) added it to the Sucuri Firewall network. In this case, you will have to communicate with that agency/developer to whitelist this PHP file.
Again: This blockage was NOT applied using the Sucuri WordPress plugin, so if you uninstall it nothing will change because the Sucuri Firewall will still be running the security filters against that file that OneSignal is using for whatever reason.
Marking as resolved, feel free to re-open the ticket if you need more help.
[1] https://waf.sucuri.net/
[2] https://kb.sucuri.net/firewall/Whitelist+and+Blacklist/whitelist-file-folderEverything is fine until you figure out that the plugin is running amok.
What exactly do you mean by “amok”?
It is as bad as ransomware […]
That’s a very bad comparison.
I encourage you to read about what “ransomware” really is from this WikiPedia article [1]. I am sure you will learn a lot from it; after that, I am sure that you will understand the difference between a real “ransomware” and a security plugin that simply reports unusual activity in your website. The plugin doesn’t do any encryption nor any significant change in your project files, so calling it “ransomware” is very misleading for other users.
if you do have an issue with the firewall blocking something it shouldn’t be, the only choice you have is to pay for a subscription. Guess what? you can’t even submit a support ticket without paying them
If you are talking about the Sucuri Firewall, it means that you already paid for the service, which means that submitting a support ticket will cost absolute nothing, $0.00, nada!
Just to clarify, the Sucuri Firewall and the Sucuri WordPress plugin are two completely different services. If you are seeing warnings about malicious code being served by your website to the Internet, this is because external scanners (there are many in the market) found the malware and flagged your website as compromised, the Sucuri WordPress plugin is simply showing you the warnings so you can fix them. The Sucuri Firewall has nothing to do with this, if you had the firewall in the first place, you wouldn’t even see the warnings because we are cleaning and filtering the malicious code.
I encourage you to read more about how the Sucuri Firewall works from here [2].
Even if you deactivate the plugin, it still continues to cause problems
This doesn’t even makes sense. If you deleted the plugin from your website, how can it cause problems if the code that powers the plugin is not running anymore? Maybe you if explain what problems you are experiencing I could help you.
[1] https://en.wikipedia.org/wiki/Ransomware
[2] https://sucuri.net/website-firewall/@ooas — The solution is to use this command [1] to search for the definition of the
DISALLOW_FILE_EDITconstant in your entire website and delete it. You have to do this manually because the file editor was not disabled using the Sucuri plugin, something else in your website applied that hardening (maybe a different plugin or simply someone with access to the server), otherwise the revert button would work.Also, notice that the previous poster was talking about the “Block PHP files in Uploads Directory” and you are talking about the “Plugin and Theme Editor”, the code that powers these options is completely different, the only things that they have in common is the fact that they are both in the same page but other than that, they are completely different things; the explanation that I left in my previous comment doesn’t apply to your case because you are experiencing a different problem.
[1]
grep -rn "define(.*.DISALLOW_FILE_EDIT" .If you search “Jp_sitemap_master” on the Internet [1] you will find this ticket [2] which points to this other ticket [3] that someone else created half a year ago. There, I commented about a solution.
can anyone help me please with what this is about […]
The alert is triggered by JetPack after it generates a new XML file for the sitemap of your website. This is not necessarily malicious, the alert is intended to alert you that something changed in your website that you should be aware of, it is up to the webmaster to decide if the change was malicious or not.
[…] and whether I need to be concerned?
If you didn’t install JetPack and/or you don’t want the “sitemap.xml” file to be modified, then yes, you should be concerned about these changes and take immediate action as this could be the starting point of a SEO infection. On the other hand, if you both installed JetPack and configured the plugin to apply changes to the “sitemap.xml” file to reflect changes in your posts/pages, then you can disregard these alerts (and even disable them if you want).
[1] https://www.google.com/search?q=wordpress+%22Jp_sitemap_master%22
[2] https://wordpress.org/support/topic/jp_sitemap_master-2/
[3] https://wordpress.org/support/topic/jp_sitemap_master/Hello @zonwarrior
What is the difference between the patch and open_basedir request?
The patch fixes the PHP exception that is preventing the WordPress Integrity tool to load. The “open_basedir” request is a modification requested Kinsta.com to force the plugin to scan the directories specified in this setting during a file system scan, and skip any directory outside the tree.
I thought they were the same request lol.
They are conceptually related but technically speaking are two different things. One is a bug (the one I patched) and the other one is a feature request (the one requested by Kinsta.com).
What is this ‘nice thing to have’ ?
I was referring to the request made by Kinsta.com; the feature request to skip the directories not specified in the “open_basedir” setting. I say that it is a “nice thing to have” because if I don’t implement this feature nothing will be broken. Kinsta.com requested this change to reduce the number of logs in their system, because according to them, their system is still logging the exception even if the PHP script is gracefully handling it.
I’ve been noticing my diskspace moving up on my websites that have sucuri. My suspicion is that sucuri is storing security logs on my server, and that’s why it’s growing. Is there a way to delete all my old security logs to make space on my server?
This may be related to the logs created by Kinsta.com and that’s why they requested the modification besides the patch that I already submitted. However, this is just speculation from my side, as I don’t have access to an account in their servers to check what is actually happening.
You can delete the security logs stored in your server using the “Data Storage” panel located in the plugin’s general settings page. You can also manually delete the logs which are all located here — “/wp-content/uploads/sucuri/”
Hello @zonwarrior
I don’t have any news when this fix will be officially pushed to the new release. The patch that handles the runtime exception is already available in the development repository here [1] that you can download from here [2].
But the modifications requested by Kinsta.com to consider
open_basedirduring a scan is still in the backlog of my TODO list, there are other tasks with more priority right now so I haven’t had time to work on this. The priority of this change is low because it is not really affecting the functionality of the website, it’s just a “nice thing to have” requested by Kinsta. You will probably receive a notification from your WordPress installation about the update once we release the new version.Thank you for your patience.
[1] https://github.com/Sucuri/sucuri-wordpress-plugin/pull/43/commits/2795c7e
[2] https://github.com/Sucuri/sucuri-wordpress-pluginThe login page is just one of many ways a user can log into a WordPress website.
Read this — https://blog.sucuri.net/2015/10/brute-force-amplification-attacks-against-wordpress-xmlrpc.html
Hello @jkuzma did you apply the changes suggested in my previous comment?
[…] did you create Sucuri
No, I am just one of the many developers working at Sucuri. The company was funded by Daniel Cid and Tony Perez [1]. Later, we joined GoDaddy after an acquisition at the beginning of 2017.
[…] are you one of their top engineers?
I wish 😅 but no, I am just average in the Sucuri hierarchy.
By the way, you said “I will make the appropriate modifications to exclude all the directories contained in the open_basedir whitelist during a malware scan.” You mean “to exclude all the directories NOT contained in the open_basedir whitelist” correct? – Kinsta asked
Ah yes! My bad, the naming of that variable is confusion — and I am not a native English speaker — what Kinsta said is correct: I will modify the code that powers the WordPress Integrity tool in the Sucuri plugin to exclude all the directories NOT contained in the “open_basedir” whitelist”.
Definitely!
I will make the appropriate modifications to exclude all the directories contained in the
open_basedirwhitelist during a malware scan. Thank you for reporting the problem. I will make sure that the fix gets included in the next update.Happy New Year 🙂
Ah okay! I understand, thank you for contacting Kinsta.
This error was fixed in August 14, 2017 as you can see here [1].
Unfortunately, the fix was just recently merged (21 days ago, on Dec 11, 2017) as you can see here [2]. My co-workers in the development team are still running unit, integration and vulnerability tests against the new code base to verify that all my changes are correct. If you check the pull-request, you will notice a lot of changes, that’s why it is taking some time for these modifications to be released to the public.
Feel free to download the development version of the plugin from here [3] or wait until the official release of the update which will happen in a couple of weeks. I will notify my project manager that this bug will be fixed with this update so they can consider a faster release process.
[1] https://github.com/Sucuri/sucuri-wordpress-plugin/commit/2795c7e
[2] https://github.com/Sucuri/sucuri-wordpress-plugin/pull/43
[3] https://github.com/Sucuri/sucuri-wordpress-plugin