Всякий раз, когда я где-то использую SSH, я получаю что-то вроде этого в журналах:
sshd[16734]: reverse mapping checking getaddrinfo for
1.2.3.4.crummyisp.net [1.2.3.4] failed - POSSIBLE BREAK-IN ATTEMPT!
И это является правильно: если я сделаю host 1.2.3.4 он возвращается 1.2.3.4.crummyisp.net, но если я сделаю host 1.2.3.4.crummyisp.net не найдено.
У меня два вопроса:
Какая угроза безопасности существует? Как кто-то мог подделать односторонний DNS каким-либо угрожающим образом?
Есть ли у меня способ исправить это? Я отправлю своему интернет-провайдеру отчет об ошибке, но кто знает, куда это денется.
Какая угроза безопасности существует?
Как кто-то мог подделать односторонний DNS каким-либо угрожающим образом?
Любая сторона, контролирующая обратную зону DNS, может установить для своих записей PTR все, что пожелает. Вполне возможно, что кто-то может установить свой PTR-рекорд на legithost.example.com, а затем попытайтесь ворваться в вашу среду.
Если у вас есть пользователи с толстыми пальцами, которые склонны ошибочно вводить свои пароли и не принимают мер по борьбе с перебором, множество записей журнала для неудачных паролей от legithost.example.com может быть отклонен как «О, это просто Боб - он не может печатать, чтобы спасти свою жизнь!» и дать злоумышленнику возможность угадывать пароли, пока они не войдут.
(Теоретическая выгода от этого сообщения заключается в том, что злоумышленник не могу создать / изменить A запись для legithost.example.com в вашей зоне DNS, поэтому он не может отключить предупреждение - при отсутствии атаки с отравлением DNS ...)
Есть ли у меня способ исправить это?
Опция 1: Исправьте свой DNS так, чтобы вперед (A) и обратный (PTR) записи совпадают.
Вариант 2: Добавить UseDNS no к вашей системе sshd_config файл, чтобы отключить предупреждение.
Если HostbasedAuthentication настроен, можно указать имена хостов, которые могут войти в /etc/hosts.equiv, ~/.shosts и ~/.rhosts. (На клиентском хосте также есть проверка открытого ключа (это может быть known_host к серверу)).
Это может быть использовано при утечке ключа (в этом случае проблема уже возникла) и HostbasedUsesNameFromPacketOnly установлен на yes (Возможно UseDNS no может также потребоваться), и злоумышленник с соответствующими ключами сообщает имя авторизованного хоста.
Другая атака может заключаться в том, что один известный сервер притворяется другим известным сервером для получения более высоких привилегий.
Чтобы избежать этих атак, сравнивается обратный и прямой DNS (и запись в журнале появляется, если они не совпадают).
Другая вещь, которая может быть атакована: authorized_keys host= параметр и Match блок для Host, который может быть активирован для неправильного хоста в случае использования имен хостов (вместо IP-адресов) и изменения записей DNS. (UseDNS yes необходимо использовать для этого не-IP)