Descripción
I created this plugin because I am tired of having my WordPress sites being hacked. It is used to completely lock the filesystem with the help of a bash script. The said script is external from the website and ran via cron so you need cron access to make this work. Otherwise, this plugin is useless to you.
This plugin has a known bug. See FAQs.
Instalación
- Upload the plugin files to the
/wp-content/plugins/filesystem-unlocker
directory, or install the plugin through the WordPress plugins screen directly. - Activate the plugin through the ‘Plugins’ screen in WordPress
- Use the left menu Filesystem Unlocker to configure the plugin (this has to be done before configuring and cron’ing scripts)
- You need to put the folowing script somewhere on your filesystem, elsewhere then in the webserver’s directory. It needs to be run with the webserver’s privileges or a higher privilege that can chmod files in the webserver’s directory.
- Edit the script to match your users, passwords, database prefixes, paths and the like.
- Minimaly, cron a job that runs this script every minute of everyday
- Ideally, cron this job to run only when you are EFFECTIVELY playing in your ftp. You are sleeping from 10pm to 6am ? Then don’t run the script. It won’t unlock your filesystem if it’s not ran. But then, you need an additionnal script to be ran the minute after you go to sleep to ensure the ftp is locked in the scenario where there was «time left in the parking meter» when your cron stop to execute.
The script in step 4 goes as follows:
#!/bin/bash #################################################################################################### # You NEED to edit the folowing strings # #################################################################################################### # # # -uuser : -uYourMySQLUser... ex.: -umarc # # -ppassword : -pYourUserSPassword... ex.: -pabracadabra # # MySQLDatabaseName : Your MySQL database name... ex.: datab1f32 # # wpTablePrefix__ : Your wordpress installation table prefixes... ex.: wp_prefix123__ # # /path/to/public_html : the path to your webserver's root document... ex.: /home/user/public_html # # # #################################################################################################### #################################################################################################### # Note on the choice of the path to be locked... # #################################################################################################### # # # The above mention of /path/to/public_html may or may not be accurate in the case your WordPress # # installation is not at the root of your webserver's tree. But take into account I suggest you # # lock your WHOLE filesystem because if you choose to lock only your WordPress's files, any hacker # # being "ethical" as they are, will write outside of your "locked zone" and exploit your webserver.# # Thus, I STRONGLY suggest you lock your WHOLE filesystem. # # # # Should you choose otherwise, you could adapt the above # # /path/to/public_html # # with # # /path/to/public_html/wordpress/install/path # # # #################################################################################################### timetolock=$(mysql -uuser -ppassword -se "select option_value from MySQLDatabaseName.wpTablePrefix__options where option_name='filesystem_unlocker_plugin_options'"); isitlockedalready=$(mysql -uuser -ppassword -se "select option_value from MySQLDatabaseName.wpTablePrefix__options where option_name='filesystem_unlocker_plugin_lock_state'"); if [ $timetolock -gt 0 ] && [ $isitlockedalready -eq 1 ] then find /path/to/public_html -type d -exec chmod 755 {} \; && find /path/to/public_html -type f -exec chmod 644 {} \; mysql -uuser -ppassword -se "update MySQLDatabaseName.wpTablePrefix__options set option_value = 0 where option_name='filesystem_unlocker_plugin_lock_state'"; fi if [ $timetolock -eq 0 ] && [ $isitlockedalready -eq 0 ] then find /path/to/public_html -type d -exec chmod 555 {} \; && find /path/to/public_html -type f -exec chmod 444 {} \; mysql -uuser -ppassword -se "update MySQLDatabaseName.wpTablePrefix__options set option_value = 1 where option_name='filesystem_unlocker_plugin_lock_state'"; fi if [ $timetolock -gt 0 ] && [ $isitlockedalready -eq 0 ] then mysql -uuser -ppassword -se "update MySQLDatabaseName.wpTablePrefix__options set option_value = option_value-1 where option_name='filesystem_unlocker_plugin_options'"; fi
The optional script in step 7 goes as follows:
#!/bin/bash #################################################################################################### # You NEED to edit the folowing strings # #################################################################################################### # # # -uuser : -uYourMySQLUser... ex.: -umarc # # -ppassword : -pYourUserSPassword... ex.: -pabracadabra # # MySQLDatabaseName : Your MySQL database name... ex.: datab1f32 # # wpTablePrefix__ : Your wordpress installation table prefixes... ex.: wp_prefix123__ # # /path/to/public_html : the path to your webserver's root document... ex.: /home/user/public_html # # # #################################################################################################### #################################################################################################### # Note on the choice of the path to be locked... # #################################################################################################### # # # The above mention of /path/to/public_html may or may not be accurate in the case your WordPress # # installation is not at the root of your webserver's tree. But take into account I suggest you # # lock your WHOLE filesystem because if you choose to lock only your WordPress's files, any hacker # # being "ethical" as they are, will write outside of your "locked zone" and exploit your webserver.# # Thus, I STRONGLY suggest you lock your WHOLE filesystem. # # # # Should you choose otherwise, you could adapt the above # # /path/to/public_html # # with # # /path/to/public_html/wordpress/install/path # # # #################################################################################################### find /path/to/public_html -type d -exec chmod 555 {} \; && find /path/to/public_html -type f -exec chmod 444 {} \; mysql -uuser -ppassword -se "update MySQLDatabaseName.wpTablePrefix__options set option_value = 1 where option_name='filesystem_unlocker_plugin_lock_state'";
FAQ
- I use a captcha, database backup or «the like» plugin that needs to write to the filesystem. Will it be locked as well ?
-
Yes it will. And these plugins will «break». Such scripts are rarely made for writing elsewhere then the webserver’s directories. As such, you could midofy the lock script to get it to unlock a specific directory after having locked them all. But what would be the point? A hacker could then use this to hack your site anyways.
- Can I still use my «the like» plugins with this locking script ?
-
Yes you could. Either you get them to write elsewhere (then the webserver’s directories) and make sure that they won’t update with their respective author’s updates or you do this another way since you have cron (thus shell) access.
My advice : don’t open a door. Hackers like opened doors. Change the way you do things and you’ll get results you never had…. Security and protection.
- Who can unlock the filesystem ?
-
By default, only people with edit_posts permissions and up can do this. This being because if you can edit a post, well, you could need to upload a picture to put into your post.
- Are there any known bugs ?
-
No known bugs exist at this time. Please notify any and all bugs to the support forums on the plugin’s page.
Reseñas
No hay valoraciones para este plugin.
Colaboradores y desarrolladores
«Filesystem Unlocker» es un software de código abierto. Las siguientes personas han colaborado con este plugin.
ColaboradoresTraduce «Filesystem Unlocker» a tu idioma.
¿Interesado en el desarrollo?
Revisa el código , echa un vistazo al repositorio SVN o suscríbete al registro de desarrollo por RSS.
Registro de cambios
1.1
- Transformed all admin pages request into admin_url( $path, $scheme ) instead of hardcoding paths.
1.0
- Initial release