Rules not updating. Done a lot to fix this, but no vail

  • Hi,

    For some reason, I can’t update rules, no matter what I do.

    I have read pretty much all articles on this issue, and done basically all I found, but still no luck. AND, I have done all below on multiple sites.

    Here is what I have done, pretty much in order:

    1. Deleted rules.php, waited, and it appears as 0kb.
    2. Deleted whole wflogs folder, waited, and all files appear as expected, but rules.php is still 0kb.
    3. Disabled Wordfence plugin (keeping tables and data), deleted the apikey from db, enabled plugin, got new key, still rules.php 0kb.
    4. Disabled and deleted Wordfence plugin (deleted ALL tables and data, and made sure all files are gone, from plugin folder and wflogs too), reinstalled plugin, activated it with new key again, all files appear as they should, but rules.php is still just 0kb.
    5. Changed new installation to use SQL rather than wflogs, still can’t get rules to update. Weird say the least…

    On that last note, Diagnostics says SQL is fine, connection is fine to and from your servers, and I see no red flags.

    Now, I have done all the above on more than one sites (same server), so I really don’t know what’s up.

    I did install WF on other server yesterday too, and it worked fine. Rules updated right when I activated the plugin, as they should.

    On this problematic server, I have about 20 sites, and as you can guess, none of them update rules. So, server-side issue, but what and where and why? If you’d be blocking my server IP, I’d think Diagnostics would flag “Connecting to Wordfence servers (https)”, right?

    Some of the sites are old and have been moved around few times even, and have had WF on them for years. They all used to work. It was after some update (I guess it was after 7.8.0 or something), they just stopped updating rules.

    BR, – Yorkki

Viewing 13 replies - 1 through 13 (of 13 total)
  • Plugin Support wfpeter

    (@wfpeter)

    Hi @yorkki, thanks for getting in touch about this.

    It certainly sounds like you’ve been thorough, and your step-by-step breakdown of solutions you’ve already tried is really helpful. I think in this case it’s worth looking into a possible IP block (although I may expect a comms error in diagnostics if this was the case) or another element of your server configuration.

    So you don’t have to make those details public, drop us a diagnostic to wftest @ wordfence . com directly using the link at the top of the Wordfence > Tools > Diagnostics page. Then click on “Send Report by Email”. Please add your forum username where indicated and respond here after you have sent it.

    NOTE: It should look as follows – Screenshot of Tools > Diagnostic > Send by Email

    Thanks,
    Peter.

    Thread Starter yorkki

    (@yorkki)

    Hi Peter, sent report from one of the wflogs sites. If needed, I can send another from sql.

    The server is not old, it’s kinda new, so there may be PHP module or two missing or something else, but as I said, no red flags on Diagnostics. I actually hope it’s IP blocking ??

    BR, – Yorkki

    Thread Starter yorkki

    (@yorkki)

    Hi, haven’t heard anything back from you. Any update on this?

    BR, – Yorkki

    Plugin Support wfpeter

    (@wfpeter)

    Hi @yorkki, I’ve just confirmed that I’ve now seen your diagnostics in: https://www.ads-software.com/support/topic/rules-not-updating-continued/

    As you may suspect from the amount of troubleshooting you’ve already tried, I can’t see any permission or fail messages when it comes to wflogs, rules or communication in and out of your site. It’s especially strange that both database and file-based rules appear to be returning a fail message too. I’ve forwarded the diagnostics to some of my colleagues to see if there’s anything else we can check for.

    We only check connection to noc1 in diagnostics, so it might be worth checking the connection to noc4 too.

    Using the command line terminal on your server (or having your host do so if you’re unable) you can try cURL from the server. Try the command below several times and see if the output changes or if it ever times out:

    curl -v 'https://noc4.wordfence.com/?ticket=yorkki'

    Adding the query string will help us to find you in our logs. The expected response status code should be a 301 Moved Permanently response. Let me know if you are able to do that in the mean time.

    Thanks,
    Peter.

    Thread Starter yorkki

    (@yorkki)

    Hi Peter, thanks for the reply. I get HTTP/2 301 or HTTP/1.1 301 Moved Permanently from all servers, depending on the distro.

    Edit: just did the query four times in a row, will do few more from the problem server.

    BR, – Yorkki

    • This reply was modified 1 year, 5 months ago by yorkki.
    Thread Starter yorkki

    (@yorkki)

    Hi, just sent another report. Now this report is from different server, so different IP. It’s in a different country even! I did a new clean WP installation, and the only plugin is WF.

    Same problem there, rules.php is just 0kb no matter what I do.

    Did few curl commands from this server too.

    Any particular port(s) I should have open for rules? Both these servers are on a cloud, so maybe something the cloud / provider is blocking? My only server working with rule updates, is not on a cloud…

    I’m lost…

    BR, – Yorkki

    • This reply was modified 1 year, 5 months ago by yorkki.

    What OS are you running on your server @yorkki ?
    I had a similar issue with Alma/Rocky 9.2 due to SHA1 being disabled in the crypto-policy

    Thread Starter yorkki

    (@yorkki)

    @daemonic79 Hi, thanks for your reply. I’m running Rocky Linux 9.2 on all of the problem servers. I think you are on something here.

    I can try to google this, but if you have an easy fix procedure, would appreciate it, thanks ??

    BR, – Yorkki

    @yorkki sure…
    My thread on this was https://www.ads-software.com/support/topic/rules-not-updating-5/

    Solution is as follows;

    To show your current crypto policy, run the following;
    update-crypto-policies --show
    which returns;
    DEFAULT
    To then add SHA1 to the default policy, run the following;
    update-crypto-policies --set DEFAULT:SHA1
    which returns;
    Setting system policy to DEFAULT:SHA1
    Note: System-wide crypto policies are applied on application start-up.
    It is recommended to restart the system for the change of policies
    to fully take place.
    Reboot the server as directed, you can check it applied afterwards by running the original command again;
    update-crypto-policies --show
    which returns;
    DEFAULT:SHA1

    Feel free to do your own research on the above commands, before typing random commands from the internet into your server ??

    This appears to modify the policy files within /etc/crypto-policies/, reverting should be;
    update-crypto-policies --set DEFAULT

    Due to hitting the free rate limit of once every 24 hours, i had to wait for the next update, but it then worked for me. Hope this works for you ??

    • This reply was modified 1 year, 4 months ago by daemonic79.
    • This reply was modified 1 year, 4 months ago by daemonic79.
    • This reply was modified 1 year, 4 months ago by daemonic79. Reason: Tidied code formtting
    Thread Starter yorkki

    (@yorkki)

    Awesome @daemonic79 , I’ll try on one server, which I can reboot right now. Will let you know if it works. Thanks!

    BR, – Yorkki

    Thread Starter yorkki

    (@yorkki)

    @daemonic79 Damn, wasn’t the easy fix I was hoping for.

    I changed the DEFAULT and verified it was sha1, rebooted server. Then first tried just deleting rules.php, but it came back as 0kb. Then deleted whole wflogs, all came back ok but rules.php still 0kb. Then removed the plugin and deleted all data/tables, installed it again but the damn one file is still 0kb ??

    Damn this sucks lol. Thanks for the help though, appreciate it.

    Not sure what to do next…

    BR, – Yorkki

    @yorkki Sorry it didnt work for you…

    I started off debugging by adding the following after line 1924 ($this->response = ……) in wp-content/plugins/wordfence/vendor/wordfence/wf-waf/src/lib/waf.php
    file_put_contents('./output.txt', var_export($payload, true), FILE_APPEND);
    file_put_contents('./output.txt', var_export($this->response, true), FILE_APPEND);

    This would save the payload and response for the rules request to a local text file (will end up being in the wp-admin folder). I did this to work around the rate limit, as it meant i could use the saved response data then to continue debugging.

    With this information i worked through in a test script effectively doing the same thing as the $waf->verifySignedRequest function on line 1933, which then gave me the pointer to look into the openssl signing functions.

    Thread Starter yorkki

    (@yorkki)

    @daemonic79 Holy cow, it works now for some reason. So it must’ve been the sha1. It just took a little bit of time to update. Now my rules.php has been updated and I can see from the backend that the rules are there!

    Million thanks @daemonic79 for the help/tip. Now I guess need to figure out what other impacts this might have before doing other (prod) servers.

    You recon this is something WF should take a look at / fix at their end, or is it just Rocky/Alma “issue”?

    BR, – Yorkki

Viewing 13 replies - 1 through 13 (of 13 total)
  • The topic ‘Rules not updating. Done a lot to fix this, but no vail’ is closed to new replies.