19000 неудачных попыток ввода пароля root в auth.log за 2 дня?

Я отлаживал некоторые проблемы с входом в систему и случайно заметил множество неудачных попыток ввода пароля root в моем /var/log/auth.log. Это VPS Linode.

Я нашел 19К попыток за последние два дня.

Я знаю, что мне нужно переместить sshd на другой порт, но мне кажется, что запомнить и использовать это сложно, и необходимо обновить кучу скриптов. Кроме того, не мог ли злоумышленник просто сканировать порты, чтобы найти новый порт?

У меня установлен очень надежный пароль для root, поэтому меня это не особо беспокоит.

И я предполагаю, что это всего лишь 6 в минуту ... так что, вероятно, не проблема производительности.

Но это не кажется идеальным.

Есть мысли, как это заблокировать или предотвратить?

Кажется, исходит из довольно небольшого списка IP-адресов ... может быть, я мог бы заблокировать их? Я проверил несколько, и похоже, они в Китае.

Другой вариант - отключить вход в систему с правами root и настроить пользователя sudo с уникальным именем пользователя. Но я не думаю, что это поможет с этой конкретной проблемой - люди все еще могут ПОПРОБОВАТЬ использовать ssh как root ...

ОБНОВЛЕНИЕ: после того, как apt-get install fail2ban с настройками по умолчанию, я увидел уменьшение количества неудачных попыток root в auth.log в 6-8 раз:

root@localhost:/var/log# grep "Failed password for root" auth.log | wc
    21301  327094 2261733
root@localhost:/var/log# grep "May  1.*Failed password for root" auth.log | wc
    6217   95973  664165
root@localhost:/var/log# grep "May  2.*Failed password for root" auth.log | wc
    8370  127280  880779
root@localhost:/var/log# grep "May  3.*Failed password for root" auth.log | wc
    1030   16250  111837

Я также устранил аутентификацию по паролю root ssh и переключился на вход на основе ключа только для root, выполнив следующие действия: https://unix.stackexchange.com/questions/99307/permit-root-to-login-via-ssh-only-with-key-based-authentication

Тем не менее, это не мешает ошибочным записям пароля появляться в auth.log. Это просто означает, что даже если они знают пароль, они не могут пройти. Таким образом, fail2ban уменьшает количество этих записей в журнале, а ssh на основе ключей для root обеспечивает фактическую безопасность.

Наконец, как было предложено, я реализовал белый список IP-адресов для порта 22, чтобы полностью исключить записи журнала. Для справки, это можно сделать в Ubuntu с помощью ufw следующим образом:

apt-get install ufw
ufw allow from 127.198.4.3 to any port 22
ufw --force enable

Я использую --force там, потому что я делаю это в скриптах, а не в интерактивном режиме, когда раскручиваю новые узлы.

ОДНАКО, чтобы иметь дело с доступом с моего динамического IP-адреса, без использования веб-консоли Lish Linode каждый раз, когда мой IP-адрес меняется, я использую гибридный подход.

У меня есть главный сервер, на котором размещен мой основной домен, а другие узлы при необходимости раскручиваются в качестве суб-серверов в субдоменах. Главный сервер содержит приватный ключ, который используется для ssh на суб-серверах. Это также IP, который занесен в белый список для ssh.

Но главный сервер не использует ни ключей ssh, ни белого списка IP-адресов. Я хочу иметь к нему доступ из любого места в чрезвычайной ситуации, даже если у меня нет с собой ключевого файла, или даже из места, где я бы не стал доверять установку ключевого файла. Мне нужно что-то вроде доступа по паролю, но безопасно в среде с использованием ключей или ssh-скомпрометированной среде.

Решением этой проблемы, которое я использую в течение многих лет, является аппаратная двухфакторная аутентификация с использованием USB-устройства YubiKey и модуля Yubico PAM, установленного на главном сервере.

Таким образом, даже если у злоумышленника есть пароль root к главному серверу, он не сможет войти без моего YubiKey. И это легко носить с собой. Я могу безопасно получить root-доступ на моем сервере из самого грязного интернет-кафе в мире.

Достигнув главного сервера, я могу подключиться к любому из подчиненных серверов по ssh без пароля.

Так что мне все еще нужен fail2ban на главном сервере, чтобы сократить количество записей auth.log. В конце концов, это не нужно на суб-серверах, потому что белый список IP решает проблему.