Почему могут быть видны пакеты в сети, если firewall должен блокировать их?

Почему файрвол может пропускать "заблокированные" пакеты

Это классическая проблема в работе с сетевыми экранами (firewall), которая регулярно встречается в практике любого DevOps/SRE инженера. Причины кроются не в том, что файрвол "не работает", а в особенностях работы сетевого стека Linux/ОС, настройках политик и архитектурных нюансах. Рассмотрим основные сценарии.

1. Неверный порядок правил и тракт обработки

Правила большинства файрволов (как iptables/nftables в Linux) обрабатываются сверху вниз в рамках каждого тракта (chain). Если пакет попал под первое разрешающее правило, последующие блокирующие – игнорируются.

# НЕВЕРНЫЙ пример: блокировка в конце не сработает для SSH
iptables -A INPUT -p tcp --dport 22 -j ACCEPT  # Правило 1: Разрешили SSH
iptables -A INPUT -s 192.168.1.100 -j DROP     # Правило 2: Заблокировали IP. Для SSH оно уже не применится!

# ВЕРНЫЙ пример: блокировка в начале
iptables -I INPUT 1 -s 192.168.1.100 -j DROP   # Правило 1: Блокировка
iptables -A INPUT -p tcp --dport 22 -j ACCEPT  # Правило 2: Общее разрешение SSH

2. Трафик не проходит через ожидаемый тракт или таблицу

В iptables есть несколько таблиц (filter, nat, mangle, raw). Правила для фильтрации обычно в filter. Но пакет сначала может быть перенаправлен (DNAT) в таблице nat, минуя INPUT-цепь filter. Кроме того, важно различать цепочки INPUT (входящие на сам хост), FORWARD (транзитные) и OUTPUT (исходящие).

• Случай сервиса с портом 8080:

  # Правило блокирует входящие подключения на порт 8080
  iptables -A INPUT -p tcp --dport 8080 -j DROP
  # Но если настроен DNAT c 80 на 8080, пакет сначала попадёт в PREROUTING цепь таблицы nat
  iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination :8080
  # В этом случае для внешнего клиента порт "80" открыт, и он видит ответ от 8080.
  

3. Состояния соединений (stateful inspection) и RELATED/ESTABLISHED

Современные файрволы часто являются stateful. Правило, разрешающее ответные пакеты установленных соединений, обычно стоит одним из первых для корректной работы протоколов.

# Разрешаем ответы на иницированные нами запросы
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j DROP # Блокируем новые входящие на 443

• Проблема: Если вы видите "ответные" пакеты, это нормально — они подпадают под правило ESTABLISHED. Заблокированы будут только новые попытки SYN на порт 443 извне.

4. Альтернативные пути трафика

• Loopback-интерфейс (lo): Правила часто применяются только к внешним интерфейсам (eth0). Трафик внутри хоста (127.0.0.1) может проходить свободно.
• Другие сетевые интерфейсы или VLAN: Правило может быть привязано к конкретному интерфейсу (-i eth0), тогда пакет, пришедший через eth1 или виртуальный интерфейс (docker0, veth*, tun0), будет проигнорирован.
• Policy Routing: Пакет может быть направлен по другому таблице маршрутизации, где для него определен иной путь, обходящий файрвол.

5. Приложения с RAW-сокетами или CAP_NET_RAW

Некоторые приложения (например, tcpdump, nmap) или malware могут использовать RAW-сокеты или иметь capability CAP_NET_RAW. Это позволяет им обходить часть сетевого стека ядра и получать/отправлять пакеты напрямую, минуя правила фильтрации. Для диагностики такие приложения сами часто этим пользуются.

6. Ошибки приоритета в системе Cloud/Orchestration

В облачных средах (AWS Security Groups, GCP Firewall Rules, k8s Network Policies) действует многоуровневая защита. Правило на уровне виртуальной сети или группы безопасности может разрешать трафик, в то время как локальный файрвол на инстансе пытается его заблокировать. Обычно облачные правила имеют приоритет (работают раньше ОС на виртуальной машине).

Методика диагностики

1. Определите точку наблюдения. Откуда вы видите пакеты? (tcpdump -i any port 8080).
2. Проверьте полный набор правил. iptables-save или nft list ruleset. Ищите правила во всех таблицах.
3. Анализируйте логи файрвола. Добавьте логирование для спорных правил.

   iptables -I INPUT -p tcp --dport 8080 -j LOG --log-prefix "BLOCK-8080: "
   iptables -I INPUT -p tcp --dport 8080 -j DROP
   

    Просмотр логов: `journalctl -k -f` или `dmesg -T -w`.

1. Проверьте состояние соединений. conntrack -L | grep :8080.
2. Включите трассировку пакета (для сложных случаев). Используйте trace в nftables или более низкоуровневые инструменты вроде bpftrace.

Таким образом, видимость "заблокированных" пакетов почти всегда объяснима сложной, но логичной моделью обработки сетевого трафика в современных системах. Ключ к решению — системное понимание порядка обработки и использование инструментов трассировки, а не предположение о неисправности файрвола.