Dodajte provjeru korisničkog imena u Dante

Prebacite SOCKS politiku u Dante 1.4.4 s pristupa samo prema izvoru na izričitu provjeru računa, uz zadržavanje ograničenja izvora i odredišta.

U Dante 1.4.4 klijentska pravila prihvataju vezu prije SOCKS pregovaranja, dok SOCKS pravila određuju koji autentificirani zahtjevi smiju nastaviti. Veza s dozvoljenog izvora i dalje može zahtijevati korisničko ime u drugoj fazi.

Za autentifikaciju korisničkim imenom operativnog sistema pregledajte i servisne identitete i metodu. Čitanje baze računa može zahtijevati privilegirani identitet:

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

Koristite stvarni servisni račun s malim ovlastima instaliran za Dante. Kreirajte ili odaberite ovlašteni klijentski račun kompatibilan s pozadinskim sistemom za korisnička imena; servisni identitet i klijentska prijava imaju različite uloge.

Zadržite granice zahtjeva

Nakon postojećeg uskog klijentskog pravila zahtijevajte račun 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 računa su primjeri. Time se dozvoljava jedan izvor, jedno odredište, jedna naredba i navedeni autentificirani korisnik. Ne zamjenjujte tu granicu neograničenim izvorima samo zato što ste dodali lozinku.

Globalne i postavke metode u pojedinačnom pravilu moraju se slagati. Provjerite je li ostalo staro pravilo koje dozvoljava samo none iz postavke pristupa samo prema izvoru. Zadržite i predviđena ograničenja slušača i vatrozida.

Testirajte pregovaranje i pristup odvojeno

Prije pokretanja provjerite datoteku načinom za provjeru konfiguracije instaliranog servera. Zatim koristite ovlašteni klijent koji zaista podržava SOCKS5 pregovaranje korisničkim imenom i lozinkom. Provjerite nedostajuće i pogrešne vjerodajnice te dozvoljeni račun koji traži zabranjeno odredište.

Podpregovaranje korisničkim imenom i lozinkom definirano u RFC 1929 ne šifrira lozinku. Kasnija HTTPS sesija s odredištem ne štiti tu raniju razmjenu s proxyjem. Koristite odgovarajuće zaštićen put između klijenta i servera.

Uspješna provjera konfiguracije potvrđuje sintaksu i identitete, a ne bazu računa ili mrežni put. U serverskim zapisima pronađite fazu koja je odbila stvarni test.

Povezani članci