Блокування облікового запису і заборона адреси: де OpenVPN справді рахує
Заборона джерела та блокування запису рахують різні речі. Знайдіть сховище, яке володіє лічильником невдач, перш ніж вибирати поріг для VPN на основі PAM.
Блокувати адресу й блокувати обліковий запис — два різні механізми, і вони відмовляють у протилежних напрямках. Заборона адреси зупиняє одне джерело, а цільовий запис залишається доступним з іншого місця; блокування запису зупиняє цю особу всюди, зокрема на ноутбуці самого користувача.
Для VPN, який передає автентифікацію PAM, лічильником є те, до чого доходить стек PAM, а не те, що записав слухач.
Два лічильники, дві різні жертви
Обмежувач швидкості дивиться на джерело і питає, скільки спроб нещодавно прийшло з нього. Блокування дивиться на особу і питає, скільки невдач накопичив запис. Перше захищає доступність, друге — облікові дані; жодне не замінює інше.
Тому фраза ми блокуємо IP після п яти невдач не є відповіддю на звіт про заповнення облікових даних. Нападник змінює джерела, кожне отримує мало спроб, і запис ніколи не рахується. Навпаки, блокування без контролю джерел дозволяє нападнику тримати запис заблокованим нескінченно, навмисно провалюючись.
Два механізми мають і різні історії відновлення. Заборона адреси спливає за таймером, про який нікому не треба думати; блокування запису може вимагати адміністратора, документованого періоду очікування або самостійного скидання.
Знайдіть сховище, яке вже має лік
Перш ніж щось додавати, з ясуйте, чи вже існує сховище невдач. Локальний запис Linux, служба каталогу і зовнішній постачальник ідентичності ведуть власний лік, а модуль PAM перед ними створює другий, а не розширює перший.
grep -rnE 'faillock|pam_tally|pam_unix' /etc/pam.d/
ls -l /etc/pam.d/ | head -20
Прочитайте файл служби, який VPN справді називає, і простежте його рядки включення. У багатьох дистрибутивах служба VPN включає спільний файл, тож лік, який ви налаштовуєте, поширюється і на SSH, і на локальні входи.
Якщо каталог уже застосовує блокування, корисне питання — як розмова PAM доходить до цього рішення і як VPN про нього повідомляє. Локальний лік зверху не стає лічильником каталогу, і дві політики можуть розходитися в тому, коли запис розблоковується.
pam_faillock має три позиції виклику, а не одну
Модуль розділяє три операції, які один скопійований рядок зазвичай розмиває: перевірку, чи запис уже заблоковано, запис невдачі та очищення історії після успіху.
Саме тут міграція зі старого модуля ліку зазвичай помиляється. Скопіювати рядок із робочого прикладу pam_tally2 у стек pam_faillock — не перейменування; документоване налаштування інше, і виклик не на місці може записувати невдачі, жодного разу їх не перевіривши.
faillock --user alice
faillock --user alice --reset
Утиліта перевірки — найшвидший спосіб побачити, чи лічильник справжній: вона показує записані невдачі для запису і може їх очистити. Якщо контрольована невдача не змінює цей вивід, позиція виклику неправильна.
Окрема назва служби — не ізоляція
Власний файл служби PAM для VPN робить задуману політику видимою, але не обмежує ефект. Будь-яке включення спільного файлу приносить те, що робить цей файл, зокрема ліки для всієї системи.
Ясно вирішіть, чи блокування охоплює лише доступ через VPN, чи кожну службу, яка автентифікує той самий запис. Обидві відповіді захищені; помилка — вірити, що ви обрали одне, поки стек реалізує інше.
Потім врахуйте ціну. Блокування може спричинити нападник, і страждає власник запису. Поріг, період очікування і адміністративний шлях відновлення — частина політики, і відновлення не повинно залежати від переналаштування VPN під час інциденту.
Прийміть послідовність, а не одну відмову
Тестуйте призначеними особами за затвердженим планом і тестуйте ланцюг, а не одну подію: чинний запис автентифікується, навмисно неправильний пароль рухає лічильник, налаштоване блокування набуває чинності, а документоване відновлення повертає доступ.
faillock --user test-vpn-01
journalctl -u openvpn-server@lab -n 30 --no-pager | grep -i 'auth\|pam'
Спостерігайте за поведінкою при успіху так само уважно, як при невдачі. Якщо успішний вхід не очищає історію, запис заблокується після повільного накопичення звичайних помилок. Якщо він очищає все з кожної служби, лічильник слабший, ніж стверджує політика.
Нарешті, зупиніть клієнтів без нагляду, перш ніж оголосити перемогу. Збережені облікові дані, які повторюють спроби у фоні, знову створять невдачі за кілька хвилин після відновлення і знову заблокують запис. Обмеження швидкості за джерелом може залишитися додатковим засобом, але це не політика запису.