Voeg gebruikersnaamauthenticatie toe aan Dante

Verander het SOCKS-beleid in Dante 1.4.4 van toegang op basis van alleen de bron naar een expliciete accountcontrole, met behoud van bron- en doelbeperkingen.

In Dante 1.4.4 laten clientregels de verbinding toe vóór de SOCKS-onderhandeling, terwijl SOCKS-regels bepalen welke geauthenticeerde verzoeken mogen doorgaan. Een verbinding vanaf een toegestane bron kan in de tweede fase nog steeds een gebruikersnaam vereisen.

Controleer bij authenticatie met gebruikersnamen van het besturingssysteem naast de methode ook de service-identiteiten. Voor het lezen van de accountdatabase kan een bevoorrechte identiteit nodig zijn:

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

Gebruik het daadwerkelijke serviceaccount met beperkte rechten dat voor Dante is geïnstalleerd. Maak of kies een bevoegd clientaccount dat bij de gebruikersnaambackend past; de service-identiteit en de clientaanmelding vervullen verschillende rollen.

Behoud de grenzen voor verzoeken

Vereis na de bestaande, strikt begrensde clientregel het account op de toegestane SOCKS-route:

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
}

De adressen en accountnaam zijn voorbeeldwaarden. Dit staat één bron, één doel, één opdracht en de opgegeven geauthenticeerde gebruiker toe. Vervang die grens niet door onbeperkte bronnen alleen omdat er een wachtwoord is toegevoegd.

De globale en regelspecifieke methode-instellingen moeten overeenkomen. Zoek naar een oude regel die alleen none toestaat en is overgebleven uit een opzet met uitsluitend broncontrole. Behoud ook de bedoelde listener- en firewallbeperkingen.

Test onderhandeling en toegang afzonderlijk

Controleer het bestand vóór het starten met de configuratiecontrolemodus van de geïnstalleerde server. Gebruik daarna een bevoegde client die daadwerkelijk SOCKS5-onderhandeling met gebruikersnaam en wachtwoord ondersteunt. Test ontbrekende en onjuiste aanmeldgegevens en een toegestaan account dat een verboden doel aanvraagt.

De gebruikersnaam/wachtwoord-subonderhandeling uit RFC 1929 versleutelt het wachtwoord niet. Een latere HTTPS-sessie met het doel beschermt die eerdere proxyuitwisseling niet. Gebruik een passend beveiligd pad van client naar server.

Een geslaagde configuratiecontrole bevestigt de syntaxis en identiteiten, niet de accountdatabase of het netwerkpad. Kijk in de serverlogboeken in welke fase een echte test is afgewezen.

Gerelateerde artikelen