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, 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:


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.


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/


Stack changes for k0nsl

I am again experimenting with the Cherokee [1] web server in my stack for k0nsl.org — it currently handles the PHP backend of it all, which so far seems to be working quite nice. Nginx is used as frontend and for most static files, finally Apache2 is used for miscellaneous tasks. The last time I used Cherokee for my projects was briefly in October of last year (2012).

I will investigate more as time goes on, but it looks as if I will be using Cherokee permanently in the stack.


1. Cherokee is a flexible, very fast, lightweight Web server. It is implemented entirely in C, and has no dependencies beyond a standard C library. It is embeddable and extensible with plug-ins. It supports on-the-fly configuration, TLS/SSL, virtual hosts, authentication, cache friendly features, PHP, custom error management, several load balancing policies, database balancing, and much more. Check out their Github for more information: https://github.com/cherokee/webserver/


Cdorked.A Inspector

Below is a tool written by Marc-Etienne M.Léveillé of ESET to check for the existence of Linux/Cdorked.A [1]

// This program dumps the content of a shared memory block
// used by Linux/Cdorked.A into a file named httpd_cdorked_config.bin
// when the machine is infected.
// Some of the data is encrypted. If your server is infected and you
// would like to help, please send the httpd_cdorked_config.bin
// and your httpd executable to our lab for analysis. Thanks!
// Build with gcc -o dump_cdorked_config dump_cdorked_config.c
// Marc-Etienne M.Léveillé

#include <stdio.h>
#include <sys/shm.h>

#define CDORKED_SHM_SIZE (6118512)
#define CDORKED_OUTFILE "httpd_cdorked_config.bin"

int main (int argc, char *argv[]) {
    int maxkey, id, shmid, infected = 0;
    struct shm_info shm_info;
    struct shmid_ds shmds;
    void * cdorked_data;
    FILE * outfile;
    maxkey = shmctl(0, SHM_INFO, (void *) &shm_info);
    for(id = 0; id <= maxkey; id++) {
        shmid = shmctl(id, SHM_STAT, &shmds);
        if (shmid < 0)
        if(shmds.shm_segsz == CDORKED_SHM_SIZE) {
            // We have a matching Cdorked memory segment
            printf("A shared memory matching Cdorked signature was found.\n");
            printf("You should check your HTTP server's executable file integrity.\n");
            cdorked_data = shmat(shmid, NULL, 0666);
            if(cdorked_data != NULL) {
                outfile = fopen(CDORKED_OUTFILE, "wb");
                if(outfile == NULL) {
                    printf("Could not open file %s for writing.", CDORKED_OUTFILE);
                else {
                    fwrite(cdorked_data, CDORKED_SHM_SIZE, 1, outfile);
                    printf("The Cdorked configuration was dumped in the %s file.\n\n", CDORKED_OUTFILE);
    if(infected == 0) {
        printf("No shared memory matching Cdorked signature was found.\n");
        printf("To further verify your server, run \"ipcs -m -p\" and look");
        printf(" for a memory segments created by your http server.\n");
    else {
        printf("If you would like to help us in our research on Cdorked, ");
        printf("please send the httpd_cdorked_config.bin and your httpd executable file ");
        printf("to our lab for analysis at eset.com. Thanks!\n");
    return infected;

1. Linux/Cdorked.A: New Apache backdoor being used in the wild to serve Blackhole


Free hosting

You can apply for free web hosting here. What you will get PHP/MySQL/cPanel access, with more details in welcome e-mail.

NOTE: I don’t accept more clients, at the moment.


Content that will be automatically removed if found on my server:

  • Paedophilia
  • Homosexuality

Everything else is allowed as per UN’s Declaration of Human Rights (specifically “article 19”) .