Hacker News Reader

Comment by falcolas | Hacker News Reader

A few free safety and performance tips when dealing with wordpress:

- Whitelist IPs for access to your wp_admin and wp_login.

- If you have the skills to automate WordPress updates yourself, remove all write access (except for the uploads folder) from the user WordPress is running as (i.e. www-data). It's all just unzip and untar over the structure of the directory anyways.

- If you remove write access, you might as well block the "cron" as well.

- Limit the WordPress DB user to the usual crud operations; don't let it create or alter tables.

- If you feel like getting really into it, whitelist explicit URLs. Maintaining it isn't really too hard, and it reduces your attack surface significantly.

- Set up even a simple nginx cache in front of WordPress - even a 1-5 minute cache will let your site run on crappy hardware and handle HN or Reddit with a minimum of sweat.

View on HN

May I add a very general tip for web servers? Mount /tmp on its own volume and set the noexec mount flag.

I've seen too many old php apps fall due to files uploaded and executed from /tmp. Bulletin boards, blogs, but this was all 8 years ago.

Never occurred to me to do this. That's actually a great idea.

Good tip. If you'll excuse me, I'm going to go make a Jira ticket now...

  nodev,noexec,nosuid

is how I've mounted /tmp (and several others) for going on two decades. I've never been a fan of installers creating a single partition by default and I wish they didn't do it.

Years ago, like you, I saw an out-of-date web app get hit by an exploit but was "saved" because of some of those mount options.

I'm a big fan of SELinux on public-facing servers too (especially web servers, for the same reason), but that's an argument for another day.

I wanted to add nosuid too but I kept it simple, thanks for adding your own two cents.

Edit: Also a big fan of SElinux, high five!

I'd also recommend looking into Bedrock, as it neatly sets you up for updating via Composer, which is quite nice once you get used to it. Good thing to fire off on a post-deploy hook. Then you can completely disable any internal updates and completely control the version of core and plugins.

The folder structure also adds some minor security through obscurity.

There are other niceties in there too.

Thanks for the suggestion. Looks interesting. Link for others: https://roots.io/bedrock/

Another safety tip: don't install any plugins unless you're very, very sure that they're safe. Most security problems with WordPress originate in badly written plugins, not in the core product.

If you're not going to install plugins, doesn't it neuter one of the big draws to using WordPress in the first place? Ideally there would be better separation between the plugin and core stuff, but oh well.

I usually only install one or two plugins on client sites. The main draw is the fairly good interface and the extremely wide brand familiarity.

If you know what you're doing with it, it can be a very nice admin experience.

That may be so, but if all you want is a nice interface I think there are lots of non-WordPress options.

I understand the security ramifications of altering tables, but why restrict create?

Somebody maliciously making thousands of MySQL tables in your DB as some sort of DoS?

Some plugins create their own tables.

Another safety tip, don't use 'admin' as the administrator username, and don't have any posts associated with the administrator as an author.

As for the cache Cloudflare's free tier as allowed me to handle pretty large traffic loads in the past, much more then my $5 droplet should be able to handle. This was for a blog platform I wrote in Flask though(and optimized for cloud flare) so it might not be comparable.

Yup - it's the same concept, different application. Anything that reduces the need to run code will help with the performance of your blog.

Do you have a more in depth tutorial about this? Thanks

Afraid not - company secrets and all that.

That said, the steps above are the broad painting of exactly what we've done, and a few Google searches will help nail down the specifics.

Re: caching, wp-supercache works pretty good too.

My only concern there is that `wp-supercache` is a plugin, so you're still having to spin up php and work through the WordPress core just to get to the point where you can serve the files out of that cache.

It's likely better than no cache, but an external cache will be much more efficient under load.

It can use mod rewrite to avoid most of that.

I see, write the static files down a directory and have Apache serve them.

What's the benefit over a straight use of mod_cache or mod_file_cache then?

Mostly that it's a wordpress plugin that a non-administrator can install. Like on a cheap shared hosting setup, where they have no way to alter the apache setup.

Reply on news.ycombinator.com