Aldonu uzantnoman aŭtentikigon al Dante

Ŝanĝu la SOCKS-politikon de Dante 1.4.4 de aliro nur laŭ fonto al eksplicita kontokontrolo, konservante limigojn de fonto kaj celo.

En Dante 1.4.4, klientaj reguloj akceptas la konekton antaŭ la SOCKS-intertraktado, dum SOCKS-reguloj decidas, kiuj aŭtentikigitaj petoj rajtas pluiri. Konekto el permesita fonto povas ankoraŭ bezoni uzantnomon ĉe la dua etapo.

Por aŭtentikigo per uzantnomoj de la operaciumo, ekzamenu la servajn identecojn kune kun la metodo. Legi la kontodatumbazon povas postuli privilegian identecon:

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

Uzu la efektivan malaltprivilegian servokonton instalitan por Dante. Kreu aŭ elektu rajtigitan klientkonton kongruan kun la uzantnoma kontrolsistemo; la serva identeco kaj la klienta ensaluto havas malsamajn rolojn.

Konservu la petolimojn

Post la ekzistanta strikta klientregulo, postulu la konton sur la permesita SOCKS-vojo:

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
}

La adresoj kaj kontonomo estas lokokupiloj. Tio permesas unu fonton, unu celon, unu komandon kaj la specifitan aŭtentikigitan uzanton. Ne anstataŭigu tiun limon per senlimaj fontoj simple ĉar pasvorto estis aldonita.

La ĝeneralaj kaj regulospecifaj metodagordoj devas kongrui. Serĉu malnovan regulon kun nur none, restintan el fontobazita aranĝo. Konservu ankaŭ la intencitajn limigojn de aŭskultilo kaj fajroŝirmilo.

Testu intertraktadon kaj aliron aparte

Antaŭ lanĉo kontrolu la dosieron per la agordkontrola reĝimo de la instalita servilo. Poste uzu rajtigitan klienton, kiu vere subtenas SOCKS5-intertraktadon per uzantnomo kaj pasvorto. Kontrolu mankantajn kaj malĝustajn ensalutilojn kaj permesitan konton petantan malpermesitan celon.

La uzantnoma/pasvorta subintertraktado difinita de RFC 1929 ne ĉifras la pasvorton. Posta HTTPS-sesio kun la celo ne protektas tiun pli fruan prokuran interŝanĝon. Uzu taŭge protektitan vojon inter kliento kaj servilo.

Sukcesa agordkontrolo konfirmas sintakson kaj identecojn, ne la kontodatumbazon aŭ retvojon. Rigardu la servilajn protokolojn por la etapo, kiu rifuzis realan teston.

Rilataj artikoloj