firewalld vs iptables - когда использовать который [закрыт]


29

TL; DR На новых установках сервера CentOS я должен использовать firewalld или просто отключить это и вернуться к использованию /etc/sysconfig/iptables?


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

Я много знаю о iptables, но очень мало о firewalld.

На Fedora и RHEL / CentOS - традиционная конфигурация iptables была сделана в /etc/sysconfig/iptables. С firewalld, его конфигурация живет /etc/firewalld/и представляет собой набор файлов XML. Fedora, похоже, движется в сторону firewalld в качестве замены этой устаревшей конфигурации. Я понимаю, что firewalld использует iptables под капотом, но у него также есть свой собственный интерфейс командной строки и формат файла конфигурации, как указано выше - это то, что я имею в виду в отношении использования одного против другого.

Есть ли конкретная конфигурация / сценарий, для которого лучше всего подходит каждый из них? В случае NetworkMangaer против сети, похоже, что хотя NetworkManager и задумывался как замена сетевых сценариев, из-за отсутствия поддержки сетевого моста и некоторых других вещей, многие люди просто не используют его в настройках сервера на все. Так что, похоже, существует общая концепция «использовать NetworkManager, если вы работаете в Linux desktop/gui, и сеть, если вы работаете на сервере». Это именно то, что я извлекаю из чтения различных постов, но оно, по крайней мере, дает руководство относительно того, как можно использовать эти вещи - по крайней мере, когда они находятся в своем текущем состоянии.

Но я делал то же самое с firewalld и просто выключал его и вместо этого использовал iptables. (Я почти всегда устанавливаю Linux на сервер, а не для настольного использования). Является ли firewalld эффективной заменой iptables, и я должен просто использовать это на всех новых системах?


10
Firewalld использует iptables внизу.
user9517 поддерживает GoFundMonica

Конечно, и это имеет смысл. Но очевидно, что существует большая разница между тем, как вы храните конфигурацию и каким инструментом вы пользуетесь - iptables vs firewall-cmd, / etc / sysconfig / iptables vs /etc/firewalld/.../*.xml. Я рассмотрю вопрос немного, чтобы прояснить это.
BGP

Нет необходимости «очищать весь набор правил каждый раз, когда появляется шанс» iptables. Это просто интерфейсный инструмент, если он очищает таблицы, потому что вы сказали это.
gparent

Чтобы уточнить, я имею в виду «перезапуск службы iptables», в результате чего правила будут удалены и повторно добавлены. (Хотя это по-прежнему не влияет на состояние соединения, что хорошо.) Конечно, вы можете просто запустить команду iptables из командной строки, чтобы изменить отдельные правила - но я обычно стараюсь хранить все в / etc / sysconfig / iptables и используйте команду "service", чтобы придерживаться соглашения, предложенного инструментами, предоставленными дистрибутивом.
BGP

Ответы:


12

Поскольку firewalldон основан на конфигурации XML, некоторые могут подумать, что проще настроить брандмауэр программным способом. Этого также можно достичь iptables, но другим способом, а не XML. Если вы уже знакомы с тем, как это iptablesработает, зачем вам переносить все ваши настройки firewalld?

Если вы считаете, что ваш самый большой iptablesнабор правил брандмауэра, как вы думаете, как часто вы выиграете от динамического аспекта firewalld? В большинстве случаев производительность iptablesникогда не является проблемой. В большинстве случаев, когда производительность iptablesявляется проблемой, можно решить, используя ipsetоснованные наборы IP источника / назначения.

Это другой спор, стоит ли вам использовать NetworkManager.


3
Производительность не iptablesимеет значения в этом случае, потому что медлительность будет происходить независимо от того, вставлены ли правила firewalldс помощью iptablesинструмента или напрямую .
gparent
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.