Skip to main content

You are here

WordPress

Locking Down WordPress Access with Varnish 3.x

I have Varnish in front of all my WordPress sites and configured all /wp-admin traffic use https via Nginx. See https://www.rubysecurity.org/wordpress_admin-ssl

So to lock down access to my WordPress site's requires both Varnish and Nginx configs to be modified.

Block at the http Varnish level:

sub vcl_recv {
    if ((req.url ~ "wp-(login|admin)") && (client.ip !~ MY-IP-ADDRESS)) {
                error 403 "Fuck off";
        }
}

Block at the https Nginx level (using shit.alpha01.org as an example):

                location /wp-admin {
                        allow   MY-IP-ADDRESS;
                        deny all;
                        proxy_pass https://shit.alpha01.org/wp-admin;
                        proxy_set_header X-Real-IP $remote_addr;
                        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                        proxy_set_header Host $http_host;
                }
                location /wp-login.php {
                        allow MY-IP-ADDRESS;
                        deny all;
                        proxy_pass https://shit.alpha01.org/wp-login.php;
                        proxy_set_header X-Real-IP $remote_addr;
                        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                        proxy_set_header Host $http_host;
                }

Linux: 

Awesome Applications: 

Securing the WordPress Admin Dashboard

So the primary reason why I wanted to add SSL support to www.rubyninja.org is because I want all my /wp-admin traffic to be served securely.

Configuring WordPress to force the login page and all wp-admin traffic to be served over SSL is simply just a matter of defining the FORCE_SSL_LOGIN and FORCE_SSL_ADMIN constants in wp-config.php

define( 'FORCE_SSL_LOGIN', true );
define( 'FORCE_SSL_ADMIN', true );

Programming: 

Awesome Applications: 

Varnish WordPress Performance Testing

Thanks to my new job, I've been working a lot with Varnish. Man, Varnish is one kick ass HTTP web accelerator! A few months back I ran a few performance Apache performance tests on my WordPress site with different layers of caching enabled:
https://www.rubysecurity.org/php_xcache
https://www.rubysecurity.org/apache_stress-testing

So now I wanted to see how the results may differ using Varnish.

Configuration:
At a bare minimal, Varnish needs to be configured to remove cookies set by WordPress in order to make the content cacheable.

sub vcl_recv {
  # Drop any cookies sent to Wordpress.
  if (!(req.url ~ "wp-(login|admin)") && req.http.host ~ "rubyninja.org") {
    unset req.http.cookie;
  }
}

sub vcl_fetch {
  # Drop any cookies Wordpress tries to send back to the client.
  if (!(req.url ~ "wp-(login|admin)") && req.http.host ~ "rubyninja.org") {
    unset beresp.http.set-cookie;
  }
}

With this configuration enabled, I ran the same identical ab tests that used to benchmark my server previously.

[[email protected] ~]# ab -n 1000 -c 5 http://www.rubyninja.org/index.php
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking www.rubyninja.org (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Finished 1000 requests

Server Software: Apache/2.2.15
Server Hostname: www.rubyninja.org
Server Port: 80

Document Path: /index.php
Document Length: 0 bytes

Concurrency Level: 5
Time taken for tests: 39.528015 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Non-2xx responses: 1001
Total transferred: 374139 bytes
HTML transferred: 0 bytes
Requests per second: 25.30 [#/sec] (mean)
Time per request: 197.640 [ms] (mean)
Time per request: 39.528 [ms] (mean, across all concurrent requests)
Transfer rate: 9.23 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 87 100 134.1 93 3092
Processing: 88 95 10.7 91 220
Waiting: 87 94 10.6 90 218
Total: 177 196 134.4 186 3183

Percentage of the requests served within a certain time (ms)
50% 186
66% 192
75% 196
80% 199
90% 207
95% 217
98% 234
99% 251
100% 3183 (longest request)

The requests per second handled by the webserver weren't much different from the caching layer that I already had enabled previously, which is the WordPress W3 Total Cache plugin configured with Page, Database, Object, and Browser cache enabled using APC, and mod_pagespeed.

However the huge difference is that all requests never reached the Apache backend. Varnish cached all content and served all the requests directly. Varnish is just fucking awesome.

Awesome Applications: 

PHP: XCache performance testing

Aside APC, as far as I know XCache is the second most popular PHP caching optimizer. So I manually compiled and installed XCache on my www.rubyninja.org VM and configured the WordPress W3 Total Cache plugin to use the XCache optimizer and ran the same benchmarks test that I did when APC was enabled.

After a few tests, the total requests per second was around 24-25 seconds. Slightly slower than APC. However, unlike APC, I noticed that with XCache the overall server load was less (peak at about 3.3), in addition the I/O system activity also appeared to be less than with APC.

Concurrency Level: 5
Time taken for tests: 40.740110 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Non-2xx responses: 1000
Total transferred: 351000 bytes
HTML transferred: 0 bytes
Requests per second: 24.55 [#/sec] (mean)
Time per request: 203.701 [ms] (mean)
Time per request: 40.740 [ms] (mean, across all concurrent requests)
Transfer rate: 8.39 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 6 134.1 0 3000
Processing: 99 196 25.6 200 297
Waiting: 98 196 25.6 199 297
Total: 99 202 136.9 200 3209

Percentage of the requests served within a certain time (ms)
50% 200
66% 209
75% 214
80% 216
90% 222
95% 227
98% 234
99% 241
100% 3209 (longest request)

Programming: 

Awesome Applications: 

Apache stress testing

As I didn't have anything much better to do a Sunday afternoon, I wanted to get some benchmarks on my Apache VM that's hosting my blog www.rubyninja.org. I've used the ab Apache benchmarking utility in the past to simulate high load on a server but have not used it on benchmarking Apache in detail.

My VM has a single shared Core i5-2415M 2.30GHz CPU with 1.5 GB of RAM allocated to it.

I based made my benchmarks using a total of 1000 requests with 5 concurrent requests at a time.

ab -n 1000 -c 5 http://www.rubyninja.org/index.php

Results:
Using just the mod_pagespeed Apache module enabled.

Time taken for tests: 154.687976 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Non-2xx responses: 1000
Total transferred: 351000 bytes
HTML transferred: 0 bytes
Requests per second: 6.46 [#/sec] (mean)
Time per request: 773.440 [ms] (mean)
Time per request: 154.688 [ms] (mean, across all concurrent requests)
Transfer rate: 2.21 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 3
Processing: 328 772 46.4 772 1040
Waiting: 327 771 46.4 772 1040
Total: 328 772 46.4 772 1040

Using mod_pagespeed and APC enabled.

Time taken for tests: 41.355400 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Non-2xx responses: 1000
Total transferred: 351000 bytes
HTML transferred: 0 bytes
Requests per second: 24.18 [#/sec] (mean)
Time per request: 206.777 [ms] (mean)
Time per request: 41.355 [ms] (mean, across all concurrent requests)
Transfer rate: 8.27 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 6 134.1 0 3000
Processing: 88 199 28.4 202 459
Waiting: 88 199 28.4 201 459
Total: 88 205 137.2 202 3208

Using the WordPress W3 Total Cache plugin configured with Page, Database, Object, and Browser cache enabled the APC caching method and mod_pagespeed.

ime taken for tests: 37.750269 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Non-2xx responses: 1000
Total transferred: 351000 bytes
HTML transferred: 0 bytes
Requests per second: 26.49 [#/sec] (mean)
Time per request: 188.751 [ms] (mean)
Time per request: 37.750 [ms] (mean, across all concurrent requests)
Transfer rate: 9.06 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 5 133.9 0 2996
Processing: 74 181 26.6 185 315
Waiting: 74 181 26.6 184 314
Total: 74 187 136.4 185 3178

As you can see, APC is the once caching method that makes a huge difference. Without APC, the server response time was just 6.46 requests per second and the load average peaked at about 12, while with the default APC configuration enabled, the server response time was 24.18 requests per second, with a load average peaking about 3. Adding the W3 Total Cache WordPress plugin helped performance slightly more, from 24.18 requests per second to 26.49 requests per second (load was about the same, including I/O activity). One interesting thing that I noticed is that with caching enabled, that is APC, the I/O usage spiked considerably. Most notably, MySQL was the high cpu usage process when doing the benchmarks. Since the caching is based in memory at this point it appears that the bottleneck in the web application is MySQL.

Programming: 

Awesome Applications: 

Custom WordPress auto update via FTP

When I originally migrated my blog off GoDaddy, one of the things that stopped functioning was the WordPress auto update feature. Luckily, I was able to easily overcome this using my own custom FTP settings. For its simplicity, I used vsftpd.

Install:

yum install vsftpd
chkconfig vsftpd on

Configure vsftpd to jail FTP users to their home directory in /etc/vsftpd/vsftpd.conf :

chroot_local_user=YES

Restart vftpd:

/etc/init.d/vsftpd restart

Now, I'll create the user that will be used to download and install the WordPress auto updates. :

useradd -d /PATH/TO/WORDPRESS/SITE -G apache -s /sbin/nologin apache_ftp_user
passwd apache_ftp_user

Before applying an update, update your permissions:

chown -R apache_ftp_user:apache /PATH/TO/WORDPRESS/SITE

Now use apache_ftp_user username and password on the WordPress FTP connection wizard page:

WordPress FTP Connection Information

Awesome Applications: 

Premium Drupal Themes by Adaptivethemes