DSO Server Setup Steps

The System Info: Website|Server|Opcode Cache|Accelerators|IP Info pane/table (top left) is where you should now only be seeing this: WP Filesystem API Method: direct.

The System Info: File|Folder Permissions (CGI or DSO)|Script Owner User ID (UID)|File Owner User ID pane/table (bottom right) will always display static file/folder permissions and the UID for files and folders.

Post your entire File|Folder Permissions (CGI or DSO)|Script Owner User ID (UID)|File Owner User ID pane/table. If you want to obscure your actual UID then change them consistently. What I need to see is whether all UID’s match or not and not the actual UID.

Example:

Actual:  ../.htaccess	404	0404	5555	5555
Obscured: ../.htaccess	404	0404	1	1

Yep, that DSO Setup forum topic needs to be updated. When that forum topic was originally create the new System Info File|Folder Permissions (CGI or DSO)|Script Owner User ID (UID)|File Owner User ID pane/table did not exist yet. 😉

Ok so all UID’s match so that looks good. So now describe in detail what exactly is not working in the other plugin and post the name of the plugin so I can download it and look at the code in that plugin. Are you seeing any 403 errors in your Security Log for that other plugin? If so, post that Security Log entry for that plugin.

The error message is only observed after Setup Wizard is run, and it is not displayed once the BPS root .htaccess file is renamed or deleted.

The Setup Wizard creates a new BPS root htaccess file. By renaming/deleting the BPS root htaccess file you have confirmed that a whitelist rule is needed in the root htaccess file for the AkeebaBackupWP plugin.

Try this first: Create a plugin skip/bypass rule for AkeebaBackupWP

1. Copy the code below to this BPS Root Custom Code text box: CUSTOM CODE PLUGIN/THEME SKIP/BYPASS RULES
2. Click the Save Root Custom Code button.
3. Go to the BPS Security Modes page, click the Create secure.htaccess File AutoMagic button, select the Activate Root Folder BulletProof Mode Radio button and click the Activate|Deactivate button.

# AkeebaBackupWP plugin skip/bypass
RewriteCond %{REQUEST_URI} ^/wp-content/plugins/akeebabackupwp(.*) [NC]
RewriteRule . - [S=13]

Note: The 403 error that you are seeing logged in the BPS Security Log is probably not the same 403 error that AkeebaBackupWP support is referring too.

Oops yeah good catch on the URI. Forgot to add your full URI in the skip/bypass rule. 😉 Ok so a plugin skip/bypass rule is not going to work for whatever is being blocked.

Try these whitelisting methods next in the same order as they are shown below:

Notes: Replace/change YourWebsite.com in the code below with your actual website domain name. You can get that by looking at the existing TIMTHUMB FORBID RFI and MISC FILE SKIP/BYPASS RULE root htaccess code in your BPS root htaccess file. I have added the additional akeebabackupwp\.php| file and code in the code below.

1. Copy the code below to this Custom Code text box: CUSTOM CODE TIMTHUMB FORBID RFI and MISC FILE SKIP/BYPASS RULE: Add additional Referers and/or misc file names. IMPORTANT! Change the HTTP_REFERER YourWebsite.com domain name to your actual domain/website’s name.
2. Save your new custom code by clicking the Save Root Custom Code button.
3. Click the Create secure.htaccess File AutoMagic button on the Security Modes page.
4. Activate BulletProof Mode for your Root folder on the Security Modes page.

# TIMTHUMB FORBID RFI and MISC FILE SKIP/BYPASS RULE
# Use BPS Custom Code to modify/edit/change this code and to save it permanently.
# Remote File Inclusion (RFI) security rules
# Note: Only whitelist your additional domains or files if needed - do not whitelist hacker domains or files
RewriteCond %{QUERY_STRING} ^.*(http|https|ftp)(%3A|:)(%2F|/)(%2F|/)(w){0,3}.?(blogger|picasa|blogspot|tsunami|petapolitik|photobucket|imgur|imageshack|wordpress\.com|img\.youtube|tinypic\.com|upload\.wikimedia|kkc|start-thegame).*$ [NC,OR]
RewriteCond %{THE_REQUEST} ^.*(http|https|ftp)(%3A|:)(%2F|/)(%2F|/)(w){0,3}.?(blogger|picasa|blogspot|tsunami|petapolitik|photobucket|imgur|imageshack|wordpress\.com|img\.youtube|tinypic\.com|upload\.wikimedia|kkc|start-thegame).*$ [NC]
RewriteRule .* index.php [F]
#
# Example: Whitelist additional misc files: (example\.php|another-file\.php|phpthumb\.php|thumb\.php|thumbs\.php)
RewriteCond %{REQUEST_URI} (akeebabackupwp\.php|timthumb\.php|phpthumb\.php|thumb\.php|thumbs\.php) [NC]
# Example: Whitelist additional website domains: RewriteCond %{HTTP_REFERER} ^.*(YourWebsite.com|AnotherWebsite.com).*
RewriteCond %{HTTP_REFERER} ^.*YourWebsite.com.*
RewriteRule . - [S=1]

If the whitelisting method above does not work then try this next;

1. Add the page=akeebabackupwp Query String skip/bypass rule below to this wp-admin Custom Code text box: CUSTOM CODE WPADMIN PLUGIN/FILE SKIP RULES
2. Click the Save wp-admin Custom Code button.
3. Go to the Security Modes page and Activate wp-admin Folder BulletProof Mode.

# AkeebaBackupWP wp-admin Query String skip/bypass rule
# RewriteCond %{QUERY_STRING} page=akeebabackupwp(.*) [NC]
# RewriteRule . - [S=2]

Ok I found a free Akeeba Backup version for WordPress. Downloaded it, installed and tested it and both file and db backups work fine, but I am also seeing a 403 error even though the backups completed successfully. So this appears to only be a nuisance 403 error and not an error indicating that something is actually not working. I will figure out exactly what is triggering this error and post the solution shortly. I may find that what the Akeeba Backup support folks said about a 403 error always occurring with their plugin is that in that case BPS logs all 403 errors on a website whether or not the 403 error has anthing to do with BPS. If this is the case then it is a nuisance error that just needs to not be logged.

[403 GET / HEAD Request: August 13, 2015 - 1:49 pm]
Event Code: WPADMIN-SBR
Solution: http://forum.ait-pro.com/forums/topic/security-log-event-codes/
REMOTE_ADDR: 127.0.0.1
Host Name: Z666P-HP
SERVER_PROTOCOL: HTTP/1.1
HTTP_CLIENT_IP:
HTTP_FORWARDED:
HTTP_X_FORWARDED_FOR:
HTTP_X_CLUSTER_CLIENT_IP:
REQUEST_METHOD: GET
HTTP_REFERER: http://demo5.local/wp-admin/admin.php?page=akeebabackupwp-core%2Fakeebabackupwp.php&view=main
REQUEST_URI: /wp-content/plugins/akeebabackupwp-core/app//backups/index.html?_=1439498971140
QUERY_STRING:
HTTP_USER_AGENT: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.155 Safari/537.36

So on my XAMPP Dev server if I comment out all of these code lines below with # signs in this file: /app/backups/.htaccess I no longer see that 403 error and the /backups folder is still protected. I did not bother with editing any of the other Akeeba Backup htaccess files.

#<IfModule !mod_authz_core.c>
Order deny,allow
Deny from all
#</IfModule>

#<IfModule mod_authz_core.c>
#  <RequireAll>
#    Require all denied
#  </RequireAll>
#</IfModule>

So there must obviously be some differences between the Akeeba free and pro versions. Maybe there are several 403 errors occurring and not just the one 403 error due to Akeeba htaccess file code itself. Or maybe the localhost server itself has had additional configuration done in the httpd.conf file or the vhosts conf file.

Both file backups and DB backups worked fine for me whether or not I changed the Akeeba htaccess file code. Are Akeeba backups also working normally for you even though you are seeing a nuisance 403 error(s)?

Most likely the API upgrade check is being blocked by 1 or more of these BPS root .htaccess file security rules below and commenting them out with a # sign in your root .htaccess file would tell you which rule or rules that is:

Most likely:

#RewriteCond %{HTTP_USER_AGENT} (havij|libwww-perl|wget|python|nikto|curl|scan|java|winhttp|clshttp|loader) [NC,OR]

#RewriteCond %{HTTP_USER_AGENT} (;|<|>|'|"|\)|\(|%0A|%0D|%22|%27|%28|%3C|%3E|%00).*(libwww-perl|wget|python|nikto|curl|scan|java|winhttp|HTTrack|clshttp|archiver|loader|email|harvest|extract|grab|miner) [NC,OR]

Less likely:

#RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=http:// [NC,OR]
#RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=(\.\.//?)+ [NC,OR]
#RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=/([a-z0-9_.]//?)+ [NC,OR]

Least likely:

#RewriteCond %{QUERY_STRING} ftp\: [NC,OR]
#RewriteCond %{QUERY_STRING} http\: [NC,OR]
#RewriteCond %{QUERY_STRING} https\: [NC,OR]

You would be checking the httpd.conf and vhosts conf files to see what they are doing or not doing with the mod_authz_core module.

In my XAMPP httpd.conf file I see that the module is being loaded, but this is XAMPP, which has been modified to run under Windows instead of Linux.
LoadModule authz_core_module modules/mod_authz_core.so. In my vhosts conf file I am using the new “Require all granted” vs the older “Order” directive, but my htaccess files are still using “Order” and they are working so that tells me there is a fallback for the older “Order” directive in htaccess files and they still work fine. I assume Apache is doing a standard deprecation method: https://en.wikipedia.org/wiki/Deprecation just like PHP or any other software does for backwards compatibility and moving forward. So basically that means that this htaccess code below should work for many versions of Apache until the “Order” directive is completely removed.

Order Deny,Allow
Deny from all

If everything is working correctly then that falls under nuisance. The 403 error for the API upgrade being blocked is not a nuisance error and is a critical error. One of the security filters above is most likely blocking the API upgrade check.