Вопрос или проблема
Мой журнал fail2ban по адресу /var/log/fail2ban.log полностью заполнен записями, говорящими:
fail2ban.filter : WARNING Определен IP с помощью поиска DNS: [IP адрес]
Я думаю, это могло начаться после того, как я изменил порт ssh…
Есть идеи, в чем причина и как это остановить?
Была та же проблема.
Простое решение: добавьте следующую строку в начало файла /etc/fail2ban/jail.conf, в разделе [DEFAULT]
usedns = no
Чтобы понять, почему ваш журнал заполняется предупреждениями, обратитесь к следующей странице в вики Fail2Ban. Это делается, чтобы предотвратить манипулирование злоумышленниками с PTR записью их атакующих IP для внедрения ложных значений в ваши журналы.
Проверьте PTR запись [IP адрес] и сравните разрешенное имя с оригинальным IP адресом, например
drill -x ip_address или dig -x ip_address или host ip_address
Затем сравните результат с:
drill result или dig result или host result
Они должны совпадать. Если это не так – злоумышленник изменил PTR.
Вы можете изменить директиву usedns на “no” или “warn” в jail.conf.
В моем случае предупреждением было:
WARNING Определен IP с помощью поиска DNS: localhost = ['127.0.0.1', '127.0.0.1', '::1']
Это появлялось каждые 10 секунд. Установка usedns=no не вариант, так как я хотел найти коренную причину – в конце концов, где-то в моих журналах этот “localhost” появился. После проверки нескольких журналов я выбрал “грубую силу”:
find /var/log -type f -name '*.log' | xargs grep localhost -l
что дало мне все журналы, содержащие этот “localhost” (которые всего были два, один из них сам fail2ban.log).
Выяснилось, что это был “mysql/error.log”. Я удалил базу данных без остановки сервиса (ой…) что привело к (каждые 10 секунд):
2021-01-20T05:31:17.784116Z 2680 [Note] Access denied for user 'myserviceaccount'@'localhost' (using password: YES).
В итоге – не нужно останавливать предупреждения (только остановите службу 😉 ).
Убедитесь, что ваш регекс фильтрации не совпадает с вашим собственным хостом, например, в журнале:
your-host.com:443 123.22.33.44 - - [01/Mar/2025:00:00:00 +0000] "GET /your-endpoint HTTP/1.1" 200 78413 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, как Gecko) Chrome/70.0.2020.127 Safari/537.36"
регекс <HOST> в шаблоне ^.*<HOST>.*$ соответствует your-host.com вместо 123.22.33.44, как вы ожидаете.
.
Ответ или решение
Fail2ban — это важный инструмент для управления безопасностью сервера, особенно при организации защиты от различных автоматизированных атак, таких как перебор паролей. Ваша ситуация, связанная с большим количеством записей в логе Fail2ban, конкретно сообщающих о том, что определение IP осуществлялось через DNS Lookup, указывает на некоторые настройки, которые, возможно, требуют корректировки.
Теория
Fail2ban работает, анализируя логи и применяя санкции (например, блокируя IP-адреса) на основании определённых шаблонов или регулярных выражений. Ключевым механизмом Fail2ban является возможность работы как с IP-адресами, так и с доменными именами, которые могут быть разрешены в IP через DNS Lookup. Потенциальные атакующие могут попытаться использовать манипуляции с DNS, например, изменяя PTR-записи, чтобы записывать ложные значения в ваши логи. Такой подход может затруднить отслеживание их реальных IP-адресов.
Одной из причин появления проблем после изменения порта SSH может быть то, что некоторые службы или сценарии продолжают обращаться к старому порту или же фильтры Fail2ban не обновлены с учётом нового порта. При этом Fail2ban может использовать DNS Lookup для каждого подключения, что и вызывает предупреждения в логах, если опция usedns настроена на yes или warn.
Пример
Рассмотрим пример из вашего описания, где в логе содержится запись:
fail2ban.filter : WARNING Determined IP using DNS Lookup: [IP address]Эта запись в логе указывает на то, что Fail2ban выполняет DNS Lookup для некоторых IP-адресов до того, как он сможет принять решение о блокировке или других действиях. Это, в свою очередь, приведёт к увеличенному времени обработки и значительным объемам логов, особенно если DNS запросы выполняются часто или кэширование DNS не настроено должным образом.
Применение
Для предотвращения подобных ситуаций рекомендуется установить параметр usedns в значение no в конфигурационном файле Fail2ban. Это значительным образом уменьшит количество DNS Lookup операций:
-
Откройте файл
/etc/fail2ban/jail.confили его эквивалент (в зависимости от вашей системы конфигураций может быть где-то ещё, например, в отдельной папке/etc/fail2ban/jail.d/). -
В секции
[DEFAULT]добавьте или измените строку:usedns = noЭто отключит использование DNS Lookup для IP-адресов, что предотвратит излишние запросы и записи в логах.
Дополнительно может быть полезно проверить файлы логов на наличие записей, вызывающих эти DNS-поисковые запросы. В некоторых случаях может оказаться, что ваши служебные учётные записи раз в какое-то время делают запросы, которые ошибочно интерпретируются как потенциальные атаки (как в вашем примере с MySQL). В этом случае, исправление конфигурации службы, вызывающей подозрительные действия, может устранить проблему на корню.
Для диагностики использования неверных PTR-записей и сравнения результатов, используйте утилиты командной строки, такие как dig, drill, или host, чтобы убедиться в правильности резолюции DNS:
-
Проверьте текущий PTR:
dig -x <IP-адрес> -
Сравните с обратным разрешением:
dig <полученное-имя>
Неправильные или поддельные PTR-записи могут указать на то, что была предпринята попытка замаскировать реальные IP-адреса.
Заключение
Использование и настройка Fail2ban требует понимания взаимодействия сервисов и потенциальных угроз, особенно в условиях изменяющихся конфигураций, как в случае с изменением порта SSH. Осознание того, как настройки usedns влияют на логирование и работу Fail2ban, позволяет эффективно минимизировать ложные срабатывания и уменьшить нагрузку на систему, что критично для поддержания безопасности и работоспособности вашего сервера.