Какой опыт работы с сетевыми экранами (firewall)

Что проверяют

Понимаете ли вы, как фильтрация трафика устроена на хосте, в облаке и в кластере, и умеете ли менять правила, не отрезав доступ самому себе. Уточняют обычно так: «как закрыть доступ к базе отовсюду, кроме приложения».

Как отвечать

Разложите опыт по уровням, где DevOps встречает межсетевой экран:

• хост Linux: netfilter и его интерфейсы. iptables с цепочками INPUT, OUTPUT, FORWARD и таблицами filter и nat; nftables как современная замена, в свежих Debian и RHEL iptables обычно и так работает поверх nftables; обёртки ufw и firewalld;
• stateful-фильтрация: правило вида ct state established,related accept пропускает ответы, поэтому открывать нужно только входящие соединения. Порядок важен: срабатывает первое подходящее правило;
• облако: группы безопасности хранят состояние и вешаются на интерфейс, сетевые ACL в AWS без состояния и вешаются на подсеть. Правило со ссылкой на группу приложения надёжнее диапазона адресов;
• Kubernetes: NetworkPolicy работает, только если её поддерживает CNI, например Calico или Cilium. Пока политик нет, поды общаются друг с другом без ограничений;
• L7: WAF и ограничение частоты запросов перед приложением;
• страховка: правила в коде (Ansible, Terraform), на удалённой машине iptables-apply или таймер отката, консоль провайдера как запасной вход.

Дальше один случай: как переводили правила на nftables или искали, почему сервис недоступен, по счётчикам пакетов на правилах. Детали ваши: сколько серверов, где хранились правила. Если с аппаратными экранами не работали, так и скажите и опирайтесь на хостовые и облачные.

Где спотыкаются

Ставят политику DROP по умолчанию раньше, чем разрешили SSH, и теряют доступ к серверу.

Не знают, что Docker сам пишет правила в iptables и публикует порты в обход ufw. Закрытый в ufw порт контейнера остаётся открытым из интернета. Помогают цепочка DOCKER-USER или привязка порта к 127.0.0.1.

Открывают порт базы на 0.0.0.0/0 «на время» и забывают закрыть.