This week I finally got round to implementing genuine SSL certificates on my sites/domains. I’d made a few aborted attempts previously, hampered mainly by an inept ISP that seemed unable to process my SSL certificate orders, but decided to give Let’s Encrypt ( a try this time, and I’m very pleased I did.

Done purely through the terminal, the setup process was as follows:

1. Download and install Certbot

> sudo apt-get update
> sudo apt-get install software-properties-common
> sudo add-apt-repository ppa:certbot/certbot
> sudo apt-get update
> sudo apt-get install python-certbot-apache

2. Run Certbot with automated Apache plugin

> sudo certbot --apache

And – after following the on-screen instructions – that was pretty much that. I did have to ensure that the correct port was open on my server, to allow confirmation of domain ownership, but the whole thing was otherwise trouble-free.

The only annoying thing is that – in my haste – I’ve already pointed away from the IP address currently hosting its content, and directly at the box hosting, which means I’ll have to spend some time amalgamating the content. It will probably get messy as f-

Anyway, very happy about the whole HTTPS situation. It’s almost the kind of thing a professional developer would do…




NFS (Now F**king Sorted)


I finally managed to get the NFS mount working, and this is how I did it…

NOTE: This is the initial setup before I’ve secured it up a bit, just for a POC, so don’t do this yourself without doing some extra work to secure it later…

Server Side


$ sudo apt-get update
$ sudo apt-get install nfs-kernel-server


1. Create folder for sharing

$ cd /var
$ sudo mkdir nfs
$ sudo chmod -R 777 nfs

2. Add file

$ cd nfs
$ sudo vi test.txt

(add any old text in, and save)

3. Configure exports

$ sudo vi /etc/exports

Add the following line

/var/nfs  *(rw,sync,subtree_check,insecure)

4. Export and start service

$ sudo exportfs -a
$ sudo service nfs-kernel-server start

5. Confirm installed and running

$ ps aux | grep nfs
$ showmount -e

Client Side

1. Confirm we can see NFS mounts

$ showmount -e {server IP address}


At this point, things weren’t going well. I could not connect to NFS, even just to list mounts. In order to diagnose this, I looked at outgoing traffic from my Mac, using:

$ sudo tcpdump host {server IP address}

This showed me that connections were certainly being attempted from the Mac, but the Ubuntu server was giving nothing back. The next step was to determine if the server firewall was rejecting requests.

Running this on the server, whilst attempting showmount -e {server IP address} again on the client confirmed that connections were being dropped:

$ sudo tail -F /var/log/kern.log

I had some over-eager rules in ufw that were blocking the NFS requests (even though an NMAP port scan showed all the required ports being open, etc.) and once I’d stopped the firewall from blocking connections I could confirm that the folder was now ready to mount.

2. Mount

$ sudo mount -o rw -t nfs {server IP address}:/var/nfs /path/to/local/folder

3. Confirm that mount was successful

$ cd /path/to/local/folder
$ ls
$ cat test.txt

4. Unmount

$ sudo umount -f /path/to/local/folder

And that is about it. Obviously, there are some places where security can immediately be tightened (eg. Don’t just have 777 permissions on the folder, and use specific IP ranges in /etc/exports instead of just *) but this should help in getting NFS up and running initially.

I may revisit this again once my knowledge has improved a bit.



SQL Injection


At the moment, I’m looking to shore up the basic security of my server DB, including provisions to protect against the possibility of an SQL Injection attack.

Let’s say, for arguments’ sake, that I had some PHP code that looked like the following:

$query = "SELECT name FROM my_table WHERE id='" . $id . "'";

Normal usage of this – where, for example, an id value of 131 had been entered – would result in the following query:

SELECT name FROM my_table WHERE id='131';

If, however, I was a nefarious cunt, I might enter something like 131′ or ‘1=1, which would result in the following:

SELECT name FROM my_table WHERE id='131' or '1=1';

So some unwarranted SQL has actually been injected into the query, perhaps circumventing the purpose of the code. If this was, for example, a check to prove that a valid user exists (okay, the example SQL here is ridiculous and unfit for purpose, but anyway…), then this would provide the hacker with a result > 0 in all cases, and possibly grant access.

This is a highly simplified example of what can be a very complicated and costly attack, but it does highlight the basic premise of the method. Other possibilities are updating, inserting, deleting and worse.

I’ve been implementing various ways to combat SQL Injection on a basic level.