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 ...)
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 ...)
Odpowiedzi:
Ta UseDNS
opcja 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 no
jest 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 bob
na maszynie zwanej darkstar
może zalogować się jak alice
nie wykazując żadnych poświadczeń” (pisząc darkstar bob
w ~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 .
UseDNS
nie 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).
UseDNS
jest bardzo przydatne i krytyczne. Uwierzytelniasz użytkownika na podstawie klucza, a serwer na podstawie nazwy hosta przypisanego do adresu MAC.
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 .
from=
polu przed danym kluczem autoryzowanym (jeśli jest używany).
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 yes
dla UseDNS
. Po odkomentowaniu i ustawieniu go no
mogł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 no
i dlatego nie mogę ssh
dział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!