Налаштування 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: якщо правила вже прописані, одразу видно, що успадковується, а що конфліктує.
• Список довірених мереж і адрес — офіс, філії, пули віддаленого доступу, адреси підрядників і системи моніторингу.
• Як видаються адреси клієнтам: статично чи з динамічного пулу. Від цього залежить, задавати правило за адресою, за підмережею чи за іменем вузла.
• Схема проходження трафіку: де балансувальник, де зворотний проксі, чи є на периметрі перетворення адрес.
• Вимоги до журналювання відмов: куди пишуться події, строк зберігання, чи потрібне вивантаження в загальний збір логів.
• Допустиме вікно робіт і порядок повернення до попередніх правил — якщо правки застосовуємо на бойовому контурі.

Цього достатньо, щоб обговорити задачу предметно й повернутися з оцінкою та планом робіт: порядок зміни правил, точки перевірки на кожному кроці та спосіб відкотити конфігурацію.

Якщо частина даних недоступна, починаємо з інвентаризації — наші інженери зберуть її самі й узгодять список сервісів. Опишіть вашу ситуацію: дамо оцінку, строки та план старту проєкту.