use htaccess to deny access to multiple files

If your php script includes files that are very sensitive and should not be accessed by anyone, you can deny access with this htaccess rule set. Just place this in your htaccess file at the top most directory that you want to protect:

Warning: Make a backup of your .htaccess file first. If things go wrong, you won’t leave your site disabled due to a typo.

This code should go near the top of your htaccess file. I like to use block statements first to save processing time later.

This particular rule set denies access to the very important file, wp-config.php. Although WordPress and PHP has built in rules to avoid exposing this code, this extra precaution protects it.

We are also denying access to xmlrpc.php. Attacks are on the rise against this file, so if you are not using this feature, deny access to it and protect your site/server.

<FilesMatch "^(wp-config|xmlrpc)\.php$">
order allow,deny
deny from all
</FilesMatch>

Redirect old directory to new directory

A simple htaccess modification can solve a web site change for you. If you want to create a new directory for whatever reason and redirect the old directory to the new one, this will get it done:

## /testa/ to /testb/
RewriteEngine on
RewriteRule ^testa/(.*)$ testb/$1 [R,L]

This will rewrite the directory and all the files in the directory as well.

Live example usage:

http://blog.m3server.com/testa/sample.text
http://blog.m3server.com/testa

WordPress Brute Force Attack

This how to article is in reference to WordPress, however, it can easily be adjusted for any php based authentication system.

Background:
If a bots are hitting your site to gain access to a user account, generally it is the “admin/administrator” account, your server could be at risk of crashing, slowing down, or exposed to unauthorized entry.

What is a bot? It’s a computer program running on infected internet servers and home computer users alike. Little service programs (robots) designed to work hard at generating user names and passwords directed at a login page. Once access is granted, the bot reports back to the owner with the site address and login credentials.

Even some WordPress users of your site’s blog can upload files to the server. If a hacker gets one of these passwords, they can upload their malware scripts. Bots can do this to. This is a very serious threat to your site’s performance and security alike.

Most of these bots are simple POST actions without GET requests. Normal users either click on the “login” link on your site, or go to the bookmark page, and even may just type your site in the browser. At that time, they enter the user name and password, then click “submit” or “log in”. That button action is the actual POST. But the GET came before the POST.

With that in mind, a very simple rule will protect your site from the most common brute force attacks hitting your WordPress login offering you a very solid amount of protection.

Add the follow section of code above the # BEGIN WordPress line in your WordPress document root directory.

# Make a backup of your .htaccess FIRST. Then test your site. If something isn’t working properly, you can restore your backup file.

RewriteEngine on
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{HTTP_REFERER} !^http://(www\.)?m3server\.com [NC]
RewriteCond %{REQUEST_URI} ^(.*)?wp-login\.php(.*)$ [OR]
RewriteCond %{REQUEST_URI} ^(.*)?wp-admin$
#RewriteCond %{REMOTE_ADDR} !^123\.123\.123\.124$
RewriteRule ^(.*)$ - [F]

In the example above, replace www.m3server.com with your site’s domain name. If your site redirects to the www version, use that. Some examples could be:
www.your_domain.com
your_domain.com
blog.your_domain.com

Note the line that is disabled (commented out with #). You can enter your IP in that location if it is static or otherwise doesn’t change often for extra protection. WordPress is more so used now for designing and building web sites and therefore are not actual blog systems with users authenticating.

The more sites you have on your server, the greater load your server is already under, the more important it is for you to use this simple protection.

Troubleshoot WordPress Errors

Troubleshooting WordPress is easier than most php based applications since it has debug code built in. You just need to enable it. We will show you how, but please take the time and learn what your doing rather than following steps. We highly recommend developing on another VPS server to avoid causing problems with your live site. Always best to test first!

Do note, that while we go the extra mile to assist clients in anyway we can, we are not tech support for WordPress. WordPress.org has great forums filled with knowledgeable staff. So before you make WordPress your platform of choice to build your web site or enterprise, do study it’s operation and know how to contact the forums and 3rd party plugin publishers for support. If the 3rd party plugin publisher is no loner answering support, script is outdated for years, why use it and risk your site’s operation?

http://wordpress.org/support/

First, read the manual here:
Debug WordPress

Opening the file wp-config.php with your favorite plain text editor reveals the manual:

* This file has the following configurations: MySQL settings, Table Prefix,
* Secret Keys, WordPress Language, and ABSPATH. You can find more information by
* visiting {@link http://codex.wordpress.org/Editing_wp-config.php Editing
* wp-config.php} Codex page. You can get the MySQL settings from your web host.

Second, make a backup of your current file please. Save your self time and money if something goes wrong.

WARNING. Improper use or simple typo of a file edit can render your site broken / inoperable. Don’t scream at your neighbor if you forget to make a backup of your file. Then, if things go wrong, you can just upload your original file to the server via ftp. Backups are important, you have been politely warned.

Using information from the manual above, we like these settings for our blog:

/**
 * This will log all errors notices and warnings to a file called debug.log in
 * wp-content (if Apache does not have write permission, you may need to create
 * the file first and set the appropriate permissions (i.e. use 666 or 777) )
 */
define( 'WP_DEBUG', true );
define( 'SCRIPT_DEBUG', true );
define( 'CONCATENATE_SCRIPTS', false );
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
/* That's all, stop editing! Happy blogging. */

You can experiment by enabling WP_DEBUG_DISPLAY by setting the value to true. This will allow errors to be displayed in your browser. display_errors will need set to 1 in the example above.

You will find the debug.log in your base WordPress path under the directory:
/wp-content/debug.log

Is is recommended that you block access to this file with this .htaccess modification:

<Files debug.log>
Order allow,deny
Deny from all
</Files>

Additionally, you can login to your M3Server control panel to also view traffic logs and error logs. Access is also provided by ssh/ftp download of the files in your user’s home directory:
/home/user/logs/site.com.error.log
/home/user/logs/site.com.log

These are enabled by default on all M3 6 series servers using M3Admin version 6 control panel.

WordPress E-Mail SMTP

By default WordPress uses php MAIL function for easy access to sending emails from your site to your users. This is needed for various functions including notifying users of password reset requests, sign ups, and other notifications.

Due to complex task of securing WP from spammers through weakening of the WP security system due to faulty and malware infected 3rd party plugins, you should consider securing your mail server. Spammers can gain access to uploading php scripts to your site through exploits. Once accomplished, they can blast away spamming users every day using your resources and potentially getting your server listed on blacklist sites due to spam.

Speed up your server, secure your site, and improve delivery rates of emails by using SMTP options instead of php MAIL function.

You can program this yourself (not support by m3 support), or you can use a simple plugin such as:

http://wordpress.org/plugins/wp-mail-smtp/

Make sure you do not use your FTP user name and password for sending email. Instead, setup an email account via your server’s control panel. Please do make sure your email account is very strong. You can even configure the wp-mail-smtp plugin to use 3rd party accounts such as gmail or any other service that provides smtp auth / IMAP access. Please read their documentation and reference the developer for support.

http://wordpress.org/support/plugin/wp-mail-smtp

Example settings for M3 to use SMTP:

- port 587
- tls / ssl is preferred
- Smtp auth is required and is accessed via your email account’s user name and password.

Note: (user name) is not your email address. Use the user name for fields marked “user name”. Use the email address for fields marked “email address”.

WordPress Auto Updates without SuPHP

SuPHP is nice, makes WordPress and other php apps very easy to use, with regards to permissions and ownership of files and directories. Perfect for the beginner web site operator or those that have 100s of sites.

However, it is less secure and comes with a significant performance hit. Php code can’t be cached/optimized at the server level via php caching. Security issues arrise since the scripts are executed as your ftp user, vulnerabilities leave you at complete risk. It’s basically like running your entire site as chmod 777. True, it does protect you from other users on the server. But most clients have one ftp user name and 30+ sites. If one WordPress site is out of date and exploited, it puts all of our sites at risk.

Follow this guide to keep you most secure regardless of what method you run your server:
wordpress-security
security check list

By default, like C-Panel, our servers are setup with suPHP enabled. You can most certainly request this to be disabled.

Running WordPress without suPHP:

Make a backup of your file FIRST, then, enter this code at the bottom of your wp-config.php for each site:

NOTICE:  Replace the variables below with your actual information:

## your_ftp_user, yourpass??, and server.host.net ##

The example below doesn’t automatically set this information so please make the adjustments beofre addig it to your file.

/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');
define('FTP_USER','your_ftp_user');
define('FTP_PASS','yourpass??');
define('FTP_HOST','server.host.net');
define( 'FTP_SSL', true );

VERY IMPORTANT Use the real server name here, not your domain. Else this may not work if your using advanced services like CDN or other caching.

We encourage you to read and study all options to suit you best:
WordPress Config

Once the file is uploaded to your server, you can request from support that we disable suPHP from your site(s). In the very near future, this option will be available from the M3 Admin Server Control Panel.