Skip to main content

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: 

Locking Down Drupal Access with Nginx

This site is powered by Drupal. Drupal and WordPress for that matter, are well targeted platforms, mainly because of their large install base on the internet. Quite frankly the reason I bother using both Drupal and WordPress instead of a flat-file based CMS is because I have to deal with these web applications at work on a daily basis, so it's a great way to keep myself current with the technology that's paying my bills.

I have Nginx acting as an SSL proxy for www.rubysecurity.org, which is hosted on an Apache back-end. So I have a few configs that I've enabled to lock down access to my Drupal site. The configs are made at the Nginx proxy level, so they can never reach Apache.

Firstly, I have all of Drupal's /admin locked out from outside access:

        location = /admin {
                allow MY-HOME-IP-ADDRESS;
                deny all;
                return 403;
        }

Next, I only allow login access from my home ip address:

        location = /user {
                allow MY-HOME-IP-ADDRESS;
                deny all;

                proxy_pass https://www.rubysecurity.org/user;
                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;
        }

Lastly, since Nginx is unable to process query strings at the location block level, I've setup an additional config to drop all user login query requests.

       if ($args ~* "q=user") {
                set $blockme  M;
        }
        if ($remote_addr != MY-HOME-IP-ADDRESS) {
                set $blockme  "${blockme}E";
        }
        if ($blockme = ME) {
                return 403;
       }

Linux: 

Awesome Applications: 

My Home Lab Network Diagram

It's Friday night, I don't have anything interesting to do, so I created a diagram of my current home lab setup.

Home Lab Network Diagram

Grepping for PHP system level command functions

grep --color -r -E -e '(escapeshellarg|escapeshellcmd|exec|passthru|proc_close|proc_get_status|proc_nice|proc_open|proc_terminate|shell_exec|system)(\s+)?\(' ./

Programming: 

Setting up Graphite on CentOS 6.x gotcha

I installed graphite-web via the EPEL repo, and I was getting an 500 error when accessing the Graphite web interface.
Error log:

[Sat Sep 12 00:56:27 2015] [error] [client 192.168.1.21] mod_wsgi (pid=17318): Exception occurred processing WSGI script '/usr/share/graphite/graphite-web.wsgi'.
[...]
[Sat Sep 12 00:56:27 2015] [error] [client 192.168.1.21] File "/usr/lib/python2.6/site-packages/django/db/backends/sqlite3/base.py", line 344, in execute
[Sat Sep 12 00:56:27 2015] [error] [client 192.168.1.21] return Database.Cursor.execute(self, query, params)
[Sat Sep 12 00:56:27 2015] [error] [client 192.168.1.21] DatabaseError: attempt to write a readonly database

Fix: It turns out the sqlite3 database file Graphite write's too, was own by root. So it was simply a matter of updating the ownership to what ever user Apache is running under, in my case it's apache.

chown -R apache.apache /var/lib/graphite-web/

Linux: 

Awesome Applications: 

VirtualBox: Increase guest VM CPU count

Syntax
VBoxManage modifyvm <VMNAME> --cpus <CPUcount>

[email protected]:~$ VBoxManage showvminfo monitor | grep "Number of CPUs"
Number of CPUs: 1
[email protected]:~$ VBoxManage modifyvm monitor --cpus 3
[email protected]:~$ VBoxManage showvminfo monitor | grep "Number of CPUs"
Number of CPUs: 3

Awesome Applications: 

BIND - Slave zone transfer stopped working

I was surprised to see that a typo fucked up caused all slave transfers to shit themselves. I came across a situation where a new slave zone was specified to a non-existing location in the file system and that caused the rest of the slave zones to get permission denied errors when trying to update.

Logs

Jul 12 03:23:27 ns2 named[1184]: dumping master file: etc/zones/tmp-Zbk9acg9uv: open: permission denied
Jul 12 03:27:50 ns2 named[1184]: dumping master file: etc/zenos/tmp-4yxBXaUMTq: open: file not found
Jul 12 03:29:46 ns2 named[1184]: dumping master file: etc/zones/tmp-KPqzHa9ev9: open: permission denied
Jul 12 03:38:02 ns2 named[1184]: dumping master file: etc/zones/tmp-kuhtUPjcAi: open: permission denied

Awesome Applications: 

Running my own Git server: GitList

For the longest time I've been wanting to streamline updates to my sites, ie. implement good software deployment technique and procedures. To be specific, start using Git for source code management, and Jenkins to deploy. No, I'm not drinking the whole Agile Kool-Aid. After all we're in 2015, and people who still continue to use FTP/SFTP to push out changes to their sites should really need to be practicing more long term sustainable procedures. Setting up a git server is really simple. See https://www.rubysecurity.org/ansible-git

Git workflow:
I prefer to only communicate with Git over ssh and not https. Since I don't use the default ssh port, the initial repository clone looks like this:

git clone ssh://[email protected]$GIT-SERVER:$SSH-PORT/home/git/$REPO

GitHub has become the defacto Git hosting provider. I think much of it's success, aside from the fact that Git is an amazing piece of software, is GitHub's polished web user interface. While Git ships with a daemon that provides a visual look at the repositories, it's definitely not pretty. I wanted to have a local GitHub like interface on my private git repos, so I decided to use GitList. GitList is fairly minimalistic. Requiring just PHP and mod_rewrite, it allows you to browse your repositories, view files under different revisions, commit history and diffs. Configuring GitList is really easy.

git clone https://github.com/klaussilveira/gitlist.git
cd gitlist
chmod 777 cache
mv config.ini-example config.ini

Then update config.ini to point to the location where the Git repositories are stored in the server. On my server, they're located in /home/git.

repositories[] = '/home/git/' ;

Lastly, is just configuring the web server's virtual host. Since I use Apache mine looks like this.

<VirtualHost 192.168.1.16:443>
        ServerName git.rubyninja.org
        ServerAlias git.rubyninja.org

        DocumentRoot /var/www/gitlist

        <Directory "/var/www/gitlist">
                AllowOverride All
                AuthType Basic
                AuthName "Git Repos"
                AuthUserFile /home/svn/.htpasswd
                Require valid-user
        </Directory>

        SSLEngine on
        SSLCertificateFile /etc/httpd/certs/svn.rubyninja.org.crt
        SSLCertificateKeyFile /etc/httpd/certs/svn.rubyninja.org.key
        SSLCACertificateFile /etc/httpd/certs/rubyninjaCA.crt

        ErrorLog logs/git_ssl_error_log
        CustomLog logs/git_ssl_request_log \
                "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
</VirtualHost>

GitList
GitList

Programming: 

Awesome Applications: 

Git Ansible Playbooks

One of the reasons I love Ansible over any other config management tool is because of its simplistic design and ease of use. It literally took me less than 15 minutes to write a set of playbooks to manage my local git server.

git_server_setup.yml - configures base server git repository configuration.

---
- hosts: git
  tasks:
  - name: Installing git package
    yum: name=git state=latest

  - name: Creating developers group
    group: name=developers state=present

  - name: Creating git user
    user: name=git group=developers home=/home/git shell=/sbin/nologin

  - name: Updating /home/git permissions
    file: path=/home/git mode=2770

create_git_user.yml - creates local system git user accounts.

---
- hosts: git
  tasks:

  - name: Creating new git user
    user: name={{ user_name }} password={{ user_password }} home=/home/git shell=/usr/bin/git-shell group=developers

  vars_prompt:
  - name: "user_name"
    prompt: "Enter a new git username"
    private: no

  - name: "user_password"
    prompt: "Enter a password for the new git user"
    private: yes
    encrypt: "sha512_crypt"
    confirm: yes
    salt_size: 7

create_git_repo.yml - creates an empty bare git repository.

---
- hosts: git
  vars:
    repo_name: www.alpha01.org

  tasks:
  - file: path=/home/git/{{ repo_name }} state=directory mode=2770

  - name: Creating {{ repo_name }} git repository
    command: git init --bare --shared /home/git/{{ repo_name }}

  - name: Updating repo permissions
    file: path=/home/git/{{ repo_name }} recurse=yes owner=git

Awesome Applications: 

Server Move and Upgrades!

My little corner of the internet has a new home. My old $29.99 8GB RAM, 3.40GHz Intel Core i3 dedicated server was simply not enough to handle my server needs. Which apparently OVH doesn't even provide that service anymore. So instead I hoped to their mid-tear dedicated service service branch they call So you Start. I opted with their $49.00 SYS-IP-2 service. Now my server's specs is a follows:

  • 2.66 GHz+ Intel Xeon W3520 (4 cores/ 8 threads)
  • 32 GB ECC
  • 2 x 2 TB SATA drives (Software RAID)

I would've love the drives to be SAS and the RAID to be hardware based, but it's definitely not a deal breaker, and just $49.99 a month, it's not much to complain about.

CentOS 6 to CentOS 7 upgrade:
My server migration was fairly straight forward for the most part. I opted to re-create the KVM hypervisor and its guests from scratch. Mainly because I wanted to upgrade all of guests and host from CentOS 6 to CentOS 7. This is where I encountered my first problem. Since I rely on custom nat PREROUTING/POSTROUTING iptables firewall rules for my VMs to properly be able to talk to each other and to the internet. I realized CentOS 7 defaults to firewalld, so instead of trying to rewrite my firewall rules to be compatible with firewalld, I decided to continue to use CentOS 6 on my host operating system, and only upgrade my guests VMs to CentOS 7.

On a side note, my previous guest VMs were originally using raw image format (default cache settings) for its storage, and by god what a hell of a difference it makes changing to use native block storage via LVM. I/O performance on my old server was terrible, the I/O wait percentage was roughly about 6%, now it's less than 1%. Even with the software raid, I/O performance is much better on my new server.

PHP 5.3 to 5.6 upgrade:
Since I don't have anything heavily customized on any of sites, the PHP version upgrade was practically painless.

Apache 2.2 to 2.4 upgrade:
Luckily, upgrading Apache wasn't a big hassle. Anyone considering upgrading from 2.2 to 2.4, it's definitely worth checking out the official upgrade documentation since dropping the old 2.2 configs in onto a 2.4 environment won't work off the gecko. In my case all of my sites were returning 403 forbidden replies and non of my .htaccess files weren't being read by Apache. The fix was really simple.

                AllowOverride All
                Require all granted
   

I must say, I really like Apache 2.4 new authorization syntax. What used to be a three line configuration is now a single line configuration, and much more human readable.

Future Upgrade Plans:
I didn't tackle this during the server migration, but I'll definitely going to be upgrading to Varnish 4 and use PHP FastCGI via php-fpm and mod_proxy_fcgi.

Programming: 

Linux: 

Awesome Applications: 

Pages

Premium Drupal Themes by Adaptivethemes