Securing your network with iptables

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.

To put some emphasis on the importance of this rule, I want to tell you a little story of a time when I didn’t follow it and there were great consequences.

A few years ago I was building a service that allowed access to certain resources. These resources were private to the company I used to work for, so they shouldn’t be visible to anybody else. This service provided an HTTP endpoint that exposed the information. The way I ensured that the person calling the endpoint was supposed to access that information was by adding a check for an Auth token when a specific endpoint was called.

When a GET request to /secret-resource was made, a function was executed and the code looked something like this:

1
2
3
4
5
6
7
8
function listSecretResource(request) {
  if (!isValid(request.headers.authorization)) {
    return sendResponse(401);
  }

  // Code here only got executed if the user
  // was valid
}

This might not seem that bad, but it was a huge mistake. Short after that endpoint was delivered I was asked to create a new endpoint, but I forgot to add the check for the auth token:

1
2
3
4
function listAnotherSecretResource(request) {
  // There was no check, so this code always
  // got executed
}

This caused the endpoint to be open to anybody, leaking secret information to the public. This could have been avoided by including an authorization check on all endpoints by default. This would mean that by default nobody without an access token can communicate with this service. Since some of the endpoints were actually public, we had to go to those endpoints and explicitly say that they could be accessed by anyone.

The previous example is at the code level, but iptables works at the network level. Although they work at different levels, the principal is the same.

The problem I’m facing now is indeed at the network level. I have a MySQL server that requires a username and password to log-in, but can be accessed from anywhere in the world. Since at this moment I only want my blog to be able to access the database, I could use iptables to block all connections except for the ones coming from my blog’s IP address. I can create similar configurations for other services by blocking all connections and then only allowing the ones I know I want. The end result will be a more tightly secured network, and better sleep at night.

Uncomplicated Firewall

How your system will handle a package is decided by iptables rules. Uncomplicated Firewall (ufw) is a tool that makes it easier to configure your firewall (iptables). Since it is the recommended tool for Ubuntu, I’m going to be using it to configure my servers.

I’m connected to my server using SSH and I want to make sure I’m not locked out of my server, so the first thing I did is open port 22:

1
sudo ufw allow 22

Note that this command allows everybody in the world to access port 22 on my server. This is fine for me because you need a valid SSH key to log into my server. If you want, you can have a more restrictive configuration. e.g. Allow only your home IP address.

After opening port 22 we can go ahead and enable ufw:

1
sudo ufw enable

After enabling ufw I tried restarting my server and SSHing back in to make sure it works fine. Back in the server I checked the status of the firewall:

1
2
3
4
5
6
7
8
9
10
ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), deny (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22                         ALLOW IN    Anywhere                  
22 (v6)                    ALLOW IN    Anywhere (v6)

The Default section shows that by default all incoming traffic is denied, which is what we want.

One problem with ufw is that it doesn’t show you all iptables in your system, just the rules it manages. In the previous output you can’t see that Docker is opening port 80 and allowing everyone to communicate with a server I am running on that machine. You can see the rules Docker added to iptables:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
iptables -L

Chain FORWARD (policy DROP)
target     prot opt source               destination        
DOCKER-ISOLATION  all  --  anywhere             anywhere            
DOCKER     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
...            

Chain OUTPUT (policy ACCEPT)
...          

Chain DOCKER (1 references)
target     prot opt source               destination        
ACCEPT     tcp  --  anywhere             172.17.0.2           tcp dpt:http

Chain DOCKER-ISOLATION (1 references)
target     prot opt source               destination        
RETURN     all  --  anywhere             anywhere

For the specific case of Docker, we can tell it to not mess our iptables configuration:

1
2
3
4
5
6
7
8
9
mkdir /etc/systemd/system/docker.service.d

cat << EOF > /etc/systemd/system/docker.service.d/noiptables.conf
[Service]
ExecStart=
ExecStart=/usr/bin/docker daemon -H fd:// --iptables=false
EOF

systemctl daemon-reload

You can restart your server and the rules Docker added will be gone. If you don’t have anything else messing your iptables, you will only have port 22 open at this point.

At this point I have a service running on docker, but not accessible from the outside:

1
2
CONTAINER ID   IMAGE      COMMAND                  PORTS                NAMES
66191e736932   some-app   "nginx -g 'daemon ..."   0.0.0.0:80->80/tcp   some-app-container

If we want to make this service available we just need to open the port:

1
sudo ufw allow 80

In the future if I need other ports open I can use a similar command to open them. This way my server is my more secure since it only allows things I explicitly tell it to.

Leave a Comment


NOTE - You can use these HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Time limit is exhausted. Please reload CAPTCHA.