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. в чем может быть причина этой проблемы?
Фактически, это было от моего хостинг-провайдера - они спамили мой VPS каждые 6 секунд, чтобы показать статус моего сервера на своей веб-консоли. Мой сервер отображается как активный, если ему отвечает мой sshd.
Я только что установил OpenVPN и разрешил SSH только через него - так что, по словам моих провайдеров, мой сервер может похвастаться 100% простоями.
Скорее всего, это keepalive (проверка ответа сервера) от комм. устройство.
Такие сообщения отправляются SSH, когда кто-то пытался получить к нему доступ, но не выполнил шаги. Например, если NMS проверяет, активен ли порт ssh 22, он просто попытается подключиться к порту 22 и, если соединение будет успешным, зависнет, в таких случаях SSH сообщает то же самое.
Так это из-за сканирования портов SSH.
Какой-то злоумышленник (сюрприз!) Забивает ssh, пытаясь найти комбинацию имени пользователя и пароля, которая вводит их в систему. Вероятно, от какого-то ботнета, делающего то же самое, неизвестно скольких других ничего не подозревающих жертв.
Установите что-нибудь вроде fail2ban или DenyHosts (некоторые из них должны быть доступны для любого дистрибутива Linux) или настроить локальный брандмауэр, чтобы ограничить попытки подключения SSH. Изменение порта SSH приводит к сбою глупых попыток грубой силы, но также приводит к сбою законного использования.
Попробуйте изменить порт ssh с 22 на другой в sshd_config:
sudo nano /etc/ssh/sshd_config
Если он не останавливает сообщения, проблема также может быть вызвана следующим: Freebpx вызывает ошибки sshd в файле журнала / var / log / secure или см. обсуждение здесь "Не получена строка идентификации" в 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), чтобы соответствующим образом игнорировать законную попытку.
В моем случае это было вызвано проверкой работоспособности моего Elastic Load Balancer (ELB). Я действительно хочу, чтобы балансировщик нагрузки гарантировал sssd работает на моем хосте, поэтому это сообщение ожидалось в моем случае использования. Для моего конкретного случая использования AWS FireLens, Мне удалось отфильтровать эти сообщения с помощью exclude-patterns свойство объекта конфигурации.
Эта проблема была отмечена выше в комментарии, но я пропустил его в первые несколько раз, когда прочитал этот пост, поэтому я хотел опубликовать его как отдельный ответ верхнего уровня.