Не думал что этот вопрос настолько актуален — почему перестают работать очевидные правила iptables на хостовой машине, если на сервере запущены какие-либо docker контейнеры?
Давай разбираться.
Если коротко, то когда ты запускаешь docker контейнеры, то все начинает работатьчерез жопу по правилам маршрутизации самого docker’а. И плевать он хотел что у тебя там на хостовой машине было ранее сконфигурировано в плане безопасности.
Давай рассмотрим на примере как с этим можно побороться.
Вводные: На сервере крутится контейнер nginx, порты 80 и 443 смотрят в мир, то есть открыты для всех.
Задача: Нужно, чтобы порты 80 и 443 были доступны только для определенных IP адресов.
Если бахнуть на хостовой машине так:
А решение простое, правим немного свой docker-compose.yml и добавляем networks. В моем примере я добавил сеть bashdays.
Не забывай правильно подставить свой интерфейс ethX/enoX, а то всякое бывает.
Важное замечание. После перезапуска контейнеров, docker снова перетрет правила на хостовой машине. Поэтому весь этот процесс хорошо бы автоматизировать. Я сильно не заморачивался, просто закинул правила в bash скрипт, повесил на крон (каждую минуту), да и все.🧠 Закостылил так закостылил.
Сегодня чуть позже покажу более правильный скрипт, который будет следить за ребутом docker, но по сути те же яйца, только сбоку. Рад был всех вас видеть!
tags: #networks
—
🟢 Подпишись: @bashdays
Давай разбираться.
Если коротко, то когда ты запускаешь docker контейнеры, то все начинает работать
Давай рассмотрим на примере как с этим можно побороться.
Вводные: На сервере крутится контейнер nginx, порты 80 и 443 смотрят в мир, то есть открыты для всех.
Задача: Нужно, чтобы порты 80 и 443 были доступны только для определенных IP адресов.
Если бахнуть на хостовой машине так:
-A INPUT -s xxx.xxx.xxx.xxx/32 -p tcp -m tcp --dport 80,443 -j ACCEPTТо порты 80 и 443 так же будут доступны всем желающим. Вот на эти грабли почти каждый и наступает.
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
А решение простое, правим немного свой docker-compose.yml и добавляем networks. В моем примере я добавил сеть bashdays.
version: '3.2'Ну и теперь на хостовой машине можно уже что-то запрещать или разрешать с помощью iptables.
services:
nginx:
image: nginx:1.20.1
container_name: nginx
ports:
- '80:80'
- '443:443'
networks:
- bashdays
networks:
bashdays:
driver: bridge
driver_opts:
com.docker.network.enable_ipv6: "false"
com.docker.network.bridge.name: "docker_bashdays"
/sbin/iptables -F DOCKER-USERГде <EXTERNAL IP> это айпишник сервера который доступен из мира. А <CLIENT_IP> собственно айпишник клиента, которому мы разрешим конектится к порту 80 и 443. Все! Теперь у нас и docker в шоколаде и хостовые правила iptables работают «наверное» правильно.
/sbin/iptables -I DOCKER-USER -i eth0 -o docker_bashdays -j DROP
/sbin/iptables -I DOCKER-USER -i eth0 -s <EXTERNAL IP> -j RETURN
/sbin/iptables -I DOCKER-USER -i eth0 -p tcp --dport 80 -s <CLIENT IP> -j RETURN
/sbin/iptables -I DOCKER-USER -i eth0 -p tcp --dport 443 -s <CLIENT IP> -j RETURN
/sbin/iptables -I DOCKER-USER -i eth0 -o docker_bashdays -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
Не забывай правильно подставить свой интерфейс ethX/enoX, а то всякое бывает.
Важное замечание. После перезапуска контейнеров, docker снова перетрет правила на хостовой машине. Поэтому весь этот процесс хорошо бы автоматизировать. Я сильно не заморачивался, просто закинул правила в bash скрипт, повесил на крон (каждую минуту), да и все.
Сегодня чуть позже покажу более правильный скрипт, который будет следить за ребутом docker, но по сути те же яйца, только сбоку. Рад был всех вас видеть!
tags: #networks
—