BPS Pro F-Lock
Why Lock WordPress Mission Critical files index.php, .htaccess files, wp-config.php and wp-blog-header.php with Read Only 400 and 404 Permissions?
If you have a WordPress website on shared hosting (like most website owners have) and your web host is using suPHP or suExec and running PHP as a CGI (Common Gateway Interface) and not using DSO – running PHP as an Apache Module (mod_php) then you should be locking your WordPress Mission Critical files. Why? In Mass Code Injection attacks aimed at Web Hosts there is a vulnerability with having 644 Group Permissions on files. What this means is that it could be possible to cross code inject your WordPress Mission Critical file in a Shared Hosting Environment if Group Permissions Read is allowed. Just allowing Group Permissions Read and not having Group Permissions Write on files can make them vulnerable to Mass Code Injection attacks on Web Hosts in a Shared Hosting Environment.
BPS Pro F-Lock has an AutoLock file locking feature and allows you to Lock and Unlock your WordPress Mission Critical files index.php, .htaccess files, wp-config.php and wp-blog-header.php with 400 and 404 Read Only file permissions on the fly. If you don’t know what “on the fly” means, it means that with one convenient click from within your WordPress Dashboard you can unlock and lock your WordPress Mission Critical Files. No need to use FTP or access your Web Host’s Control Panel to change file permissions.
Locking files with Read Only 400 and 404 permissions the old fashioned way is a pain in the #$@. F-Lock makes file locking and unlocking on the fly simple, fast and painless. F-Lock is designed to warn you immediately when a WordPress Mission Critical file is unlocked and allow you to lock it right away with one click. This is especially handy when you need to be able to temporarily write to a WordPress Mission Critical file and lock it down again with one click.
404 File Permissions
.htaccess files should have 404 File Permissions
Owner Permissions – Read On – Write X – Execute X
Group Permissions – Read X – Write X – Execute X
Public Permissions – Read On – Write X – Execute X
400 File Permissions
index.php, wp-config.php and wp-blog-header.php should have 400 File Permissions
Owner Permissions – Read On – Write X – Execute X
Group Permissions – Read X – Write X – Execute X
Public Permissions – Read X – Write X – Execute X
Click to Enlarge Image
Below is the Read Me Hover Tooltip help in BPS Pro 5.1 for the F-Lock Component of BPS Pro.
What is AutoLock?
AutoLock is automated file locking. When first installing BPS Pro you need only click on the Save Options button to lock all of your files together at one time. Whatever Lock or Unlock file options are selected for each of your files is automatically applied to your files just by accessing the F-Lock page. Manual control of individual file permissions is done by choosing the file you want to Lock or Unlock, selecting Lock or Unlock for that file and then clicking the Save Options button. AutoLock is used for 2 reasons – to make locking files quick and easy and to display real time file permissions status.
IMPORTANT – Web Host Server API Info – CGI or DSO Info
BPS Pro checks your Web Hosts Server API and your Web Hosts Server API is displayed in green font right below this Read Me Hover Tooltip. Most people will have php run as CGI on their Web Hosts and you should see that your Server API is CGI. If your Web Host is using DSO / Apache mod_php instead CGI then file locking and unlocking does not pertain to you. Set your file permissions to DSO – 644 File Permissions and then turn off the S-Monitor F-Lock: Check File Lock / Unlock Status checking option. DSO file permissions are handled in a completely different way then CGI file permissions. The majority of Web Hosts will be using CGI so the rest of this help file pertains to anyone who sees that their Server API is CGI.
Why Lock Mission Critical Files?
Hackers specifically target these files in Mass Code Injection attacks on web hosts. This is done by exploiting the Group Permissions on files located in Root folders for hosts that use CGI. By locking these files with Read Only 400 and 404 permissions the Group Permissions are removed and these files are protected against Mass Code Injection attacks. For hosts using DSO – 644 file permissions are secure because php file security is handled using a different type of file security.
Will Locking Files With Read Only Permissions Break WordPress?
No. 400 and 404 files permissions have been tested on several different web hosts using suPHP and suEXEC with CGI and WordPress performs normally. DSO file permissions should be the standard 644 file permissions. BPS is checking and displaying your Server API. If you see CGI displayed as your Server API then you can use the regular File Lock and Unlock options. The regular file Lock options should work fine on most if not all web hosts. The majority of web hosts these days are using suPHP or suEXEC and a CGI php handler. If you see that your Server API is DSO then ONLY use the DSO 644 permissions options. There is no need to have an unlock for DSO. 644 permissions are secure for DSO because of the different way that the DSO mod_php Apache module handles php files and security and WordPress and plugins can write to files with 644 permissions. If you see something other than CGI or DSO displayed as your Server API then check with your web host web host to find out what the most restrictive file permissions that you can use are or you can just experiment. If you are experimenting be prepared to FTP to your website and manually change the file permission back to what it was if you see 500 errors. Incorrect file permissions could cause you website to display 500 errors and be down. It is possible but not likely that the Server API could display another interface name such as continuity, embed, isapi, litespeed or other interface names instead of cli or cgi.
Will Locking Files With Read Only Permissions Break Plugins?
Locking the files will not interfere with a plugins normal operation but if a plugin needs to write to any of these locked files then the file will temporarily need to be unlocked so that a plugin can write to it. If you are using the B-Core File Editor to edit your root .htaccess file you will need to unlock the root .htaccess file so that BPS can write to it. A Lock / Unlock button has been added to the BPS .htaccess File Editor page. F-Lock allows you to quickly Lock and Unlock files on the fly without having to use FTP or your Control Panel.
What is GWIOD – Lock / Unlock?
GWIOD is short for Giving WordPress Its Own Directory. People who are using this type of WordPress site set up will have an additional .htaccess file and index.php file in their Site Root folder. This will allow them to lock both their Site Root .htaccess file and index.php file as well as the .htaccess file and index.php files that exist in their actual WordPress installation folder. If you are not using this type of WordPress set up then these files will either show up as duplicates of your already locked or unlocked files or could generate error messages. If you are not using this type of WordPress set up and you are seeing error messages then turn this check off by selecting the Turn Off Checking & Alerts dropdown list option. If the file does not really exist then you will see …file does not exist under Permissions & Status for that file.
What is DR – Lock / Unlock?
DR is short for Document Root. This allows you to lock and unlock an .htaccess file or index.php file in your Document Root folder. If your WordPress installation is already in your Document Root folder then the DR Permissions & Status information will just be duplicated permissions and status information about your already locked or unlocked files. If you have multiple WordPress sites installed and some are subfolder installations and one is a WordPress Document Root installation then you will be able to lock and unlock the Document Root files from any of your WordPress subfolder websites. If you have a single WordPress installation installed in your Document Root folder then these files will show up as duplicates of your already locked or unlocked files. If you are seeing error messages about these files not being locked because they do not really exist then turn this check off by selecting the Turn Off Checking & Alerts dropdown list option. If the file does not really exist then you will see …file does not exist under Permissions & Status for that file. Another possible scenario is that if you have an HTML site in your Document Root folder then you could lock the .htaccess file for that HTML site.
The Wrong Permissions and Status Table Is Displayed
If BPS detects CGI then you will see the CGI Permissions & Status Table displayed and you should be able to set permissions to 400 and 404. If BPS detects DSO then you will see the DSO Permissions & Status Table and should only be able to set permissions to 644. BPS looks at the Server API name that your host has configured to display. If your host is using CGI but they are using another interface name then BPS will not be able to detect that your Server is using CGI and will display the DSO Permissions and Status Table. Please let us know about this by sending us an email. We can then add additional coding to BPS to create an exception for your particular host.
Help links are provided on the Help & FAQ page.
BPS Pro 5.2 will have the added capability of allowing you to choose and add any additional files that you want to lock down and monitor.
Tags: Lock WordPress Files, WordPress File Lock, WordPress htaccess 404 Permissions, WordPress index.php 400 Permissions, WordPress Read Only 400 Permissions, WordPress Read Only File Permissions, WordPress Read Only Permissions, WordPress wp-blog-header.php 400 Permissions, WordPress wp-config.php 400 Permissions
Categories: BulletProof Security Pro