Який сенс sshd „UseDNS”?

Я знаю, що це робить, але не знаю чому . Який напад (-ів) запобігає?

Чи це актуально для всіх видів аутентифікації? (на базі хоста, пароля, відкритого ключа, інтерактивної клавіатури ...)

UseDNSОпція в основному марна. Якщо клієнтські машини знаходяться там в Інтернеті, є велика ймовірність того, що у них немає зворотного DNS, їх зворотний DNS не вирішується вперед або їх DNS не надає іншої інформації, окрім „належить до цього ISP », про який вже вам розповідає 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 має сенс.

^{редагувати: оновлено згідно з коментарем Андрія Войтенкова .}

Він потрібен, коли ви використовуєте опцію ВІД у файлі дозволеного_контажу, і ви хочете фільтрувати за іменами, а не лише IP-адресами.

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

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

Я хотів би додати, що мій експеримент був на контейнерах LXC, а не на фізичній машині, на випадок, якщо це має значення!