iptables — использовать имя службы или номер порта, IP-адрес или имя хоста?

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 ответ
1

Эффект может не всегда соответствовать ожиданиям администратора.

Немного предыстории:

сетевой фильтр модули ядра Linux работают с IP-пакетами. В основном они оценивают, обрабатывают и/или модифицируют заголовки этих IP-пакетов и, как правило, не затрагивают раздел данных (это больше относится к сфере глубокая проверка пакетов (ДПИ)).

Заголовки IP-пакетов не содержат удобочитаемые именаони состоят из таких вещей, как IP protocol number а источник и место назначения IP-address, Источник и место назначения TCP port числа и т.п.

Чтобы быть наиболее эффективными, правила для фильтров пакетов в ядре 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.)

Добавить комментарий

Ваш адрес email не будет опубликован.