Журнал sshd заполнен «Я не получил идентификационную строку от»

Mar  2 02:34:02 freetalker3 sshd[28436]: Did not receive identification string from 211.110.33.50
Mar  2 02:34:08 freetalker3 sshd[28439]: Did not receive identification string from 211.110.33.50
Mar  2 02:34:13 freetalker3 sshd[28442]: Did not receive identification string from 211.110.33.50
Mar  2 02:34:19 freetalker3 sshd[28445]: Did not receive identification string from 211.110.33.50
Mar  2 02:34:24 freetalker3 sshd[28448]: Did not receive identification string from 211.110.33.50
Mar  2 02:34:30 freetalker3 sshd[28451]: Did not receive identification string from 211.110.33.50
Mar  2 02:34:35 freetalker3 sshd[28454]: Did not receive identification string from 211.110.33.50
Mar  2 02:34:41 freetalker3 sshd[28457]: Did not receive identification string from 211.110.33.50
Mar  2 02:34:46 freetalker3 sshd[28460]: Did not receive identification string from 211.110.33.50
Mar  2 02:34:52 freetalker3 sshd[28463]: Did not receive identification string from 211.110.33.50
Mar  2 02:34:57 freetalker3 sshd[28466]: Did not receive identification string from 211.110.33.50
Mar  2 02:35:03 freetalker3 sshd[28469]: Did not receive identification string from 211.110.33.50
Mar  2 02:35:08 freetalker3 sshd[28472]: Did not receive identification string from 211.110.33.50
Mar  2 02:35:14 freetalker3 sshd[28475]: Did not receive identification string from 211.110.33.50
Mar  2 02:35:20 freetalker3 sshd[28478]: Did not receive identification string from 211.110.33.50
Mar  2 02:35:25 freetalker3 sshd[28481]: Did not receive identification string from 211.110.33.50
Mar  2 02:35:31 freetalker3 sshd[28484]: Did not receive identification string from 211.110.33.50
Mar  2 02:35:36 freetalker3 sshd[28488]: Did not receive identification string from 211.110.33.50

Мой /var/log/auth.log полон этих сообщений, спам каждые 6 секунд. мой сервер на vps и ip кажется что это внутренний ip. что может быть причиной этой проблемы?

Какой-то негодяй (сюрприз!) Стучит по ssh, пытаясь найти комбинацию имени пользователя и пароля, которая вводит их в систему. Вероятно, из какого-то ботнета поступают так же с тем, кто знает, сколько других ничего не подозревающих жертв.

Установите что-то вроде fail2ban или DenyHosts (некоторые из них должны быть доступны для любого дистрибутива Linux) или настройте локальный брандмауэр, чтобы ограничить количество попыток подключения по SSH. Изменение порта SSH приводит к сбою попыток тупой грубой силы, но также приводит к сбою законного использования.

На самом деле, это было от моего хостинг-провайдера - они спамят мой VPS каждые 6 секунд, чтобы показать состояние моего сервера на своей веб-консоли. Мой сервер отображается как активный, если мой sshd отвечает на них.

Я только что установил OpenVPN и разрешил SSH только через это - так, по словам моих провайдеров, мой сервер может работать на 100% простоев.

Скорее всего, это keepalive (проверка того, что сервер отвечает) от комм. устройство.

Такие сообщения генерируются SSH, когда кто-то пытался получить к нему доступ, но не завершил шаги. Например, если NMS проверяет, работает ли порт ssh 22 или нет, он просто попытается подключиться к порту 22, а если соединение установится успешно, он будет зависать, в таких случаях SSH сообщает об этом.

Так что из-за сканирования порта SSH.

Попробуйте изменить порт ssh с 22 на другой в sshd_config:

sudo nano /etc/ssh/sshd_config

Если это не останавливает сообщения, проблема также может быть вызвана следующими причинами : Freebpx вызывает ошибки sshd в файле / var / log / secure log или смотрите обсуждение здесь "Не удалось получить строку идентификации" в auth.log на форумах Ubuntu.

Если вам интересно, кто сканирует порты или пытается выполнить аутентификацию на вашем компьютере, просто проверьте:

# whois 211.110.33.50

# KOREAN(UTF8)

조회하신 IPv4주소는 한국인터넷진흥원으로부터 아래의 관리대행자에게 할당되었으며, 할당 정보는 다음과 같습니다.

[ 네트워크 할당 정보 ]
IPv4주소           : 211.110.0.0 - 211.110.239.255 (/17+/18+/19+/20)

и т.п.

Это также может быть попытка выполнить хорошо известный эксплойт переполнения буфера.

Это задокументировано в фильтре /etc/fail2ban/filter.d/sshd-ddos.conf, который вы можете включить, чтобы защитить себя с помощью следующих попыток взлома:

Fail2Ban ssh filter for at attempted exploit
The regex here also relates to a exploit:
http://www.securityfocus.com/bid/17958/exploit
The example code here shows the pushing of the exploit straight after
reading the server version. This is where the client version string normally
pushed. As such the server will read this unparsible information as
"Did not receive identification string".

Строка назначения для этого эксплойта (угадайте, что?) «Не получила идентификационную строку от ...»

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

Можно настроить фильтр fail2ban (через директиву ignoreregex), чтобы соответствующим образом игнорировать легитимную попытку.