Просто любопытно. Пример в nftables вики разрешить связанные и установленные соединения, а затем сбросить недопустимые соединения. Это необходимо?
Если вы никогда не используете отвергать утверждение в любом правиле, не имеет большого значения отбрасывать или не отбрасывать недействительным пакеты. Если вы используете отвергать заявление, вам непременно следует отказаться от недействительным состояния.
Во многих случаях отбрасывание пакета в недействительным состояние не является обязательным: принимающий сетевой стек при получении такого пакета сам проигнорирует его. В любом случае можно представить, что есть ошибки, и что, когда система является маршрутизатором, выполнение этого защитит системы, находящиеся позади, если их реализация не сможет правильно справиться.
Есть один случай, когда становится обязательным падение недопустимые пакеты: это не так отвергать их. Это было недавно добавлен в iptables' документация:
Предупреждение: вы не должны без разбора применять цель REJECT к пакетам, состояние соединения которых классифицируется как INVALID; вместо этого вы должны только УБИРАТЬ их.
Рассмотрим исходный хост, передающий пакет P, причем P испытывает такую большую задержку на своем пути, что исходный хост выдает повторную передачу P_2, при этом P_2 успешно достигает своего пункта назначения и обычно продвигает состояние соединения. Возможно, что опоздавший P может считаться не связанным с какой-либо записью отслеживания соединения. Создание ответа отклонения для пакета, классифицированного таким образом, приведет к разрыву работоспособного соединения.
Итак, вместо:
-A INPUT ... -j REJECTрассмотрите возможность использования:
-A INPUT ... -m conntrack --ctstate INVALID -j DROP -A INPUT ... -j REJECT
Точно такое же поведение при использовании столы, поскольку оба полагаются на Conntrack. Такие инструменты, как Firewalld всегда получал правильно и вообще уронил недействительным заявляет, прежде чем делать какие-либо отвергать в их сгенерированных правилах. Пользователи, не знающие об этом, могли не сделать этого при создании правил вручную.
Просто переписав выше с столы в уме:
Netfilter's Conntrack проверяет гораздо больше, чем обычно думают. Например, с потоками TCP он также проверяет допустимость порядковых номеров по отношению к текущему окну TCP (PDF). Когда пакет задерживается (возможно, временно перенаправляется через Интернет на альтернативный более медленный путь), возможно, он прибывает после того, как такой пакет уже был повторно передан и успешно подтвержден ACK, таким образом, теперь он становится вне окна и помечен как недействительным штат. Теперь посмотрим, что происходит с этими правилами (в type filter hook input цепочка клиентского межсетевого экрана без обслуживания):
ct state established accept
tcp reject with tcp reset
reject
Такой недопустимый пакет (например, возникший во время длительной и огромной загрузки) вызовет TCP RST, прерывая загрузку. Хуже того, если бы правила не было в клиентской системе, но эквивалентное правило было в прямой цепочке брандмауэра маршрутизатора, администратор такой клиентской системы не имел бы ни малейшего представления о том, что произошло (за исключением, возможно, просмотра некоторых повторных передач до того, как соединение прервется в перехваченном трафике). .
Теперь с этим:
ct state established accept
ct state invalid drop
tcp reject with tcp reset
reject
Если вы уроните такой недействительным пакет, ничего не происходит, загрузка продолжается без изменений. При отсутствии правил брандмауэра это то, что сделал бы стек TCP: игнорировал такой пакет, не реагировал на него с помощью TCP RST.
Если вы не отбрасываете недействительные соединения явно, то nftables будет выполнять следующие правила. Если правила сопоставления нет, будет применена политика цепочки по умолчанию (которая по умолчанию - «принять»).
Так что это зависит от ваших следующих правил и политики по умолчанию. Но если, скажем, одно из ваших правил - принимать входящие пакеты на порт 22, вы действительно хотите сначала сбросить недопустимые соединения.