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 modified if you yourself created the appropriate commit.

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

Demo application

Take the following infrastructure as an example:

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

➜ 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 a client part at your disposal, you should see something like this greeting:

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

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

Looks like someone is using evalin the wrong place! Therefore, a potential attacker can take advantage of our carelessness and execute arbitrary code on the 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 hacked machine, a hacker usually tries to get comfortable: he downloads the PHP shell and various toolkits. Some crackers also tend to replace the look and content of your site:

Recover after attack

One of the great things provided by the copy-on-write file system is the ability to see changes in the container. The command docker diffwill show what the cracker 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 ours index.html, but also loaded the PHP shell, carefully named shell.php. But the first thing you need to restore the site.

For further proceedings, the image of the hacked system can be saved by the team docker commit. And since the containers are not stable, we reload 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 cracker made:

➜ docker run -it ebc3cb7c3a312696e3fd492d0c384fe18550ef99af5244f0fa6d692b09fd0af3 sh
# cat index.html
HACKED BY SUPER ELITE GROUP OF HACKERS  
# cat shell.php

It seems that the guys from the SUPER ELITE GROUP OF HACKERS have 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-onlythat instructs Docker to prohibit changes to the container file system. Installing it could prevent the modification index.html, but more importantly, the attacker would not be able to load the command shell or any other tool he needed.

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, cracker attempts to change index.htmlfailed.

Does this give a one hundred percent 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 identification information or steal data from the database.

Nevertheless, there is a real opportunity to significantly complicate the life of hackers trying to crack our systems. To do this, use Docker security features and minimal container images .

Conclusion

The security of our applications will never be absolute. But the use of Immutable infrastructure can significantly complicate the work of hackers, and if hacking does happen, making the recovery procedure much easier.

So for the sake of safety and stability, it’s quite possible to tighten a few handles and strengthen the defense of our containers!