Lägg till autentisering med användarnamn i Dante

Ändra SOCKS-policyn i Dante 1.4.4 från åtkomst enbart efter källa till en uttrycklig kontokontroll och behåll käll- och målbegränsningarna.

I Dante 1.4.4 tillåter klientregler anslutningen före SOCKS-förhandlingen, medan SOCKS-regler avgör vilka autentiserade begäranden som får fortsätta. En anslutning från en tillåten källa kan fortfarande kräva användarnamn i det andra steget.

Vid autentisering med operativsystemets användarnamn behöver du granska tjänsteidentiteterna utöver metoden. Läsning av kontodatabasen kan kräva en privilegierad identitet:

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

Använd det faktiska tjänstekonto med låga rättigheter som installerats för Dante. Skapa eller välj ett behörigt klientkonto som passar användarnamnsbackendens krav; tjänsteidentiteten och klientinloggningen har olika roller.

Behåll gränserna för begäranden

Efter den befintliga snäva klientregeln kräver du kontot på den tillåtna SOCKS-rutten:

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
}

Adresserna och kontonamnet är exempelvärden. Detta tillåter en källa, ett mål, ett kommando och den angivna autentiserade användaren. Ersätt inte denna gräns med obegränsade källor bara för att ett lösenord har lagts till.

De globala och regelspecifika metodinställningarna måste stämma överens. Leta efter en gammal regel som bara tillåter none och är kvar från en rent källbaserad konfiguration. Behåll även de avsedda lyssnar- och brandväggsbegränsningarna.

Testa förhandling och åtkomst var för sig

Kontrollera filen med den installerade serverns konfigurationskontroll innan du startar den. Använd sedan en behörig klient som faktiskt stöder SOCKS5-förhandling med användarnamn och lösenord. Testa saknade och felaktiga inloggningsuppgifter samt ett tillåtet konto som begär ett förbjudet mål.

Underförhandlingen med användarnamn och lösenord i RFC 1929 krypterar inte lösenordet. En senare HTTPS-session till målet skyddar inte det tidigare proxyutbytet. Använd en lämpligt skyddad väg från klient till server.

En lyckad konfigurationskontroll bekräftar syntax och identiteter, inte kontodatabasen eller nätverksvägen. Titta i serverloggarna efter det steg som avvisade ett verkligt test.

Relaterade artiklar