Добавьте в 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 с назначением не защищает этот предшествующий обмен с прокси. Используйте надлежащим образом защищённый путь от клиента к серверу.

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

Похожие статьи