Benutzernamen-Authentifizierung für Dante einrichten

Stellen Sie die SOCKS-Richtlinie von Dante 1.4.4 von rein quellbasiertem Zugriff auf eine ausdrückliche Kontoprüfung um und behalten Sie Quell- und Zielbeschränkungen bei.

In Dante 1.4.4 lassen Clientregeln die Verbindung vor der SOCKS-Aushandlung zu. SOCKS-Regeln entscheiden anschließend, welche authentifizierten Anfragen fortfahren dürfen. Auch eine Verbindung aus einer erlaubten Quelle kann im zweiten Schritt einen Benutzernamen benötigen.

Prüfen Sie für die Authentifizierung mit Betriebssystemkonten neben der Methode auch die Dienstidentitäten. Das Lesen der Kontodatenbank kann eine privilegierte Identität erfordern:

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

Verwenden Sie das tatsächlich für Dante eingerichtete Dienstkonto mit geringen Rechten. Erstellen oder wählen Sie ein berechtigtes Clientkonto, das zum Benutzernamen-Backend passt; Dienstidentität und Clientanmeldung erfüllen unterschiedliche Aufgaben.

Anfragegrenzen beibehalten

Verlangen Sie nach der bestehenden eng gefassten Clientregel das Konto auf der erlaubten 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
}

Adressen und Kontoname sind Platzhalter. Erlaubt werden eine Quelle, ein Ziel, ein Befehl und der angegebene authentifizierte Benutzer. Ersetzen Sie diese Grenze nicht durch beliebige Quellen, nur weil ein Passwort hinzugekommen ist.

Globale und regelspezifische Methodeneinstellungen müssen übereinstimmen. Suchen Sie nach einer alten Regel, die nur none zulässt und aus der rein quellbasierten Einrichtung stammt. Behalten Sie auch die vorgesehenen Listener- und Firewallbeschränkungen bei.

Aushandlung und Zugriff getrennt testen

Prüfen Sie die Datei vor dem Start mit dem Konfigurationsprüfmodus des installierten Servers. Nutzen Sie dann einen berechtigten Client, der tatsächlich SOCKS5-Aushandlung mit Benutzername und Passwort unterstützt. Prüfen Sie fehlende und falsche Zugangsdaten sowie ein erlaubtes Konto, das ein verbotenes Ziel anfragt.

Die in RFC 1929 definierte Benutzername/Passwort-Unterverhandlung verschlüsselt das Passwort nicht. Eine spätere HTTPS-Sitzung zum Ziel schützt diesen vorherigen Proxyaustausch nicht. Verwenden Sie einen angemessen geschützten Weg vom Client zum Server.

Eine erfolgreiche Konfigurationsprüfung bestätigt Syntax und Identitäten, nicht die Kontodatenbank oder den Netzwerkpfad. Sehen Sie in den Serverprotokollen nach, in welcher Phase ein echter Test abgewiesen wurde.

Ähnliche Artikel