Обмежити спільний ресурс Samba одним користувачем і однією адресою VPN

У цьому проєкті плутаються два різні дозволи: кому можна користуватися каталогом і яким адресам можна взагалі підключатися. Записати список облікових записів поруч зі списком джерел здається зв'язуванням, але Samba оцінює обидва списки як незалежні предикати. Допускається кожен, хто задовольняє обидва, і це ширше правило, ніж задумують більшість адміністраторів. Рішення — або інша схема ресурсу, або шар політики, здатний виразити пару.

Міф: два списки дають одне правило

Довідник smb.conf визначає valid users і hosts allow як два незв'язані параметри, і саме встановлення обох на одному ресурсі — місце, де починається плутанина. Задайте valid users = mira, tomas і hosts allow = 10.77.0.21, 10.77.0.22, і допускаються чотири комбінації: Міра з будь-якої з двох адрес, Томас з будь-якої з двох адрес. Ніщо в конфігурації не прив'язує перше ім'я до першої адреси, і порядок появи імен не має значення. Їх переставляння, додавання другого рядка hosts allow або по одному імені в рядку нічого не змінює. Результат — добуток двох списків, а не відображення між ними.

Те, чого більшість насправді хоче, є вужчим: Міра лише з однієї адреси, Томас лише з іншої. Один визначення ресурсу не має синтаксису для такого прив'язування, і жоден хитрий порядок його не створює. Це форма політики, яку Samba не виражає всередині одного ресурсу, і саме там міф виживає.

Що Samba оцінює і в якому порядку

Етапи йдуть у фіксованому порядку, і неправильний порядок дає неправильний діагноз. Клієнт відкриває з'єднання; глобальна перевірка хоста виконується, якщо вона налаштована; налаштування сеансу автентифікує обліковий запис; потім клієнт підключається до ресурсу, де застосовуються його власний список хостів, valid users і режим лише для читання; і лише коли відкривається файл, вирішують дозволи файлової системи автентифікованої особи. Кожен етап може сам відхилити запит, і проходження одного нічого не говорить про наступний. Важливий наслідок: обліковий запис відомий уже тоді, коли оцінюється список хостів ресурсу, а список хостів досі не має способу назвати цей обліковий запис.

Тому ресурс не може прив'язати одного користувача до однієї адреси: hosts allow і valid users — окремі предикати, що застосовуються на одному й тому самому етапі підключення дерева, і кожен відповідає на своє питання. Предикат хоста ніколи не бере ім'я облікового запису як вхід, тому його не можна записати для окремого користувача. Пару може виразити лише другий ресурс або шар політики поза Samba.

Глобальні значення важливі через спосіб успадкування. Ресурс, який пропускає hosts allow, успадковує глобальне значення, а ресурс, який задає своє, використовує це значення замість глобального, а не на додаток до нього. Тому широкий глобальний список розширює ресурси, які ніколи не задають параметр, і нічого не робить ресурсу, який визначає своє. Запустіть testparm -s і прочитайте надруковані значення для кожного ресурсу: цей вивід і є чинна політика, а файл на диску — ні.

Звуження одного ресурсу також нічого не робить для решти сервера. Інші ресурси, черги друку і з'єднання IPC зберігають власні правила, тому проєкт, що спирається на список адрес одного ресурсу, захищає один шлях, а не хост.

Два імені ресурсу над одним каталогом

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

[shared-mira]
    path = /srv/shared
    guest ok = no
    read only = yes
    valid users = mira
    hosts allow = 10.77.0.21
    hosts deny = ALL

[shared-tomas]
    path = /srv/shared
    guest ok = no
    read only = yes
    valid users = tomas
    hosts allow = 10.77.0.22
    hosts deny = ALL

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

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

Що може довести адреса джерела

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

Навіть тоді адреса — не пристрій. Два ноутбуки за однією адресою тунелю, перерозподілена оренда і спільна робоча станція разом спростовують припущення, що джерело ідентифікує людину. Ставтеся до обмеження як до мережевого обсягу і тримайте автентифіковані облікові записи SMB як шар ідентичності, з обліковими даними пристрою, наприклад сертифікатом, якщо потрібна авторизація пристрою.

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

Доведіть це перехресними парами

Перевірте конфігурацію, потім протестуйте чотири комбінації свіжими з'єднаннями, а не повторно використаним сеансом. Задумана пара має дійти до каталогу, а обидві перехресні пари мають зазнати невдачі. Кешований сеанс з попереднього тесту охоче відповість за неправильну комбінацію і змусить зламане правило виглядати правильним.

testparm -s
smbclient //fileserver/shared-mira -U mira -c 'ls'
smbclient //fileserver/shared-tomas -U tomas -c 'ls'
smbstatus --shares

Перевірка синтаксису доводить лише те, що файл розбирається. Облікові дані, ACL і рішення щодо хоста перевіряються справжнім з'єднанням, тому запустіть клієнтську команду з тієї адреси, яку хочете перевірити, і стежте, який етап її відхиляє. Якщо перехресна пара проходить, чинний список хостів ширший, ніж припускає блок, і testparm -s — перше, що треба прочитати. Якщо перехресна пара зазнає невдачі з неправильної причини, підозрювані — обліковий запис або ACL.

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