iptables
(и/или последующий инструмент nftables
) — это служебная программа пользовательского пространства, которая позволяет системному администратору настраивать правила фильтрации IP-пакетов брандмауэра ядра Linux, реализованного в виде различных Сетевой фильтр модули. (резюме из Википедия)
С iptables
а также nftables
представляют собой служебные программы пользовательского пространства, предназначенные для использования людьми, системными администраторами, и люди не всегда полностью довольны лежащими в основе числами, они принимают удобочитаемые описания для IP-протоколов (tcp, icmp, udp и т. д.), IP- адреса (имена хостов) и номера портов (сервисные имена).
С точки зрения пользовательского интерфейса использование удобочитаемых имен кажется хорошей вещью:
- как администратор я, вероятно, не единственный, кто гораздо лучше интуитивно понимает значение:
iptables --protocol udp
по сравнению с:
iptables --protocol 17
и подобные. - имя хоста
gateway.example.net
часто имеет больше смысла, чем IP-адрес, такой как192.0.2.1
- а на веб-сервере разрешение HTTP и HTTPS более очевидно, чем разрешение TCP/80 соответственно. TCP/443.
Это безопасно делать?
Или стоит держаться подальше от этого?
Каковы предостережения?
linux сеть iptables брандмауэр nftables
ХБраун
1 ответ
Эффект может не всегда соответствовать ожиданиям администратора.
Немного предыстории:
сетевой фильтр модули ядра Linux работают с IP-пакетами. В основном они оценивают, обрабатывают и/или модифицируют заголовки этих IP-пакетов и, как правило, не затрагивают раздел данных (это больше относится к сфере глубокая проверка пакетов (ДПИ)).
Заголовки IP-пакетов не содержат удобочитаемые именаони состоят из таких вещей, как IP
protocol number
а источник и место назначенияIP-address
, Источник и место назначения TCPport
числа и т.п.
Чтобы быть наиболее эффективными, правила для фильтров пакетов в ядре Linux также хранятся со значениями IP-протокола, номеров портов и IP-адресов в том же формате, что и в пакетах, которые они оценивают.
Когда правило загружается в ядро
iptables
а такжеnftables
перевести удобочитаемый ввод в числовые значения необходимы и хранятся в модулях ядра netfilter.Системный преобразователь используется для преобразования протоколов, служб, сетевых имен и имен хостов. Это делает фактическое разрешение зависимым от вашей конфигурации ( nsswitch.conf)
iptables
а такжеnftables
перевести удобочитаемый ввод в числовые значения когда выполняются команды.результирующие числовые правила остаются в силе в ядре до тех пор, пока они не будут явно сброшены/удалены/обновлены.
Это также имеет ряд эффектов и/или последствий, которые не сразу очевидны.
Использование имен протоколов с iptables
:
В целом это безопасно и не приводит к ненужной путанице.
Файл /etc/protocols
используется по умолчанию для преобразования имен протоколов в номера протоколов в iptables --protocol [human readable protocol name]
Маловероятно, что имена протоколов IP (например, UPD и TCP) могут вызвать путаницу.
Использование имен хостов с iptables
или же nftables
:
Файл по умолчанию /etc/networks
можно использовать для перевода сетевые имена используемые в пунктах назначения и/или источниках. По крайней мере, согласно руководству, я никогда не видел, чтобы кто-то использовал это в реальном мире. Поскольку, насколько я знаю getent networks network-name
также не предоставляет метод возврата сетевой маски, что делает использование сетевых имен непрактичным ИМХО.
Файл по умолчанию /etc/hosts
используется для перевода имена хостов на IP-адреса в пунктах назначения и/или источниках, обычно с DNS в качестве запасного варианта.
Не используйте имена хостов.
Пакетный фильтр работает по IP-адресам. Используйте IP-адреса и диапазоны IP-адресов в конфигурации вашего брандмауэра.
Когда имя хоста используется в правиле брандмауэра с iptables
это будет выполнено с (одним) IP-адресом, чтобы имя хоста разрешалось в момент выполнения команды iptables.
Когда имя хоста не может быть разрешено, правило вообще не добавляется.
Это кажется очевидным и не очень проблематичным, но это приводит ко многим крайним случаям, которые на практике оказываются очень распространенными.
конфигурация брандмауэра обычно применяется при загрузке до полная активация сети, а затем разрешение DNS еще не сработает. Правило, например, разрешающее удаленное администрирование с вашего хоста-бастиона
iptables -I INPUT --source bastion.example.com -j ALLOW
не будет применяться (при загрузке системы), если в системном файле hosts нет записи bastion.example.com. (А кто захочет поддерживать файлы hosts, когда у них есть внутренний DNS?)При обновлении прямой DNS-записи: брандмауэр Linux будет продолжать использовать старый IP-адрес до тех пор, пока правило не будет явно сброшено/удалено/обновлено (путем запуска
iptables
команду еще раз).Когда прямая DNS-запись является циклической записью или использует геолокацию: часто будет использоваться только один IP-адрес.
Другими словами:
iptables -I OUTPUT --destination www.google.com -j REJECT
например, только частично заблокирует доступ к Google не более чем на 300 секунд. Затем срок действия DNS TTL истекает, и запросы наwww.google.com
вернуть другой IP-адрес, обычно новый, который не заблокирован действующими правилами брандмауэра.Обычно использование имени хоста для отклонения нежелательного доступа уже является плохой идеей.
Системы обычно видят IP-адрес только из входящего соединения, и им необходимо выполнить обратный поиск по IP-адресу, чтобы определить связанное имя хоста. Блокировка по имени хоста проблематична по двум причинам:обратный поиск DNS может быть медленным
полученному имени хоста нельзя доверять, потому что владелец IP-адреса может установить любое имя хоста, которое он хочет, в обратной записи DNS. Они могут изменить свою
untrusted.example.net
кtrusted.example.com
по желанию (некоторые системы обращаются к этому, выполняя второй прямой поиск имени хоста из записи PTR, и будут принимать только системы, в которых они совпадают).iptables -A INPUT --source untrusted.example.net -j REJECT
Для iptables проблема немного отличается, так как будет выполняться только прямой поиск DNS. Но тем не менее, когда вы используете untrusted.example.net, а не IP-адрес, вы больше не контролируете, что блокируется.
Если владелец этой записи DNS изменит untrusted.example.net, скажем, на IP-адрес вашего шлюза, вы заблокируете себя.
Если владелец полностью удалит запись, вы больше не будете блокировать его IP.
Еще одна потенциально запутанная вещь: при отображении правил брандмауэра сопоставление IP-адреса с именем хоста, если оно выполняется с помощью обратного поиска DNS. Часто эта запись PTR не существует, а когда она существует, то результирующее имя хоста не будет соответствовать имени хоста, которое использовалось при создании правила. Например:
www.google.com. 300 IN A 172.217.168.228
228.168.217.172.in-addr.arpa. 18721 IN PTR ams15s40-in-f4.1e100.net.
И, вероятно, какие-то другие причины, о которых я забыл.
Использование имен служб с iptables
:
Хотя это безопасно, это также, кажется, вызывает некоторую путаницу.
Файл /etc/services
используется для перевода имя службы на номер порта когда вместо номера порта человекочитаемый «наименование услуги» используется с iptables --protocol tcp --source-port
(или псевдоним --sport
и тому подобное --destination-port
/ --dport
и т.д.).
Имя службы фактически представляет собой удобочитаемый номер порта и (пока никто не модифицировал /etc/services), когда администратор использует, например, ssh
что будет таким же, как использование порт 22
.
iptables -I INPUT -p tcp --dport ssh -j ACCEPT
источник путаницы кажется, что люди путают имя службы (ssh) с протоколом приложения (ssh).
Приведенное выше правило не разрешает весь входящий ssh-трафик.
Например, когда ваш ssh-сервер настроен на прослушивание порта 22222, этот порт не открывается этим правилом.
Это правило разрешает весь трафик только на порт 22.
Это также не блокирует трафик, который не является ssh, от подключения к порту 22 либо. Типичный демон ssh не сможет правильно ответить, но такие запросы, как http://hostname:22/
также не блокируются пакетным фильтром. (Для этого потребуется DPI.)