Pievienojiet Dante autentifikāciju ar lietotājvārdu

Mainiet Dante 1.4.4 SOCKS politiku no piekļuves tikai pēc avota uz nepārprotamu konta pārbaudi, saglabājot avota un galamērķa ierobežojumus.

Dante 1.4.4 klienta noteikumi pieņem savienojumu pirms SOCKS saskaņošanas, bet SOCKS noteikumi nosaka, kuri autentificētie pieprasījumi drīkst turpināties. Savienojums no atļauta avota otrajā posmā joprojām var prasīt lietotājvārdu.

Autentifikācijai ar operētājsistēmas lietotājvārdiem pārskatiet gan pakalpojuma identitātes, gan metodi. Kontu datubāzes lasīšanai var būt vajadzīga privileģēta identitāte:

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

Izmantojiet īsto zemu tiesību pakalpojuma kontu, kas uzstādīts Dante vajadzībām. Izveidojiet vai izvēlieties pilnvarotu klienta kontu, kas sader ar lietotājvārdu pārbaudes aizmugursistēmu; pakalpojuma identitāte un klienta pieteikšanās pilda atšķirīgas lomas.

Saglabājiet pieprasījumu robežas

Pēc esošā šaurā klienta noteikuma pieprasiet kontu atļautajā SOCKS maršrutā:

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
}

Adreses un konta nosaukums ir parauga vērtības. Tas atļauj vienu avotu, vienu galamērķi, vienu komandu un norādīto autentificēto lietotāju. Neaizstājiet šo robežu ar neierobežotiem avotiem tikai tāpēc, ka pievienota parole.

Globālajiem un konkrētā noteikuma metodes iestatījumiem jāsakrīt. Pārbaudiet, vai no tikai avotā balstītas konfigurācijas nav palicis vecs noteikums, kas atļauj vienīgi none. Saglabājiet arī paredzētos klausītāja un ugunsmūra ierobežojumus.

Saskaņošanu un piekļuvi pārbaudiet atsevišķi

Pirms palaišanas pārbaudiet failu uzstādītā servera konfigurācijas pārbaudes režīmā. Pēc tam izmantojiet pilnvarotu klientu, kas patiešām atbalsta SOCKS5 lietotājvārda/paroles saskaņošanu. Izmēģiniet trūkstošus datus, nepareizus datus un atļautu kontu, kas pieprasa aizliegtu mērķi.

RFC 1929 definētā lietotājvārda/paroles apakšsaskaņošana nešifrē paroli. Vēlāka HTTPS sesija ar galamērķi neaizsargā šo agrāko apmaiņu ar starpniekserveri. Izmantojiet pienācīgi aizsargātu ceļu no klienta līdz serverim.

Veiksmīga konfigurācijas pārbaude apstiprina sintaksi un identitātes, nevis kontu datubāzi vai tīkla ceļu. Servera žurnālos meklējiet posmu, kurā noraidīts reāls izmēģinājums.

Saistītie raksti