Forum Replies Created

Viewing 15 replies - 31 through 45 (of 77 total)
  • wp_kc

    (@wp_kc)

    Re: mysqli_connect() fatal error.

    On fresh installs of PHP 7.x, the mysqli library will be disabled by default. This will always cause WordPress to fail.

    To fix it, you need to edit /etc/php/7.x/apache2/php.ini configuration file to remove the semicolon in front of this line…

    extension=php_mysqli.dll

    If you do not have control over that file, then I suggest you contact your web hosting provider and ask them to enable the php_mysqli extension.

    Thread Starter wp_kc

    (@wp_kc)

    Thank-you. I usually set-it-and-forget-it on the firewall policies, so I disabled it just long enough to set the policies on the 3 web sites running on the server, then re-enabled it. It doesn’t seem to hurt anything else.

    Perhaps this is a new item to add to the FAQ (or not-so-FAQ) in case others run into the same problem.

    • This reply was modified 9 years ago by wp_kc. Reason: bad grammar
    Thread Starter wp_kc

    (@wp_kc)

    Sure enough, I tracked it down to mod_security2. Here is what is in the logs when you try to save settings on the Firewall Policies page.

    
    ModSecurity: Warning. Pattern match "(?i)(?:\\\\W|^)(?:javascript:(?:[\\\\s\\\\S]+[=\\\\\\\\(\\\\[\\\\.<]|[\\\\s\\\\S]*?(?:\\\\bname\\\\b|\\\\[ux]\\\\d))|data:(?:(?:[a-z]\\\\w+\\\\/\\\\w[\\\\w+-]+\\\\w)?[;,]|[\\\\s\\\\S]*?;[\\\\s\\\\S]*?\\\\b(?:base64|charset=)|[\\\\s\\\\S]*?,[\\\\s\\\\S]*?<[\\\\s\\\\S]*?\\\\w[\\\\s\\\\S]*?>))|@\\\\W*?i\\\\W*?m\\\\W*?p\\\\W*? ..." at ARGS:nfw_options[csp_backend_data]. [file "/usr/share/modsecurity-crs/rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf"] [line "300"] [id "941170"] [rev "3"] [msg "NoScript XSS InjectionChecker: Attribute Injection"] [data "Matched Data:  data:; found within ARGS:nfw_options[csp_backend_data]: script-src 'self' 'unsafe-inline' 'unsafe-eval' *.videopress.com *.google.com *.wp.com; style-src 'self' 'unsafe-inline' *.googleapis.com *.google.com *.jquery.com; connect-src 'self'; media-src 'self' *.youtube.com *.w.org; child-src 'self' *.videopress.com *.google.com; object-src 'self'; form-action 'self'; img-src 'self' *.gravatar.com *.wp.com *.w.org *.cldup.com woocommerce.com data:;"] [severity "CRITICAL"] [ver "OWASP_CRS/3.0.0"] [mat [hostname "example.com"] [uri "/wp-admin/admin.php"] [unique_id "WWC2lwozdh0AAN02Ft0AAAAG"], referer: https://www.example.com/wp-admin/admin.php?page=nfsubpolicies
    
    ModSecurity: Access denied with code 403 (phase 2). Operator GE matched 5 at TX:anomaly_score. [file "/usr/share/modsecurity-crs/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "57"] [id "949110"] [msg "Inbound Anomaly Score Exceeded (Total Score: 5)"] [severity "CRITICAL"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-generic"] [hostname "www.example.com"] [uri "/wp-admin/admin.php"] [unique_id "WWC2lwozdh0AAN02Ft0AAAAG"], referer: https://www.example.com/wp-admin/admin.php?page=nfsubpolicies
    

    So apparently the recommended rules for mod_security2 interpret the posted data from the policies page as a XSS attack! Temporarily disabling mod_security2 allowed me to save the firewall policies.

    Thread Starter wp_kc

    (@wp_kc)

    Thanks Nagmay! That was the problem.

    I had this at the top of my editor-style.css file…

    @import url(../twentyseventeen/assets/css/editor-style.css);

    In my case, that was redundant since my code just adds to the editor style already set up by the twentyseventeen theme. I removed that line and the error message went away.

    Strange that it worked without an error before, but now it produces an error.

    Thread Starter wp_kc

    (@wp_kc)

    Thanks for your rely Marius. Since I do web app coding for a living, I have all my browsers set to clear their caches on exit. And I ran CCleaner as a sanity check. Same result.

    I don’t have much loaded in the way of plug-ins, but I will go through the routine of disabling them to see if anything changes.

    After that, I guess I’ll have to start doing some file diffs between the current and previous versions of WP and Twentyseventeen to see if I can track down why it is happening. Or maybe single-stepping through the code as it loads the editor will be a faster approach.

    To use SSL with Cloudflare, install these two helper plugins…

    https://wordpress.org/plugins/cloudflare/
    https://wordpress.org/plugins/cloudflare-flexible-ssl/

    The Cloudflare Flexible SSL plugin will fix redirect problems when using CloudFlare with WordPress.

    Also, in your CloudFlare account turn on the Automatic HTTPS Rewrites feature.

    And in today’s world, you may as well force everyone to go to the https version of your web site. So in the Settings > General menu of your WordPress site, set the WordPress and SIte addresses to the https URL of your web site. Then in CloudFlare add a new page rule at the top of your page rule list to do an https redirect.

    • This reply was modified 9 years, 1 month ago by wp_kc.

    I know you said you don’t want to fiddle with code, but in this post I list a few simple edits that will fix the plug-in, as well as a way to prevent it from being updated until you are absolutely sure any new version is working properly…

    wordpress.org/support/topic/a-couple-of-code-fixes-for-eran-miller

    Thread Starter wp_kc

    (@wp_kc)

    As for how plugins work on the WordPress site, here are the rules…

    wordpress.org/plugins/about/guidelines/

    Basically the plugin must be free, open source, no “phoning home” to spy on plugin users, no “trialware,” nothing illegal or immoral, etc.

    There is nothing that prevents a change of “ownership” of the plugin code. Also, since it is GPL, anyone is free to copy the code and start modifying it. You can even get a modified version of the plugin back into the WordPress plugin repository simply by renaming it and sending it in for review. An example of this was the “Semisecure Login” plugin which became the “Semisecure Login Reimagined” plugin…

    wordpress.org/plugins/semisecure-login-reimagined/

    Thread Starter wp_kc

    (@wp_kc)

    I would recommend after making the code changes I listed above that you change the version numbers for the plugin to a high number, like 100.100.100 so that the fixes don’t get overwritten by updates until you are absolutely sure that any new updates have addressed all these problems. Make the following changes to do this…

    File: ajax-event-calendar.php
    Line: 6
    Version: 100.100.100

    File: ajax-event-calendar.php
    Line: 41
    define('AEC_VERSION', '100.100.100');

    In this particular case, the error message is because of poor coding. See my post at: wordpress.org/support/topic/a-couple-of-code-fixes-for-eran-miller to see how to fix it.

    I would also recommend after making the code changes I listed that you change the version numbers for the plugin to a high number, like 100.100.100 so that the fixes don’t get overwritten by updates until you are absolutely sure that any new updates have addressed all these problems. Make the following changes to do this…

    File: ajax-event-calendar.php
    Line: 6
    Version: 100.100.100

    File: ajax-event-calendar.php
    Line: 41
    define('AEC_VERSION', '100.100.100');

    Thread Starter wp_kc

    (@wp_kc)

    File: css/custom.css
    Line: 32
    #aec-modal-container .aec-content{overflow:auto;padding:5px 10px 0;font-size:13px;max-height:580px}

    Thread Starter wp_kc

    (@wp_kc)

    Another one for you…

    File: admin-event.php
    Add Line at: 25
    $event = new stdClass();

    Thread Starter wp_kc

    (@wp_kc)

    Your welcome! Thanks for such a great WP firewall.

    Here is an update that is a bit more integrated with Fail2Ban…

    Instead of calling the filter conf file wordpress-ninjafw.conf, I changed it to ninjafirewall.conf. Here is the procedure now…

    Create a filter called ninjafirewall.conf witht eh following command and include the following text in it…
    sudo vi /etc/fail2ban/filter.d/ninjafirewall.conf

    [INCLUDES]
    after = common.conf
    
    [Definition]
    _daemon = ninjafirewall
    failregex = ^.* %(__daemon_combs_re)s Possible brute-force attack from <HOST> on
    ignoreregex =

    Add the following text to the end of the jail.local file…
    sudo vi /etc/fail2ban/jail.local

    [ninjafirewall]
    enabled = true
    port = all
    filter = ninjafirewall
    logpath = /var/log/auth.log
    maxretry = 2

    Restart the service…
    sudo service fail2ban restart

    To test the set up run this command…
    sudo fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/ninjafirewall.conf

    If there are any entries from NinjaFirewall in the auth.log file fail2ban-regex will show you the number of matches.

    If there are any IP addresses that are currently banned you can see them by running this command…
    sudo iptables -L

    I’ve been sticking to version 3.63 of the plugin with all the troubles I see in the 4.0.x versions. So I’m not sure what the exact names of the options are. But you need to turn on these things to get blacklisted IPs in the .htacess….

    • Look for an option that says something like “modify core files” or modify .htaccess, and turn that option on.
    • Turn on the Ban Users feature.
    • Enable blacklist settings for login and 404

    However I would not recommend doing any of this in a 4.0.x version of the plugin because you’ll just end up locking yourself and everyone out of your site. Probably the only reason the plugin is working for you now is because you have most of the security features turned off! 😀

    I would say you could go back as far as version 3.6.3 without loosing anything significant. In fact, even if 4.0 were working reliably, I don’t see that it offers anything of value over version 3.6.3.

    With all the problems 4.0.x is having it’s better to stick with a 3.6.x version until you no longer see daily complaints in this support forum of web sites being hosed by this plugin.

Viewing 15 replies - 31 through 45 (of 77 total)