Дадайце аўтэнтыфікацыю па імені карыстальніка ў Dante

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

У 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 з прызначэннем не абараняе гэты папярэдні абмен з проксі. Выкарыстоўвайце належным чынам абаронены шлях ад кліента да сервера.

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

Падобныя артыкулы