On csf and apf firewalls add to the /etc/csf/csfpre.sh or /etc/apf/preroute.rules

#Attack on wordpress:

/sbin/iptables -I INPUT -p tcp –dport 80 -m string –string “Log+In&testcookie=1” –algo kmp -j DROP

Add this to your modsecurity2 rules:

<LocationMatch “/wp-login.php”>
SecAction initcol:ip=%{REMOTE_ADDR},pass,nolog,id:313371
SecAction “phase:5,deprecatevar:ip.counter=2/30,pass,nolog,id:313372”
SecRule IP:COUNTER “@gt 1” “phase:2,pause:300,deny,status:406,setenv:RATELIMITED,skip:1,nolog,id:313373”
SecAction “phase:2,pass,setvar:ip.counter=+1,nolog,id:313374”
</LocationMatch>

And if all else fails you can block all wp-login.php in the main apache config :

<Files wp-login.php>
order deny,allow
Deny from all
</Files>

or chmod 000 all wp-login.php files:

For clients wanting to secure their wordpress login edit your .htaccess in your ftp folder and add the below with the ipaddress that need to connect to your wordpress login:

<Files wp-login.php>
deny from all
allow from xxx.xxx.xxx.xxx
</Files>

#note this command is for Hsphere clusters change the path to where your web files are located.

find /hsphere/local/home -type f -name ‘wp-login.php’ -print0 | xargs -0 chmod 000

If you have any further questions please dont hestitate to contact us.

I.e. If I’m not blogging or otherwise updating content, why would I have to log into WordPress on any regular basis?

Let me share with you some reasons as to why you should be logging into your WordPress content management system — CMS — or blog as often during the week as you are able to practically do so.

1. First and foremost, if you use a backup plugin, is it working? How would you know?
2. Secondly, are there any updates available for your plugins, themes, or WordPress itself?
3. Are there any other notifications for which you need to take some action?

For backup, I strongly recommend BackWPUp. It connects with the Dashboard so that when you login, you can see a recent list of successful as well as any unsuccessful backups.

If you have backup covered, in my experience you still want to check on a regular basis for updates.

Now, if you have WordFence or a similar plugin installed, you will get email notifications of updates. Outside of such notifications, logging into WordPress will allow you to see if there are updates available.

If there are updates available, I do encourage you to read the change log first prior to applying the update; and, to backup (including the database) prior to any update.

Here’s why. We use Relevanssi as a replacement to the WordPress search function; it had a recent update. If I would have just upgraded, I would have missed the important instructions in the change log telling me to deactivate and then reactivate the plugin after the update to apply important WordPress database changes the plugin needed to make.

What are your thoughts for how often the steward / manager of a WordPress site should log in as an administrative user?

Comment and let us know.

If you asked me from September 2012 forward, the answer would change dramatically with WordPress Brute Force Attacks now exceeding 50% of all attacks being reported.

If you review your or your hosting provider reviews your web site’s access logs on a regular basis, you can tell if there are Brute Force attacks being attempted on your WordPress site by seeing multiple requests to access the file wp-login.php from the same IP address over and over again. Sometimes it might be a single request every x period of time; other times it might be scores of requests from the same IP address. By the way, are you or your provider regularly checking your web site access logs for abuse?

How can you protect yourself against WordPress Brute Force attacks?

1. Use strong passwords that are at least 12 wide which are unique to the user id and the application / device (you never re-use the same password for anything).
2. Change your password every 90 days; and never re-use the same password from the past. Alternate the width of the password each time, never going less than 12 wide.
3. Make sure your WordPress was installed in a secure manner. If your WordPress was installed by a hosting automation system rather than manually, the installation is insecure. Use the WordPress Hardening Codex to go through and harden your WordPress installation or ask your designer or hosting provider to do it for you.
4. Go through the excellent check lists and articles at the WordPress Security Checklist site.
5. If you can take advantage of limiting access to wp-config.php by IP address, then do so.
6. Consider using plugins like More Security Login, Login Security Solution, and Limit Login Attempts.
7. Consider using a hosting provider like our company that does review the logs for you, has intrusion systems in place to catch and stop most break in attempts, who does free daily backups and free restores who will work with you to keep your site secure.

Since nothing is hacker proof, should you find your WordPress site hacked, see our Site Security page for what we recommend for you to do (if you host with us, we do the clean up 100% in-house).

Do you have your own suggestions for how to protect against WordPress Brute Force Attacks? Let us know in the comment area below.

Melinda, who hosts the Small Business Chat on twitter every Wednesday night from 8 PM to 9 PM Eastern Time, focuses on helping people become entrepreneurs and for the small businesses they create to grow and succeed.

Whether you have been in business for many years, or are just starting up… did you know that if you properly plan and prepare for your ecommerce store you greatly increase your opportunity to succeed?

If you are nodding your head, do you know how many business managers just leave this decision to their “Web” person or “IT” person?

Over the past 17 years in business, we’ve seen, read, or heard about the above two issues so often, we’ve lost count.

As you take ownership and responsibility of the decision for picking a shopping cart / ecommerce system, I encourage you to ask the following questions:

1. Is the ecommerce system PCI DSS certified (if the answer is no, attaining payment card industry (PCI) compliance runs from impossible to expensive)?
2. When was the last security bug (problem, issue, report, etc.) filed for the system on Secunia’s Vulnerability Database?
3. How many times per year is there a security bug reported over the last 15 years (the more frequently published, the higher degree there are unreported security bugs)?
4. How long has the ecommerce company that created the ecommerce system been in business (unfortunately a lot of business five years old or less fail)?
5. Does the ecommerce shopping cart provider list certified technology partners that can assist you if you run into problems using the system?
6. Is the ecommerce system fully portable should you need to move to a different hosting provider?
7. Will the ecommerce system work on the smallest of shared hosting plans?
8. How well does the shopping cart system scale? How long can you stay in a shared hosting environment to keep your monthly hosting investment to a minimum?

While you do need to trust the people with whom you are working, if you are the steward / manager of the business, the buck stops with you; and, I would encourage you to double check against any bias which may cost you your business.

I would like to share with you why you should consider ShopSite from ShopSite.com as the only ecommerce shopping cart you will need.

ShopSite is VISA PA DSS Certified. Since 1998 (when we started using and offering ShopSite as a ShopSite certified technology partner), any customer of ours using ShopSite who has a PCI Compliance Scan has ShopSite passing with flying colors.

In all of the years ShopSite has been available, they’ve only had one (1) security issue back in 1996. Compared to any other cart, that is outright amazing!!!

ShopSite has been in business for almost two decades. Very few other companies compare.

ShopSite has certified designers and certified technology / hosting partners. Dynamic Net is a certified technology / hosting partner; and we maintain relationships with certified ShopSite designers.

ShopSite is extremely portable especially if you purchase the license vs. renting (it is still portable with renting; but you want to assure that with the hosing provider from whom you rent the software prior to renting it — for us, it is 100% portable).

ShopSite is extremely fast (it is compiled code vs. interpreted PHP, Perl CGI, etc.); and ShopSite scales extremely well in a shared hosting environment.

ShopSite ecommerce stores have handled massive floods of traffic when the business is featured on national media in a shared hosting environment.

ShopSite is relatively web server agnostic; you don’t have to worry about a down ecommerce store because your hosting provider updated the operating system, the web server software, or the database software.

Please contact us if you have questions as to why ShopSite would be the only ecommerce system / shopping cart software your small to medium business will ever need.

Please share your thoughts and questions about this article below in the comment area.

Before you check the check boxes or otherwise press the update button, are you taking the following measures to protect the investment of time you have in your site?

1. Backup prior to updates; be sure your backup is handling the mysql WordPress database as well as all of your WordPress content.
2. Read the release notes (details) / change log.

You may be surprised that some plugins what you to take very specific actions after the update in order for the update to be successful.

Case in point was a recent update to Relevanssi required users to “deactivate and reactivate Relevanssi in order to make the database changes happen.”

Since we tell our children to look before they cross the street, should we not also look before we update (backing up first as well)?

However, there are times you do need to be one or more versions behind.

What are some of the reasons behind making such a decision?

Recently a plugin was throwing errors for me after updating to the latest version. The author of the plugin is extremely responsive, and shared the particular bug will receive number one priority for getting fixed. Yet, due to a scheduled extended weekend, the ETA on the fix was going to be several days.

So the choices were live with the bug or downgrade.

Another reason for wanting to downgrade is if the plugin author or team decide to take the plugin in a new direction that is no longer compatible with how you are using WordPress.

wp-clean fix did this in their 2.4.x version when they branched off from doing a great job at keeping your database tables clean to doing that plus theme bundling. If you are like me, you enjoy the cleaning features, but not the bloat of themes and bundling other plugins into it.

So, how do you downgrade a WordPress plugin?

1. Backup your WordPress database plus content. You can use whatever means you are most comfortable using; I do recommend BackWPup.
2. Locate the version you want by going to the plugin page for the plugin you want to downgrade, change to the developer tab, look for the Older Versions section, and then download the .zip file to your machine of the version you want to use.
3. FTP or SFTP to your WordPress site, and change to the wp-content/plugins folder.
4. Rename the plugin folder of the plugin you want to downgrade to a different name (you are going to delete this folder later; this is just a safety measure).
5. Now through your WordPress administration area, go to Plugins, Install New, Upload. Your web page address should contain plugin-install.php?tab=upload
6. Click browse and change to the folder where you downloaded the older version (step #2 above), and select the file. Then click Install Now.
7. Follow the plugin installation prompts, and active the plugin.
8. Test, test, test.
9. If you are happy everything is working, do step #3, find the folder you renamed, and then delete the renamed folder.

You are now on the downgraded version of the plugin.

Caveats? If the upgrades from the version you are on contain security fixes, you don’t have those fixes.

Please contact us if you have any questions.

It is when you go to your site and see just a blank, empty, white page rather than your site.

While you may not have known the name of the problem, it is something you can experience with WordPress (as well as other content management systems).

Now, let’s go over trouble shooting the issue so you can have your web site back online.

The most common cause of the WordPress white screen of death is a plugin — brand new or upgraded.

Since you don’t have access to your WordPress administration area, it is not as easy as logging in, going to plugins, installed plugins, active plugins, and then deactivating the plugin.

What you can do instead is FTP to your site, and change to the wp-content directory, then to the plugins directory.

From there you can rename (best case) or delete (if your FTP client doesn’t allow you to rename, your best bet would be to backup the directory and files first) delete the plugin directory you just installed or just upgraded.

Now, in the worse case if you logged into WordPress, saw a half dozen or so updates, selected all of them, and ran through all of the updates… maybe you didn’t write down in advance the names of each plugin updated.

Check the file and date stamp of the folders in the plugin directory for clues.

In the absolute worse case, rename all of the plugins. I recommend including the original plugin folder name, and maybe adding in something like “-broken” after the folder name or “broken-” before the file name.

If there were several plugins updated, or you just don’t know which one, I do recommend renaming one plugin folder at a time (keep it renamed) as you try out your site.

If you’ve renamed several, and the site now works, then go back and rename one folder, test the site; if the site is still working, rename another folder and test the site. Continue this until the site is broken again to correctly identify which specific plugin caused the problem.

Now that you’ve identified which plugin caused the problem, I encourage you to visit the WordPress support area for plugins, and post about your problem so the plugin developer can work on a fix.

If you are one of our managed hosting customers, please do not hesitate to call us or open up a support ticket; we will gladly work through this with and for you.

Contact us if you have any questions.

Let me share steps you can take to make your WordPress site more secure against hackers.

Please note a number of the steps I will share are listed on Hardening WordPress, Official WordPress Codex article.

In May 2011, I shared with our readers about recommended .htaccess file settings for WordPress hosted on our servers.

Since then, I’ve been testing various changes to increase security as well as potentially enhance the performance of a site using the settings.

I’ve tested what I’m about to share extensively on our site at http://www.dynamicnet.net/ for the past several months.

If you have questions following what I’m sharing, please do ask in the comment area at the bottom of this article; but ultimately you may need to work things out with your hosting provider technical support. If your hosting provider cares about you as a person, as well as your business or hobby, they will help you in this area.

NOTE: If you are using a WordPress designer / developer, please have them review the .htaccess file we recommend to ensure it will not conflict with their work.

See Dynamic Net, Inc’s. recommended .htaccess starter file; feel free to copy it to notepad (do not use WordPad or Word unless you know how to save the file as a pure text file without any formatting or codes), and save that file as .htaccess to upload via FTP to the WordPress home directory (typically your domain directory or a blog directory) of your WordPress site.

Let’s go over our recommended .htaccess starter file:

A the top of every .htaccess file should be a measure to protect the .htaccess file itself from browser-based attacks.

order allow,deny
deny from all

Now, we want to tell the Web server there are certain files that no one should browse directly.

Order Deny,Allow
Deny from all

The above lines tell the Web server not to allow the direct browsing of wp-config.php, wp-cache-config.php, advanced-cache.php, php.ini, php5.ini, config.php, and db-config.ini.

Now, if you have a dedicated IP address, you can include an additional layer of protection:

#
#Order Deny,Allow
#Deny from all
#allow from [ip address 1 without brackets]
#allow from [ip address 2 without brackets and so on]
#

Simply fill in your IP address(es) — remove the second allow from if you only have one IP address — and uncomment all of the lines in order for the wp-login.php, install.php and readme.html file to only allowed to be accessed via the browser from the IP addresses so entered.

Next turn off directory indexes so that if someone browses a directory / folder for which you don’t have a default page set up, they will receive an access denied error message.

IndexIgnore *
Options All -Indexes

Next, if you are using a php error log, tell the Web server to deny direct access to the file

 Order allow,deny
 Deny from all
 Satisfy All

Please change the above file name to the file name you use on your web server. If you are not sure what to use, please contact your web hosting provider technical support department.

Next is a method of blocking common bandwidth abusers and hacking tools:

SetEnvIf user-agent "Indy Library" stayout=1
SetEnvIf user-agent "libwww-perl" stayout=1
SetEnvIf user-agent "Download Demon" stayout=1
SetEnvIf user-agent "GetRight" stayout=1
SetEnvIf user-agent "GetWeb!" stayout=1
SetEnvIf user-agent "Go!Zilla" stayout=1
SetEnvIf user-agent "Go-Ahead-Got-It" stayout=1
SetEnvIf user-agent "GrabNet" stayout=1
SetEnvIf user-agent "TurnitinBot" stayout=1
deny from env=stayout

Now we move onto turning on the Apache rewrite engine with the following:

RewriteEngine On
RewriteBase /

What follows is a series of protections against common types of exploits. What you see here can be applied to sites running Drupal, Joomla, and WordPress as well as other PHP-based sites.

RewriteCond %{QUERY_STRING} proc/self/environ [OR]
RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|\%3D) [OR]
RewriteCond %{QUERY_STRING} base64_(en|de)code[^(]*\([^)]*\) [OR]
RewriteCond %{QUERY_STRING} (|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
RewriteRule .* index.php [F]

RewriteCond %{REQUEST_METHOD} GET
RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=http:// [OR]
RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=(\.\.//?)+ [OR]
RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=/([a-z0-9_.]//?)+ [NC]
RewriteRule .* - [F]

RewriteCond %{QUERY_STRING} \=PHP[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12} [NC]
RewriteRule .* - [F]

RewriteCond %{QUERY_STRING} (;||'|"|\)|%0A|%0D|%22|%27|%3C|%3E|%00).*(/\*|union|select|insert|cast|set|declare|drop|update|md5|benchmark) [NC]
RewriteRule .* - [F]

Next come the WordPress specific settings for permalinks along with additional protection per the Hardening WordPress codex article.

RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

RewriteRule ^wp-admin/includes/ - [F,L]
RewriteRule !^wp-includes/ - [S=3]
RewriteRule ^wp-includes/[^/]+\.php$ - [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]
RewriteRule ^wp-includes/theme-compat/ - [F,L]

The rest deal with optimizing the performance of the site itself.

    Header append Vary Accept-Encoding

AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript
AddOutputFilterByType DEFLATE application/xml application/xhtml+xml application/rss+xml
AddOutputFilterByType DEFLATE application/javascript application/x-javascript

BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html

Header append Vary User-Agent env=!dont-vary

FileETag MTime Size

        # Enable expiration control
        ExpiresActive On

        # Default expiration: 1 hour after request
        ExpiresDefault "now plus 1 hour"

        # CSS and JS expiration: 2 week after request
        ExpiresByType text/css "now plus 2 weeks"
        ExpiresByType application/javascript "now plus 2 weeks"
        ExpiresByType application/x-javascript "now plus 2 weeks"

        # Image files expiration: 1 month after request
        ExpiresByType image/bmp "now plus 1 month"
        ExpiresByType image/gif "now plus 1 month"
        ExpiresByType image/jpeg "now plus 1 month"
        ExpiresByType image/jp2 "now plus 1 month"
        ExpiresByType image/pipeg "now plus 1 month"
        ExpiresByType image/png "now plus 1 month"
        ExpiresByType image/svg+xml "now plus 1 month"
        ExpiresByType image/tiff "now plus 1 month"
        ExpiresByType image/vnd.microsoft.icon "now plus 1 month"
        ExpiresByType image/x-icon "now plus 1 month"
        ExpiresByType image/ico "now plus 1 month"
        ExpiresByType image/icon "now plus 1 month"
        ExpiresByType text/ico "now plus 1 month"
        ExpiresByType application/ico "now plus 1 month"
        ExpiresByType image/vnd.wap.wbmp "now plus 1 month"
        ExpiresByType application/vnd.wap.wbxml "now plus 1 month"
        ExpiresByType application/smil "now plus 1 month"

        # Audio files expiration: 1 month after request
        ExpiresByType audio/basic "now plus 1 month"
        ExpiresByType audio/mid "now plus 1 month"
        ExpiresByType audio/midi "now plus 1 month"
        ExpiresByType audio/mpeg "now plus 1 month"
        ExpiresByType audio/x-aiff "now plus 1 month"
        ExpiresByType audio/x-mpegurl "now plus 1 month"
        ExpiresByType audio/x-pn-realaudio "now plus 1 month"
        ExpiresByType audio/x-wav "now plus 1 month"

        # Movie files expiration: 1 month after request
        ExpiresByType application/x-shockwave-flash "now plus 1 month"
        ExpiresByType x-world/x-vrml "now plus 1 month"
        ExpiresByType video/x-msvideo "now plus 1 month"
        ExpiresByType video/mpeg "now plus 1 month"
        ExpiresByType video/mp4 "now plus 1 month"
        ExpiresByType video/quicktime "now plus 1 month"
        ExpiresByType video/x-la-asf "now plus 1 month"
        ExpiresByType video/x-ms-asf "now plus 1 month"

If you are using a stock WordPress .htaccess file that just contains the mod_rewrite statements for permalinks (see settings, Permalinks in your WordPress administration area), then you should be safe to replace the .htaccess file with the .htaccess file what we recommend for security and performance

.

However, if you have a lot of settings already present above and beyond the normal permalinks, you would need to see what can be replaced or otherwise merged in.

Please contact us if you are one of our hosting customers, and we will do this for you freely. If you are not hosting with us, your own hosting provider technical support department should be happy to help you determine what can be replaced / merged or ignored for your particular environment.

Wouldn’t it be nice if you didn’t have to enter the FTP information (and not save the FTP information in your browser)?

Yes, there’s a way to have WordPress store that information for you so that you are never asked; and updates are now just one click rather than several clicks.

In order to take advantage of this tip, you will need to gather three pieces of information:

1. Your FTP server host name — this is typically your domain name; check with your hosting provider if you are not sure.
2. Your FTP user id.
3. Your FTP password

Now edit your wp-config.php file (this file will be in the same folder as your WordPress home directory; if you are not sure of the exact location, ask your hosting provider), and add the following lines modifying the areas for your FTP server host name, your FTP user id, and your FTP password.

// ** FTP SETTINGS FOR AUTO-UPDATE ** //
define(‘FTP_HOST’, ‘FTP server host name’);
define(‘FTP_USER’, ‘FTP user id’);
define(‘FTP_PASS’, ‘FTP password’);

Double check the four additional lines (don’t copy and past the above “as is” without first substituting your own information), and save then file.

See Editing wp-config.php on the WordPress Codex.

Considerations:

1. Make sure your .htaccess file secures wp-config.php
2. See our article on how to create secure passwords which are hard to crack.

If you are one of our managed hosting customers, we can set this up for you. Just contact us.

For those of you who don’t know about Microsoft FrontPage, it was both a tool for web hosting customers as well as an a server-based application for web hosting providers to allow individuals and organizations to design rather sophisticated sites visually.

The client would use their PC or MAC along with the Microsoft FrontPage software to visually design their site on their machine; and then publish their work to the Internet.

Where it differed from products like Dreamweaver is that you didn’t have to be a designer to use Microsoft FrontPage; and, Microsoft FrontPage had extensions (a server based application the hosting provider would run) which would allow common, dynamic, functionality such as form to email, discussion forums, and so on to work without forcing the client to learn how to program in perl or php.

Those of you who were around prior to the DOT COM bust of the year 2000 probably remember how difficult it was for small businesses on a tight budget to have their own web presence. Microsoft FrontPage did that for a very large number of small businesses.

Years later you have Microsoft Corporation abandoning Microsoft FrontPage leaving them in a lurch.

Small businesses often don’t have in-house designers, perl or PHP developers, and often come from the school of DIY — do it yourself.

WordPress is a full content management system which allows individuals and organizations to design their own site in a very visual way.

While it does help if a hosting provider is WordPress friendly, WordPress doesn’t require the hosting provider to install special extensions (for which Microsoft FrontPage did require in order to allow Microsoft FrontPage users to take advantage of all of the features).

I would like to share how we have been helping our managed hosting customers make the move to WordPress.

We set up a subdomain (basically a separate web site that in our case is parallel to their main site) like dev.theirdomain or wp.theirdomain; and then do a manual install of WordPress with various hardening measures to make sure our customer has a secure foundation for starting to use WordPress.

From there it is a matter of being there for the customer as they learn and DIY.

The WordPress Codex is a great place for WordPress beginners to experts to continue to learn.

When our customers are ready to make the switch from their development area (i.e. replace their entire site with their new WordPress-based content management system), we do the following on the server (the below is pseudo code as we are actually using Linux-based commands):

• Change to the client’s home directory (which in our case is one directory above their web area).
• Move their development area to a temp area
• Move their main domain to the development area
• Move the temp area to their main domain

For the Linux geeks, this looks like the following:

cd /full_path_to_client_home
mv dev.theirdomain dev.tmp
mv theirdomain dev.theirdomain
mv dev.tmp theirdomain

Then we follow the steps we’ve published on how to let WordPress know the web page address (URL) has changed.

Viola, the customer’s site is now running WordPress; and when the time comes the development area (what was their original site) can be deleted.

If you are one of our managed hosting customers, please note we provide this help with moving to WordPress freely.

Contact us if you have any questions.