Dodajte autentifikaciju korisničkim imenom u Dante

Prebacite SOCKS politiku u Dante 1.4.4 sa pristupa samo prema izvoru na izričitu proveru naloga, uz zadržavanje ograničenja izvora i odredišta.

U Dante 1.4.4 klijentska pravila prihvataju vezu pre SOCKS pregovaranja, a SOCKS pravila određuju koji autentifikovani zahtevi smeju da nastave. Veza sa dozvoljenog izvora i dalje može zahtevati korisničko ime u drugoj fazi.

Za autentifikaciju korisničkim imenom operativnog sistema pregledajte identitete servisa uz metod. Čitanje baze naloga može zahtevati privilegovani identitet:

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

Koristite stvarni servisni nalog s malim ovlašćenjima instaliran za Dante. Napravite ili izaberite ovlašćeni klijentski nalog kompatibilan sa pozadinskim sistemom za korisnička imena; identitet servisa i klijentska prijava imaju različite uloge.

Zadržite granice zahteva

Posle postojećeg uskog klijentskog pravila zahtevajte nalog na dozvoljenoj SOCKS ruti:

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
}

Adrese i naziv naloga su primeri. Time se dozvoljavaju jedan izvor, jedno odredište, jedna komanda i navedeni autentifikovani korisnik. Ne zamenjujte tu granicu neograničenim izvorima samo zato što je dodata lozinka.

Globalna podešavanja metoda i podešavanja pojedinačnog pravila moraju biti usklađena. Proverite da li je ostalo staro pravilo samo sa none iz postavke pristupa isključivo prema izvoru. Zadržite i predviđena ograničenja osluškivača i zaštitnog zida.

Pregovaranje i pristup testirajte odvojeno

Pre pokretanja proverite datoteku režimom provere konfiguracije instaliranog servera. Zatim koristite ovlašćeni klijent koji zaista podržava SOCKS5 pregovaranje korisničkim imenom i lozinkom. Proverite nedostajuće i pogrešne podatke i dozvoljeni nalog koji traži zabranjeni cilj.

Potpregovaranje korisničkim imenom i lozinkom definisano u RFC 1929 ne šifruje lozinku. Kasnija HTTPS sesija sa odredištem ne štiti tu raniju razmenu sa proksijem. Koristite odgovarajuće zaštićenu putanju od klijenta do servera.

Uspešna provera konfiguracije potvrđuje sintaksu i identitete, a ne bazu naloga ili mrežnu putanju. U serverskim zapisima pronađite fazu koja je odbila stvarni test.

Povezani članci