Iptables вместо firewalld ubuntu
Помогите, пожалуйста, разобраться. Вот есть netfilter/iptables, который пришел на смену ipchains. Netfilter - функции уровня ядра, iptables - userspace, через который настраиваются правила. Правильно? Дальше идет firewalld, который является, по сути, фронтендом к iptables. Верно? И тут в RHEL8 по дефолту попадаю на nftables, который вообще непонятно на каком уровне работает, причем firewalld имеет его поддержку и может дергать, как и iptables. Из-за нехватки компетенции, сложить пазл из официальной документации не получается, помогите.
- Зачем нужен firewalld? Это же, по сути, еще один уровень абстракции над netfilter/iptables? То есть, это все равно, что если бы в iptables передавались правила из еще одного iptables? Или неправильно понял?
- Вот тут совсем темнота. На каком уровне работает nftables? Является ли он заменой Netfilter на уровне ядра, либо это «коннектор» в виде микроВМ, который просто помог упразднить зоопарк *tables и является прослойкой к Netfilter? Вообще не понимаю, объясните как дураку, пожалуйста.
- Ну и риторический вопрос - стоит использовать nft, где он идет уже из коробки или(по консервативному невежеству) сносить вместе с firewalld и ставить iptables-services? Есть ли ощутимый профит от заявленного удобства и производительности?
Заранее спасибо вам за ответы!
На каком уровне работает nftables? Является ли он заменой Netfilter на уровне ядра
Ну и риторический вопрос - стоит использовать nft
Изучать точно стоит. А вот использование - наверное только после изучение. Нет времени изучать - используй iptables.
А пресловутый firewalld - это лишь упрощенная оболочка для обеих подсистем(iptables & nftables) которая вероятно имеет GUI интрфейс. Т.е. хочешь в GUI или минимально вникать - пользуй.
А пресловутый firewalld - это лишь упрощенная оболочка для обеих подсистем(iptables & nftables) которая вероятно имеет GUI интрфейс. Т.е. хочешь в GUI или минимально вникать - пользуй.
Гуй то то да, но нифига не упрощенный. Проще руками правил написать. И запихать скрипт в /etc/rc.local. Ну или самое прикольное в /etc/network/if-up.d
Спасибо большое за ответ! Теперь понятно.
Получается в том же RHEL8 на уровне ядра «из коробки» есть и netfilter и Nftables? Потому что удалив последний и установив iptables-services все отлично работает.
Если это так, то как разгуливаются коллизии при использовании обоих, по не знанию, скажем? Кто-то кого-то блокирует просто? Или iptables как-то транслируется в Nftables вместо netfilter через какой-то костыль? Вот этот момент не пойму.
есть слой совместимости для поддержки netfilter/iptables поверх Nftables.
Хорошая инструкция, тоже заморочался два года назад, когда вышал убунта 18.04, где можно было использовать nft вместо iptables.
Два года парился, ломал пальцы и мозги (всё-таки вся эта борода ближе к тому как правила использует компьютер, чем человек), пока в итоге не дочитался до того, что nftables и iptables это проект одной и той же команды и конечно же они сделали iptables-nft, который имеет тот же самый один в один синтаксис что и iptables, но использует kernel интерфейс nft. то есть просто привычная утилита которая не враппер над nftables, а просто имплементирует работу с kernel nft другим синтаксисом (всем привычным).
iptables-nft являются частью iptables, и допустим в убунте их можно просто включить с помощью alternatives.
посмотреть что используется можно сделав iptables -v, например это выглядит так:
iptables v1.8.4 (nf_tables): no command specified
и это значит что используется iptables-nft
Я реально два года пользовался nft но так и не смог к нему привыкнуть (а я сторонник всего нового) и через два года вернулся на iptables синтаксис, но безусловно пользуясь nft (потому что это крутой новый интефейс для фильтрации пакетов)
А как iptables-nft реализует сеты, словари, которых нет в классическом iptables?
А как с этим работет докер и его костыли?
извиняюсь что повторяюсь, но с iptables-nft докер прекрасно и без проблем работает (и kubernetes, вернее flannel и calico тоже).
fail2ban работает, да я думаю вообще всё работает. я перечислил только то, что я точно пробовал.
iptables-nft консольная утилита полностью повторяющая синтаксис iptables, но работающая с интерфейсом nft в ядре. то есть ей можно колбасить привычные правила и делать всё как обычно, под капотом это всё будет nftables (и даже отображаться в виде длиннющих правил если использовать утилиту nft)
а так в целом есть какие-то проекты типа использования nft вместо iptables для докера - но они в настолько зачаточном состоянии уже годы, что не стоит надеяться что ими можно будет пользоваться. мне кажется все кто хочет просто ставят iptables-nft и пользуются (я реально пытался запустить докер с поддержкой nft, и это где-то в 2020-м было даже хуже чем концепт)
Вот тут-то и проблема. Правила iptables-nft не видны через nftables и наоборот. В результате, та дичь, которую докер динамически добавляет через iptables-nft, не может нормально интрегрироваться в системе, где используется iptables-nft, и приходится всю систему переводить на "старый добрый" iptables в лице ipatables-nft.
Т.е. если у вас в системе есть несколько изолированных виртуальный сетевых интерфейсов, VPN'ы с различными правилами доступа к интерфейсам и серисам и т.п. Т.е. как раз тот случай, когда требуется сложное и гибкое конфигурирование фильтров и хочется использовать NFT, то наличие докера и его производных с их ублюдочными и кривым автоконфигурированием сетевых интерфейсов через iptables ломает абсолютно и всё.
и nft и iptables-nft это интерфейсы к nftables в ядре. они обе редактируют одни и те же правила и очевидно взаимозаменяемы.
в моей системе показывает тоже самое что и
nft list table ip filter
я вообще в своём ядре забанил модули которые отвечали за "классический" iptables, и старый iptables невозможно использовать в принципе, ни через cli ни через api. и всё нормально работает.
А докер работает? Свои правила нормально добавляет/удаляет?
вот кусок из iptables -L -n -v
вот кусок из nft list table ip filter
можно заметить что даже счётчики пакетов примерно совпадают (всё же там была секунда паузы между первой и второй командой). то есть это не дубликаты, это одни и те же правила в ядре, просто выведенные с помощью двух разных утилит
Можно попросить подсказать, как в ядре банили модули? Просто пересобрали, или? Перехожу как раз на nft и хочется не оставлять лазеек для пути назад :)
Да, я пересобирал на сервере где делал изначальные тестовые прогоны. Ну там вообще не только для этого ядро кастомное, так что было ок. Потом убедился что достаточно поменять iptables c iptables-legacy на iptables-nft через /etc/alternatives, и старые модули не подгружаются со временем от использования любого софта который у нас в продакшене, и дальше на серверах которые уже ставились с nft не парился. Я думаю можно в /etc/modprobe.d/blacklist.conf перечислить основные модули iptables-legacy:
и этого будет достаточно чтобы те кто попытаются дёрнуть за старый интерфейс обломились.
То есть теперь счётчики есть не для каждого правила, а только там где явно включено? И ещё, а есть ли в nft плагины? Совместимы ли плагины от iptables?
Да, счётчики опциональны.
Упоминания плагинов в документации не встречал.
Довольно похоже на pf.
Да. Много лет потребовалось, чтобы сделать что-то похожее на PF. Но вот с читабельностью так и не получилось.
Благодарю, осень полезно и подробно
Так вроде бы в Debian работает firewalld и дальше сам разбирается, не?А так всегда возникает вопрос «зачем?»
firewalld достаточен для простых вещей, типа открыть порт для чего-то, но для ряда случаев этого очень мало и приходится копать глубже.
В firewalld есть iptables-подобный язык для более сложных правил. Его должно хватать для большинства ситуаций.
А зачем, если есть настоящий iptables/nftables, в который эти правила всё равно транслируются?
Если у вас все правила "сложные", то незачем. А если у вас большинство задач типовые, но возникла необходимость что-то сложное сделать, то разумней использовать firewalld, с которым простые задачи решаются просто. Ну на мой взгляд так.
Тот неловкий момент, когда администраторы Facebook почитали данный мануал и пошли применять полученные знания на практике
Это точно для людей? Для человека удобнее именно табличный вид, а не парсить json Или у программеров это уже на уровне лимбической системы парстся?
А что сложного в чтении JSON? Вот таблички, у них внутри цепочки, условия проверяются сверху вниз
По сути базовые правила nft 1-в-1 как iptables, только по человечески сгруппированные и без мусорных дефисов
Вы сильно лукавите, что это просто. Это возможно, но отнюдь не просто, иначе зачем нужны бы были все эти плагины и оболочки над json? Элементарно, сравнить две строчки проще чем два "облака". Ну и странно пенять на мусорные дефисы при обилии скобок.
Особенно радует впихивание ; в командной строке с последующим его экранированием \;
Откройте для себя jq и у вас никогда не будет проблем с парсингом json
Ну и муть мутная!! Авторы этого интерфейса под веществами были скорее всего!
nftables и iptables это проект одной и той же команды
Вообще это не дело - иметь такой зоопарк файрволлов. ip,nfttables, pf, firewalld, возможно что-то еще. Притом каждый файрволл абсолютно несовместим по синтаксу с другим. Из всех перечисленных, более менее по user-friendly (но ущербнее по функционалу) это firewalld, но эта зараза напрочь ломает правила iptables - в итоге ни тот ни другой вместе нормально не пашут. Поэтому логичнее всего надо было оставить только один - iptables. Давеча был сильно разочарован в iptables на CentOS - оказалось там нет такой элементарной возможности как сохранить правила после перезагрузки. Карл, 21 век! WTF? И мне нужно извращаться в target это прописывать, где собственно ничерта и не заработало. Благо хоть в крон получилось засунуть что-то вроде /sbin/iptables-restore < somerules и отрабатывать это каждые 5 минут. Костыль, но хоть как-то пашет. Притом что в дебиане и убунте есть штатная утилита сохранения правил без всяких таргетов, скриптов и кронов. Мало того что есть куча разношёрстных файрволов. Так еще один и тот-же файрвол на разных ОС - тоже отличается. Бардак!
В iptables на CentOS всё так-же работает service iptables save , оно-же /usr/libexec/iptables/iptables.init save . Правда нужно доставить пакет iptables-services . После этого появляется /etc/sysconfig/iptables-config c IPTABLES_SAVE_ON_STOP , IPTABLES_SAVE_ON_RESTART .
До боли знакомый ключик - не пашет, точно могу сказать. Возможно трабл в том, что я ставил openvpn из готового скрипта, а как он там настроен "из коробки" только писателям того скрипта известно. В любом случае такая мелочь как iptables-persistent в любом linux-дистре должен быть в коробке, а это утилитки охх как не хватает мне в моей конфе.
Сейчас в CentOS «из коробки» - firewalld, а всё остальное - по желанию :)
Я даже больше обрадую вас - уже так лет 7. Вроде как с Centos 7.
sudo yum remove -y firewalld
sudo yum install -y iptables-services
sudo systemctl daemon-reload
sudo systemctl enable iptables
В смысле напрочь ломает правила iptables? Если вы о тех, которые сами в обход firewalld настраивали — то да, хотя любой файрволл считает, что он тут один командует, и под себя создает все цепочки фильтров и тому подобные структуры уровня ядра. А так у него есть firewalld add rule с функционалом практически эквивалентным iptables, но в рамках firewalld'овских цепочек, т.е. пихается сильно ниже по ветвлению, чем правило iptables -A INPUT.
Ужас, то ли дело бсдёвый ipfw. Оно может хорошо и функционально на каких то защитных шлюзах, но на обычных серверах, тем более на рабочем десктопе, ну нафик.
Ну вот и зачем ломать то, что и так прекрасно работает? Иптейблс прекрасен, прост и понятен, а это треш какой-то
iptables, arptables, ebtables, ipset - делались каждый по отдельности. А тут собрали всё вместе, порефакторили и причесали.
Мне тоже лень переучиваться, но надо.
Нет, не надо. В этом нет смысла.
А я ни то, ни другое не учил, как теперь выбирать? :)
Ничего не знаешь — учи наиболее популярное из того, что не deprecated. Здесь nftables.
Учитывая, что nftables ещё долго и много где будут использоваться через эмуляцию iptables - пока что придётся выбирать оба.
А потом придёт bpfilter с синтаксисом iptables и надо будет всё вспоминать
История говорит, что будет другой ещё более замысловатый синтаксис с элементами того, другого и ещё чего-нибудь третьего.
Разработчики ведра, попив пивка в гермашке, решили выкинуть на мороз iptables. Старые тулзы переименуют в iptables-legacy, а новые будут называться как старые, но будут использовать nf_tables.
Сделано это, чтобы не шокировать ветеранов unix-администрирования. Всем остальным предлагается переходить на firewalld nftables.
Годно, хоть какие-то подвижки теперь будут.
Я все-таки не пойму, ну зачем нарочно ломать? Какой-нибудь скрипт где-то 100 пудов поломается. Хорошо, если админ будет знать, что надо просто переименовать, а если ситуация, когда новый дистр, а на нем что-то старое не поднимается? Или просто, скомпилил новое ядро и хренак отвалилось.
И это не единственный случай
Линукс постепенно хуже виндов делается в плане совместимости.
praseodim ★★★★★ ( 21.06.18 15:47:05 )Последнее исправление: praseodim 21.06.18 15:48:24 (всего исправлений: 2)
Ох. где можно найти документацию на nftables и как теперь настраивать сеть?
Вечное легаси - это тоже не ок, надо идти вперед. nftables появилось еще в 3.13, ЕМНИП, так что времени было много.
Человечеству. Ну и лично тебе тоже.
Сейчас повыползают травмированные айпитейблсом пациенты и начнут рассказывать, как в километровых конфигах трава была зеленее.
Не вижу проблем.
nftables появилось еще в 3.13, ЕМНИП, так что времени было много.
А зачем принуждать?
Хипстеры готовы постоянно переписывать, все что старее одного года.
Наконец структурированные правила, а не наркоманские стены текста.
С пониманием к NIH-синдрому, но чего бы не напрягать своим зудом человечество и не назвать поделку iptables-new-super.
1) зачем переименовывать iptables в iptables-legacy, если новое называется nf_tables. кому iptables может помешать? или надо обязательно явно указать что оно legacy чтобы всем видно было, кто первый раз столкнулся?
2) ну никто же не запретит нам сделать ln -s /usr/bin/iptables-legacy /usr/bin/iptables
а там этот, очкастый гремлин на букву П к этому событию не приложился?
надо обязательно явно указать что оно legacy чтобы всем видно было, кто первый раз столкнулся?
Да. Иначе народ будет пользовать iptables, пока его окончательно не выпилят, и тогда всё равно придётся переучиваться, но уже в срочном порядке.
2) ну никто же не запретит нам сделать ln -s /usr/bin/iptables-legacy /usr/bin/iptables
Мешать будет бинарь /usr/bin/iptables, транслирующий правила iptalbes в формат nf_tables.
а там этот, очкастый гремлин на букву П к этому событию не приложился?
Pablo Neira Ayuso? Приложился, и весьма сильно.
кстати, а net-tools уже выпилили окончательно из дистрибутивов? все уже перешли на iproute2? тоже же долго кота тянули.
а когда ipchains меняли на iptables, так же было?
Не знаю, я слишком молод.
ЕМНИП, там синтаксис был похожий, должно было быть проще.
2) ну никто же не запретит нам сделать ln -s /usr/bin/iptables-legacy /usr/bin/iptables
Не запретит, но об этом надо знать (и о 100500 аналогичных случаев), а теперь представляем себе админа у которого внезапно в новом дистре или на новом ядре поломались правила.
Причем, можно этого даже не заметить сразу. Ну отвалился файрвол, ну поимели через какой-то сервис, который не настраивали торчать в интернет. Зато борьба с легаси.
Проект iptables, разработанный Расти Расселом (Rusty Russell) в 1999 году для управления netfilter и заменивший в ядре 2.4 ipchains и ряд других инструментов вроде ipnatctl, предлагает более расширяемый способ фильтрации пакетов, обеспечивающий сисадмину больший контроль при упрощении самих правил. Так, в ipchains нужно было создавать правило в каждой цепочке, прослеживая весь маршрут пакета, теперь достаточно одного. Появление модулей позволяло очень просто расширять возможности. В процессе развития проекта iptables был портирован для IPv6 (в 2011 году, ip6tables), добавлялись дополнительные модули (ULOG, nf_conntrack), он научился производить разные манипуляции с пакетами, классифицировать трафик (до седьмого уровня OSI), балансировать нагрузку и многое другое. С ростом количества функций усложнились и настройки. При этом, даже несмотря на некоторую унификацию, каждое расширение имеет свой синтаксис, одни поддерживают диапазоны, отрицание, префиксы, другие — нет. Поначалу каждое изменение правил требовало полного перезапуска брандмауэра, включая выгрузку модулей, что приводило к разрыву установленных соединений. Сейчас такой проблемы нет.
Для простых случаев настройка при помощи iptables — дело нехитрое, но в сложных сетях управлять большим количеством правил становится тяжело; чтобы изучить все настройки и понять, как оно работает, нужно потратить время. Трудно с ходу разобраться, что делают все цепочки, правила начинают повторяться, их становится сложно обслуживать, обновлять и переносить на другие системы.
Неудивительно, что для решения этих проблем были придуманы разные надстройки. Так, в Ubuntu для простой настройки правил используется ufw (Uncomplicated Firewall — несложный файрвол). Например, чтобы открыть доступ к SSH-порту, достаточно ввести
Разработчики приложений могут создавать готовые профили, которые активируются при установке пакета, избавляя пользователя от выдумывания и ввода правил.
Под капотом FERM находится обычный Perl-скрипт, который конвертирует конфигурационные файлы в правила iptables.
В Fedora 18 был анонсирован демон firewalld, ставший официальным приложением для управления настройками netfilter в RHEL 7 / CentOS 7. Последние становятся все популярнее на VDS, а значит, придется столкнуться с их особенностями.
Возможности firewalld
Firewalld запускается как демон, новые правила добавляются без перезапуска и без сброса установленного файрвола. Изменения в конфигурации могут быть сделаны в любое время и применяются мгновенно: сохранять или применять изменения не требуется. Поддерживается IPv4, IPv6, автоматическая загрузка модулей ядра и сетевые зоны, определяющие уровень доверия соединений. Предоставляется простой интерфейс добавления правил для служб и приложений, белый список приложений, имеющих право менять правила. В настоящее время такую возможность поддерживает libvirt, Docker, fail2ban, Puppet, скрипт установки Virtuozzo и многие другие проекты. В репозитории YUM уже есть пакеты fail2ban-firewalld и puppet-firewalld, поэтому подключить их можно одной командой.
Firewalld предоставляет информацию о текущих настройках брандмауэра через D-Bus API, а также принимает изменения через D-Bus с использованием методов аутентификации PolicyKit. В качестве бэкенда используются iptables, ip6tables, ebtables, ipset и планируется nftables. Но сами правила, созданные непосредственно этими утилитами, firewalld не может разобрать, поэтому оба метода использовать нельзя.
Управление производится при помощи утилит командной строки firewall-cmd или графической firewall-config, позволяющей настроить все правила в удобной среде. Для помощи в миграции текущих правил iptables на firewalld используется утилита firewall-offline-cmd, по умолчанию считывающая /etc/sysconfig/system-config-firewall . В последних релизах появилась утилита firewallctl, имеющая простой синтаксис и позволяющая получать информацию о состоянии службы, конфигурации брандмауэра и изменять правила.
Графическая firewall-config поддерживает firewalld
Параметры firewall-cmd
Разрешить соединение на определенный порт очень просто:
Чтобы любые изменения вступили в силу, всегда после правок должна быть запущена команда
Для удаления порта из правил используется параметр --remove-port :
Вообще, многие команды --add-* имеют значения для проверки статуса --query-* , --list-* — список, изменения --change-* или удаления --remove соответствующего значения. Для краткости на этом не будем дальше заострять внимание. После релоада правил проверяем:
В firewalld предусмотрен режим, позволяющий одной командой заблокировать все соединения:
Для проверки, в каком режиме находится файрвол, есть специальный ключ:
Отключается panic mode:
В firewalld необязательно знать, какой порт привязан к сервису, достаточно указать название сервиса. Все остальное утилита возьмет на себя.
После установки firewalld знает настройки более 50 сервисов, получаем их список.
Используя фигурные скобки, можно задавать сразу несколько сервисов. Информация по настройкам сервисов доступна при помощи
Firewalld хранит все настройки в XML-файлах в каталогах в /usr/lib/firewalld. В частности, сервисы лежат в services. Внутри файла описание: название, протокол и порт.
Это каталог системный, и менять там ничего нельзя. Если нужно переопределить настройки или создать свой сервис, то копируем любой файл в качестве шаблона в /etc/firewalld/services , правим под свои условия и применяем настройки.
Для настройки ICMP используется отдельный набор правил. Получаем список поддерживаемых типов ICMP:
Все настройки firewalld хранит в XML-файлах
Firewalld знает о почти 50 сервисах
Управление зонами
Для определения уровня доверия сетевому соединению в firewalld используются зоны. Зона может содержать несколько сетевых подключений, но сетевое соединение может входить только в одну зону. Список всех зон получаем командой firewall-cmd --get-zones .
Получаем список зон
После установки создается девять зон, в зависимости от назначения может быть использована одна или несколько зон:
Описания зон также представлены в XML-файлах в /usr/lib/firewalld/zones .
После установки системы обычно используется зона public. Если имеющихся зон недостаточно, то можно создавать новые зоны при помощи
Настройки зон по умолчанию
Все пакеты, не попадающие под определенные зоны, обрабатываются в зоне по умолчанию.
Теперь — какие зоны сейчас активны и какие интерфейсы к ним привязаны.
Также можем получить обратную информацию — к какой зоне привязан интерфейс.
Смотрим настройки зоны (сервисы, порты, протоколы. ).
Если параметр пуст, то это значит, что настройки не установлены. При необходимости переназначаем интерфейс зоне:
Если сейчас проверить вывод firewall-cmd --zone=public --list-all , то увидим, что из списка установок пропал сетевой интерфейс. Разрешим подключение сервиса:
Удаляется он так же:
К зонам можно привязывать и другие источники, определяемые по MAC, отдельному IP или адресу сети. Пакет, пришедший из такого источника, будет обрабатываться по правилам зоны.
Список всех source смотрим при помощи --zone=trusted --list-sources . NAT, позволяющий нескольким компьютерам подключаться к сети, в firewalld включается одной командой. Смотрим текущие настройки маскарадинга:
Если в ответ получим no , то включаем:
Это все. Для доступа извне настроим форвардинг порта в один из компьютеров. Например, нам нужен доступ по SSH к внутреннему серверу:
Удаляется правило форвардинга при помощи --remove-forward-port .
Сложные правила
Для отдельного ПК или небольших сетей базовых возможностей вполне хватает, для настройки сложных правил в firewalld изначально предлагался так называемый direct-синтаксис, чуть позже появился собственный язык Rich Language. В первом варианте достаточно знать синтаксис iptables, рекомендуется использовать в крайнем случае, так как правила не сохраняются после перезагрузки.
Синтаксис direct правила такой:
Добавляем правило, разрешающее соединение по 25-му порту:
Пробросим соединение по 22-му на другой сервер:
Большой плюс Rich Language в том, что все параметры можно описать в XML в файле зоны. Формат файла очень простой и повторяет названия параметров:
Настройка файрвола — дело привычки. Часто удобнее вбить команду, которой пользуешься уже не один год, чем осваивать новую утилиту. Поэтому иногда все-таки хочется вернуть классический инструмент. Это не проблема. Iptables в CentOS 7 не ставится, поэтому его нужно вернуть:
Чтобы не настраивать все повторно, лучше сохранить текущие правила, сгенерированные firewalld.
Останавливаем firewalld и запускаем iptables:
Проверяем текущие правила:
Запрещаем автозапуск firewalld при загрузке ОС:
Выводы
Как видишь, ничего сложного! Firewalld очень упрощает установки, особенно если учесть, что настройки легко перенести.
Читайте также: