Wymagaj logowania w obu usługach 3proxy: HTTP i SOCKS

Skonfiguruj użytkowników 3proxy, silne uwierzytelnianie i reguły dostępu do usług dla klientów HTTP i SOCKS5.

Zdefiniowanie użytkownika nie jest całą konfiguracją logowania 3proxy. Usługa potrzebuje też metody uwierzytelniania i reguły dostępu, która jej używa. Kolejność ma znaczenie, ponieważ ustawienia usługi obowiązują podczas przetwarzania konfiguracji.

Przykład wyłącznie lokalny dla dwóch usług:

users alex:CL:replace_with_a_private_password
auth strong
allow alex
proxy -i127.0.0.1 -p3128
flush
allow alex
socks -i127.0.0.1 -p1080

Dokumentacja konfiguracji wyjaśnia users, auth strong i polecenia usług. CL przechowuje to przykładowe hasło jako zwykły tekst. Chroń plik i wybierz obsługiwaną formę przechowywania poświadczeń odpowiednią dla wdrożenia.

Klient potrzebuje właściwej wymiany logowania

Usługa HTTP oczekuje uwierzytelniania proxy HTTP. Usługa SOCKS potrzebuje klienta obsługującego uwierzytelnianie SOCKS5 nazwą użytkownika i hasłem. Klient SOCKS4 nie może zapewnić tej wymiany tylko dlatego, że dociera do tego samego portu nasłuchu.

Słowo strong to nazwa trybu uwierzytelniania, a nie gwarancja szyfrowanego transportu. W razie potrzeby chroń odcinek od klienta do proxy. HTTPS do celu i szyfrowanie do proxy pozostają odrębnymi decyzjami.

Powiązania loopback ograniczają ten przykład do dostępu lokalnego. Dla klientów zdalnych wyraźnie wybierz zamierzony nasłuch i politykę sieciową. Publiczny nasłuch z symbolami wieloznacznymi nie zastępuje sprawdzenia zachowania logowania.

Jeśli jedna usługa żąda poświadczeń, a inna nie, sprawdź ustawienia przed każdym poleceniem usługi, reguły po każdym flush i pamięć podręczną uwierzytelniania. Zmiana hasła nie naprawi usługi uruchomionej pod niewłaściwą polityką. Podobnie zmiana konta systemu operacyjnego demona nie tworzy użytkownika proxy.

Powiązane artykuły