Wordfence - publicly exposed user.ini

Keywords: WordPress - AWS - Technical issue - Application configuration

bnsupport ID: 3cda499c-8d9a-a43d-3a86-fd4835fa5bbc

bndiagnostic output:

? Apache: Found possible issues
? Resources: Found possible issues
https://docs.bitnami.com/general/apps/wordpress/troubleshooting/debug-errors-apache/
https://docs.bitnami.com/bch/apps/moodle/troubleshooting/deny-connections-bots-apache/
https://docs.bitnami.com/installer/faq/linux-faq/administration/increase-memory-linux/

Description:
I found a similar thread on this but it seems like they were using a different configuration with nginx: Wordfence critical issue: Publicly accessible config, backup, or log file found: .user.ini

We are attempting to edit our htaccess file to resolve the exposed user.ini issue, but we receive a permission denied message when trying this through SFTP. We tried changing the permissions of the htaccess file to 666 but the change was also denied. Any idea on how to resolve it? Thanks

Hi @js102

Thanks for using Bitnami WordPress!

I found a similar thread on this but it seems like they were using a different configuration with nginx:

Could you please check this thread instead? They are using Apache as well, so this should match your use case:

but we receive a permission denied message when trying this through SFTP. We tried changing the permissions of the htaccess file to 666 but the change was also denied. Any idea on how to resolve it? Thanks

We have a guide that covers problems regarding Permissions and SFTP, I think you might find it handy:
https://docs.bitnami.com/general/how-to/troubleshoot-permission-issues/#you-cant-upload-a-file-via-sftp

Best regards,
Jose Antonio Carmona


Was my answer helpful? Click on :heart:

Thanks. It worked and is resolved now.

By the way, I do receive this warning now on the BNSupport diagnostic:
[Sat Sep 11 15:23:33.636615 2021] [authz_core:error] [pid 3997:tid
139937231902464] [client ip_address:3270] AH01630: client denied by server
configuration: /opt/bitnami/wordpress/.user.ini

But I take it that is expected, right? Our intention was to indeed block the user.ini

Hello @js102,

Yes, that error is the expected one and confirms the change to make user.ini private is working. Apache treats it as an error but in this case, we can think of it as a warning/info given this was the wanted behavior.

Regards,
Francisco de Paz