Telegram Group & Telegram Channel
🌐 Задача-ловушка: Пропавший трафик после настройки iptables

Условие:

На сервере настроен простой iptables-фильтр для блокировки всего входящего трафика, кроме SSH:


iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
iptables -A INPUT -p tcp --dport 22 -j ACCEPT


После применения этих правил вы проверяете, что SSH соединения работают нормально (локально и удалённо). Сервер отвечает на пинги, всё ок.

На следующий день вы добавляете локальный контейнер (например, Docker), запускаете его с пробросом порта:


docker run -d -p 8080:80 nginx


Проблема: Снаружи контейнер не доступен. В браузере или curl получаете Connection refused. Но в ss -tlnp порт 8080 виден и слушает.

Дополнительно, если выполнить:


curl http://localhost:8080


— сервер отвечает нормально. Но с других машин — нет.

Вопрос:
Почему порт 8080 недоступен извне? В чём подвох с iptables? Как починить проблему?

🔍 Подсказка:

Docker использует nat таблицы и PREROUTING`/`FORWARD цепочки для проброса портов.


Разбор:

💥 Ловушка:

Ваш iptables-правила:


iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -p tcp --dport 22 -j ACCEPT


запрещают ВСЁ, кроме SSH. Вы думаете, что входящие соединения через Docker должны идти через INPUT, но это не так!

Когда Docker пробрасывает порт с хоста (например, 8080), схема такая:

- Входящий пакет попадает в цепочку PREROUTING (nat)
- Потом через FORWARD, если пакет не адресован хосту напрямую, а перенаправлен внутрь контейнера

И тут главная ловушка: даже если контейнер слушает порт на 0.0.0.0, Docker обрабатывает проброс трафика через FORWARD, а у вас политика по умолчанию:


iptables -P FORWARD DROP


Поэтому трафик до контейнера блокируется именно на этапе FORWARD.

🔧 Как проверить:

Запустить:


iptables -L -v -n


Вы увидите, что счётчик пакетов в FORWARD показывает дропы.

🛠 Как починить:

Добавить правило разрешения проброса пакетов для Docker:


iptables -A FORWARD -o docker0 -j ACCEPT


Или (более строго):


iptables -A FORWARD -i eth0 -o docker0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i docker0 -o eth0 -j ACCEPT


Вывод:

• В Linux iptables цепочки работают по строгой логике:
- INPUT — для пакетов к хосту
- FORWARD — для пакетов, которые переходят через хост (например, контейнеры или маршрутизаторы)

• Даже если кажется, что контейнер слушает на 0.0.0.0, проброс портов Docker работает через FORWARD, а не напрямую через INPUT.

💡 Бонус-вопрос:
Что изменится, если вы запустите контейнер с флагом --network=host? Какие цепочки будут задействованы тогда?



tg-me.com/DevOPSitsec/1495
Create:
Last Update:

🌐 Задача-ловушка: Пропавший трафик после настройки iptables

Условие:

На сервере настроен простой iptables-фильтр для блокировки всего входящего трафика, кроме SSH:


iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
iptables -A INPUT -p tcp --dport 22 -j ACCEPT


После применения этих правил вы проверяете, что SSH соединения работают нормально (локально и удалённо). Сервер отвечает на пинги, всё ок.

На следующий день вы добавляете локальный контейнер (например, Docker), запускаете его с пробросом порта:


docker run -d -p 8080:80 nginx


Проблема: Снаружи контейнер не доступен. В браузере или curl получаете Connection refused. Но в ss -tlnp порт 8080 виден и слушает.

Дополнительно, если выполнить:


curl http://localhost:8080


— сервер отвечает нормально. Но с других машин — нет.

Вопрос:
Почему порт 8080 недоступен извне? В чём подвох с iptables? Как починить проблему?

🔍 Подсказка:

Docker использует nat таблицы и PREROUTING`/`FORWARD цепочки для проброса портов.


Разбор:

💥 Ловушка:

Ваш iptables-правила:


iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -p tcp --dport 22 -j ACCEPT


запрещают ВСЁ, кроме SSH. Вы думаете, что входящие соединения через Docker должны идти через INPUT, но это не так!

Когда Docker пробрасывает порт с хоста (например, 8080), схема такая:

- Входящий пакет попадает в цепочку PREROUTING (nat)
- Потом через FORWARD, если пакет не адресован хосту напрямую, а перенаправлен внутрь контейнера

И тут главная ловушка: даже если контейнер слушает порт на 0.0.0.0, Docker обрабатывает проброс трафика через FORWARD, а у вас политика по умолчанию:


iptables -P FORWARD DROP


Поэтому трафик до контейнера блокируется именно на этапе FORWARD.

🔧 Как проверить:

Запустить:


iptables -L -v -n


Вы увидите, что счётчик пакетов в FORWARD показывает дропы.

🛠 Как починить:

Добавить правило разрешения проброса пакетов для Docker:


iptables -A FORWARD -o docker0 -j ACCEPT


Или (более строго):


iptables -A FORWARD -i eth0 -o docker0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i docker0 -o eth0 -j ACCEPT


Вывод:

• В Linux iptables цепочки работают по строгой логике:
- INPUT — для пакетов к хосту
- FORWARD — для пакетов, которые переходят через хост (например, контейнеры или маршрутизаторы)

• Даже если кажется, что контейнер слушает на 0.0.0.0, проброс портов Docker работает через FORWARD, а не напрямую через INPUT.

💡 Бонус-вопрос:
Что изменится, если вы запустите контейнер с флагом --network=host? Какие цепочки будут задействованы тогда?

BY DevOps


Warning: Undefined variable $i in /var/www/tg-me/post.php on line 283

Share with your friend now:
tg-me.com/DevOPSitsec/1495

View MORE
Open in Telegram


DevOps Telegram | DID YOU KNOW?

Date: |

How Does Bitcoin Mining Work?

Bitcoin mining is the process of adding new transactions to the Bitcoin blockchain. It’s a tough job. People who choose to mine Bitcoin use a process called proof of work, deploying computers in a race to solve mathematical puzzles that verify transactions.To entice miners to keep racing to solve the puzzles and support the overall system, the Bitcoin code rewards miners with new Bitcoins. “This is how new coins are created” and new transactions are added to the blockchain, says Okoro.

Telegram Gives Up On Crypto Blockchain Project

Durov said on his Telegram channel today that the two and a half year blockchain and crypto project has been put to sleep. Ironically, after leaving Russia because the government wanted his encryption keys to his social media firm, Durov’s cryptocurrency idea lost steam because of a U.S. court. “The technology we created allowed for an open, free, decentralized exchange of value and ideas. TON had the potential to revolutionize how people store and transfer funds and information,” he wrote on his channel. “Unfortunately, a U.S. court stopped TON from happening.”

DevOps from us


Telegram DevOps
FROM USA