yorman
Forum Replies Created
-
@makemymark — the fix that I mentioned in previous comments on this thread are all available in the development repository [1] you have to install that to get them in your website, otherwise you will have to wait until the public release of version 1.8.8 when this pull-request is merged [2] but it may take several days before these changes are approved because they are mixed with other changes in the code. If you need an immediate fix, please install the development version of the code.
[1] https://github.com/cixtor/sucuri-wordpress-plugin
[2] https://github.com/Sucuri/sucuri-wordpress-plugin/pull/40We went full circle here ha ha ha 😀
There are two reasons of why the API service cannot generate a key for your website. One is that the domain name is not reachable. Second is that the email address is hosted in a domain without a proper MX record.
If the domain is the problem then we can simply use another one, it doesn’t needs to be yours, you could generate a key for a website like “example.com” without any problem because the service only checks if the pair “email + domain” already were used, not if “email” is actually the owner of “domain”. However, if the problem is with the email address (because the host lacks a proper MX record) then you will have to use a different one.
Send me a message to
[removed](email removed to avoid spam) and I will generate the key for you; don’t forget to include the domain name and email that you want to associate to the key, just in case the system allows me to generate the key using that data. I will immediately reply with a valid key.I believe you have installed a plugin called “Ninja Forms”, this plugin creates temporary data in the posts table, the Sucuri plugin detects this and reports the changes in the post with ID 121124 to you, then when “Ninja Forms” finishes doing its job (whatever it is) deletes the temporary post and that’s why you cannot find it in the database anymore.
From a message that I posted more than a year ago [1]:
There are many plugins in the WordPress market that use the posts table to store temporary or segmented data, this is because WordPress does not supports the creation of separated tables to process data independently, plugin/theme developers usually hook the predefined WordPress functions to insert their data in the same table as the posts and pages but set a flag in one of the columns to differentiate them so they do not appear in the normal interfaces, but they still appear as “posts” in the actions triggered by WordPress and monitored by the plugin, so for example, if one of those plugins is creating a temporary entry in the posts table (like contact form or feedback plugins do) they will appear and dissapear in the audit logs like you saw. Please check the “Ignore Alerts” in the plugin’ settings page to disable the alerts for specific post-types like this one.
The fix I was referring to is to remove the “FailedLoginFooter” from the message, but the rest of the information that you are receiving in your inbox is correct, your website is being targeted by someone and is being victim of a password guessing attack, that is why the username remains the same while the program that they are using tries multiple sequences of text as the password.
What you can do for now, until you decide to put a firewall in front of your website to stop these attacks, is to block the IP address where the requests are coming from. The IP address is included in the messages that you are receiving.
You can also reduce the number of mails in your inbox by disabling the “Receive email alerts for failed login attempts” option from the “Alerts” panel in the plugin’ settings page, and then enabling the “Receive email alerts for password guessing attacks”. This will instruct the plugin to collect all the failed login events into one single message that will be sent to you every hour with the summary of the attack, so instead of receiving one mail per failed user authentication you will receive just one which will reduce the mechanical work that you are doing by deleting these messages manually.
I have tried to search online but have not been successful in finding a proper reason or a solution to the issue on hand.
What issue exactly? Are you referring to the text “FailedLoginFooter” at the end of each password? Or to the fact that you are receiving multiple notifications about a password guessing attack?
If it is the former, I already fixed this in the alpha version of the code here [1] but the changes have not been approved yet. You can install this version of the code from here [2] or wait until the public release in a couple of days.
Regarding the password guessing attack [3] I suggest you to read this [4] and this [5] to understand what they are and how to stop them. Most people decide to install a firewall in front of their websites to filter out the malicious traffic, others try to block these attacks with elaborate access control rules with their web servers, others use security through obscurity and hide their login page.
You can use any of these techniques or implement a new one; my personal suggestion is to install a firewall, Sucuri offers one here [6] in case that you are interested to pay for a premium service, there are some free alternatives though here [7].
[1] https://github.com/Sucuri/sucuri-wordpress-plugin/pull/40
[2] https://github.com/cixtor/sucuri-wordpress-plugin
[3] https://kb.sucuri.net/definitions/attacks/brute-force/password-guessing
[4] https://blog.sucuri.net/2016/12/ask-sucuri-how-to-stop-brute-force-attacks.html
[5] https://sucuri.net/website-firewall/stop-brute-force-attacks
[6] https://sucuri.net/website-firewall/
[7] https://www.google.com/search?q=web+application+firewall@andrewbloom — thank you for your comment.
I suggest people to disable the alerts for the
Postman_sent_mailpost-type rather than disable all the alerts associated to modifications in the posts, otherwise you will end up missing significant events. You can do this using the tool “Post-Type Alerts” at the bottom of the “Alerts” panel in the plugin’ settings page.If you install the alpha version of the code [1] you can also disable specific post transitions, in this case, when a post changes from being “new” to being “private”.
@heathcliffe2000 — yes, the settings were automatically reset back to their default values. The plugin was using “add_filter” [1][2] to modify the settings for the heartbeat API at runtime, deleting the code caused these settings to be back to its normal state. However, if you notice anything strange after the upgrade of the plugin please let me know and I will investigate.
[1] https://github.com/sucuri/sucuri-wordpress-plugin/commit/f45dd8e#diff-198096ad83dfc8152a10d95eb1b6b598
[2] https://developer.wordpress.org/reference/functions/add_filter/@deeveedee — @7thcircle — @dudnee — @uberjuice — I have re-added the option to disable the reporting of the passwords used during a password guessing attack here [1] please install the alpha version of the code from here [2] so you can have this feature available in your website, we will release version 1.8.8 in a couple of weeks to include this and other bug fixes.
[1] https://github.com/cixtor/sucuri-wordpress-plugin/commit/84dd39d
[2] https://github.com/cixtor/sucuri-wordpress-plugin@jamesvg — @colewebdev — I have fixed the problem with this commit [1] please install the alpha version of the code from here [2] if you need this patch immediately or wait until version 1.8.8 is publicly released. Thank you for reporting the bug.
[1] https://github.com/cixtor/sucuri-wordpress-plugin/commit/d21a062
[2] https://github.com/cixtor/sucuri-wordpress-plugin@colewebdev thank you for testing.
@jamesvg — I was able to reproduce the issue by changing the ownership and removing the write permissions of these two files [1][2]. When these files are not writable by the plugin it cannot ignore the irrelevant files during startup as shown in this piece of code [3]; I will modify the code to take in consideration this case and ignore the files in a different way.
[1] /wp-content/uploads/sucuri/sucuri-settings.php
[2] /wp-content/uploads/sucuri/sucuri-integrity.php
[3] https://github.com/Sucuri/sucuri-wordpress-plugin/blob/b1e8647/src/integrity.lib.php#L574-L634The plugin ignores both the WordPress configuration file [1] and the access control file [2] automatically, but the addition of these files to the false/positive list happens once or when this option [3] is set to anything other than the word “done”. In my tests these two files are correctly ignored, there is something in your server environment that is preventing the plugin from reading the false/positive list.
Lets try this, go to the settings page and scroll to the bottom, you will find a section called “Import and Export Settings” with a text area containing the relevant settings of the plugin in a JSON object. Locate one that says “sucuriscan_integrity_startup” and then modify the word “done” next to “false” or anything else, as long as it is different than “done”, submit the form and check if those two files are still being flagged in the dashboard.
Let me know if it works, otherwise I will investigate this a bit more.
[1] https://github.com/Sucuri/sucuri-wordpress-plugin/blob/b1e8647/src/integrity.lib.php#L589
[2] https://github.com/Sucuri/sucuri-wordpress-plugin/blob/b1e8647/src/integrity.lib.php#L584
[3] https://github.com/Sucuri/sucuri-wordpress-plugin/blob/b1e8647/src/integrity.lib.php#L581@heathcliffe2000 — @bacchusfugue — yes, we removed that option here [1] as we realized that it was causing more issues than not. This was not a security related feature, the purpose for this option was to allow web masters to disable the heartbeat functionality if — and only if — they were experiencing issues with the latency of the API service, since the heartbeat generates a significant amount of HTTP requests. After the rest of the code was improved, we decided that the option was not necessary anymore.
We have no intention to re-implement this option again, I believe another developer can copy and paste the code from the commit linked below and offer this functionality with a different plugin.
[1] https://github.com/sucuri/sucuri-wordpress-plugin/commit/f45dd8e
@deeveedee — @7thcircle — @dudnee — @uberjuice — the option to remove the password from the failed login alerts was deleted with version 1.8.4; I have added a condition [1] to allow you to programmatically disable this behavior by setting a constant in the WordPress configuration file. Please install the alpha version of the code from here [2] to get the early update or wait until the public release of version 1.8.8; I will probably re-add the option to the settings page, but for now install the alpha code if you need an immediate fix.
[1] https://github.com/cixtor/sucuri-wordpress-plugin/commit/b1a9169
[2] https://github.com/cixtor/sucuri-wordpress-pluginI am ware of these scans; the IP address “173.255.233.124” is associated to SiteCheck [1] the service that powers the malware scans in the plugin. A scan is requested when you access the plugin’s dashboard [2] and the data is cached for 20 minutes [3][4]. The scans are not triggered automatically, they require human interaction.
There is no option to disable the execution of the scans, and even if there was an option in the plugin, anyone on the Internet can request a scan anytime they want simply by using this page [1].
If you want to stop the plugin from triggering the execution of the scans, please install the alpha version of the code [5] which includes a condition [6] to allow web masters to force the plugin to scans a different domain name; define a constant “SUCURISCAN_SITECHECK_TARGET” in the WordPress configuration file with “localhost” as its value or any domain that you want the plugin to scan instead of yours.
[1] https://sitecheck.sucuri.net/
[2] https://github.com/Sucuri/sucuri-wordpress-plugin/blob/b1e8647/src/sitecheck.lib.php#L35-L63
[3] https://github.com/Sucuri/sucuri-wordpress-plugin/blob/b1e8647/src/sitecheck.lib.php#L126-L128
[4] https://github.com/Sucuri/sucuri-wordpress-plugin/blob/b1e8647/sucuri.php#L176-L179
[5] https://github.com/cixtor/sucuri-wordpress-plugin/archive/master.zip
[6] https://github.com/cixtor/sucuri-wordpress-plugin/commit/00feb9bMarking as resolved after +6 days with no replies from the original poster. I will assume that one of the solutions suggested in my previous comment worked and the author of the ticket is not experiencing the reported issues anymore. Feel free to re-open the ticket otherwise.