Патрабаваць уваход для службаў HTTP і SOCKS у 3proxy

Наладзьце карыстальнікаў 3proxy, моцную аўтэнтыфікацыю і правілы доступу да службаў для кліентаў HTTP і SOCKS5.

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

Прыклад толькі для лакальнага доступу з дзвюма службамі:

users alex:CL:replace_with_a_private_password
auth strong
allow alex
proxy -i127.0.0.1 -p3128
flush
allow alex
socks -i127.0.0.1 -p1080

Даведнік па канфігурацыі тлумачыць users, auth strong і каманды службаў. CL захоўвае гэты прыкладны пароль як звычайны тэкст. Абараніце файл і выберыце падтрымліваную форму захоўвання ўліковых даных, прыдатную для разгортвання.

Кліенту патрэбны правільны абмен уваходам

Служба HTTP чакае аўтэнтыфікацыю HTTP-проксі. Службе SOCKS патрэбны кліент, які падтрымлівае аўтэнтыфікацыю SOCKS5 па імені карыстальніка і паролі. Кліент SOCKS4 не можа забяспечыць такі абмен толькі таму, што дасягае таго ж порта праслухоўвання.

Слова strong — гэта назва рэжыму аўтэнтыфікацыі, а не гарантыя шыфраванага транспарту. Абараняйце участак ад кліента да проксі, калі гэта патрэбна. HTTPS да пункта прызначэння і шыфраванне да проксі застаюцца асобнымі рашэннямі.

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

Калі адна служба запытвае ўліковыя даныя, а іншая не, праверце налады перад кожнай камандай службы, правілы пасля любога flush і кэш аўтэнтыфікацыі. Змена пароля не выправіць службу, запушчаную пад няправільнай палітыкай. Гэтак жа змена ўліковага запісу аперацыйнай сістэмы дэмана не стварае карыстальніка проксі.

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