Лаборатория: открыть сервис без ослабления iptables¶
Сценарий для обучения администратора НАЙС.ОС CLOUD: сервис уже запущен, но должен быть доступен только доверенной управляющей сети. Требуется сохранить default deny, разрешить нужное соединение, проверить обратный трафик и записать результат так, чтобы он не исчез после reboot. Не предполагается, что произвольный iptables-save автоматически станет постоянным состоянием.
Ситуация¶
Есть условный TCP-сервис на 8443, слушающий 192.0.2.10. Доступ разрешён только подсети 198.51.100.0/24. Вход по SSH должен оставаться доступен в рамках существующей политики; сеть Docker не должна измениться. Префиксы — учебные, не используйте их в действующей системе.
Шаг 1. Инвентаризация¶
ss -lntp | grep ':8443'
ip -4 address
ip -4 route
iptables -V
iptables -S
iptables -L INPUT -n -v --line-numbers
iptables -L OUTPUT -n -v --line-numbers
iptables -S DOCKER-USER 2>/dev/null || true
Если ss не показывает слушающий сервис, проблему следует решать на уровне приложения, а не открывать весь firewall. Если указан только 127.0.0.1:8443, разрешение INPUT не заставит приложение слушать на внешнем интерфейсе.
Шаг 2. Подготовьте возврат¶
umask 077
mkdir -p /root/firewall-change
iptables-save > /root/firewall-change/before-ipv4.rules
ip6tables-save > /root/firewall-change/before-ipv6.rules
systemctl cat iptables > /root/firewall-change/iptables-unit.txt
Зафиксируйте, какой backend возвращает iptables -V, и оцените отличия iptables-nft и iptables-legacy в alternatives. В НАЙС.ОС конфигурация всё равно поддерживается через iptables, а не ручной переход к другим менеджерам.
Шаг 3. Определите порядок цепочек¶
Просмотрите iptables -L INPUT -n -v --line-numbers. Если перед предполагаемой точкой вставки есть терминальный DROP/REJECT, правило, добавленное через -A INPUT, не сможет его обойти. Если имеются цепочки ограничений по источнику/интерфейсу, не вставляйте новый ACCEPT до них без осознанного решения ИБ.
Планируемое правило (сеть заменить реальной):
iptables -I INPUT <ПОЗИЦИЯ> -s 198.51.100.0/24 \
-d 192.0.2.10/32 -p tcp --dport 8443 \
-m conntrack --ctstate NEW -j ACCEPT
<ПОЗИЦИЯ> здесь сознательно оставлена как placeholder: её нельзя безопасно определить без реального firewall. Не копируйте команду с угловыми скобками в оболочку — они имеют синтаксическое значение для shell.
Шаг 4. Проверьте ответный трафик¶
При OUTPUT DROP ответа приложения не будет, если возвратный трафик для ESTABLISHED,RELATED не разрешён. Сначала изучите iptables -S OUTPUT, потом определите минимально необходимое правило. Не заменяйте OUTPUT DROP на ACCEPT ради демонстрации.
Шаг 5. Проверьте положительный и отрицательный тесты¶
С клиента внутри разрешённой сети должен устанавливаться TCP-сеанс; с клиента вне разрешённой сети — нет. Используйте curl или другое штатное приложение, учитывая TLS/HTTP-протокол сервиса. В реальном журнале фиксируйте конкретный адрес тестового клиента, время запроса и номер затронутого правила.
Не считайте отсутствие ответа доказательством срабатывания iptables: сбой может быть в маршруте, приложении, гипервизоре или внешнем firewall.
Шаг 6. Долговременное сохранение¶
В SPEC НАЙС.ОС пакет iptables устанавливает iptables.service и вспомогательные файлы /etc/systemd/scripts/ip4save/ip6save. Без содержимого SourceN нельзя гарантировать, что ip4save является файлом правил, а не скриптом. Откройте systemctl cat iptables и сами файлы, после чего закрепите правило штатным механизмом системы. Затем проведите контролируемый reboot и повторите оба теста.
Откат¶
Если разрешён доступ к консоли, восстановите исходный набор правил подготовленной процедурой (например, предварительно проверенным iptables-restore из сохранённого файла) либо удалите только добавленное правило по его точной спецификации. Не прибегайте к iptables -F. Важны также DOCKER-USER, Docker NAT и действующие SSH-сеансы.
Связанные материалы: iptables, диагностика, сохранение правил, conntrack.