Nftables. Как выглядит будущее настройки файрвола в Linux

Начинающие админы часто считают, что файрвол в Linux называется iptables. Более опытные знают, что нынешняя подсистема ядра для фильтрации трафика и модификации пакетов называется NetFilter, а команда iptables всего лишь утилита для ее настройки. В этой статье я познакомлю тебя с новым инструментом, который все чаще встречается в современных дистрибутивах, — nftables.

INFO

Возможно, для тебя это будет новостью, но iptables вовсе не уникальна, есть и другие утилиты подобного рода. Собственно, настраивать ей можно только правила для пакетов IPv4 на сетевом уровне. Для IPv6 понадобится ip6tables, для канального уровня — ebtables и arptables.

Настройка сетевых интерфейсов, маршрутов, пространств имен и прочего уже давно унифицирована в утилите ip из пакета iproute2, а зоопарк старых утилит (ifconfig, vconfig, route и прочие) поддерживается только для совместимости со старыми скриптами. Ждет ли такая же унификация межсетевой экран? До версий ядра 2.4 Linux прошел через множество реализаций межсетевых экранов в ядре и утилит для их настройки (ipfilter, ipfwadm, ipchains), но NetFilter и iptables используются уже почти двадцать лет и кажутся незыблемыми.

Как ни странно, первые попытки переосмыслить настройку МСЭ предпринимались еще в 2008 году. Проект назвали nftables, но он стал легендарным (в узких кругах) долгостроем. В 2014 году его наконец приняли в основную ветку ядра 3.13, но пользовательские утилиты какое-то время оставались почти непригодными к работе. К примеру, счетчики пакетов для правил хранились в ядре, но просмотреть их из пространства пользователя не было никакой возможности.

Сейчас дело наконец меняется и дистрибутивы даже начинают использовать nftables по умолчанию. Сторонние инструменты вроде fail2ban тоже уже добавляют ее поддержку.

Несколько причин расстаться с iptables и перейти на nftables:

  • унифицированный синтаксис;
  • быстрая загрузка больших конфигов;
  • встроенная поддержка списков адресов/портов;
  • средства автоматической конвертации правил из iptables;
  • вывод правил в JSON.

В этой статье мы перенесем настройки моего VPS с iptables на nftables. Использовать сразу оба инструмента на одной машине не выйдет, так что нужно планировать одномоментную миграцию.

Документацию можно найти в вики проекта.

Проблемы iptables

Хотя NetFilter вполне хорошо справлялся со своей задачей, его настройка через iptables нередко оказывалась куда сложнее, чем могла бы быть.

К примеру, встроенный синтаксис для групп адресов и сетей в нем так и не появился. Существует отдельный инструмент для этих целей — ipset, который позволяет создать группы и ссылаться на них в правилах, вроде iptables -I FORWARD -m set --match-set TrustedHosts src -j ACCEPT.

Однако само то, что группы настраиваются отдельно от правил и с помощью другой утилиты, создает много проблем. Нужно помнить два разных синтаксиса, да еще и убедиться, что настройки ipset при загрузке применяются раньше правил iptables, — это при том, что во многих дистрибутивах Linux встроенного сервиса для ipset так и нет.

Другая надоедливая проблема — нельзя указать несколько разных действий в одном правиле.

Хотя еще больше раздражает отсутствие возможности использовать одни правила для IPv4 и IPv6. В современном мире dual stack уже стал нормой на серверах, машин с одним IPv4 все меньше, а машин с одним IPv6 нет и не предвидится, в итоге админу приходится дублировать одни и те же правила в двух разных конфигах.

Кроме того, в некоторых местах синтаксис опций iptables достаточно хрупкий. Где-то можно ставить пробел после запятой, где-то нет. Где-то можно смело поменять две опции местами, где-то это вызовет ошибку. Если правила генерируются скриптом, это особенно усложняет тестирование.

Все это приводит к тому, что iptables часто используют как своеобразный низкоуровневый «язык ассемблера», который генерируется либо фронтендами вроде shorewall или firewalld, либо пользовательскими скриптами. А цель проекта nftables — в первую очередь сделать настройку правил простой и удобной для человека. Давай посмотрим, насколько это удалось.

Продолжение доступно только участникам

Материалы из последних выпусков становятся доступны по отдельности только через два месяца после публикации. Чтобы продолжить чтение, необходимо стать участником сообщества «Xakep.ru».

Присоединяйся к сообществу «Xakep.ru»!

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score! Подробнее

Даниил Батурин: Координатор проекта VyOS (https://vyos.io), «языковед», функциональщик, иногда сетевой администратор

Комментарии (6)

  • Честно говоря, после синтаксиса "nftables" как раз захотелось достать огнемёт, настолько нечеловеко-читаемым кажется синтаксис. Особенно после "ufw" или "firewall-cmd".
    IMHO, основная проблема как раз связана с малым количеством опорных визуальных элементов в синтаксисе. В iptables цепляешься за названия цепочек, action'ы, значения ip/port. А с "nftables" ощущение, что однозначная тех.документация превратилась в некоторую художественную прозу.

  • всё это закончится сочинением новой надстройки над этим адом. я одно понять не могу. в чем была проблема использовать команды из iptables для nftables? был бы новый чёрный ящик со старыми командами. чем дальше - тем менее понятно визуально и плохочитаемо

  • "Затем мы создадим две группы, одну для IPv4, другую для IPv6. Увы, использовать оба типа адресов в одной группе не выйдет" и "Хотя еще больше раздражает отсутствие возможности использовать одни правила для IPv4 и IPv6. В современном мире dual stack уже стал нормой на серверах, машин с одним IPv4 все меньше, а машин с одним IPv6 нет и не предвидится, в итоге админу приходится дублировать одни и те же правила в двух разных конфигах." и где спрашивается выигрыш???

    • В IPset мешать адреса из разных протоколов в одной группе точно так же нельзя. Поиск по массиву с элементами разного размера всегда гораздо медленнее, чем с элементами одинакового.

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

      Надстройки всегда будут, у всех разные вкусы и цели. Но и писать их здесь проще, хотя бы надстройка над одним инструментов, а не над тремя как минимум (iptables, ip6tables, ipset).

  • iptables если найти и прочитать полный мануал, ОЧЕНЬ мощный, проверенный временем инструмент, зачем менять ШИЛО на МЫЛО, когда он есть почти везде.

  • Вот жеж гадство... я только начал понимать iptables...

Похожие материалы