Tambahkan Autentikasi Nama Pengguna ke Dante

Ubah kebijakan SOCKS Dante 1.4.4 dari akses berdasarkan sumber saja menjadi pemeriksaan akun yang tegas, sambil mempertahankan batasan sumber dan tujuan.

Di Dante 1.4.4, aturan klien menerima koneksi sebelum negosiasi SOCKS, sedangkan aturan SOCKS menentukan permintaan terautentikasi mana yang boleh dilanjutkan. Koneksi dari sumber yang diizinkan masih bisa diwajibkan memberikan nama pengguna pada tahap kedua.

Untuk autentikasi menggunakan nama pengguna sistem operasi, tinjau identitas layanan selain metodenya. Membaca basis data akun mungkin memerlukan identitas dengan hak istimewa:

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

Gunakan akun layanan berhak rendah yang benar-benar dipasang untuk Dante. Buat atau pilih akun klien berwenang yang kompatibel dengan backend nama pengguna; identitas layanan dan login klien memiliki peran berbeda.

Pertahankan batas permintaan

Setelah aturan klien ketat yang sudah ada, wajibkan akun pada rute SOCKS yang diizinkan:

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 akun tersebut hanyalah contoh. Aturan ini mengizinkan satu sumber, satu tujuan, satu perintah, dan pengguna terautentikasi yang disebutkan. Jangan mengganti batas itu dengan sumber tanpa batas hanya karena kata sandi telah ditambahkan.

Pengaturan metode global dan pengaturan pada aturan harus selaras. Cari aturan lama yang hanya mengizinkan none dan tersisa dari konfigurasi berbasis sumber saja. Pertahankan pula batasan listener dan firewall yang dimaksud.

Uji negosiasi dan akses secara terpisah

Sebelum menjalankannya, periksa berkas dengan mode pemeriksaan konfigurasi server yang terpasang. Kemudian gunakan klien berwenang yang benar-benar mendukung negosiasi nama pengguna/kata sandi SOCKS5. Uji kredensial yang tidak ada, kredensial salah, dan akun yang diizinkan tetapi meminta tujuan terlarang.

Subnegosiasi nama pengguna/kata sandi yang ditentukan RFC 1929 tidak mengenkripsi kata sandi. Sesi HTTPS ke tujuan yang berlangsung kemudian tidak melindungi pertukaran proksi sebelumnya itu. Gunakan jalur klien-ke-server yang terlindungi dengan semestinya.

Pemeriksaan konfigurasi yang berhasil mengonfirmasi sintaks dan identitas, bukan basis data akun atau jalur jaringan. Periksa log server untuk mengetahui tahap yang menolak pengujian nyata.

Artikel terkait