☰

iptables/nftables: как исключить весь пересылаемый трафик из отслеживания соединений на маршрутизаторе?

tag-icon • tag-icon iptables nftables
iptables/nftables: как исключить весь пересылаемый трафик из отслеживания соединений на маршрутизаторе?

Linux-бокс имеет несколько сетевых интерфейсов. IP-пересылка включена для IPv4 и IPv6.

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

Для брандмауэра с отслеживанием состояния я бы обычно использовал цепочки INPUT и OUTPUT таблицы фильтров. Пересылаемый трафик направлялся бы в цепочку FORWARD. Но, насколько мне известно, нет способа пометить трафик как неотслеживаемый в цепочке FORWARD. Такая логика должна идти в цепочку PREROUTING в необработанной таблице. Но, я полагаю, в цепочке PREROUTING еще не решено, пересылается трафик или нет.

Отслеживание соединений имеет много недостатков, таких как потеря пакетов, когда список отслеживаемых соединений достигает максимального размера.

Какой самый простой способ исключить перенаправленный трафик (и только перенаправленный трафик) из отслеживания соединений?

решение1

Для общего набора правил можно задатьnftablesсделать поиск маршрута заранее, используяfibвыражение вместо ожидания стека маршрутизации, чтобы сделать это. Это позволяет включить (будущее)выходинтерфейс, несмотря на то, что он еще не существует (решение о маршрутизации не было принято), за счет дополнительного поиска. Затем, если результаты говорят, что пакет будет маршрутизирован, предотвратите отслеживание с помощьюnotrackзаявление.

ВЫРАЖЕНИЯ FIB

fib {saddr | daddr | mark | iif | oif} [. ...] {oif | oifname | type}

Авыдумкавыражение запрашиваетвыдумка(база пересылки информации) для получения информации, такой как индекс выходного интерфейса, который будет использовать конкретный адрес. Вход — это кортеж элементов, который используется в качестве входа длявыдумкафункции поиска.

ЗАЯВЛЕНИЕ НЕТРЕКА

Оператор notrack позволяет отключить отслеживание соединений для определенных пакетов.

notrack

Обратите внимание, что для того, чтобы это утверждение было эффективным, его необходимо применять к пакетам доconntrackпроисходит поиск. Поэтому он должен находиться в цепочке спредварительная маршрутизацияиливыходкрючок и приоритет крюка -300 или ниже.

Поэтому следует провести «простую» проверку маршрутапредварительная маршрутизация, используя только адрес назначения в качестве селектора и проверяя наличие выходного интерфейса (немаршрутизируемые пакеты или пакеты, предназначенные для хоста, не будут разрешаться). Исключение длявот(loopback) интерфейс для его отслеживания: хотя он представляет локальный трафик, пакет, отправленный (черезвыходпуть) от хоста к себе возвращается черезпредварительная маршрутизацияпуть и имеет выходной интерфейсвоттоже. Поскольку исходящий пакет уже создалconntrackзапись, лучше сохранять последовательность.

nft add table ip stateless
nft add chain ip stateless prerouting '{ type filter hook prerouting priority -310; policy accept; }'
nft add rule ip stateless prerouting iif != lo fib daddr oif exists notrack

Замена ipсемейства на inetкомбинированное семейство должна распространить то же самое общее поведение на IPv4+IPv6.

Чтобы быть более конкретным, можно указать будущий выходной интерфейс, fib daddr oif eth1например, с помощью , который более или менее эквивалентен oif eth1, но также доступен впредварительная маршрутизация.

Конечно, если топология известна заранее, можно избежать поиска FIB, используя одно или несколько правил, основанных на тестах адресов, поскольку тогда маршруты известны администратору заранее. Может потребоваться сравнение результатов, чтобы узнать, интереснее ли это, чем сохранение универсального метода.

Например, с помощью предоставленной ОП информации заменим предыдущее правило на:

nft add rule ip stateless prerouting 'ip daddr != { 192.168.1.1, 192.168.2.1, 127.0.0.0/8 } notrack'

должен иметь почти эквивалентный эффект. 127.0.0.0/8 присутствует по тем же причинам, что и выше свотинтерфейс.

Обработка широковещательной рассылки (например, 192.168.1.255, полученной наeth0) и multicast (например, link-local 224.0.0.1, полученный на интерфейсе) могут работать не одинаково в обоих методах или не так, как ожидалось, и, возможно, потребуют дополнительных правил для определенных нужд, особенно со 2-м методом. Поскольку отслеживание широковещательной и multicast рассылки редко бывает полезным, потому что источник ответа не будет (и не может) быть исходным адресом назначения широковещательной или multicast, поэтому запись conntrack никогда не «увидит» двунаправленный трафик, это обычно не имеет большого значения для правил с отслеживанием состояния.

Примечания

  • Обычно это несовместимо с NAT с отслеживанием состояния.

    Насколько я понимаю, DNAT в направлении удаленного хоста получит ответный трафик, не де-NATированный, и произойдет сбой, а перенаправленный SNAT не сработает, поскольку не былоconntrackзапись создана. Редко используемый SNAT во входном пути должен быть в порядке, и комбинация DNAT+SNAT (использующая локальный источник адреса) также может работать, поскольку в обоих направлениях, исходном и ответном, задействован локальный пункт назначения, поэтомуconntrackтогда запись всегда должна быть правильно создана или просмотрена.

  • стандартный набор правил

    Фактические правила использованияiptablesилиnftables(в своей собственной другой таблице) может быть сделано как обычно, включая правила состояния для самого хоста. Поскольку маршрутизируемый трафик не будет создаватьconntrackзаписи, правила, если таковые имеются, связанные с таким трафиком, должны быть только без указания состояния и не должны использовать никаких ctвыражений, поскольку они никогда не будут соответствовать друг другу.

  • проверка поведения

    Даже без соответствующих правил брандмауэра можно проверить общее поведение следующим образом:

    • используя фиктивное ctправило, чтобы убедиться, чтоconntrackобъект регистрируется в текущем сетевом пространстве имен.

      nft add table ip mytable
nft add chain ip mytable mychain '{ type filter hook prerouting priority -150; policy accept; }'
nft add rule ip mytable mychain ct state new

    • использоватьconntrackинструмент для отслеживания событий:

      conntrack -E

    • генерировать трафик с удаленного

      НОВЫЙconntrackЗатем будут созданы записи для трафика, принимаемого маршрутизатором, но не для маршрутизируемого трафика.

Связанный контент