There comes a time on every system administrator’s life when they need to start being a little more conscious about security. That time has finally come for me.

I have a couple of servers in DigitalOcean where I run various sites and services. Some of these need to communicate with each other to do their job, for example, this blog runs in a server with Apache and PHP and communicates with another server that is running a MySQL database.

This is all good, but one of the most important rules of security is to only allow access to resources on a per-need basis. What this means is that from a security standpoint, nobody should be able to access a resource unless explicitly allowed. This rule applies to almost all scenarios that require some kind of access control and is a good idea to follow it whenever possible.

I now have a good amount of data in my blog that I would be very sad if I lost. As a precautionary measure I decided to build a little system that will backup my data regularly so I’m prepared in case of a disaster.

The strategy

The strategy is going to be very simple. I’m going to create a user in my database that has read permissions on the tables I want to backup. This user will run mysqldump from a different machine and will save the backups there. I will create a cron job that will do this once a day.

I’m looking for a centralized log management system that I can plug into some of my hobby projects and while I was about to spin up my ELK server (Elasticsearch, Logstash, Kibana) I found that Loggly has a free tier. I have used Loggly before and it is pretty good so I decided to give it a try.

Before we start setting things up in Loggly, we need to decide which logs we want to send. Here are a few that apply for me:

– Apache logs for ncona.com (Running inside docker container)

– MySQL logs (Running inside Digital Ocean droplet)

– Cron logs (Also inside Digital Ocean droplet)

Before we start configuring our system we need to create a Loggly account.

The question

There are a row of houses, each house can be painted with one of three colors red, blue or green. The cost of painting each house with a certain color is different. You have to paint all the houses such that no two adjacent houses have the same color. You have to paint the houses with minimum cost. How would you do it?

Note: Painting house-1 with red costs different from painting house-2 with red. The costs are different for each house and each color.

I’m slowly incrementing the number of projects I host in my personal servers and as the number increases I find the need to standardize the way I deploy each service. Currently each service has a different way of running and I have to try to remember how to do it each time I have an update. As one of the steps to a more streamlined deploy process I decided for each service to have a production ready image hosted in a Docker registry. The deploy will then just be a matter of downloading and running the image in the production machine (not perfect, but a step forward).

My first idea was to host a Docker registry myself, but luckily I found a service that offers 20 private repositories for free. To start using canister.io, you just need to register for the basic plan and create a new repo.

To push images you can use the command line. Start by logging in:

1
docker login --username=username cloud.canister.io:5000

Previously I wrote a post explaining how to do SSL termination with Ha-proxy. It seemed to be working fine, but it was giving me problems about mixed content when loading my blog.

What was happening was that my blog was being served on https://ncona.com, but all the JS, CSS and links where being returned in http. This actually makes a lot of sense because the load balancer is requesting content using http and then forwarding this content to the browser.

Once the problem is understood, the solution is just a matter of finding out how to tell wordpress to render https content when Ha-proxy receives an https request. A way to do this is by sending a header to wordpress when the request came on port 443. We can do this in haproxy.cfg:

1
2
3
4
5
6
7
frontend https-in
        bind *:443 ssl crt /certs/ncona.pem
        reqadd X-Forwarded-Proto:\ https

        acl ncona-web-frontend hdr(host) -i ncona.com www.ncona.com

        use_backend ncona-web if ncona-web-frontend

The reqadd instruction will add a header to the request being sent to the backend. Now we can inspect for this header in wp-config.php:

1
2
3
4
if ($_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') {
  $_SERVER['HTTPS'] = 'on';
  $_SERVER['SERVER_PORT'] = 443;
}

This solved the problem and I can finally serve my blog with https.

SSL termination refers to the process of terminating the encrypted connection at the load balancer and handling all internal traffic in an unencrypted way. This means that traffic between your load balancer and internal services (or between internal services) will not be encrypted, so you should make sure your network is secure. If you have your own data center, you can trust your network, otherwise you should set up a VPN so traffic can’t be sniffed.

Terminating SSL at the load balancer has a few advantages:

• Single place responsible of managing encryption and decryption of traffic
• Centralized place to store certificates
• The load balancer can analyze the traffic and take special actions based on this
• The load balancer can modify the request and response if necessary

A somewhat common scenario of wanting the load balancer to modify the request is adding headers to HTTP requests. More specifically, it is common to have the load balancer add a X-Forwarded-For header, which includes the IP address where the request originated. Without this header, all requests would look like they originated in the load balancer.

This blog and a few other of my personal projects are not using HTTPS at the moment of this writing. Using plain HTTP has a couple of disadvantages that could result in catastrophic consequences:

• Traffic can be sniffed – If somebody monitored the traffic in your network they would be able the see everything you are sending and receiving (including usernames and passwords).
• Traffic can be modified – When using plain HTTP, there is no guarantee that who you are talking to is who they say they are. Because of this, somebody could intercept your traffic and give you a response of their own. They could give you a log-in form to trick you into entering your credentials

I was trying to do some tuning on my servers network, but while I was at that I realized I couldn’t do it because I didn’t know anything about how Docker does networking. Since I need to move forward with my network configuration, I’m writing this article in the hope of understanding it better.

There are three networks automatically created by the Docker daemon when it starts: bridge, host and none. In this article I’m going to cover the bridge network since it is the default and most flexible one. You can see the networks using docker network ls:

1
2
3
4
NETWORK ID          NAME                DRIVER
d8a90e633c4a        bridge              bridge
b342b31dab76        host                host
48ac37e62c31        none                null

You will also see the bridge network interface created by Docker when running ifconfig:

1
2
3
4
5
6
7
8
docker0   Link encap:Ethernet  HWaddr 05:42:37:b5:36:7a
          inet addr:172.17.0.1  Bcast:0.0.0.0  Mask:255.255.0.0
          inet6 addr: fe80::42:47ff:feb5:867a/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:221192 errors:0 dropped:0 overruns:0 frame:0
          TX packets:199761 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:69251108 (69.2 MB)  TX bytes:205171116 (205.1 MB)

Lately I’ve been working on a system that has a lot of big tables (with a lot of columns), and often I want to do something like:

1
SELECT * FROM users WHERE id = 1;

But there are so many columns that it doesn’t look good on a terminal:

1
2
3
4
5
+----+-------------------+---------------------+---------------------+---------------------+-----------------------+--------+-------------------------------------+----------------------------------------------------------------------------------------------------+
| id | username          | created_at          | updated_at          | issuer              | issuer_id             | points | email                               | picture_url                                                                                        |
+----+-------------------+---------------------+---------------------+---------------------+-----------------------+--------+-------------------------------------+----------------------------------------------------------------------------------------------------+
|  1 | carlos            | 2016-01-31 13:03:36 | 2016-11-04 18:15:56 | accounts.google.com | 111394444444498347111 |    100 | NULL                                | https://lh4.googleusercontent.com/-laaaaaajmcc/AAAAAAAAAAA/AAAAAAAAAAA/qwertyuioaa/s96-c/photo.jpg |
+----+-------------------+---------------------+---------------------+---------------------+-----------------------+--------+-------------------------------------+----------------------------------------------------------------------------------------------------+