0

Locking Down WordPress WP-Admin

I’m pretty sure every WordPress [1] user out there has read much about different ways to limit access to the WordPress administration back-end (WP-Admin), and many of them are certainly good. My way is quite simple, although it most likely has a couple of penalties and some pitfalls I’m not yet aware of, but I can live with it.

My procedure of locking down the WP-Admin area consists of running Nginx [2] on a dedicated port (whichever port you prefer) bound to a internal/private/local IP address (i.e 127.0.0.1, 192.168.0.1 et cetera), configured with PHP-FPM, coupled with Apache2 as the front-end (with mod_proxy [3] enabled) to serve and process all requests to the WordPress administrative back-end. The requests are proxied to the Nginx instance via Apache. This configuration effectively translates to the following: I only keep Nginx running whenever I access the administration back-end of WordPress (WP-Admin), and when I’m done, I simply shutdown Nginx. Simple. The end result is that nobody will be able to access the WP-Admin area if Nginx isn’t running.

The only issues I have run into so far is that static resources are not being served properly, but that should be easy a fix. I’m looking into it.

Try accessing the WP-Admin area of k0nsl.org and see the result:
https://k0nsl.org/blog/wp-admin/

k0nsl-backend-down01

Everything in “/blog/wp-admin” results in a 503 ‘Service Temporarily Unavailable’ (check the headers with “curl -I https://k0nsl.org/wp-admin”) because Nginx is shutdown. It certainly is a simple solution; but it works

This configuration above coupled with various other tweaks (such as the CloudFlare-Country-Login [4]) makes WordPress a bit more secure to use.

Update: 11.21.13

I solved the assets issue not being served properly JS too; Earlier, I had accidentally forgot to enable Javascript concatenation by commenting out CONCATENATE_SCRIPTS define in wp-config.php. Everything works perfectly right now.

Notes

1. WordPress: Blog Tool, Publishing Platform, and CMS -> http://wordpress.org/
2. Nginx: The High Performance Reverse Proxy, Load Balancer, Edge Cache, Origin Server -> http://nginx.com/products/
3. Apache Module mod_proxy -> http://httpd.apache.org/docs/2.2/mod/mod_proxy.html
4. WordPress: CloudFlare-Country-Login -> https://k0nsl.org/blog/wordpress-cloudflare-country-login/

0

Hide Google+ Goobly Gook from WP-Jetpack

I was annoyed with the injection of my Google+ details beneath every post when I activated the ‘Google+ Profile’ option in the WordPress plugin Jetpack [1] and couldn’t find any option to actually hide it entirely or change it’s placement. So I hacked it away, effectively hiding it, using a simple divider.
Like so:
wp-jetpack-gplus-authorshop01_k0nsl
You will want to jump to line 189 [2] in the file ‘gplus-authorship.php’ located in a subfolder of Jetpack (in effect: modules).
I do know it is possible to toggle it with the option ‘Show Google+ infomation with this post’. Perhaps the best practice would be to just remove the entire code block. Probably.
The authorship relation tag is not affected by this.

Here’s a gist of it:

$output = '';
$output .= '<div style="display:none" id="k0nsl">';
$output .= '<div class="sharedaddy sd-block sd-social sd-gplus">';
$output .= '<h3 class="sd-title">' . __( 'Google+', 'jetpack' ) . '</h3>';
$output .= '<div class="sd-content">';
$output .= $this->byline( $post );
$output .= $this->follow_button( $post );
$output .= '</div>';
$output .= '</div>';
$output .= '</div>';

Notes

1. Jetpack by WordPress.com http://wordpress.org/plugins/jetpack/
2. Exact position in pico: 189/209 (90%), col 1/30 (3%), char 6562/7082 (92%)