Just set up an ElasticSearch container to use with company's Laravel app. Creating docker-compose.yml and running it is flawless and straight-forward but the issue occurs when I want to firewall this thing so that it's only accessible from one, specific IP of the mentioned Laravel app.
While researching I noticed that plenty of people are having these issues where traffic to port forwarded by Docker gets completely exposed to the public and that they're unable to firewall it properly.
I found several solutions in last 6 hours of which none were working. I assume this has something to do with the way Docker processes/forwards the inbound traffic and my iptables knowledge isn't so vast so that I could understand what's happening on my own.
This is my docker-compose.yml (for what it's worth):
version: '3.4'
services:
elasticsearch:
image: khezen/elasticsearch:6.1.1
container_name: elasticsearch
environment:
NETWORK_HOST: 0.0.0.0
HOSTS: 127.0.0.1
CLUSTER_NAME: fd-es
NODE_NAME: node-1
HEAP_SIZE: 31g
HTTP_SSL: "true"
ELASTIC_PWD: "somepasswd"
HTTP_CORS_ENABLE: "true"
HTTP_CORS_ALLOW_ORIGIN: /https?:\/\/localhost(:[0-9]+)?/
ulimits:
memlock:
soft: -1
hard: -1
volumes:
- ./config/elasticsearch.yml:/elasticsearch/config/elasticsearch.yml
- ./data:/elasticsearch/data
- ./logs:/elasticsearch/logs
ports:
- 9200:9200
networks:
- es-network
restart: always
networks:
es-network:
driver: bridge
These are my currently used iptables rules which are to some degree what I want but all traffic to port 9200 from any client is still let through instead of being accessible only from my app:
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [779:162776]
:DOCKER - [0:0]
-A DOCKER -s xxx.xxx.xxx.xxx -p tcp -m tcp --dport 9200 -j ACCEPT
-A DOCKER -o docker0 -p tcp -m tcp --dport 9200 -j ACCEPT
-A DOCKER -p tcp --dport 9200 -j DROP
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -p icmp -m icmp --icmp-type 8 -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -p udp -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -p tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 44344 -j ACCEPT
-A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p tcp -j REJECT --reject-with tcp-reset
-A INPUT -j REJECT --reject-with icmp-proto-unreachable
-A INPUT -j DROP
I tried disabling Docker's iptables support and disabling bridge networking and tweaked iptables rules couple of dozen of times but to no avail.
I'd appreciate any suggestion and help to make this happen because I'm out of ideas and search results for this problem.
Thanks in advance!
For everyone looking for solution to this problem, the answer is this:
Found it here: https://unrouted.io/2017/08/15/docker-firewall/
Works perfectly.
I'll explain my scenario where I've tested what you want to achieve.
I've launched a docker container where port 9010 is forwarded to port 8080:
Docker creates a DNAT rule for the PREROUTING chain that forwards traffic from port 9010 to port 8080:
Docker also creates a rule in the DOCKER chain allowing all traffic sent to the container's IP address and port 8080.
The DOCKER chain is used in the FORWARD chain, where all traffic sent to the docker0 bridge is processed by rules in the DOCKER chain.
Now I want to filter traffic sent to port 8080 (traffic to port 9010 has been processed by the PREROUTING and now it's traffic sent to port 8080) blocking all IP addresses while allowing traffic from IP 192.168.1.142. The IP address of the container could be added to those rules for increased granularity of course.
I add the following rules at the beginning of the FORWARD chain. Alternatively you could replace FORWARD with DOCKER.
Thanks to those rules only IP 192.168.1.142 can reach the 8080 port used by the container.
For those visiting this answer if you only want to allow one specific IP address to access the containers use the iptables command suggested in the Docker docs.
I think adding this line would have fixed your issue :