part I : how to secure wordpress server and other LAMPs
LAMP stands for Linux+Apache+MySQL+PHP. Wordpress.org blog server project is one of the many open source web projects use this combination as their foundations. Wordpress.org blog server’s setup is quick & easy like a snap. Thrilled by the newly found freedom to publish with ease, people tend to overlook the need for security for their wordpress servers. Unfortunately, the latter is just as vulnerable to malicious attacks as the next LAMP application server.
Matter of fact is, today’s Internet is no longer as friendly as we fondly recall of its early days. Once web service (TCP/80) was opened to this Fedora Core Linux 6/i386 from the Internet on our firewall this past weekend, many suspicious requests (’GET / HTTP/1.0′) came in from various presumably “owned” home computers within a few minutes.
In this article, we’ll run through some quick steps to secure wordpress blog server as well as other regular LAMP application servers. The need to secure a Internet-facing server vigorously will be left for another article.
- Linux
- keep all packages up-to-date, esp. those updated to patch up some published vulnerabilities
- turn on SELinux (RHEL4/CentOS4/Fedora4 all ship with targeted SELinux policy, which restrains httpd processes to access a very limited set of resources by MAC (Mandatory Access Control), regardless of rights under traditional DAC (Discretionary Access Control).
- turn on Firewall
- SSH and HTTP/HTTPS probably are the only two you needed to allow inbound traffic
- ICMP can be dropped as long as it is not type 3 or 11
- You can even turn restrict the incoming IP for SSH and HTTPS, if they are used for administrative purposes only and know which IP addresses you come from all the time.
- do use SSH and secure it (how to secure OpenSSH)
- turn off SSH protocol v1
- disallow direct root login
- disallow all users except a special access group or an explicit list of users
- disallow authentication by password. Unless you have 64 random bytes or higher as your password, it could be attacked by dictionary attack. Instead, start using SSH key for authentication exclusively. The catch is that you need to make sure you have the key with you all the time, if you want to access the server from workstations other than the one which has the pair of SSH keys.
- disallow TCP tunneling. It is a powerful feature. Dangerous when it is used against you.
- turn off unused services
- remove unused packages
- choose strong password for root and any user accounts you use to access the server
- secure SSH by enforcing SSH v2 only and by disallowing authentication by passwords.
- Apache
- remove unused module packages (mod_perl, mod_python, mod_ssl)
- disable unused module (mod_proxy_ajp on FC6)
- harden it using httpd.conf
- comment out unused modules (DAV/LDAP/auto_index/cgi/asis, etc.)
- “Deny all” on Directory /
- “ServerTokens Prod” to show only “Apache” in the “Server:” header. However, there’s still “X-powered-by” header revealing the version of PHP.
- install mod-security & configure rules. gotroot.com has a set of working mod-security rules for wordpress.
- MySQL
- remove the default ‘test’ database or alike
- /usr/bin/mysqladmin -u root -p drop test
- check ‘mysql’ database and remove unused rows in user/db/host tables
- MySQL installations on Fedora Core Linux, for example, has wide-open permission for database name that starts with “test_”. It is convenient for testing purposes, but detrimental to the overall server security.
- remove the default ‘test’ database or alike
- PHP
- At least, turn on safe mode using /etc/php.ini
- make sure “register_globals = Off” in /etc/php.ini
- apply PHP-hardening patch from hardened-php.net
226c226
< safe_mode = On
> safe_mode = Off- More on PHP secure configuration (part I, part II)
- Wordpress.org blog server software
- minimal approach: remove things you do not need for your site. You can review the list of wordpress files and their purposes and usage, to determine whether a specific file is needed or not. For example, I removed
- wp-mail.php needed only if you want to publishing posts by emailing your blog posts to a pop3 account.
- xmlrpc.php needed only if you post to your site remotely. Or as wordpress.org documented here, it “handles incoming xmlrpc commands. Among other things, this allows posting without using the built-in web-based administrative interface.”
- wp-config-sample.php Your real working configuration is at wp-config.php.
- enable SSL for wp-login.php and /wp-admin/ pages
- opt for long-winding password for the all-powerful ‘admin’ user. v2.0.6 wordpress.org uses md5() to store the user account passwords, therefore you can really use crazily long password.
- update wp_users set user_pass = md5(’crazylongorekjr3k2jr3kerherhkekhrdhrkjewrehrekjr’) where ID=1;
- Or, go for client SSL certificate. Surprise, there’s wordpress plugin for this too!
- careful with the 3rd party code you add (activated or not), including themes and plug-in.
- minimal approach: remove things you do not need for your site. You can review the list of wordpress files and their purposes and usage, to determine whether a specific file is needed or not. For example, I removed
To finish it off for the initial round of securing your newly-minted wordpress server, it is recommended to conduct vulnerability assessment/analysis (a list of vulnerability assessment tools)against your site, before open your blog server to the world. Better, before it connects to the LAN or any network.
The above steps are to secure the server itself. To complete the picture, you need to secure the information security ecosystem that the server lives in. One main component of this security ecosystem is the management workstation, from which you manage the server by SSH, Plex, or a web browser access wordpress’s administrator dashboard. The regular personal computing security measures need to be in place: anti-virus, personal firewall, privacy protector, hardened and secured operating system, updates and patches being applied to the operating system and browsers in a timely fashion.
On the management workstation, the web browser often gets overlooked. I noticed some readers of this site is using aged browsers, including IE 5. Microsoft is generally known to be slow to release major security or bug fixes for IE, since it shares DLLs with other major components of the underlying Windows operating systems. In contrast, Firefox is relatively independently of the operating system, more standard compliant and faster to delivery security patches.
Do come back every so often to revisit the topic of security during operations. If nothing else, your own priorities and security needs may change, as your business grows and more vendors and partners added to your business ecosystem.
As we’ll emphasize throughout, information security (InfoSec) is an ongoing process. It encompasses far more than merely securing software components. More information security best practice can be found at part II of this article.
