Voeg gebruikernaamverifikasie by Dante

Verander Dante 1.4.4 se SOCKS-beleid van toegang slegs volgens bron na 'n uitdruklike rekeningkontrole, met behoud van bron- en bestemmingsbeperkings.

In Dante 1.4.4 laat kliëntreëls die verbinding toe vóór SOCKS-onderhandeling; SOCKS-reëls bepaal daarna watter geverifieerde versoeke mag voortgaan. 'n Verbinding vanaf 'n toegelate bron kan steeds in die tweede fase 'n gebruikernaam vereis.

Vir verifikasie met bedryfstelselgebruikersname moet jy die diensidentiteite én die metode nagaan. Om die rekeningdatabasis te lees, kan 'n bevoorregte identiteit nodig wees:

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

Gebruik die werklike diensrekening met min voorregte wat vir Dante geïnstalleer is. Skep of kies 'n gemagtigde kliëntrekening wat met die gebruikernaamagterkant werk; die diensidentiteit en kliëntaanmelding vervul verskillende rolle.

Behou die versoekgrense

Vereis ná die bestaande eng kliëntreël die rekening op die toegelate SOCKS-roete:

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
}

Die adresse en rekeningnaam is plekhouers. Dit laat een bron, een bestemming, een opdrag en die bepaalde geverifieerde gebruiker toe. Moenie dié grens met onbeperkte bronne vervang bloot omdat 'n wagwoord bygevoeg is nie.

Die globale en reëlspesifieke metode-instellings moet ooreenstem. Soek na 'n ou reël wat slegs none toelaat en uit die brongebaseerde opstelling oorgebly het. Behou ook die bedoelde luisterpunt- en brandmuurbeperkings.

Toets onderhandeling en toegang afsonderlik

Kontroleer die lêer met die geïnstalleerde bediener se konfigurasiekontrolemodus voordat jy dit begin. Gebruik dan 'n gemagtigde kliënt wat werklik SOCKS5-gebruikernaam/wagwoordonderhandeling ondersteun. Toets ontbrekende aanmeldbesonderhede, verkeerde aanmeldbesonderhede en 'n toegelate rekening wat 'n verbode teiken aanvra.

Die gebruikernaam/wagwoordsubonderhandeling wat RFC 1929 omskryf, enkripteer nie die wagwoord nie. 'n Latere HTTPS-sessie met die bestemming beskerm nie daardie vroeëre proxy-uitruiling nie. Gebruik 'n behoorlik beskermde pad tussen kliënt en bediener.

'n Geslaagde konfigurasiekontrole bevestig sintaksis en identiteite, nie die rekeningdatabasis of netwerkpad nie. Raadpleeg die bedienerlogboeke om te sien in watter fase 'n werklike toets afgekeur is.

Verwante artikels