Jaki jest sens opcji „UseDNS” sshd?

Wiem co to robi, ale nie wiem dlaczego . Jakim atakom zapobiega to?

Czy ma to znaczenie dla wszelkiego rodzaju metod uwierzytelniania? (oparty na hoście, hasło, klucz publiczny, klawiatura interaktywna ...)

Ta UseDNSopcja jest w większości bezużyteczna. Jeśli komputery klienckie są dostępne w Internecie, istnieje duża szansa, że ​​nie mają odwrotnego DNS, odwrotny DNS nie rozpoznaje przekazywania lub DNS nie dostarcza żadnych informacji innych niż „należy do tego” ISP ”, który już podaje adres IP.

W typowych konfiguracjach DNS służy tylko do rejestrowania. Można go użyć do uwierzytelnienia, ale tylko jeśli IgnoreRhosts nojest określony w sshd_config. Jest to dla kompatybilności ze starymi instalacjami, które wykorzystywane rsh, gdzie można powiedzieć „użytkownik o nazwie bobna maszynie zwanej darkstarmoże zalogować się jak alicenie wykazując żadnych poświadczeń” (pisząc darkstar bobw ~alice/.rhosts). Jest bezpieczny tylko wtedy, gdy ufasz wszystkim komputerom, które mogą łączyć się z serwerem ssh. Innymi słowy, bardzo rzadko jest to użyteczne w bezpieczny sposób.

Ponieważ wyszukiwanie DNS nie dostarcza żadnych użytecznych informacji, z wyjątkiem bardzo szczególnych okoliczności, należy je wyłączyć. O ile wiem, jedynym powodem, dla którego jest domyślnie włączony, jest to, że jest ono technicznie bardziej bezpieczne (jeśli martwisz się uwierzytelnianiem, a nie dostępnością), nawet jeśli dotyczy to tylko niewielkiej liczby okoliczności.

Kolejnym argumentem przemawiającym za wyłączeniem tej funkcji jest to, że każda zbędna funkcja stanowi niepotrzebne ryzyko bezpieczeństwa .

Dodałem do tego raport o błędzie (stary, ale wciąż aktualny) w Ubuntu.

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

Zaproponowałem zmianę wartości domyślnej na Nie i dodanie do niej nowszej dokumentacji:

# 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.

Ze strony 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”.

Włączenie tego powoduje, że dostęp z lokalizacji bez odpowiedniego (do przodu i do tyłu) DNS generuje ostrzeżenie w logach.

Więc to nie zapobiega atakowi, z wyjątkiem tego, że potrzebowałby kwalifikowanego zdalnego adresu klienta, aby nie rejestrować żadnego ostrzeżenia. Takie ostrzeżenie może pomóc w wytropieniu napastnika tylko wtedy, gdy ten rekord PTR ma jakikolwiek sens.

^{edycja: zaktualizowano zgodnie z komentarzem Andrieja Voitenkowa .}

Jest to potrzebne, gdy używasz opcji FROM w pliku uprawnionych kluczy i chcesz filtrować według nazw, a nie tylko adresów IP.

Opcja FROM w wierszu pliku Author_keys pozwala ograniczyć hosty, które mogą używać określonego klucza.
Zwiększa to zdolność zarządzania wieloma serwerami, które mają do siebie dostęp, bez pozwalania klonom komputera na podszywanie się pod jego pochodzenie, zwykle niezamierzone (resztki crontabs, błąd ludzki).

Chciałbym dodać, że w CentOS 7 (7.1.1503), a więc i w Red Hat Enterprise Linux 7, nie mogłem zalogować się przy ustawieniu domyślnym yesdla UseDNS. Po odkomentowaniu i ustawieniu go nomogłem się zalogować. Wygląda więc na to, że można odmówić usługi, jeśli DNS nie działa poprawnie! W CentOS 6 wygląda na to, że domyślnie jest noi dlatego nie mogę sshdziałać bez DNS!

Chciałbym dodać, że moje eksperymenty dotyczyły pojemników LXC, a nie fizycznej maszyny, na wypadek, gdyby to miało znaczenie!