Dodaj uwierzytelnianie nazwą użytkownika w Dante

Zmień politykę SOCKS w Dante 1.4.4 z dostępu wyłącznie według źródła na jawną kontrolę konta, zachowując ograniczenia źródła i celu.

W Dante 1.4.4 reguły klienta dopuszczają połączenie przed negocjacją SOCKS, a reguły SOCKS rozstrzygają, które uwierzytelnione żądania mogą być kontynuowane. Połączenie z dozwolonego źródła nadal może wymagać nazwy użytkownika na drugim etapie.

Przy uwierzytelnianiu nazwą użytkownika systemu operacyjnego sprawdź zarówno metodę, jak i tożsamości usługi. Odczyt bazy kont może wymagać uprzywilejowanej tożsamości:

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

Użyj rzeczywistego konta usługi o małych uprawnieniach zainstalowanego dla Dante. Utwórz lub wybierz uprawnione konto klienta zgodne z backendem nazw użytkowników; tożsamość usługi i logowanie klienta pełnią różne role.

Zachowaj granice żądań

Po istniejącej, wąskiej regule klienta wymagaj konta na dozwolonej trasie SOCKS:

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
}

Adresy i nazwa konta są przykładowe. Pozwala to na jedno źródło, jeden cel, jedno polecenie i wskazanego uwierzytelnionego użytkownika. Nie zastępuj tej granicy nieograniczonymi źródłami tylko dlatego, że dodano hasło.

Globalne ustawienia metody i ustawienia w regule muszą być zgodne. Sprawdź, czy nie pozostała stara reguła dopuszczająca tylko none z konfiguracji opartej wyłącznie na źródle. Zachowaj też zamierzone ograniczenia nasłuchu i zapory.

Testuj negocjację i dostęp oddzielnie

Przed uruchomieniem sprawdź plik trybem kontroli konfiguracji zainstalowanego serwera. Następnie użyj uprawnionego klienta rzeczywiście obsługującego negocjację SOCKS5 z nazwą użytkownika i hasłem. Sprawdź brak danych, nieprawidłowe dane oraz dozwolone konto żądające zabronionego celu.

Podnegocjacja nazwy użytkownika i hasła z RFC 1929 nie szyfruje hasła. Późniejsza sesja HTTPS z celem nie chroni wcześniejszej wymiany z proxy. Użyj odpowiednio zabezpieczonej drogi między klientem a serwerem.

Pomyślna kontrola konfiguracji potwierdza składnię i tożsamości, a nie bazę kont czy trasę sieciową. W dziennikach serwera ustal, na którym etapie odrzucono rzeczywisty test.

Powiązane artykuły