Додайте в Dante автентифікацію за іменем користувача

Переведіть політику SOCKS у Dante 1.4.4 з доступу лише за джерелом на явну перевірку облікового запису, зберігши обмеження джерела й призначення.

У Dante 1.4.4 клієнтські правила допускають з’єднання до узгодження SOCKS, а правила SOCKS визначають, які автентифіковані запити можуть тривати. З’єднання з дозволеного джерела все ще може вимагати ім’я користувача на другому етапі.

Для автентифікації іменем користувача операційної системи перевірте не лише метод, а й ідентичності служби. Читання бази облікових записів може потребувати привілейованої ідентичності:

clientmethod: none
socksmethod: username
user.privileged: root
user.unprivileged: danteproxy

Використовуйте справжній службовий обліковий запис із малими привілеями, встановлений для Dante. Створіть або виберіть дозволений клієнтський обліковий запис, сумісний із механізмом перевірки імен користувачів; ідентичність служби та вхід клієнта мають різні ролі.

Збережіть межі запитів

Після наявного вузького клієнтського правила вимагайте обліковий запис на дозволеному маршруті SOCKS:

socks pass {
    from: 198.51.100.27/32 to: 203.0.113.20/32 port = 443
    command: connect
    socksmethod: username
    user: proxyuser
    log: connect error
}

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

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

Перевіряйте узгодження та доступ окремо

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

Підузгодження імені користувача й пароля за RFC 1929 не шифрує пароль. Подальший сеанс HTTPS із призначенням не захищає цей попередній обмін із проксі. Використовуйте належно захищений шлях від клієнта до сервера.

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

Схожі статті