Добавяне на удостоверяване с потребителско име в 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 сесия с дестинацията не защитава по-ранния обмен с проксито. Използвайте подходящо защитен път между клиент и сървър.

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

Подобни статии