Какой смысл использовать sshd «UseDNS»?

Я знаю, что он делает, но я не знаю почему . Какие атаки это предотвращает?

Это актуально для всех видов методов аутентификации? (на базе хоста, пароль, publickey, клавиатура-интерактив ...)

UseDNSОпция в основном бесполезна. Если клиентские машины находятся в Интернете, существует высокая вероятность того, что у них нет обратного DNS, их обратный DNS не разрешается вперед или их DNS не предоставляет никакой информации, кроме «принадлежит этому». Интернет-провайдер », о котором вам уже говорит IP-адрес.

В типичных конфигурациях DNS используется только для регистрации. Может использоваться для аутентификации, но только если IgnoreRhosts noуказано в sshd_config. Это для совместимости со старыми установками, которые использовали rsh, где вы можете сказать, что «пользователь, вызванный bobна вызываемой машине, darkstarможет войти в систему как aliceбез показа учетных данных» (написав darkstar bobв ~alice/.rhosts). Это безопасно, только если вы доверяете всем машинам, которые могут подключаться к серверу ssh. Другими словами, это очень редко используется безопасным способом.

Учитывая, что поиск DNS не предоставляет никакой полезной информации, за исключением очень специфических обстоятельств, ее следует отключить. Насколько я могу судить, единственная причина, по которой он включен по умолчанию, заключается в том, что он технически более безопасен (если вас интересует аутентификация, а не доступность), даже если это применимо только к крошечному набору обстоятельств.

Другим аргументом для отключения этой функции является то, что каждая лишняя функция представляет собой ненужную угрозу безопасности .

Я добавил в отчет об ошибке (старой, но все еще актуальной) в Ubuntu об этом.

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

Я предложил изменить значение по умолчанию на Нет и добавить более новую документацию по нему:

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

Из справочной страницы 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”.

Включение этого делает доступ из местоположения без надлежащего (прямого и обратного) DNS генерирует предупреждение в журналах.

Таким образом, это не предотвращает любую атаку, за исключением того, что для регистрации какого-либо предупреждения ему понадобится определенный удаленный адрес клиента. Такое предупреждение может помочь вам отследить злоумышленника, только если эта запись PTR имеет какой-либо смысл.

^{редактировать: обновлено в соответствии с комментариями Андрея Войтенкова .}

Это необходимо, когда вы используете опцию FROM в файле author_keys и хотите фильтровать по именам, а не только по IP-адресам.

Опция FROM в строке файла author_keys позволяет ограничить хосты, которые могут использовать определенный ключ.
Это увеличивает возможность управления несколькими серверами, которые имеют доступ друг к другу, не позволяя клонам машины выдавать себя за свое происхождение, как правило, непреднамеренно (оставшиеся crontabs, человеческая ошибка).

Я хотел бы добавить, что в CentOS 7 (7.1.1503) и, следовательно, в Red Hat Enterprise Linux 7 я не смог войти в систему с настройкой по умолчанию для yesfor UseDNS. После раскомментирования и установки его noя смог войти в систему. Таким образом, кажется, что действительно может быть отказано в обслуживании, если DNS не работает правильно! В CentOS 6, кажется, по умолчанию, noи, следовательно, я могу sshбез функционирующего DNS!

Я хотел бы добавить, что мои эксперименты были на контейнерах LXC, а не на физической машине, на случай, если что-то изменится!