Category Archives: security

WordPress Security Tip: NEVER Use Your Admin ID Visibly

WordPress is the most-hacked platform out there, and the most common attempt at hacking it involves attempting to get access to your administrative ID. For this reason you should

  • NEVER use an ID like “admin”, “administrator”, or the name of your domain for your admin ID — Pick an admin ID that will not be guessed!
  • NEVER use your admin ID to make postings or comments on your WordPress blog
  • NEVER publish a posting unless you’ve checked a preview to be sure you’re not exposing anything you don’t want to. Save drafts, use preview.

Here are some simple better practices to keep your admin ID safe:

  • Only use your admin ID for administrative tasks that actually require it.

    This includes things like updating themes and plugins — which you should be doing via SFTP — and so forth.

  • Create a second “public” persona and give it “author” or “editor” privileges only. Be sure to use this ID for anything that will be visible on your site.

    On this site, “Zanzibar McFate” has no administrative privileges. (He has a 30-character, randomly-generated password, in spite of that.)

Tip 1: Use the “Author” Pop-up Menu on the “Edit Post” page

If you click on the “Screen Options” button toward the top-righthand corner of the “Edit Post” page, it will drop down and present you with a number of things you can show or hide. Check the box next to “Author”.


Now, there will be a pop-up menu section below the editing panel on the edit post page which will let you select your “public persona” as the post’s author instead of your admin ID.


Tip 2: Use the WP Masquerade Plugin

Comments are a bit tougher to manage, since they’re published immediately. You can log out of your administrative ID and log in as your persona, but fortunately, there’s an easier way.

A nice tool to facilitate better operational security here is the WP Masquerade plugin. I can verify that it works with my WP 4.2.2 install. Download the plugin and activate it. Now, when you go to your user list as an administrator, there will be a hover-visible link beneath every user saying “Masquerade”, as shown.


Click on that link, and you’ll be effectively logged in as that user, and any comments you make will be posted under that ID. To close the Masquerade session, click on the link in the banner at the bottom of the page.


Alternatively, you can use the “Masquerade as…” drop-down which the plugin adds to the Admin toolbar.



Your WordPress administrative ID is — assuming you’ve installed and secured your WordPress correctly — the weakest link in your security chain. If you expose it publicly, you’ve greatly increased the susceptibility of your site to being hacked. Practice good opsec, and use the tools available to keep your admin ID under wraps.

The Most Recent Batch of Inept Hackers

WordPress is very popular. Very easy to install. Very easy to install incorrectly if you’re not entirely clear on how things operate on your hosting, and in my experience, even a lot of ISPs seem to not be entirely clear on that.

This is just a screenful’s worth of the security scan — I’m using the free WordFence plugin on that site, which is one of the better free ones out there — from one of the WordPress sites I run. Pretty typical.

If you’re not running some sort of live traffic and file system scanner on your WordPress site, you’re probably asking for trouble. If your administrative account has a name like “admin”, “Administrator”, or “«PASTE SOME PORTION OF YOUR SITE’S DOMAIN NAME HERE»”, or if you expose your admin account name in other ways (like via an “?author=” page, or by using your admin account as an author), you’re walking down dark alleys with twenty-dollar bills hanging out of your pockets.

If you’re using an account name like that and an easily-guessed (or duplicated) password, you’re probably already in trouble.

I’m going to have more to say on this when I get it all organized…

Set Up Your WordPress Site to Use Password-Free SFTP For Better Security

This turns out to be a pretty easy trick to do. In order to accomplish this, you will need:

  1. to be able to ssh (or, heaven forbid, telnet) into a command line on your server and operate as root or a “sudoer”;
  2. to be able to edit the wp-config.php file for your WordPress installation;
  3. to be able to stop and restart your web server.

Assumptions: You’re running CentOS or something like it. If you’re running Debian, or something like it, you’ll need to use apt-get instead of yum, and your directory layout will be different.

Enabling SSH for PHP

We’re going to set up WordPress to enable uploads via SFTP; for that, we’ll first need to build and install the ssh2 extension to PHP. At your server’s command line, execute the following to load all of the infrastructure you’ll need:

$ yum install php-devel php-pear gcc gcc-c++ make automake autoconf pcre-devel re2c libssh2 libssh2-devel

Next, have pecl install the ssh2 extension.

$ pecl install ssh2-0.12

Turn on ssh2 by creating an ini file for PHP:

$ echo "extension =" > /etc/php.d/ssh2.ini

Restart your web server:

$ service httpd restart

At this point, the SSH2 PHP extension should be installed and activated; you can use

$ php -i | grep ssh2

to verify this.

Setting Up WordPress for SFTP

First thing to do is to generate a key pair. YOU MUST BE LOGGED IN AS THE USER WHO WOULD BE DOING THE UPLOADING TO WORDPRESS. At the command line, execute

$ keygen-ssh

When prompted to enter a file name, we’ll call the key pair “~/wp_rsa”, so as not to accidentally overwrite any other keys we have around. Once your key pair has been generated, execute the following commands in that user’s home directory:

$ cat >> .ssh/authorized_keys
$ mv wp_rsa* .ssh/

For reasons that aren’t immediately clear to me, WordPress required both the public and private key to be available to it. Set the access protections appropriately:

$ chmod 755 .ssh/
$ chmod 644 .ssh/*

Next, edit wp-config.php, and add the following lines to the end, making the appropriate substitutions for your own site «where indicated»:

define('FTP_HOST', 'localhost');
define('FTP_USER', '«your user name goes here»');
define('FTP_PUBKEY', '«full path to user's home directory»/.ssh/');
define('FTP_PRIKEY', '«full path to user's home directory»/.ssh/wp_rsa');

Finally, set the protections and ownership on the wp-content directory to allow Apache to create things in there (assumption — I have ownership of my wp-content directory set to «site owner»:apache; you may need to adjust this to suit your specific situation:

$ chmod 775 «full path to WordPress directory»/wp-content

You should be good to go.

[This posting is an adapted excerpt from the upcoming book “McFate’s Indispensible and Comprehensive Guide to Building Bullet-Proof Servers”]

The Correct Way to Lock Out an IP Address From Your Server

I’ve been getting something like a one-person DoS attack overnight, it seems — a single IP address hitting port 80 hundreds of times a minute, generating endless 404s, and chewing up noticeable bandwidth — so I had to add a rule to my iptables to block the IP address at fault. Here’s how to do it:

First, list your current iptable rules, with line numbers, for easy reference:

$ sudo iptables -L -n --line-numbers
Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination         
1    fail2ban-SSH  tcp  --             tcp dpt:22 
2    ACCEPT     all  --             
3    REJECT     all  --           reject-with icmp-port-unreachable 
4    ACCEPT     all  --             state RELATED,ESTABLISHED 
5    ACCEPT     tcp  --             tcp dpt:25 
6    ACCEPT     tcp  --             tcp dpt:587 


Add a new rule to block the offending IP address (“xxx.yyy.zzz.www”).

$ sudo iptables -I INPUT 1 -s xxx.yyy.zzz.www -j DROP

This will insert the new rule at position 1, just prior to the rule that accepts TCP incoming traffic on port 22 for SSH and passes it to fail2ban.

Save the updated table and restart the service.

$ sudo service iptables save
$ sudo service iptables restart
$ sudo iptables -L -n --line-numbers
Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination         
1    DROP       all  --           
2    fail2ban-SSH  tcp  --             tcp dpt:22 
3    ACCEPT     all  --             
4    REJECT     all  --           reject-with icmp-port-unreachable 
5    ACCEPT     all  --             state RELATED,ESTABLISHED 
6    ACCEPT     tcp  --             tcp dpt:25 
7    ACCEPT     tcp  --             tcp dpt:587 


Some suggestions for doing this that turn up on Google have used the “-A” (Add) flag rather than the “-I” (Insert) flag. This will not work in most cases, it would add the new rule to the end of the INPUT chain, after the rule that accepts (for instance) HTTP packets. If the banned IP address were attempting to access port 80, if would be ACCEPTed by that rule before it could get DROPped by the new rule.

The position of the rule is important: if it follows a rule which would accept the traffic otherwise, the new rule will have no effect. Placing it before the rules for general public traffic ensures that the annoyance in question can’t consume resources by trying to do things like load non-existent web pages. In fact, by checking first, the IP address is effectively firewalled from the server.

“Shell Shock” Exploit — Probably Not a Worry For OS X Users

We’ve been hearing a lot about a very serious exploit in a universally-deployed piece of software, the “Shell Shock” bug in the bash shell. I got an alert late yesterday evening, and immediately upgraded the software on my publicly-facing servers.

There’s been some discussion of whether or not it’s an issue for OS X, and some debate over whether it’s a significant exposure on that platform. I didn’t think it was, but I haven’t seen an update for OS X Server to patch it, for example.

My own version of bash is managed through Homebrew, so rather than the stock 3.2, I’m running a newly patched and up-to-date v4.3.25(1). However, I got curious, so I decided to check the stock OS X version of bash for this exploit, and here’s what I found:


So, the (rather antiquated) OS X version of bash, which has a “modified” date of May 10, has already been patched to disallow this hack, or so it would appear.

UPDATE: Apple’s given a statement on iMore that OS X users should not be at risk from the “Shell Shock” exploit unless they have “advanced UNIX services configured”. I’m not sure which specific “advanced UNIX services” they’re referring to — at a guess, “Web Sharing”, which I don’t do, seems a likely suspect — but that may be the explanation for the commenters reporting vulnerability and me not seeing it on my system (either in /bin/bash or in /bin/sh)…

The vast majority of OS X users are not at risk to recently reported bash vulnerabilities,” an Apple spokesperson told iMore. “Bash, a UNIX command shell and language included in OS X, has a weakness that could allow unauthorized users to remotely gain control of vulnerable systems. With OS X, systems are safe by default and not exposed to remote exploits of bash unless users configure advanced UNIX services. We are working to quickly provide a software update for our advanced UNIX users.”

UPDATE, 2014-10-01: Apple has put out a patch for OS X systems.