Click to follow the official account, Java dry goods will be delivered in time
Source: Cloud Native Labs
A few days ago, there was a post on Hacker News that went viral. This was an email to the Docker security team. It mainly said that Docker had a very outrageous security risk.
Even if you expose the port to the loopback address via a parameter like -p 127.0.0.1:80:80
this , the service is still accessible to the outside world, so what?
The reason is actually very simple, Docker added such an Iptables rule:
🐳 → iptables -nvL DOCKER
Chain DOCKER (2 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp -- !docker0 docker0 0.0.0.0/0 172.17.0.2 tcp dpt:80
As long as an external attacker sends traffic to through this host 172.17.0.2:80
, it will match this rule and successfully access the service in the container, which is of 127.0.0.1
no use. The latest interview questions have been sorted out, and you can brush the questions online in the Java interview library applet.
Embarrassingly, users who choose to map ports to 127.0.0.1
are basically so secure that they don't want to take further security measures. Now comes the question, mapping to 127.0.0.1
can not be said to be very secure, it can only be said that it has nothing to do with security. . .
proof of concept
The following is an example to verify.
Run a PostgreSQL container on the A machine and map the port to 127.0.0.1
.
# IP: 192.168.0.100
🐳 → docker run -e POSTGRES_PASSWORD=password -p 127.0.0.1:5432:5432 postgres
Machine B in the same local area network adds a routing table 172.16.0.0/12
to traffic to machine A.
# IP: 192.168.0.200
🐳 → ip route add 172.16.0.0/12 via 192.168.0.100
Scan the port of the A machine in the B machine.
🐳 → nmap -p5432 -Pn --open 172.16.0.0/12
Starting Nmap 7.92 ( https://nmap.org ) at 2021-11-05 15:00 CDT
Nmap scan report for 172.17.0.2
Host is up (0.00047s latency).
PORT STATE SERVICE
5432/tcp open postgresql
Connect PostgreSQL directly in B machine.
🐳 → psql -h 172.17.0.2 -U postgres
Password for user postgres:
solution
In fact, it's not just 127.0.0.1
that you map the container port to any address of the host, and it can be accessed by the outside world, which is far from the big spectrum!
The email author proposed a solution to the Docker team, hoping to optimize Docker's iptables rules:
First, strictly limit the source addresses and network interfaces that are allowed to access the container port. For example docker run -p 127.0.0.1:5432:5432
, the original iptables rules are as follows:
Chain DOCKER (2 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp -- !docker0 docker0 0.0.0.0/0 172.17.0.2 tcp dpt:5432
The improved iptables rules are as follows:
Chain DOCKER (2 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp -- lo docker0 127.0.0.1/8 172.17.0.2 tcp dpt:5432
Similarly, if the host's address is 192.168.0.100
and the mask is 24, then docker run -p 192.168.0.100:5432:5432
the iptables rule should be:
Chain DOCKER (2 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp -- eth0 docker0 192.168.0.0/24 172.17.0.2 tcp dpt:5432
Finally, we need to modify the default behavior, if no IP address is specified when using the -p
parameter , it will be mapped to by default 127.0.0.1
. The latest interview questions have been sorted out, and you can brush the questions online in the Java interview library applet.
Although many people in the comment area have given the solution of adding iptables rules to restrict, but this is unrealistic. At present, thousands of users around the world are using the -p
parameter to map the container port to 127.0.0.1
it, and attackers are estimated to have discovered it long ago. Because of this vulnerability, we cannot expect users to add iptables rules to restrict external access. The most reliable way is to wait for Docker to officially fix this bug and then upgrade.
Citation link
There is a thread on Hacker News: https://news.ycombinator.com/item?id=31839936
Finally, I recommend the Spring Cloud Alibaba Microservices Practical Course , which took six months to build . Currently, in the first special offer, 100% of the price will be raised in the future. Sign up early, learn early, improve yourself early, and raise your salary early.