Предупреждение sshd, "ВОЗМОЖНАЯ ПОПЫТКА НА ВСТУПЛЕНИЕ!" для неудачного обратного DNS
Всякий раз, когда я где-нибудь 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 каким-то угрожающим способом?
Есть ли у меня возможность исправить это? Я отправлю своему провайдеру отчет об ошибке, но кто знает, куда это пойдет.
2 ответа
Какая угроза безопасности там?
Как кто-то может подделать односторонний 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
Tou может указать имена хостов, которые могут войти в /etc/hosts.equiv
, ~/.shosts
а также ~/.rhosts
, (Также существует проверка открытого ключа на клиентском хосте (это может быть known_host
на сервер)).
Это может быть использовано в случае утечки ключа (в этом случае у вас уже есть проблема) и HostbasedUsesNameFromPacketOnly
установлен в yes
(Возможно, UseDNS no
также может понадобиться) и злоумышленник с соответствующими ключами дает имя хоста авторизованного хоста.
Другая атака может быть одним известным сервером, притворяющимся другим известным сервером для получения более высоких привилегий.
Чтобы избежать этих атак, сравнивается обратный и прямой DNS (и запись журнала появляется, если они не совпадают).
Другая вещь, которая может быть атакована: authorized_keys
host=
Paramter и Match
блок для Host
, который может быть активирован для неправильного хоста в случае, если используются имена хостов (вместо IP-адресов) и изменяются записи DNS. (UseDNS yes
для этого нужно использовать не-IP)