1

The current setup is the following:

  • A production server (host) has only a few open ports, namely HTTP, HTTPS and secure ports for e-mailing.
  • On the host there is a non-privileged user running a Docker engine and containers.
  • Several web applications are running on Docker containers, each runs on a virtual bridged network provided by the Docker runtime. They have open ports HTTP and HTTPS. Applications are running on arbitrary web-server technology, like Apache 2.? or AKKA-HTTP.
  • Only one "http-proxy" container exposes its ports (80, 443) to the host. On this container, a non-privileged user is running a mod-secured Apache 2 server which only forwards requests based on the domain requested and forwards to one of the application containers.
  • Mail server is running on a Docker container with non-privileged user that exposes its ports to the host.

Questions are:

  1. Are there any drawbacks to this model?
  2. How would it be more secure?
  3. How exposed are the application-containers to attacks?
  4. Are there any security considerations regarding Docker?

Thanks!

  • 1
    As this didn't get mentioned in the answers, I'll mention that there's a CIS guide for hardening Docker installs benchmarks.cisecurity.org/tools2/docker/… is the current version. If you want advice on locking your install down there's a fair bit there. – Rory McCune Mar 4 '17 at 9:30
2

Are there any drawbacks to this model?

I don't see any immediate drawbacks, except for the overheads and the use of disk space if you deploy your applications on a rolling basis without keeping volumes in check. Keep in mind that "A Docker data volume persists after a container is deleted. " see the Docker documentation.

However, there might be a few longer-term drawbacks. For example: since you run this in production, how often do you apply security updates to your containers? Given that docker images are a step removed from upstream, security patches might not be deployed fast enough. How often do you check for updates to your containers, and redeploy them?

Also, if one of your containers gets 0wned, do you filter outbound connections? What if a trivial exploit in your app makes it part of a botnet?

How would it be more secure?

It depends. Do you mount the host's /proc or /sys in any container? If so, beware of this kind of attacks (and search for 'docker escape' for an entertaining read)

How exposed are the application-containers to attacks?

For attacks coming from outside your network perimeter, they are as exposed as if the applications were running as regular UNIX processes on a system.

Oddily, for attacks coming from other containers you are actually increasing your attack surfaces: assuming some containers can see others (e.g. web server can see the db server, or a log server, and so on) you have to make sure each container does not run extra services and most importantly keep them up to date.

Are there any security considerations regarding Docker?

Yes but the question is too broad. There are docker escapes due to poor container management (e.g. mounting /proc). There are potential docker exploits. There is the occasional misconfiguration that allows local users to attack it. If you're looking for a silver bullet to deploy and forget, you'll be disappointed...

  • Good answer, I'm going to improve the setup by limiting outbound connections from containers. Isn't it harder to attack an application container behind a proxy container that looks into the request and does a lot of other checks, protects against DDOS and so on...? – Dyin Jan 25 '17 at 15:55
  • @Dyin if the application is vulnerable to e.g. command injection (and this bypasses the proxy) then you're pretty much screwed. What checks did you enable? Is your proxy doing SSL stripping or are you handling SSL into each application container? – lorenzog Jan 25 '17 at 16:16
  • I handle SSL for each application container in the proxy, I guess this is SSL stripping. Never heard about SSL stripping before. I think this use-case should be agnostic about whether security on the application-level is correct or not. I mean with high probability my applications can resist SQL or any other type of ijection. I hope. Mod-evasive and mod-security has been enabled and configured on the proxy container only. – Dyin Jan 26 '17 at 11:43
  • @Dyin if SSL is handled in the each container then an SQL injection attack over https won't be caught by the proxy. – lorenzog Jan 26 '17 at 12:12
  • SSL is handled only on the proxy currently. Nice, thanks! – Dyin Jan 26 '17 at 12:22
1

Running a lightweight proxy in front of a web/appserver is a good idea, and while I am a big fan of apache httpd, I think it is a poor choice as a proxy; it is far from lightweight so your architecture will not cope with high traffic volumes. I would recommend nginx or ATS or possibly varnish. But there isn't an ATS nor varnish port of modsecurity and the nginx version is not as stable as the apache module. There are alternative WAFs for all three - whether they are appropriate for you depends on what you are doing with your WAF.

As lorenzog says docker images tend to lag in releasing patches. You've not mentioned how you propose to address configuration, deployment and patching of the servers.

All your daemons should run as non-privileged users, and all the standard applications on linux distributions do run as a non-root user - but most daemons will start as root in order to grab a low numbered port. You can start it as non-root on a high numbered port and use iptables to do port translation or use linux capabilties to delegate permission to bind a low numbered port or do the port mapping elsewhere. But do beware that this may involve tinkering with config files which may lead to conflicts with the distribution patches.

  • Thanks, I like the port mapping idea! I did not know the Apache web server has such a long code-path to resolve a request. I'll keep that in mind. – Dyin Jan 25 '17 at 16:02
0

Your setup sufficiently isolates the different environments so that a breach in one container does not give access to another container.

One thing you should check is that the web applications are not run as root within the docker containers. The web application code should be run as a normal user.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.