Lisää Danteen käyttäjänimitodennus

Vaihda Dante 1.4.4:n SOCKS-käytäntö pelkästä lähdepohjaisesta pääsystä nimenomaiseen tilitarkistukseen säilyttäen lähde- ja kohderajoitukset.

Dante 1.4.4:ssä asiakassäännöt hyväksyvät yhteyden ennen SOCKS-neuvottelua, ja SOCKS-säännöt päättävät, mitkä todennetut pyynnöt saavat jatkaa. Sallitusta lähteestä tuleva yhteys voi silti vaatia käyttäjänimen toisessa vaiheessa.

Kun käytät käyttöjärjestelmän käyttäjänimitodennusta, tarkista menetelmän lisäksi palvelun identiteetit. Tilitietokannan lukeminen voi vaatia etuoikeutetun identiteetin:

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

Käytä Dantelle asennettua todellista, vähin oikeuksin toimivaa palvelutiliä. Luo tai valitse käyttäjänimitaustajärjestelmään sopiva valtuutettu asiakastili; palvelun identiteetti ja asiakkaan kirjautuminen ovat eri rooleja.

Säilytä pyyntöjen rajat

Vaadi tili sallitulla SOCKS-reitillä olemassa olevan tiukan asiakassäännön jälkeen:

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
}

Osoitteet ja tilin nimi ovat esimerkkiarvoja. Tämä sallii yhden lähteen, yhden kohteen, yhden komennon ja nimetyn todennetun käyttäjän. Älä korvaa tätä rajaa rajoittamattomilla lähteillä vain siksi, että salasana on lisätty.

Yleisten ja sääntökohtaisten menetelmäasetusten on vastattava toisiaan. Tarkista, onko pelkkään lähteeseen perustuvasta asetuksesta jäänyt vanha vain none-menetelmän salliva sääntö. Säilytä myös tarkoitetut kuuntelija- ja palomuurirajoitukset.

Testaa neuvottelu ja pääsy erikseen

Tarkista tiedosto asennetun palvelimen määritystarkistustilassa ennen käynnistystä. Käytä sitten valtuutettua asiakasta, joka todella tukee SOCKS5-käyttäjänimi-/salasananeuvottelua. Testaa puuttuvat tunnukset, väärät tunnukset ja sallittu tili, joka pyytää kiellettyä kohdetta.

RFC 1929:n määrittelemä käyttäjänimi-/salasana-alineuvottelu ei salaa salasanaa. Myöhempi HTTPS-istunto kohteeseen ei suojaa aiempaa välityspalvelinvaihtoa. Käytä asianmukaisesti suojattua reittiä asiakkaalta palvelimelle.

Onnistunut määritystarkistus vahvistaa syntaksin ja identiteetit, ei tilitietokantaa tai verkkoreittiä. Katso palvelimen lokeista, missä vaiheessa todellinen testi hylättiin.

Aiheeseen liittyvät artikkelit