Post-WWDC thoughts

... my general impression about where Mac OS is going is that Apple wants to turn it into a sort of low-maintenance system. The pretext is security: lock down this and that because it could be exploited; remove this and that because it’s code we can’t be bothered to update or optimise, it could potentially represent a vector for an attack, blah blah. Meanwhile, let’s also use these security measures to make the life of the already stressed-out Mac developers even harder.

In 30 years as a Mac power user, what I have been appreciating about Mac software was the ability to think and act outside the box, so to speak. In recent times, Apple seems hell-bent on keeping Mac software inside the box. The walled-garden model and paranoid security made and make definitely more sense on mobile systems. I appreciate being able to look for and install apps on my iPhone that won’t mess with my device or present a security risk for the operating system or for me as a user (although Apple hasn’t done a great job at keeping scams away from the App Store); but on the Mac I want to have more freedom of movement. I’m an expert user, I know the risks involved. Let me tinker. Give the option to have a locked-down Mac for novice users who expect to use it like an appliance, or in the same way they use their phones and tablets. Leave the ‘root’ door open for those who know what they’re doing.

Ditto!!!

To be clear. I like my Apple devices. I spend thousands of dollars on Apple products for my family and me. I have the right to complain where I think things are not meeting my expectations. Apple is not infallible.

Since Apple can’t be bothered to update the open-source components of their OS, I am happy they will be removing deprecated software. It is better to see the kids placed into foster care, then watch them be abused and neglected by their parents.

It’s getting a lot harder to defend Apple’s action. Many long-time Mac users that I know — I was the president of the Princeton Macintosh Users Group for about five year - and macOS developers, are not happy. I don’t think the concerns of this user base should be dismissed with a wave of the hand. It tends to get people angry when they feel like they are being told their concerns are irrelevant.

I switched to the Mac platform (from Windows) before it was cool. I switched because OS X was UNIX and because it had a usable GUI and I could run well built commercial software and use (or write) open-source software. OS X was open and I could tinker to my heart's content.

It feels to me that with each release, the *NIX part and the openness is being deprecated.

The on-line hacker Jargon File, version 4.1.5, 24 SEP 1999 (catb.org)

:fscking: /fus'-king/ or /eff'-seek-ing/ adj. [Usenet; common]

Fucking, in the expletive sense (it refers to the Unix filesystem-repair command fsck(1), of which it can be said that if you have to use it at all you are having a bad day). Originated on {scary devil monastery} and the bofh.net newsgroups, but became much
more widespread following the passage of {CDA}. Also occasionally
seen in the variant "What the fsck?"

40 years of hacker culture in one document.

Welcome by an author (Daniel Brinneman)

The first line of defense in all of hosting and following sections I’ll write about, this being a subtle ‘zero’ or the least thought about topic of consideration, is your choice of usernames and passwords. I’ve had way too many clients always default to these two habits. The first is choosing a username that the whole of WordPress new sites used to have on install, ‘admin’ (no longer the case) and second, choosing a password that was easy for them to remember from anywhere. And then using that same combination on every single online account they had, even their personal accounts. Yikes! And even after I had generated a secure password for them, they changed it to something “easier” to remember. That always makes me feel extremely uneasy because I already can guess what’s in their site’s future. I have my clients’ best interest in mind when I generate those cumbersome passwords.

Update: Daniel moved his content to a new domain. This fixes a broken link. Let's hope I don't have to do this again.

Fellow, Desk.pm user, Daniel Brinneman recent wrote an article on how to harden a WordPress website. Daniel's piece is well written and covers the basics. Please visit his site.

While Daniel and I use basically the same process I wanted to cover the personal process I used for securing my WordPress websites. For brevity, I didn't go into detail about how to carry out each step. I may cover these steps in a later article.

Hosting Provider

Let's start with the hosting provider. I want one that is reliable, available and secure. I use a non-shared virtual private server (VPS) hosting plan with Digital Ocean1. Digital Ocean calls these droplets. Digital Ocean has multiple data centres in multiple locations globally offering five popular Linux distributions that can be automatically pre-installed upon deployment of a server: Ubuntu, CentOS, Debian, Fedora, and CoreOS. While I can certainly build my web server stack from scratch I trust the staff at Digital Ocean. I opt to use one of their pre-packaged LAMP/WordPress stacks.

Each digital ocean SSD VPS comes with full root access, a choice of operating systems, and the ability to customise the configuration. With a shared hosting plan, I would be concerned that a compromise on another tenant's account could lead to a compromise of the entire host. With a dedicated VPS, I can configure as much or as little security as I consider acceptable.

Operating System Hardening

On a *NIX system, the root user is the administrative user that has very broad privileges. Because of the heightened privileges of the root account, I would discourage regular use of the root account. This is because part of the power inherent with the root account is the ability to make very destructive changes, even by accident.

Since, with root, I have complete control of the system, I start my hardening process at the operating system level by immediately changing the root password after the server is created. I choose a long and complex password but something that I can also remember. I then create a new non-root account and add it to the sudoers file. Using the new account (via sudo) I change the server SSH configuration to disable root access to SSH, create 4096 bit SSH keys for remote authentication, then disabling and removing any unneeded services, and then install and configure file integrity monitoring software. Next, I harden the web server. I generate and install TLS (not SSL) certificates, configure the web server with forwarding Secrecy, OCSP stapling, Public Key Pinning (HPKP) and Strict Transport Security (HSTS).

Server Services

One I complete work on the web server it is time for MySQL and WordPress. I change the MySQL database password, run the MySQL security script to remove all defaults etc.. I then login to WordPress and create a new admin account -- again with a suitably long randomly generated password -- before deleting the old admin account. I then install and configure a web application firewall with specific rules around the wp-admin URL and when to alert me. I then install a WordPress security audit plugin with rules about acceptable actions and when to alert me. I then delete all default posts and pages.

Just a Bit More

Finally, I configure CloudFlare or some other content delivery network to help with any denial of services issues. Most of these also offer a web application firewall and robust analytics.

From a security operations perspective, I use the VaultPress service to do daily backups and I check to make sure backups are complete. I have a weekly reminder in my calendar to check the Linux server and the WordPress install for security patches and to check my server logs.

I also perform my vulnerability scanning using various open source tools.

I only install plugins and themes from reputable sources. I try to reduce the use of plugins as much as possible to mitigate the risk of exploitation. Plugin updates are part of my regular weekly security checks.

If you need help implementing these WordPress security tips, I am available for hire.

This post was syndicated to How to Secure a new Linux WordPress Server.


  1. Use my referral link to get a discount on Digital Ocean when signing up, and help me keep my site going. ?