netfilter / iptables: почему бы не использовать необработанную таблицу?

В Linux мы обычно используем таблицу «filter» для выполнения общей фильтрации:

iptables --table filter --append INPUT --source 1.2.3.4 --jump DROP
iptables --table filter --append INPUT --in-interface lo --jump ACCEPT

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

Итак, мы можем написать:

iptables --table raw --append PREROUTING --source 1.2.3.4 --jump DROP
iptables --table raw --append PREROUTING --in-interface lo --jump ACCEPT

пакеты обрабатываются быстрее, без необходимости проходить через conntrack + mangle + nat + маршрутизацию. Таким образом, используется немного меньше ресурсов процессора / памяти (и, в свою очередь, слегка компенсируется тем, что модуль iptable_raw должен быть загружен)
только одно правило в случае, если блок также является маршрутизатором (очевидно, он не подходит для всех правил), поскольку нет необходимости добавлять одно и то же правило для фильтра / пересылки

Я делал только быстрые тесты, и это прекрасно работает.
Документация, которую я нашел, всегда описывает необработанную таблицу, которая будет использоваться в строгих случаях. Но никто не дает даже малейшего оправдания.

Вопрос: есть ли причины не использовать необработанные таблицы, кроме догматических?

linux iptables

— Грегори МУССАТ
источник

Если вы просто хотите отбросить весь трафик с определенных IP-адресов, тогда с необработанной таблицей все в порядке. Однако брандмауэр часто немного более детализирован, поэтому в конечном итоге вы получите некоторые правила в raw и некоторые правила в filter. Это делает обслуживание головной болью и упрощает, что стоит пару циклов ЦП.

— wurtel

Если это просто проблема с головной болью, я думаю, что мы должны найти несколько примеров, говорящих о необработанной таблице. Поскольку это не так, теория головной боли, вероятно, не является основным фактором.

— Грегори МУССАТ

Автор ipset рекомендует использовать необработанную таблицу для правил iptables ipset ipset.netfilter.org/tips.html

— Стюарт Кардалл

От человека Iptables :

raw: This table is used mainly for configuring exemptions from connection
     tracking in combination with the NOTRACK target. It registers at the
     netfilter hooks with higher priority and is thus called before
     ip_conntrack, or any other IP tables.
     It  provides the following built-in chains:

     - PREROUTING (for packets arriving via any network interface)
     - OUTPUT (for packets generated by local processes)

Анализ :

Таким образом, таблица RAW находится перед conntrack и была разработана с целью ее использования для установки метки NOTRACK на пакетах, которые вы не хотите отслеживать в netfilter.

Цели -j не ограничиваются только NOTRACK, поэтому вы можете фильтровать пакеты в необработанной таблице с преимуществами меньшего потребления ЦП / памяти.

Чаще всего серверам не нужно отслеживать все соединения. Отслеживание необходимо только в том случае, если вам нужно отфильтровать пакеты в iptables на основе ранее установленных соединений. На серверах, которые служат только простой цели, например, с открытым только портом 80 (и, возможно, 21), этого не требуется. В этих случаях вы можете отключить отслеживание соединения.

Однако, если вы пытаетесь запустить маршрутизатор NAT, все становится немного сложнее. Для того, чтобы что-то NAT, вам нужно отслеживать эти соединения, чтобы вы могли доставлять пакеты из внешней сети во внутреннюю сеть.

Если целое соединение установлено с помощью NOTRACK, то вы также не сможете отслеживать связанные соединения, помощники conntrack и nat просто не будут работать для неотслеживаемых соединений, равно как и связанные ошибки ICMP. Другими словами, вам придется открыть их вручную. Когда дело доходит до сложных протоколов, таких как FTP и SCTP и других, это может быть очень трудно управлять.

Варианты использования :

Одним из примеров может быть, если у вас есть маршрутизатор с интенсивным трафиком, на котором вы хотите настроить брандмауэр входящего и исходящего трафика, но не маршрутизируемого трафика. Затем вы можете установить метку NOTRACK, чтобы игнорировать перенаправленный трафик для экономии вычислительной мощности.

Еще один пример использования NOTRACK: если у вас есть веб-сервер с высокой посещаемостью, вы можете настроить правило, которое включает отслеживание для порта 80 на всех локальных IP-адресах или на тех, которые фактически обслуживают веб-трафик. После этого вы можете наслаждаться отслеживанием состояния во всех других службах, за исключением веб-трафика, который может сэкономить некоторую вычислительную мощность в уже перегруженной системе.

Пример -> запуск-полу-состояния-linux-router-for-private-network

Вывод : нет веских причин не использовать необработанную таблицу, но есть некоторые причины, по которым следует соблюдать осторожность при использовании цели NOTRACK в необработанной таблице.

— Факундо Виктор
источник