Tambah Pengesahan Nama Pengguna pada Dante

Ubah dasar SOCKS Dante 1.4.4 daripada akses berasaskan sumber sahaja kepada semakan akaun yang jelas, sambil mengekalkan sekatan sumber dan destinasi.

Dalam Dante 1.4.4, peraturan klien menerima sambungan sebelum rundingan SOCKS, manakala peraturan SOCKS menentukan permintaan yang telah disahkan yang boleh diteruskan. Sambungan daripada sumber yang dibenarkan masih boleh memerlukan nama pengguna pada peringkat kedua.

Untuk pengesahan menggunakan nama pengguna sistem pengendalian, semak identiti perkhidmatan selain kaedahnya. Membaca pangkalan data akaun mungkin memerlukan identiti berkeistimewaan:

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

Gunakan akaun perkhidmatan sebenar dengan hak rendah yang dipasang untuk Dante. Cipta atau pilih akaun klien yang dibenarkan dan serasi dengan bahagian belakang nama pengguna; identiti perkhidmatan dan log masuk klien mempunyai peranan berlainan.

Kekalkan sempadan permintaan

Selepas peraturan klien terhad yang sedia ada, wajibkan akaun pada laluan SOCKS yang dibenarkan:

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
}

Alamat dan nama akaun itu nilai contoh. Ini membenarkan satu sumber, satu destinasi, satu perintah dan pengguna yang disahkan seperti dinyatakan. Jangan menggantikan sempadan ini dengan sumber tanpa sekatan hanya kerana kata laluan telah ditambah.

Tetapan kaedah global dan tetapan khusus peraturan mesti sepadan. Cari peraturan lama yang hanya membenarkan none dan tertinggal daripada persediaan berasaskan sumber sahaja. Kekalkan juga sekatan pendengar dan tembok api yang dimaksudkan.

Uji rundingan dan akses secara berasingan

Sebelum memulakannya, semak fail dengan mod semakan konfigurasi pelayan yang dipasang. Kemudian gunakan klien yang dibenarkan dan benar-benar menyokong rundingan nama pengguna/kata laluan SOCKS5. Uji bukti kelayakan yang tiada, bukti kelayakan salah dan akaun yang dibenarkan meminta sasaran terlarang.

Subrundingan nama pengguna/kata laluan yang ditakrifkan oleh RFC 1929 tidak menyulitkan kata laluan. Sesi HTTPS dengan destinasi yang berlaku kemudian tidak melindungi pertukaran proksi terdahulu itu. Gunakan laluan klien-ke-pelayan yang dilindungi sewajarnya.

Semakan konfigurasi yang berjaya mengesahkan sintaks dan identiti, bukan pangkalan data akaun atau laluan rangkaian. Lihat log pelayan untuk mengetahui peringkat yang menolak ujian sebenar.

Artikel berkaitan