WordPress is the most popular CMS used for many commercial websites as well as hobbyist sites. The popularity of WordPress also brings the software to the front as a target by attackers. Lax security and an over-trust of many free plugins and themes leads to many sites being easily compromised. Several steps can be taken to increase the security of hosting and running WordPress.
Changes in wp-config.php
One easy change is to require HTTPS for the WordPress login and Dashboard area. To enable and require HTTPS for the WordPress login and WordPress Dashboard area, put the following in wp-config.php: With this enabled, visiting the login URL of WordPress (Ex: http://example.com/wp–admin ) will automatically redirect to HTTPS and retain the HTTPS session while logged in to the Dashboard. Curiously, many large corporate WordPress sites have their login page and Dashboard in clear text over HTTP and are not using this above option. Ex: http://gigaom.com/wp–admin ; http://blog.ups.com/wp–admin ; http://techcrunch.com/wp–admin ; http://boingboing.net/wp–admin ; and others (eek!). In this case all it takes is an employee logging in over coffee shop wifi for the credentials to be stolen or other Dashboard activity be intercepted. Consider further protecting the login page for your blog by requiring a second factor authentication such as Yubikey ( http://henrik.schack.dk/yubikey-plugin/ ), Google Authenticator ( http://wordpress.org/extend/plugins/google-authenticator/ ), and/or Apache server auth for another layer of security.
Another suggested change in wp-config.php is to add some salt. Visit the url https://api.wordpress.org/secret-key/1.1/salt and copy/paste the provided salts to your wp-config.php. This will help add some security to the authenticated cookies when logged in to manage the site or blog. Example:
Information Leakage
By default, WordPress will disclose its version and other tidbits in the header of the HTML. To remove this information leakage, add the following to the bottom of the theme’s functions.php:
Restrict Bad Bots
Restrict various bad ‘bots’ or crawling software often used to poke at sites with mod_rewrite. These bots are easily blocked by restricting the user-agent in the file .htaccess in the root directory of the WordPress installation. An example rewrite rule that can be used in .htaccess is: RewriteCond %{HTTP_USER_AGENT} ADSARobot|ah-ha|almaden|aktuelles|Anarchie|amzn_assoc|ASPSeek|ASSORT|ATHENS|Atomz|attach|attache|autoemailspider |BackWeb|Bandit|BatchFTP|bdfetch|big.brother|BlackWidow|bmclient|Boston Project|BravoBrian SpiderEngine MarcoPolo|Bot mailto:craftbot@yahoo.com|Buddy|Bullseye|bumblebee|capture|CherryPicker|ChinaClaw|CICC|clipping|Collector |Copier|Crescent|Crescent Internet ToolPak|Custo|cyberalert|DA$|Deweb|diagem|Digger|Digimarc|DIIbot|DISCo|DISCo Pump|DISCoFinder|Download Demon|Download Wonder|Downloader|Drip|DSurf15a|DTS.Agent|EasyDL|eCatch|ecollector|efp@gmx.net|Email Extractor|EirGrabber|email|EmailCollector|EmailSiphon|EmailWolf|Express WebPictures|ExtractorPro|EyeNetIE|FavOrg|fastlwspider|Favorites Sweeper|Fetch|FEZhead|FileHound|FlashGet WebWasher|FlickBot|fluffy|FrontPage|GalaxyBot|Generic|Getleft|GetRight|GetSmart|GetWeb!|GetWebPage|gigabaz |Girafabot|Go!Zilla|Go!Zilla|Go-Ahead-Got-It|GornKer|gotit|Grabber|GrabNet|Grafula|Green Research|grub-client|Harvest|hhjhj@yahoo|Havij|hloader|HMView|HomePageSearch|http generic|HTTrack|httpdown|httrack|ia_archiver|IBM_Planetwide|Image Stripper|Image Sucker|imagefetch|IncyWincy|IndyLibrary|Indy Library|informant|Ingelin|InterGET|Internet Ninja|InternetLinkagent|Internet Ninja|InternetSeer.com|Iria|Irvine|JBHagent|JetCar|JOC|JOC Web Spider|JustView|KWebGet|Lachesis|larbin|LeechFTP|LexiBot|lftp|libwww|likse|Link|Link*Sleuth|LINKS ARoMATIZED|LinkWalker|LWP|lwp-trivial|Mag-Net|Magnet|Mac Finder|Mag-Net|Mass Downloader|MCspider|Memo|Microsoft.URL|MIDown tool|Mirror|Missigua Locator|Mister PiX|MMMtoCrawl/UrlDispatcherLLL|^Mozilla$|Mozilla.Indy|Mozilla.NEWT|MozillaMSIECrawler|MS FrontPage|MSFrontPage|MSIECrawler|MSProxy|multithreaddb|nationaldirectory|Navroad|NearSite|NetAnts |NetCarta|NetMechanic|netprospector|NetResearchServer|NetSpider|Net Vampire|NetZIP|NetZip Downloader|NetZippy|NEWT|NICErsPRO|Nikto|Ninja|NPBot|Octopus|Offline Explorer|Offline Navigator|OpaL|Openfind|OpenTextSiteCrawler|OrangeBot|PageGrabber|Papa Foto|PackRat|pavuk|pcBrowser|PersonaPilot|Ping|PingALink|Pockey|Proxy|psbot|PSurf|puf|Pump|PushSite |QRVA|RealDownload|Reaper|Recorder|ReGet|replacer|RepoMonkey|Robozilla|Rover|RPT-HTTPClient|Rsync|Scooter|SearchExpress|searchhippo|searchterms.it|Second Street Research|Seeker|Shai|Siphon|sitecheck|sitecheck.internetseer.com|SiteSnagger|SlySearch|SmartDownload |snagger|Snake|SpaceBison|Spegla|SpiderBot|sproose|SqWorm|Stripper|Sucker|SuperBot|SuperHTTP|Surfbot |SurfWalker|Szukacz|tAkeOut|tarspider|Teleport Pro|Templeton|TrueRobot|TV33_Mercator|UIowaCrawler|UtilMind|URLSpiderPro|URL_Spider_Pro|Vacuum |vagabondo|vayala|visibilitygap|VoidEYE|vspider|Web Downloader|w3mir|Web Data Extractor|Web Image Collector|Web Sucker|Wweb|WebAuto|WebBandit|web.by.mail|Webclipping|webcollage|webcollector|WebCopier |webcraft@bea|webdevil|webdownloader|Webdup|WebEMailExtrac|WebFetch|WebGo IS|WebHook|Webinator|WebLeacher|WEBMASTERS|WebMiner|WebMirror|webmole|WebReaper|WebSauger |Website|Website eXtractor|Website Quester|WebSnake|Webster|WebStripper|websucker|webvac|webwalk|webweasel|WebWhacker|WebZIP|Wget |Whacker|whizbang|WhosTalking|Widow|WISEbot|WWWOFFLE|x-Tractor|^Xaldon WebSpider|WUMPUS|Xenu|XGET|Zeus.*Webster|Zeus [NC]
WordPress Permissions
Web server files or directories should never be 777 as this will let anyone tamper with files or directories on your server. 777 permissions are not required for WordPress to operate nor for any upload directories to function. For example, a simple HTTP POST command using curl can upload a malicious plugin to take control of the blog. A recent example of this is the ToolsPack plugin found on compromised blogs due to 777 permissions (http://blog.sucuri.net/2012/02/new-wordpress-toolspack-plugin.html). In general, directories should be 750 or 755. Files should be 644 or 640. For example, this command will make all files recursively in /var/www/ to be 755 permissions: To locate any directories that are 777, the find command can be used. This command searches for directories that are 777 in /var/www/: Likewise for files, this command searches for files that are 777 in /var/www/: The other aspect of permissions concerns the owner and group of the files in /var/www or whatever is the location of the WordPress installation. Files and directories should be owned by a regular user and in the group of the apache user. This is so that if a compromise was to occur or if a rogue script was run launched by WordPress or related software it would not be able to maliciously alter or install malware in the WordPress installation or other web directories. This example command changes the owner to jsmith (example username) and group of the Apache user on Debian and Ubuntu for all files in the WordPress installation: This does cause a slight problem for WordPress Dashboard updates of plugins or themes. To temporarily switch permissions to allow Dashboard updates, change the owner to the apache user: Next perform updates in the WordPress Dashboard, then set permissions back: While not convenient, temporarily changing ownership for updates and back will help to keep the WordPress installation more secure.
Plugins and Themes from Trusted Sources
Only install plugins and themes from trusted sources. It is good to exercise a healthy bit of skepticism even when browsing available themes or plugins from wordpress.org. Inspect the author of the plugin or theme to check their credibility, the amount of time the plugin or theme has been in use, and any general common sense gauge before implementing the code on your WordPress installation. Various free themes and plugins floating around the internet have malicious links or code embedded. This malicious code is often masked as base64 so looking at the php files malicious links or javascript may not be immediately visible. One example at time of writing is an ‘Advanced Search’ plugin which is available from a random link: http://searchpluginwp.blogspot.com/ . According to sucuri.net, this plugin sneaks in many malicious URLs into your blog (http://blog.sucuri.net/2012/05/wpstats-org-spam-and-a-fake-advanced-search-plugin.html).
Limit number of plugins used
If possible, limit the total number of plugins used. For plugins that are not used and disabled, delete them completely. The same goes for unused themes. Remove unused themes from your server. The only themes installed should be the WordPress default and the current activated theme for the website. For example, many themes made use of the timthumb.php file which caused many blogs to be compromised over the past few months. This vulnerable file could be part of a random theme that is unused, yet remains sitting on the web server. The number of users allowed to have accounts should be kept to an absolute minimum as well.
Recommended Security Plugins
Many security related plugins exist for WordPress. In particular the following are very useful. Bad Behavior (http://wordpress.org/extend/plugins/bad–behavior/) restricts HTTP connections that appear malicious, somewhat acting as an IDS/IPS all from a plugin. Even better, Bad Behavior can integrate with projecthoneypot.org so that the current blacklist from project honeypot is also applied to protect against malicious connections to WordPress. To prevent spam links, it is possible to disable comment Author Links via a simple plugin called Disable comment Author Links ( http://www.tacticaltechnique.com/wordpress/disable–comment–author–links/ ). It is helpful to use a good anti-spam comment plug, such as WP Captcha-Free ( http://wordpresssupplies.com/wordpress-plugins/captcha-free/). The plugin wp-updates-notifier (http://wordpress.org/extend/plugins/wp–updates–notifier/) provides instant email notifications for plugin, theme, or core WordPress updates.
Regarding comments, be very skeptical of very generic comments on the blog such as ‘Very informative post’, ‘Great site, I love the information here’, or ‘Good post on the topic’. Many of these are from spam-bots often either testing the comment system, testing anti-spam measures, or testing for XSS.
Third party content
When choosing an advertising provider, chose a trusted provider such as Google Adsense. By using third party services the site is allowing a trust of the provider to place content, links, and code onto the site. There have been rare occurrences of third party advertising installing malware on sites as with nytimes.com, though this can be considered somewhat rare.
System Administration
p>If the blog or site is hosted on an unmanaged service such as a VPS, WordPress security extends to full server OS security. For example, if the server running WordPress is running out-of-date PHP, this leaves the entire server vulnerable. In this case it is critical to stay on top of all operating system updates. For the case of Debian or Ubuntu Linux, make use of the program apticron, which sends email notifications when operating system updates are available (http://www.cyberciti.biz/faq/apt-get-apticron-send-email-upgrades-available/). As with general server security, minimize running services on the box. For required services that are running (HTTP, SMTP, etc) minimize information leakage from the running services. Many providers that use cpanel and other administration interfaces make use of FTP as a predominant way to transfer files to the hosting site. FTP is insecure and should be avoided. Using SFTP over port 22 is the preferred way for connecting for file transfer and all modern FTP clients support SFTP. If the hosting company does not support SFTP, change to a different provider.
Logging
Daily reviewing of Apache logs can be automated in Linux with logwatch. Logwatch emails a daily snip-it of log activity and can highlight specific information that looks suspicious or would need closer manual inspection. Example logwatch email: The Linux program fail2ban is often thought of as an ssh anti-brute-forcing tool, but it has a use for web servers as well. fail2ban can be utilized to prevent repeated attempts from bots or other various malicious attempts to the server. The fail2ban configuration apache-badbots.conf from Yaroslav Halchenko is extremely useful in this regard. When enabled, repeated attempts using these user agents result in the ip being blocked by the firewall.
Maintenance
It goes without saying but upgrading all plugins, themes, and of course WordPress to their latest versions is critical. After upgrading WordPress, remove readme.html and license.txt from the WordPress directory. For the even more paranoid, remove any readme.txt files or license files from all plugins and themes which would reveal the version of the software installed. Daily mysql backups as well as daily theme/plugin backups should be in place. Recovering a snapshot of the site or database from backup should be rehearsed and procedures documented.
Scanning and Auditing
Regular auditing of the site for security against XSS and SQLi should be performed with various web application scanners either commercial or open source. Multiple web scanners should be used for various viewpoints on the current level of security of the site. For high traffic sites weekly web application scanning should be performed or automated. For lower traffic site quarterly scans can perhaps suffice.
Conclusions
WordPress is a very extensible CMS but is often also seen as an easy target for exploitation. Taking an active approach to securing WordPress should be done as would be done with securing any operating system. It is not WordPress itself which is altogether too problematic from security concern but often a poor implementation, out-of-date software and plugins, or use of untrusted plugins which result in a compromised target. It is critical to stay on top of security to keep the WordPress installation as protected as possible from would-be attackers.
