As important as securing direct access to our WordPress sites is securing indirect access to the application via the server. Here's the deal.
We can figure out the attack routes easily enough because we use them too: server login, FTP, MySQL clients like phpMyAdmin and control panels are all targets for brute-force password attacks and, just like the more obvious WordPress wp-login.php page, these need toughening up.
So far as the server goes, as we find in wpCop's Server section, there's a whole lot more to securing the thing than creating a secure login process. This, though, is the natural starting point.
So what's the difference between server login and control panel login? The control panel is simply a software package, a set of tools that helps us to tweak settings and run tasks in a user-friendly way. The control panel sits on the server, just like other helpful GUIs such as file browsers (for instance, FileZilla) or database managers (for instance, phpMyAdmin).
Hush it up with SSH
For the most direct server manipulation we use a terminal, a console, a shell, a command line interface (CLI) or whatever else it's called today. We tap out commands locally that are enacted remotely. This tool gives us the greatest flexibility to build and maintain sites and the underlying technologies that make them work. With power comes responsibility.
If we can access the server, generally messing it up, who else can?
Cue SSH.
SSH stands for Secure Shell and that's just what it does, using a kind of revamped SSL protocol to shield or tunnel our terminal logon and dataflow. SSH can be tweaked so tight it squeaks, and we'll be doing that in the Cop's Harden SSH guide. For now though we'll crack out the basics, setting it up so that we have a properly encrypted server connection to work with.
Shared hosting SSH request
Shared types will have to request direct server access and this will be provided using SSH. You can often do this in cPanel easily enough:
cPanel > Account Addons > SSH Activation Request > submit your email
Then again, you could just shortcut that palaver altogether and submit a ticket, else jump the queue by making a live chat request. (Hey, you didn't hear it here.)
Once authorized, you're halfway there. You need to set up a terminal locally, so skip down to the ingeniously titled Setting up the Terminal Locally for how to do that. With the local terminal in place, connect remotely by typing a command like this:
And here's what that means:
- ssh – the protocol to use
- -p – you need to add this and the port number only if the server is accessed using a non-default port (that is, not the SSH default port 22). Your web host will tell you if you need this
- 54321 – if the port isn't 22 then provide the non-default port
- username – your server handle, often matching the control panel username
- @123.45.67.890 – at your IP address (your control panel tells you what that is)
When you connect for the first time, you'll be asked to verify that the destination is safe. Do. Then you are prompted for your shared hosting account password and, hey presto, what on earth do you do now that you're in? Damn, where to start! Carry on.
Setting up the terminal locally
This varies from system to system. Let's cover the bases.
Securing the terminal
As with SSL, packet sniffing is no real concern when we use SSH because it would take so long to decrypt our encrypted data. Put it this way, we'll all be dead first and the hacker would need a medium. That said, with bots hacking away, automated, brute force password cracking remains an issue.
… To deflect that risk we enhance SSH by using authentication keys and denying password login. Here's how. You get a key, the server gets a key, the keys have to tally and then you're in. Otherwise, hack off! You can use your key from anywhere by thumbdriving it. Sweet.
There are three steps to setting this up. Creating the keys, uploading one to the server, and telling the server to refuse passwords. Here we go.
Using keys from multiple machines
Ah yes, you were wondering about this, huh? Well, yes you can.
Referring back to the Portable applications section of Stay Safe on a Shared Computer, you can carry an SSH client on a thumbdrive along with your local, private key, logging in with that from anywhere.
… So hey, no excuses, blog from the pub, go sshssh a bit and don't spill the beer. 😛
Other than for tightening SSH which we'll be doing in Harden SSH the Secure Shell for Safe Server Access, that's the server login properly defended and with our data protected en route.
Praise be. Have a cigar.