How to SECURE your WordPress website!

[HostLeet]

NOTE: Please read this post carefully and follow the directions, exactly! - This post is meant to help users SECURE WordPress on a cPanel and Linux hosting environment, using .HTACCESS Rules and other simple methods. If you're using another control panel and Operating System, this guide might not work for you!

First, I would like to say that all information provided in this post is freely available on the web to anyone. That being said, this post is a modified version of another post by HostWinds. I've simply improved it a bit!

Due to the recent Global WordPress Brute-Force Attack we've all seen in the past few days, I figured it couldn't hurt to post such valuable information in as many places as possible.

=================

A large number of our clients do not fully understand, or know exactly how to SECURE their WordPress website(s). Here's a quick tutorial with step-by-step directions on how to do exactly just that... If you build websites using WordPress regularly, than this guide is definitely for you. You should implement these security methods on every WP site you make! :thumbup:

STEP #1

Create a COMPLETE Backup of your website:

Make sure to keep regular backups, and keep them on a CD-ROM, DVD, or Portable Drive (don't forget to make sure your backups work!). You can do this with the cPanel Backup Manager Feature in your control panel or via FTP. A FULL cPanel backup is highly recommended. A full cPanel backup file contains the entire contents of your hosting account, and can be used to easily and seamlessly move to another host that uses cPanel. You can even send your backup file to a remote server, such as another hosting account or a Remote Backup Service Provider.

NOTE: Never keep or store your backup files on the same hosting account/server that created it. If your hosting account or server goes down, so are your backups! - Always keep off-site backups.


STEP #2

UPDATE your WordPress installation to the latest Stable Version:

This is critical because WordPress updates usually close security vulnerabilities/exploits and implement other important fixes!.. Many users ignore upgrades fearing it will break their website or theme. And although sometimes this is true, the cost of NOT upgrading is far worse than upgrading and possibly having to fix your theme or plugin. You could be faced with account termination, or worse, be liable for damages and blacklisting fees. Do yourself a HUGE favor and upgrade your WP installation and all themes and plugins, as well.


STEP #3

Change your "Admin" user login account and password:

The default WP username is "admin" and hackers know this. So - you should change it to something more personal (e.g. - "LeetUser1337" or "John1234", ect..). The best thing to do is to ADD a new user with admin privileges and then simply delete the original "admin" user account.

ALWAYS use really Strong Passwords (it should include UPPER and lowercase letters, numbers and symbols) and make them at least 16 character long. Most attackers try to brute-force your passwords so having a strong password is imperative. Also, you should never use the same password twice...


STEP #4

Change your WordPress Keys:

Many people overlook this step but it is an important one as these keys work as 'salts' for cookies and ensure better encryption of data.

Use the WordPress Key Generator to generate mentioned keys. Then edit your "wp-config.php" file and find the lines:

define(‘AUTH_KEY’, ‘put your unique key here’);
define(‘SECURE_AUTH_KEY’, ‘put your unique key here’);
define(‘LOGGED_IN_KEY’, ‘put your unique key here’);
define(‘NONCE_KEY’, ‘put your unique key here’)
................
................
and so on.

And replace them with the new ones you got from the Key Generator.


STEP #5

Install Some Security Plugins:

There are many to choose from, but not all of them are good. I highly recommend (and use) Better WP Security Plugin. This plugin is the #1 security plugin for WordPress. It takes the best WordPress security features and techniques and combines them in a single plugin thereby ensuring that as many security holes as possible are patched.

Another highly recommended plugin is Wordfence Security Plugin. Wordfence Security is a free enterprise class security plugin that includes a firewall, anti-virus scanning, malicious URL scanning and live traffic including crawlers. Wordfence is the only WordPress security plugin that can verify and repair your core, theme and plugin files.


STEP #6

Change your Database Table Prefix:

Warning: Make a backup of your database first!

The default database table prefix for a WordPress is "wp_" This makes your WP site vulnerable to SQL injection attacks. Changing the prefix to something custom like "wp1337_" or "mysite123_" is highly recommended. You can do this easily with the Better WP Security Plugin... Alternatively, you can manually change this by following the directions HERE.


STEP #7

Prevent attacks by blocking search engine spiders from indexing the admin area and other sensitive areas:

Spiders crawl all over your site structure unless they are told not to. The easiest way to prevent spiders from indexing the admin area is to create a "robots.txt" file in your "public_html" folder with the following code:

User-agent: *
Disallow: /cgi-bin
Disallow: /wp-admin
Disallow: /wp-includes
Disallow: /wp-content/plugins/
Disallow: /wp-content/cache/
Disallow: /wp-content/themes/
Disallow: */trackback/
Disallow: */feed/
Disallow: /*/feed/rss/$
Disallow: /category/*

STEP #8

Secure your ".HTACCESS" files:

Hypertext Access or .HTACCESS is the default name of directory-level configuration file that provides decentralized management of configuration while inside your directory structure and are often used for security restrictions on a particular directory. Again, most of the fixes listed in this thread can be easily implemented with a click of a button using Better WP Security Plugin.

NOTE: To ensure the codes below are not overwritten by WordPress, place them outside the # BEGIN WordPress and # END WordPress tags in the root .htaccess file. WordPress can overwrite anything between these tags!


First, we want to protect the ".htaccess" file itself, so add the following code inside the file using your favorite editor (I recommend Notepad++):

# Protect .htaccess file
<files .htaccess>
Order allow,deny
Deny from all
</files>

NOTE: Remember to do add this to ALL ".htaccess" files you have or create!


Now, lets secure your "wp-config.php" file by adding the code below inside of your ROOT ".htaccess" file:

# Protect wp-config file
<files wp-config.php>
Order allow,deny
Deny from all
</files>

Now, lets prevent hackers from browsing your directory structure by adding the code below inside of your ROOT ".htaccess" file:

# Disable directory browsing
Options All -Indexes

Now, lets prevent some SQL script injections by adding the code below inside of your ROOT ".htaccess" file:

# Protect from SQL injection
RewriteCond %{QUERY_STRING} \.\.\/ [NC,OR]
RewriteCond %{QUERY_STRING} ^.*\.(bash|git|hg|log|svn|swp|cvs) [NC,OR]
RewriteCond %{QUERY_STRING} etc/passwd [NC,OR]
RewriteCond %{QUERY_STRING} boot\.ini [NC,OR]
RewriteCond %{QUERY_STRING} ftp\:  [NC,OR]
RewriteCond %{QUERY_STRING} http\:  [NC,OR]
RewriteCond %{QUERY_STRING} https\:  [NC,OR]
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|%3D) [NC,OR]
RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(\[|\]|\(|\)|<|>|ê|"|;|\?|\*|=$).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*("|'|<|>|\|{||).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(%24&x).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(%0|%A|%B|%C|%D|%E|%F|127\.0).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(globals|encode|localhost|loopback).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(request|select|concat|insert|union|declare).* [NC]
RewriteCond %{QUERY_STRING} !^loggedout=true
RewriteCond %{QUERY_STRING} !^action=rp
RewriteCond %{HTTP_COOKIE} !^.*wordpress_logged_in_.*$
RewriteCond %{HTTP_REFERER} !^http://maps\.googleapis\.com(.*)$
RewriteRule ^(.*)$ - [F,L]

Now, lets block known bad hosts and agents with HackRepair.com's blacklist by adding the code below inside of your ROOT ".htaccess" file:

# Begin HackRepair.com Blacklist
RewriteEngine on
# Abuse Agent Blocking
RewriteCond %{HTTP_USER_AGENT} ^BlackWidow [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Bolt\ 0 [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Bot\ mailto:craftbot\@yahoo\.com [NC,OR]
RewriteCond %{HTTP_USER_AGENT} CazoodleBot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^ChinaClaw [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Custo [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Default\ Browser\ 0 [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^DIIbot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^DISCo [NC,OR]
RewriteCond %{HTTP_USER_AGENT} discobot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Download\ Demon [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^eCatch [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ecxi [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^EirGrabber [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^EmailCollector [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^EmailSiphon [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^EmailWolf [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Express\ WebPictures [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^ExtractorPro [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^EyeNetIE [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^FlashGet [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^GetRight [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^GetWeb! [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Go!Zilla [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Go-Ahead-Got-It [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^GrabNet [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Grafula [NC,OR]
RewriteCond %{HTTP_USER_AGENT} GT::WWW [NC,OR]
RewriteCond %{HTTP_USER_AGENT} heritrix [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^HMView [NC,OR]
RewriteCond %{HTTP_USER_AGENT} HTTP::Lite [NC,OR]
RewriteCond %{HTTP_USER_AGENT} HTTrack [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ia_archiver [NC,OR]
RewriteCond %{HTTP_USER_AGENT} IDBot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} id-search [NC,OR]
RewriteCond %{HTTP_USER_AGENT} id-search\.org [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Image\ Stripper [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Image\ Sucker [NC,OR]
RewriteCond %{HTTP_USER_AGENT} Indy\ Library [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^InterGET [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Internet\ Ninja [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^InternetSeer\.com [NC,OR]
RewriteCond %{HTTP_USER_AGENT} IRLbot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ISC\ Systems\ iRc\ Search\ 2\.1 [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Java [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^JetCar [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^JOC\ Web\ Spider [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^larbin [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^LeechFTP [NC,OR]
RewriteCond %{HTTP_USER_AGENT} libwww [NC,OR]
RewriteCond %{HTTP_USER_AGENT} libwww-perl [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Link [NC,OR]
RewriteCond %{HTTP_USER_AGENT} LinksManager.com_bot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} linkwalker [NC,OR]
RewriteCond %{HTTP_USER_AGENT} lwp-trivial [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Mass\ Downloader [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Maxthon$ [NC,OR]
RewriteCond %{HTTP_USER_AGENT} MFC_Tear_Sample [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^microsoft\.url [NC,OR]
RewriteCond %{HTTP_USER_AGENT} Microsoft\ URL\ Control [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^MIDown\ tool [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Mister\ PiX [NC,OR]
RewriteCond %{HTTP_USER_AGENT} Missigua\ Locator [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Mozilla\.*Indy [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Mozilla\.*NEWT [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^MSFrontPage [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Navroad [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^NearSite [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^NetAnts [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^NetSpider [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Net\ Vampire [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^NetZIP [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Nutch [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Octopus [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Offline\ Explorer [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Offline\ Navigator [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^PageGrabber [NC,OR]
RewriteCond %{HTTP_USER_AGENT} panscient.com [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Papa\ Foto [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^pavuk [NC,OR]
RewriteCond %{HTTP_USER_AGENT} PECL::HTTP [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^PeoplePal [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^pcBrowser [NC,OR]
RewriteCond %{HTTP_USER_AGENT} PHPCrawl [NC,OR]
RewriteCond %{HTTP_USER_AGENT} PleaseCrawl [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^psbot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^RealDownload [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^ReGet [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Rippers\ 0 [NC,OR]
RewriteCond %{HTTP_USER_AGENT} SBIder [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^SeaMonkey$ [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^sitecheck\.internetseer\.com [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^SiteSnagger [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^SmartDownload [NC,OR]
RewriteCond %{HTTP_USER_AGENT} Snoopy [NC,OR]
RewriteCond %{HTTP_USER_AGENT} Steeler [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^SuperBot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^SuperHTTP [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Surfbot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^tAkeOut [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Teleport\ Pro [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Toata\ dragostea\ mea\ pentru\ diavola [NC,OR]
RewriteCond %{HTTP_USER_AGENT} URI::Fetch [NC,OR]
RewriteCond %{HTTP_USER_AGENT} urllib [NC,OR]
RewriteCond %{HTTP_USER_AGENT} User-Agent [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^VoidEYE [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Web\ Image\ Collector [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Web\ Sucker [NC,OR]
RewriteCond %{HTTP_USER_AGENT} Web\ Sucker [NC,OR]
RewriteCond %{HTTP_USER_AGENT} webalta [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^WebAuto [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^[Ww]eb[Bb]andit [NC,OR]
RewriteCond %{HTTP_USER_AGENT} WebCollage [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^WebCopier [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^WebFetch [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^WebGo\ IS [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^WebLeacher [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^WebReaper [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^WebSauger [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Website\ eXtractor [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Website\ Quester [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^WebStripper [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^WebWhacker [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^WebZIP [NC,OR]
RewriteCond %{HTTP_USER_AGENT} Wells\ Search\ II [NC,OR]
RewriteCond %{HTTP_USER_AGENT} WEP\ Search [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Wget [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Widow [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^WWW-Mechanize [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^WWWOFFLE [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Xaldon\ WebSpider [NC,OR]
RewriteCond %{HTTP_USER_AGENT} zermelo [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Zeus [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Zeus\.*Webster [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ZyBorg [NC]
RewriteRule ^.* - [F,L]
# Abuse bot blocking rule end
# End HackRepair.com Blacklist

Now, lets secure your "wp-includes" folder. Limit access to this directory by adding the code below inside the ROOT".htaccess" file:

# Block the include-only files.
RewriteEngine On
RewriteBase /
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]

Now, lets secure your "wp-content" folder. Limit access to this directory by creating a NEW ".htaccess" file inside this folder and then adding the code below inside (do NOT place code inside your root .htaccess!):

Order deny,allow
Deny from all
<Files ~ ".(xml|css|jpe?g|png|gif|js)$">
Allow from all
</Files>

This code allows users to see images, CSS, etc … but will protect the important PHP files.


Now, lets secure your "wp-admin" folder with IP Restriction. Limit access to this directory by creating a NEW ".htaccess" file inside this folder and then adding the code below inside (do NOT place code inside your root .htaccess!):

# IP access for wp-admin
order deny,allow
allow from 11.22.33.44.55 
deny from all

This code denies access to the admin folder for everyone, with the exception of the IP address you have specified. Simply replace the default IP with your own.

NOTE: If you have a dynamic IP, you will need to regularly alter this file to avoid locking yourself out!


STEP #9

Make sure to Password Protect your "wp-admin" folder:

Adding server-side password protection (such as BasicAuth) to your "wp-admin" directory adds a second layer of protection around your WP admin area, the login screen, and your files. This forces an attacker or bot to attack this second layer of protection instead of your actual admin files. This, along with IP Restriction, are probably the 2 most effective ways to prevent your WP site from being hacked.


STEP #10

NEVER stop implementing security measures:

There are many other tweaks you can do and implement in order to secure your websites furtehr, such as forcing SSL, or renaming your wp-admin folder to hide the backend, ect... However, the methods listed here should protect most WP sites enough. I urge you to implement AS MANY security features as you possibly can. :thumbup:

=================


Okay, then... Now that you've successfully secured your WP website, let's KEEP IT THAT WAY!

Remember These Simple Rules To Keep Your Website(s) HACK-PROOF:

RULE #1 - Remove any plugins/addons and/or themes that you're NOT actively using. "Disabled" does not qualify as removed, physically delete the files from the server!


RULE #2 - Keep ALL of your scripts up-to-date and secured at all times (updated does not mean secure!). This is critical as updates from developers often patch security exploits and other vulnerabilities.


RULE #3 - Keep ALL plugins/addons and/or themes that you DO actively use, up-to-date/patched and secured at all times.


RULE #4 - ALWAYS keep your own off-site backups available (CD-ROM, Portable Drive, ect..). When (not if) the worst happens, you will be ready to take control and get back to business.


RULE #5 - SCAN your personal computer(s) and/or any other computer(s) used to access your hosting account and website with, regularly using a leading Anti-virus and Malware/Spyware Tool (THIS IS IMPORTANT!). No amount of security in WordPress or on your web server will make the slightest difference if there is a keylogger on your computer. Always keep your operating system and the software on it, especially your web browser, up-to-date and secured.


RULE #6 - ALWAYS connect to your hosting account using a secure connection such as FTPES (highly recommended) or using SFTP (if available).. NEVER connect using regular FTP. When you connect via regular FTP your username and password are transmitted over the internet in unsecured PLAIN TEXT! - You can connect to your account via FTPES (if your host supports it, and for your sake I hope they do!) using most FTP clients (I recommend FileZilla since it's FREE).


RULE #7 - keep an eye on your websites!.. Log into your cPanel hosting control panel and browse your website on a regular basis to monitor for malicious activity.

=================


SOME USEFUL LINKS:

More Recommended Steps To harden Your WordPress Installation: http://codex.wordpress.org/Hardening_WordPress

FREE Online Website Malware + Blacklist Scan: http://sitecheck.sucuri.net/scanner/

Download a FREE Anti-Virus & Malware Tool for Microsoft Windows (XP,Vista, Windows7): http://windows.microsoft.com/en-US/windows/products/security-essentials


I hope this guide will help many of you. I run dozens of personal WP sites and I use these very same security measures on all of them, without any issues whatsoever. Please feel free to post more tips in this thread, or if I've made a mistake, do let me know so I can correct it.

Thank you for reading! :wave:

 

[mikho]

Nice one!

Most of this will work even if you are using a webserver like nginx or lighthttpd.

As mentioned more then once i the guide above. MAKE BACKUPS!

record the steps you make, so you can eventually undo them if site gets broken.
Don't do everything at once. Make one change, test that everything works. Continue with the next step and make sure you test your site after each step. Test it by closing your browser and open it again, clear cookies, login and
browse around on your site, visiting both pages and posts.

If something goes wrong, most of the time the frontpage will work but not something else.

Good luck everyone

 

[HostMunch]

I wonder what percentage of people will actually do this, though. That's quite a lot of work if you have a few hundred websites.

 

[easyhostmedia]

I wonder what percentage of people will actually do this, though. That's quite a lot of work if you have a few hundred websites.

hard work for any person if they run 100s of sites, even without security updates.

If you are a host just made a KB with the info and then mass mail all clients linking to the KB article, explaining they need to follow it.

I have carried out this for 2 clients today so far, as they asked if i could do this and even offered to pay for my time.

 

[mikho]

I wonder what percentage of people will actually do this, though. That's quite a lot of work if you have a few hundred websites.

If you setup your wordpress blog with common sense, most of this should have been done in the beginning.

And I wonder who has the time to update 100 wordpress blogs?:dknow:

 

[easyhostmedia]

Personally i have never had any WP sites as being a webhost for too many years i get to know about many issues with WP, but i cant imagine anyone having the time to service 100 websites.

I have seen me take websites down because i dont have the time to maintain them

 

[HostLeet]

Here's a screenshot of one of my WP sites using Better WP Security. As you can see all security features have been implemented. :thumbup:

Also.. There are many ways to manage multiple sites at once, but that's another thread!.. And, if you can't manage 100 WP sites yourself because it's too much work, well then don't have 100 WP sites! :smash:

 

[M to the C]

Nice write up HostLeet!!! Really useful for anybody reading.

 

[IkY0294]

Thanks for sharing this information with us.. Many people these days that start a word press site usually never secure the word press script this is a easy tutorial and hopefully after any word press site owner sees this they will take this into consideration and will secure their script.

 

[rowebca]

Here's a screenshot of one of my WP sites using Better WP Security. As you can see all security features have been implemented. :thumbup:

Also.. There are many ways to manage multiple sites at once, but that's another thread!.. And, if you can't manage 100 WP sites yourself because it's too much work, well then don't have 100 WP sites! :smash:

What you did is great, but for me I can't understand people using something unsecured and plenty of security updates, but I guess is not about using something good , it is about to be in the "flock" of sheep. If everybody is using Iphone, Facebook, Twitter, "justin bieber" etc let's use that (it doesn't matter if is good or bad). One another example is the helmet. Instead to stop dangerous activities human invented the helmet, thinking that with a helmet they are protected.

Our days quality was replaced with quantity, 2 completely different words.

I am missing the time when everybody build their website from scratch using just Notepad.

Is humanity just a "flock"?

Sorry for my off topic.

Regards

 

[HostLeet]

What you did is great, but for me I can't understand people using something unsecured and plenty of security updates, but I guess is not about using something good , it is about to be in the "flock" of sheep. If everybody is using Iphone, Facebook, Twitter, "justin bieber" etc let's use that (it doesn't matter if is good or bad). One another example is the helmet. Instead to stop dangerous activities human invented the helmet, thinking that with a helmet they are protected.

Our days quality was replaced with quantity, 2 completely different words.

I am missing the time when everybody build their website from scratch using just Notepad.

Is humanity just a "flock"?

Sorry for my off topic.

Regards

I'm not really sure what you mean by that.. Are you saying WP is NOT secure and people only use it because it's popular? :uhh: If that's what you're saying, it is completely inaccurate.

WordPress is VERY secure, as you can see.. However, people like you need to understand that in order to release a piece of a software such as WP, it needs to be compatible with most systems out there, out-of-the-box.. Then, it is up to the user to properly secure the installation according to their system, and requirements.

If all of these, and every other security feature, came already implemented into WP by default, there is a good chance many users would install a broken WP website/theme/addon.. There are way too many different variations of setups and systems out there, they need to give you a BASIC install that will work with most. It's the same with WHMCS, Oscommerce, Joomla, and pretty much every other script, CMS, ect.. You install it, then it is up to you (the user) to make sure you 'lock' down your script and secure it further.

I don't think the helmet analogy applies here.. If that's the case, we should all just turn off our servers to keep them secure.. Because that is the ONLY way to have a truly 100% secure server. Thanks for your input, though.

 

[pwhcary]

Hello,

Every hosting provider allowing clients to host wordpress sites do keep the servers secure to host blog sites.

 

[easyhostmedia]

Hello,

Every hosting provider allowing clients to host wordpress sites do keep the servers secure to host blog sites.

yes a host should keep the server secure, but it the responsibility of the client to make sure that they are using the most up to date version of any scripts they use and making sure the scripts are secure

 

[BradatA2Hosting]

Very thorough information, thank you. I would also consider using CloudFlare for your site. They block a lot of threats before they can even get to your site.

 

[mikho]

Hello,

Every hosting provider allowing clients to host wordpress sites do keep the servers secure to host blog sites.

No matter how secure the provider keeps the backbone, if the user does not update his/her wordpress installation, or whatever script he/she is using. Bad things can and will happen.

 

[rowebca]

yes a host should keep the server secure, but it the responsibility of the client to make sure that they are using the most up to date version of any scripts they use and making sure the scripts are secure

You know, if I'll be the coder of Wordpress, I'll do (maybe php) a small script (you can call this plugin) to check if the application is updated or outdated depending by a code generated by each installation, update (in a txt file). Every page from word press will compare the code from WordPress app website with local and if the application is outdated to lock down the directory (no access from outside, only from admin ip) where installation is done. It is easy to be done. But my question is they want to do this?

Regards

 

[mikho]

You know, if I'll be the coder of Wordpress, I'll do (maybe php) a small script (you can call this plugin) to check if the application is updated or outdated depending by a code generated by each installation, update (in a txt file). Every page from word press will compare the code from WordPress app website with local and if the application is outdated to lock down the directory (no access from outside, only from admin ip) where installation is done. It is easy to be done. But my question is they want to do this?

Regards

That solution would create a massive amount of traffic to the wordpress servers.
Easiest way to bring their site would be to browse all other wordpress installations that is done around the world. It would probably end up that wordpress would IP-banthe server hosting your worpress installation which would halt your website since it would only be accessible from your Admin IP.


worst case scenario is that an update is done while you are away, your site would be locked down until you return and upgrade that plugin that caused it.
To make it even worse, your dynamic IP changed while you were away and you need to have the code updated with your new IP before you can update your installation.

Ofcourse you blame wordpress for this and you move over to another CMS.

I might sound like a cranky old man right now but I can't see that being an acceptable solution.

It is the responsibility of the owner of the site to keep it updated. if that person can't handle that "pressure" then they need to hire someone to do it for them.

 

[easyhostmedia]

It is the responsibility of the owner of the site to keep it updated. if that person can't handle that "pressure" then they need to hire someone to do it for them.

exactly. the servers security is the responsibility of the server admins, but this does not stop clients from adding exploited scripts or scripts that can be exploited. this is the reason software houses generate regular updates of their scripts, so the update will include bug fixes, security patches etc.
It is the clients responsibility to make sure they upgrade to the latest software version, as if due to a client not doing this as server issues arise then the client could see their account suspended/terminated. We have done this when a client was using e107 and when this was attached the client ignored requests to upgrade the security patches when they were released. Now we dont allow e107 on our servers as they have had several major attacks and are slow to correct these issues