Føj brugernavnsgodkendelse til Dante

Skift SOCKS-politikken i Dante 1.4.4 fra adgang alene efter kilde til et udtrykkeligt kontotjek, mens kilde- og destinationsbegrænsninger bevares.

I Dante 1.4.4 tillader klientregler forbindelsen før SOCKS-forhandlingen, mens SOCKS-regler afgør, hvilke godkendte forespørgsler der må fortsætte. En forbindelse fra en tilladt kilde kan stadig kræve et brugernavn i andet trin.

Ved godkendelse med operativsystemets brugernavne skal du gennemgå tjenesteidentiteterne såvel som metoden. Læsning af kontodatabasen kan kræve en privilegeret identitet:

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

Brug den faktiske tjenestekonto med lave rettigheder, der er installeret til Dante. Opret eller vælg en autoriseret klientkonto, som passer til brugernavnsbackend’en; tjenesteidentiteten og klientens login har forskellige roller.

Bevar grænserne for forespørgsler

Efter den eksisterende snævre klientregel kræves kontoen på den tilladte SOCKS-rute:

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
}

Adresserne og kontonavnet er eksempler. Dette tillader én kilde, én destination, én kommando og den angivne godkendte bruger. Erstat ikke denne grænse med ubegrænsede kilder, blot fordi der er tilføjet et kodeord.

De globale og regelspecifikke metodeindstillinger skal stemme overens. Se efter en gammel regel, der kun tillader none, fra en opsætning baseret alene på kilde. Bevar også de tilsigtede lytte- og firewallbegrænsninger.

Test forhandling og adgang hver for sig

Kontrollér filen med den installerede servers konfigurationskontrol, før du starter den. Brug derefter en autoriseret klient, der faktisk understøtter SOCKS5-forhandling med brugernavn og kodeord. Test manglende legitimationsoplysninger, forkerte oplysninger og en tilladt konto, der anmoder om et forbudt mål.

Underforhandlingen med brugernavn og kodeord i RFC 1929 krypterer ikke kodeordet. En senere HTTPS-session til destinationen beskytter ikke den tidligere proxyudveksling. Brug en passende beskyttet vej fra klient til server.

En vellykket konfigurationskontrol bekræfter syntaks og identiteter, ikke kontodatabasen eller netværksvejen. Se i serverloggene, hvilket trin der afviste en reel test.

Relaterede artikler