Настройка TCP Wrappers для контроля доступа к сервисам

TCP Wrappers: почему контроль доступа по адресам ломается

На боевом узле sshd, СУБД и брокер очередей слушают на всех интерфейсах, а ограничение доступа по адресам держится на нескольких строках в hosts.allow, дописанных под прежнюю схему адресации. Формально tcp wrappers включены, фактически контроль доступа к сервисам не отражает топологию: старый офисный диапазон остался в списке разрешённых узлов, адрес подрядчика добавлен вручную и не отозван, новая подсеть в правила так и не попала.

Механизм работает на уровне демона: до обработки соединения адрес клиента сверяется с hosts.allow и hosts.deny, решение принимается по первой совпавшей строке. Отсюда причина отказов, которую чаще всего не видят, — поддержку библиотеки-обёртки вырезали из актуальных сборок, и служба принимает всех, хотя файлы заполнены. Проверяется это не на глаз, а прогоном соединения с внешнего адреса и разбором того, какой процесс держит порт.

Вторая причина — правила доступа вразнобой. Их правят в момент инцидента, синтаксис масок в соседних строках трактуют по-разному, часть служб закрыта на уровне hosts.deny, часть — только фильтрацией на границе. Один и тот же адрес оказывается разрешён в одном файле и запрещён в другом, а итог читается только полным перебором. Файлы при этом не версионируются: нет ревизии для отката правки и журнала, по которому видно, кто открыл доступ и зачем.

Разбираем, как это закрывается: от инвентаризации слушающих портов и адресов до переноса правил туда, где они проверяются до старта службы, а не после.

Что даёт управляемый доступ на уровне служб

Обёртка TCP Wrappers встаёт между входящим соединением и самой службой: демон сверяет адрес клиента с правилами в /etc/hosts.allow и /etc/hosts.deny и только затем передаёт управление приложению. Проверка идёт до того, как сервис начнёт разбор запроса, поэтому отсечение обращений происходит на входе, а не после аутентификации.

Порядок разбора фиксирован — сначала разрешения, затем запреты. Базовая строка «запрещено всё» в файле запретов закрывает всё, что не перечислено явно, а белый список описывает только нужные подсети и узлы. Политика доступа остаётся читаемой: десяток строк объясняет, кому и к каким службам разрешено обращаться.

Эффект виден на метриках периметра: сканирования и попытки подключиться к чужим службам не доходят до приложения, не расходуют его ресурсы и не порождают ложных срабатываний мониторинга. Поверхность атаки сокращается до явно перечисленных адресов, а шум в журналах отсекается вместе с обращениями.

Время на изменение правил предсказуемо: правка файла применяется к следующему соединению, перезапуск службы не нужен. Добавление нового узла в белый список занимает пару минут — инженер вносит строку, проверяет соединение и фиксирует изменение, не затрагивая остальные сервисы.

Обёртка работает только для служб, собранных с её поддержкой, и не заменяет сетевой экран, а дополняет его на уровне конкретных служб. На практике её берут там, где правила периметра слишком грубы и нужен точный фильтр для отдельного демона.

Способы ограничения доступа: сравнение подходов

Доступ ограничивают на четырёх уровнях, и выбор уровня решает, что именно вы контролируете: службу, хост, вход в приложение или достижимость сегмента. TCP Wrappers работают на уровне службы: правило «разрешить подсеть, остальным отказать» применяется до обработки запроса, но только к демонам, собранным с поддержкой библиотеки-обёртки.

Сетевой экран на хосте фильтрует трафик до службы и не зависит от её сборки, но не различает пользователей — только адрес и порт. Обратный прокси проверяет запросы на входе в приложение, однако защищает лишь то, что идёт через него. Сегментация сети убирает сам маршрут к узлу, поэтому ошибка в конфигурации службы уже не открывает доступ.

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

Порядок внедрения правил доступа

Правила в hosts.allow и hosts.deny читаются при каждом подключении, поэтому неверная строка способна закрыть доступ раньше, чем вы это заметите. Внедрение идёт этапами — от инвентаризации служб до передачи в эксплуатацию.

1. Инвентаризация служб. Собираем список демонов, слушающих сеть, и проверяем, какие из них собраны с поддержкой обёртки: для остальных правила не применятся, и доступ останется открытым при формально настроенном запрете.
2. Сбор картины трафика. По журналам и активным соединениям фиксируем реальные пары «служба — адрес»: кто ходит, откуда, как часто. Это основа схемы доступа вместо предположений.
3. Проектирование схемы доступа. Описываем разрешения по принципу «запрещено всё, что не разрешено»: точечные пары в allow, базовая блокировка в deny. Учитываем порядок обработки — срабатывает первое совпадение.
4. Настройка и проверка правил. Прогоняем конфигурацию через tcpdmatch по контрольным парам «служба — адрес» и смотрим, как отказ отражается в журнале.
5. Контролируемое включение. Вводим правила в согласованное окно, следим за отказами в логах, держим готовый откат: возврат предыдущих файлов занимает минуты.
6. Передача в эксплуатацию. Файлы уходят в систему управления конфигурацией, схема доступа и порядок её пересмотра фиксируются в документации.

На выходе — минимальный набор разрешённых пар и понятный регламент, как менять его без риска отрезать нужный трафик.

Конфигурации, схемы связей и регламенты доступа

Комплект передаётся вместе с доступом к инфраструктуре и разбирается на передаче: инженер заказчика должен уметь сам добавить адрес в список исключений и понять, почему изменение не сработало. Ниже — то, что остаётся у вас после сдачи, а не остаётся в переписке с подрядчиком.

• Рабочие правила доступа — файлы с разрешёнными и запрещёнными связями по узлам и службам, с комментарием к каждой записи: кто добавил, под какую задачу, до какой даты действует.
• Схема разрешённых связей — одностраничная карта: какие узлы к каким сервисам обращаются и по каким портам. Используется при разборе инцидентов и при вводе новых сервисов.
• Регламент изменений — порядок согласования правки: заявка, проверка на тестовом контуре, окно применения, заранее описанный откат к предыдущей версии правил.
• Инструкция дежурной смены — пошаговый разбор типовых случаев: сервис недоступен у части клиентов, в логах отказ по адресу, подозрение на ложную блокировку. С указанием, какие команды выполнить и куда смотреть.
• Порядок ревизии правил — раз в квартал сверяем список с фактическим трафиком, снимаем записи, которыми никто не пользуется, и подтверждаем оставшиеся у владельцев сервисов.
• Карта ответственных — кто владеет каждым правилом и к кому идти при расхождении: сначала владелец сервиса, затем дежурный инженер, затем мы по согласованному уровню поддержки.

Документы живут в том же репозитории, что и сами правила, — при откате восстанавливается и конфигурация, и её описание. На передаче прогоняем сценарий: дежурный по инструкции снимает блокировку и возвращает её обратно без нашей подсказки.

Кейс: как закрыли доступ к служебным службам

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

Разграничение вынесли на уровень самих служб через TCP Wrappers. В hosts.allow перечислили доверенные сегменты — офисную сеть и адрес бастиона, всё остальное попало в hosts.deny с явным запретом и записью в журнал. Решение принимается в момент соединения, до аутентификации, поэтому не потребовало правок в коде сервисов и перенастройки балансировщиков.

До и после

• Отклонённых обращений с недоверенных адресов: около 400 в сутки до работ — теперь поток отсекается на входе, а легитимных отказов в правилах нет.
• Доступ к служебным портам: с любых адресов — до двух доверенных сегментов и бастиона.
• Правка правила доступа: раньше десятки минут на пересборку сетевого фильтра и согласование, теперь 3–5 минут на строку в hosts.allow.

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

Чем TCP Wrappers отличается от правил сетевого экрана?

Сетевой экран и TCP Wrappers работают на разных уровнях, и отсюда все различия. Фильтр на хосте смотрит на заголовки пакетов — адрес источника, порт, интерфейс — и отбрасывает трафик до того, как его увидит служба. Обёртка, которую Wietse Venema добавил к системным службам, встраивается в сам демон: решение принимается после установления связи, когда известно уже и имя узла.

Практическая разница — в гибкости сопоставления. Обёртка работает с именами: файлы hosts.allow и hosts.deny читаются по порядку, первое совпадение выигрывает, шаблоны покрывают целые домены, а в системный журнал попадает строка с именем сработавшего правила. Экран о домене ничего не знает — только адрес и порт.

Границы применимости жёстче, чем кажется. Обёртка видит лишь те службы, что собраны с её поддержкой: запрос к демону без такой связи пройдёт мимо, а датаграммный трафик и служебные сообщения она не разбирает вовсе. Перегрузку канала она тоже не остановит — соединение занимает ресурс раньше, чем правило сработает.

Поэтому их применяют вместе, а не вместо. Экран отсекает по адресу и порту на входе — дешёвый рубеж, который не пускает мусорный трафик к службе. Обёртка добавляет слой там, где нужен отбор по имени узла и след в журнале для разбора инцидентов. Порядок именно такой: сначала фильтрация пакетов, потом решение на уровне службы.

Отдельно стоит смотреть на сам демон: часть современных служб ведёт свои списки доступа и ограничивает клиентов без внешних обёрток. Тогда третий слой лишь усложняет поиск причины отказа — правило записано в трёх местах, а срабатывает одно.

Технические сомнения: разбор частых вопросов

TCP Wrappers проверяет доступ по имени службы и адресу клиента раньше, чем соединение отдадут демону. Отсюда и основные вопросы: когда правка начинает действовать, кто читает список первым и что делать, если новое правило закрыло доступ сильнее, чем планировалось.

Ниже — четыре сомнения, которые чаще всего всплывают при передаче конфигурации в эксплуатацию.

В каком порядке разбираются правила?

Сначала целиком проверяется запрещающий список: совпадение закрывает доступ немедленно, разрешающий уже не смотрится. Если совпадений нет, оценивается разрешающий, а его отсутствие трактуется как запрет. Порядок строк внутри файла роли не играет, поэтому финальное правило «для всех» прописываем явно.

Как ведут себя контейнеры?

Проверка идёт по адресу источника, а в изолированном окружении виден адрес шлюза, а не клиента. При пробросе портов правило по внешнему адресу не сработает — сработает по внутреннему. Ограничение доступа к сервису в кластере надёжнее держать на входе, а списки оставлять вторым рубежом.

Как откатить изменения, если доступ потерян?

Перед правкой держим копию файлов и отдельную сессию, уже прошедшую проверку — она живёт, пока соединение открыто. Возврат к предыдущей версии занимает минуты, а прогон на копии узла показывает эффект до выкладки на продуктив.

Обсудим задачу контроля доступа

Чтобы оценка работ была точной, а старт проекта — без простоев на уточнения, нам достаточно исходных данных по текущему контуру доступа. Ничего дополнительно готовить не нужно: хватит того, что уже есть у администраторов и в репозитории конфигураций.

• Перечень сервисов, к которым ограничиваем доступ (удалённая консоль, почта, файловый обмен, базы), и то, как они запускаются — напрямую или из-под суперсервера.
• Текущие файлы /etc/hosts.allow и /etc/hosts.deny: если правила уже прописаны, сразу видно, что наследуется, а что конфликтует.
• Список доверенных сетей и адресов — офис, филиалы, пулы удалённого доступа, адреса подрядчиков и системы мониторинга.
• Как выдаются адреса клиентам: статически или из динамического пула. От этого зависит, задавать правило по адресу, по подсети или по имени узла.
• Схема прохождения трафика: где балансировщик, где обратный прокси, есть ли на периметре преобразование адресов.
• Требования к журналированию отказов: куда пишутся события, срок хранения, нужна ли выгрузка в общий сбор логов.
• Допустимое окно работ и порядок возврата к прежним правилам — если правки применяем на боевом контуре.

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