Support » Plugin: Wordfence Security - Firewall & Malware Scan » Security Issue – user.ini file

Viewing 15 replies - 1 through 15 (of 15 total)
  • Plugin Support wfasa

    (@wfasa)

    Hi David,
    The .user.ini file is created during the Firewall Optimization process. At the same time as the .user.ini is created code is added in .htaccess which prevents access to the .user.ini.

    I am not sure if the sites that pop up in Google have removed that code on purpose or by accident, or if there is some other issue. I’ll run this by the team though and see. Thanks for reporting!

    I have one site where that user.ini is accessable in a browser, so the .htaccess is not preventing anything there.

    Plugin Support wfasa

    (@wfasa)

    Hi tryggis,
    If the .user.ini is not hidden after using our automatic configuration procedure, make sure that this code exist in your .htaccess

    <Files ".user.ini">
    <IfModule mod_authz_core.c>
    	Require all denied
    </IfModule>
    <IfModule !mod_authz_core.c>
    	Order deny,allow
    	Deny from all
    </IfModule>
    </Files>

    If you are on NGINX, you will need to modify your config file. We have instructions for how to do that here: https://docs.wordfence.com/en/Web_Application_Firewall_FAQ

    If you are unsure about any of the above, please reach out to your web host and ask them to assist you in hiding the .user.ini file.

    mhk1058

    (@mhk1058)

    I installed wordfence and all was fine for a week or so, now wordfence is warning me that the user.ini, that wordfence created, is publicly accessable.

    Plugin Support wfasa

    (@wfasa)

    Hi mhk1058,
    Yes, we have added a scan check that tells you if your .user.ini is visible so that people quickly find out if that is the case, for whatever reason. It can happen if the Wordfence Firewall Optimization is reverted while the .user.ini is write protected. It can also happen if you move your site between hosts, or if your host changes something significant in your server environment. It could also happen if the .htaccess in the root of the WordPress installation is reverted to a default WordPress .htaccess, or if another plugin overwrites the changes Wordfence made to your .htaccess.

    Check if the .user.ini has anything in it. If it doesn’t, you can delete it. If it does, you need to add the code above to your .htaccess. If that doesn’t help, please reach out to your web host for assistance. How files are hidden differs between hosting environments.

    Hope that helps!

    • This reply was modified 10 months ago by  wfasa.

    My WordFence is telling me the same but I noticed that its in Learning Mode till March 19th then it’ll automatically switch to Protect Mode. So I guess my user.ini file will be accessible till then? Or should i add this code to the htaccess file for the time being than remove it when WordFence Firewall goes into Protect Mode?
    <Files “.user.ini”>
    <IfModule mod_authz_core.c>
    Require all denied
    </IfModule>
    <IfModule !mod_authz_core.c>
    Order deny,allow
    Deny from all
    </IfModule>
    </Files>

    Plugin Support wfasa

    (@wfasa)

    Hi scottkr24,
    .user.ini should never be accessible to the world so you can add the code right away if your server does not hide .user.ini files by default. If you are unsure, ask your web host for assistance.

    Solved.

    I am using nginx and do not see the documentation for how to disable public access to the “.user.ini” file that Wordfence itself created in the root directory.

    Please advise on how to mod nginx to disable public access to .user.ini.

    Plugin Support wfasa

    (@wfasa)

    Hi @edcroteau,
    Please see this document on Hiding .user.ini if your server runs NGINX.

    Hope that helps!

    Thanks!

    ScalarEnt

    (@scalarent)

    I have the same issue – I added the code to the htaccess file and it fixes.

    Why wasn’t it added during the Firewall Optimization process ?

    ScalarEnt

    (@scalarent)

    Sorry I forgot to mention it is on Apache server.

    Plugin Support wfasa

    (@wfasa)

    Hi @scalarent,
    Perhaps your .htaccess wasn’t writable by the web server user that WordPress is running as?

    ScalarEnt

    (@scalarent)

    Thanks, I’ll check

Viewing 15 replies - 1 through 15 (of 15 total)
  • You must be logged in to reply to this topic.