Apa gunanya opsi sshd "UseDNS"?


79

Saya tahu apa fungsinya, tetapi saya tidak tahu mengapa . Serangan apa yang mencegahnya?

Apakah ini relevan untuk semua jenis metode otentikasi? (berbasis host, kata sandi, publickey, keyboard-interactive ...)


2
Saya menambahkan satu ke CoreOS juga di sini: github.com/coreos/bugs/issues/92

Jawaban:


66

The UseDNSpilihan adalah sebagian besar tidak berguna. Jika mesin klien ada di luar sana di Internet, ada kemungkinan besar mereka tidak memiliki DNS balik, DNS terbalik mereka tidak menyelesaikan maju, atau DNS mereka tidak memberikan informasi apa pun selain "milik ini" ISP ”yang sudah diberi tahu alamat IP Anda.

Dalam konfigurasi tipikal, DNS hanya digunakan untuk logging. Ini dapat digunakan untuk otentikasi, tetapi hanya jika IgnoreRhosts noditentukan dalam sshd_config. Hal ini untuk kompatibilitas dengan instalasi lama yang digunakan rsh, di mana Anda dapat mengatakan “pengguna yang disebut bobpada mesin yang disebut darkstardapat login sebagai alicetanpa menunjukkan kredensial” (dengan menulis darkstar bobdi ~alice/.rhosts). Ini hanya aman jika Anda percaya semua mesin yang mungkin terhubung ke server ssh. Dengan kata lain, ini sangat jarang dapat digunakan dengan cara yang aman.

Mengingat bahwa pencarian DNS tidak memberikan informasi yang berguna kecuali dalam keadaan yang sangat aneh, itu harus dimatikan. Sejauh yang saya tahu, satu-satunya alasan aktif secara default adalah bahwa secara teknis lebih aman (jika Anda khawatir tentang otentikasi, bukan ketersediaan), meskipun itu hanya berlaku untuk sejumlah kecil keadaan.

Argumen lain untuk mematikan fitur ini adalah bahwa setiap fitur berlebihan adalah risiko keamanan yang tidak perlu .


Jadi, UseDNS hanya relevan untuk otentikasi berbasis host? Jika saya tidak menggunakan otentikasi berbasis host dan saya tidak peduli apakah nama host atau IP muncul dalam log, UseDNS tidak ada bedanya?
user368507

5
@ user368507 Ya, itu dia. UseDNSbahkan tidak berguna jika Anda menggunakan otentikasi host berbasis kunci , hanya jika Anda menggunakan otentikasi host berbasis hostname (yaitu otentikasi sangat lemah).
Gilles

3
@Gilles tentu saja, jika Anda menggunakan otentikasi berbasis kunci dan berbasis hostname, UseDNSsangat berguna, dan kritis. Anda mengautentikasi pengguna berdasarkan kunci, dan server berdasarkan pada nama host, ditugaskan ke alamat MAC.
kara deniz

38

Saya menambahkan laporan bug (lama tapi masih terkini) di Ubuntu tentang ini.

https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/424371

Saya mengusulkan mengubah default ke Tidak dan menambahkan dokumentasi yang lebih baru di atasnya:

# UseDNS - Determines whether IP Address to Hostname lookup and comparison is performed
# Default value is No which avoids login delays when the remote client's DNS cannot be resolved
# Value of No implies that the usage of "from=" in authorized_keys will not support DNS host names but only IP addresses.
# Value of Yes supports host names in "from=" for authorized_keys. Additionally if the remote client's IP address does not match the resolved DNS host name (or could not be reverse lookup resolved) then a warning is logged.

2
Upvote up ... ini lebih berguna, karena berisi informasi yang saya cari.
0xC0000022L

1
Demikian pula jika UseDNS tidak ada maka nama host tidak dapat dicocokkan dengan aturan pam_access dan IP harus digunakan sebagai gantinya.
ColinM

1
Saya memutakhirkan jawaban ini beberapa tahun yang lalu tetapi hanya hari ini saya memperhatikan bahwa, defaultnya diubah menjadi "UseDNS no" di OpenSSH 6.8p1, yang ada di Ubuntu 15.10 dan yang lebih baru .
Anthony G - keadilan untuk Monica

RedHat (dalam RHEL7) baru-baru ini mengubah standar menjadi Tidak juga, yang memecah kontrol akses berbasis hostname (yang berguna sebagai sebagian besar kontrol penasehat pada intranet, jelas bukan sebagai satu-satunya mekanisme kontrol akses).
dannysauer

8

Dari halaman manual sshd_config(5):

 UseDNS  Specifies whether sshd(8) should look up the remote host name and
         check that the resolved host name for the remote IP address maps
         back to the very same IP address.  The default is “yes”.

Mengaktifkan ini membuat akses dari lokasi tanpa DNS yang benar (maju dan mundur) menghasilkan peringatan di log.

Jadi ini tidak mencegah serangan apa pun kecuali bahwa itu akan memerlukan alamat remote klien yang berkualifikasi agar tidak mencatat peringatan apa pun. Peringatan semacam itu dapat membantu Anda melacak penyerang hanya jika catatan PTR itu masuk akal.

sunting: diperbarui sesuai dengan komentar Andrey Voitenkov .


Jadi itu adalah filter pada siapa yang diizinkan terhubung berdasarkan apa pun yang ada di server DNS?
user368507

2
Mengapa itu membuat akses tidak mungkin? sshd hanya menghasilkan peringatan jika catatan DNS A / PTR tidak cocok. Urutan masuk akan lambat jika menyelesaikan masalah.
Andrey Voitenkov

Hal ini mencegah akses jika kunci yang diotorisasi telah dikompromikan selama penyerang tidak dapat menipu nilai-nilai di from=lapangan sebelum kunci yang diotorisasi tersebut dipertanyakan (jika digunakan).
Alecz

7

Ini diperlukan saat Anda menggunakan opsi FROM dalam file Authorized_key dan Anda ingin memfilter berdasarkan nama dan bukan hanya IP.

Opsi FROM di baris file yang diotorisasi memungkinkan Anda membatasi host yang dapat menggunakan kunci tertentu.
Ini meningkatkan kemampuan mengelola beberapa server yang memiliki akses satu sama lain tanpa memungkinkan klon mesin meniru asal-usulnya, biasanya tidak sengaja (sisa crontab, kesalahan manusia).


3

Saya ingin menambahkan itu pada CentOS 7 (7.1.1503) dan karenanya Red Hat Enterprise Linux 7, saya tidak dapat masuk dengan pengaturan default yesfor UseDNS. Setelah menghapus komentar dan mengaturnya no, saya bisa masuk. Tampaknya memang ada yang bisa ditolak layanan jika DNS tidak berfungsi dengan benar! Di CentOS 6, tampaknya defaultnya adalah nodan karenanya saya bisa sshmasuk tanpa DNS yang berfungsi!

Saya ingin menambahkan bahwa eksperimen saya menggunakan wadah LXC dan bukan mesin fisik, kalau-kalau ada bedanya!

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.