Jaki jest sens opcji „UseDNS” sshd?


Odpowiedzi:


65

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 .


A więc UseDNS ma zastosowanie tylko do uwierzytelniania opartego na hoście? Jeśli nie używam uwierzytelniania opartego na hoście i nie obchodzi mnie, czy nazwa hosta lub adres IP są wyświetlane w dziennikach, UseDNS nie robi różnicy?
user368507,

5
@ user368507 Tak, to wszystko. UseDNSnie jest nawet przydatny, jeśli używasz uwierzytelniania hosta opartego na kluczu , tylko jeśli używasz uwierzytelniania hosta opartego na nazwie hosta (tj. bardzo słabe uwierzytelnienie).
Gilles

3
@Gilles oczywiście, jeśli używasz uwierzytelniania opartego na kluczu i nazwie hosta, UseDNSjest bardzo przydatne i krytyczne. Uwierzytelniasz użytkownika na podstawie klucza, a serwer na podstawie nazwy hosta przypisanego do adresu MAC.
kara deniz

38

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.

2
Up up głosuj ... jest to bardziej przydatne, ponieważ zawiera informacje, których szukałem.
0xC0000022L

1
Podobnie, jeśli UseDNS jest przeczący, nazwy hostów nie mogą być dopasowane w regułach pam_access i zamiast tego należy użyć adresów IP.
ColinM

1
Poparłem tę odpowiedź kilka lat temu, ale dopiero dzisiaj zauważyłem, że domyślna zmieniona została na „UseDNS no” w OpenSSH 6.8p1, który jest w Ubuntu 15.10 i nowszych .
Anthony Geoghegan

RedHat (w RHEL7) niedawno również zmienił domyślną wartość na Nie, co psuje kontrolę dostępu opartą na nazwie hosta (co jest przydatne jako przeważnie kontrola doradcza w intranecie, oczywiście nie jako jedyny mechanizm kontroli dostępu).
dannysauer

8

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 .


Więc to jest filtr określający, kto może łączyć się na podstawie tego, co jest na serwerze DNS?
user368507

2
Dlaczego miałoby to uniemożliwić dostęp? sshd po prostu generuje ostrzeżenie, jeśli rekordy DNS A / PTR nie są zgodne. Sekwencja logowania będzie powolna w przypadku rozwiązywania problemów.
Andrey Voitenkov

Zapobiega to dostępowi, jeśli klucz autoryzowany został naruszony, dopóki atakujący nie może sfałszować wartości w from=polu przed danym kluczem autoryzowanym (jeśli jest używany).
Alecz

7

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


3

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!

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.