One of the postings on Hacker News that caught attention over the last couple of days was an email sent to the Docker security team that focused on a very outrageous security concern with Docker. Even if you expose the port to a loopback address with a parameter like
-p 127.0.0.1:80:80, the service can still be accessed externally, what happened?
The reason for this is simple: Docker has added this Iptables rule.
As long as an external attacker sends traffic through this host to
172.17.0.2:80, it will match this rule and successfully access the services in the container; 127.0.0.1 doesn’t do much good.
The embarrassing thing is that users who choose to map the port to 127.0.0.1 basically feel so secure that they no longer want to take further security measures. Now comes the question, mapping to 127.0.0.1 can’t be said to be very secure, can it, only irrelevant to security.
Proof of Concept
Here is an example to verify it.
Run a PostgreSQL container on machine A with port mapped to 127.0.0.1.
Machine B on the same LAN adds a routing table that directs all traffic accessing
172.16.0.0/12to machine A.
Scan the port of machine A in machine B.
Connect directly to PostgreSQL in machine B.
The fact that it’s not just 127.0.0.1, but that you map the container port to any address on the host, accessible externally, is outrageous!
The author of the email proposed a solution to the Docker team to optimize Docker’s iptables rules.
First, strictly restrict the source addresses and network interfaces that are allowed to access the container ports
For example, the original iptables rule for
docker run -p 127.0.0.1:5432:5432is as follows.
The improved iptables rules are as follows.
Similarly, if the address of the host is
192.168.0.100and the mask is
24, then the iptables rule for
docker run -p 192.168.0.100:5432:5432should be as follows.
Finally, the default behavior should be modified to map to 127.0.0.1 by default if no IP address is specified when using the
Although there are many people in the comments section have given the option of adding iptables rules to restrict, but this is unrealistic, there are thousands of users around the world are using the
-p parameter to map the container port to 127.0.0.1, the attacker probably found this vulnerability long ago, we can not expect users to add iptables rules to restrict external access, the most reliable The most reliable way is to wait for Docker official to fix this bug and then upgrade it.