Подозрительные записи в журнале SSH ("Принят не для анонимных")
Я получил эту цепочку записей журнала (и аналогично неоднократно) на моем сервере:
Nov 24 07:38:59 server sshd[28676]: SSH: Server;Ltype: Version;Remote: 54.38.81.12-40482;Protocol: 2.0;Client: OpenSSH_7.2p2 Ubuntu-4ubuntu2.4
Nov 24 07:38:59 server sshd[28676]: SSH: Server;Ltype: Kex;Remote: 54.38.81.12-40482;Enc: aes128-cbc;MAC: umac-64-etm@openssh.com;Comp: none [preauth]
Nov 24 07:39:00 server sshd[28676]: SSH: Server;Ltype: Authname;Remote: 54.38.81.12-40482;Name: anonymous [preauth]
Nov 24 07:39:00 server sshd[28676]: Accepted none for anonymous from 54.38.81.12 port 40482 ssh2
Nov 24 07:39:01 server sshd[28681]: refused local port forward: originator 127.0.0.1 port 46338, target 167.114.159.146 port 80
Nov 24 07:39:01 server sshd[28681]: refused local port forward: originator 127.0.0.1 port 47552, target 167.114.159.146 port 80
...
Nov 24 07:39:19 server sshd[28681]: Disconnected from 54.38.81.12
Я почти уверен, что это была хакерская атака, но как определить, была ли она успешной? Особенно неясным является сообщение "Принято не для анонимного". Означает ли это, что у меня есть учетная запись пользователя с именем anonymous, которой разрешено входить без пароля, и хакер вошел в систему как анонимный и попытался переадресовать некоторые локальные порты (и могут быть некоторые, которые были успешно переадресованы, чтобы они не войти)?
Пытался войти как анонимный стандартным способом из локальной сети (ssh anonymous@server
) но получил сообщение об отказе в разрешении.
Если меня не взломали, как я могу защитить себя от такого рода атак? Уже установлен fail2ban из-за других подозрительных записей в журнале, но это произошло после установки.
Изменить 1:
Проверил /etc/ssh/sshd_config
файл и обнаружил, что PermitEmptyPasswords
был установлен на no
, Так что все должно быть в порядке.
Изменить 2:
Я не опытный с /proc
файловая система, но это то, что я обнаружил:
user@server:~$ sudo file /proc/5931/exe
/proc/5931/exe: broken symbolic link to /usr/bin/sshd
user@server:~$ sudo which sshd
/usr/sbin/sshd
Хорошо, file
утилита говорит, что это неработающая символическая ссылка, но если я попытаюсь sudo hexdump /proc/5931/exe
Я получаю данные. Это нормально?
Изменить 3:
Теперь я знаю, в чем причина редактирования 2. Я смешиваю две системы. Я запускаю привязанный Debian Stretch на NAS-устройстве Synology. И есть процессы из этого Debian и Synology DSM в файловой системе /proc. Каждая из систем имеет другое расположение исполняемого файла sshd.
Изменить 4:
Это то, что less /proc/*/cmdline
показывает:
/usr/bin/sshd^@
sshd: user [priv]
sshd: user@pts/4^@
/usr/sbin/sshd^@
sshd: user [priv]
sshd: user@pts/3^@
Изменить 5:
Я знаю, что то, что показано здесь, не является подозрительным логином. (Заменить user
с моим именем пользователя (полностью анонимизировал этот вывод). Проблема в том, что мне нужно было бы отследить процесс, когда анонимный пользователь вошел в систему. Он внезапно отключается, поэтому я не могу наблюдать за процессом в реальном времени. Как подделать ловушку, чтобы я мог реагировать на вход анонимного пользователя?
Понял, что анонимный пользователь присутствует только в системе Synology DSM. Возможно ли, что журналы из системы DSM также записываются в загруженный Debian? Попытался отключить службы FTP и SFTP, поскольку этот пользователь принадлежит группе ftp, но пользователь остается там. Там нет ни passwd
ни usermod
команда в системе DSM, поэтому я не уверен, как отключить доступ для этого пользователя. аноним имеет свою оболочку в /sbin/nologin
поэтому не должно быть возможности войти в систему через SSH и попробовать переадресацию портов.
Изменить 6:
Изучил конфигурацию SSH в системе Synology DSM. Ну, были некоторые настройки, которые я изменил:
#PermitEmptyPasswords no
-> без комментариев
# allow the use of the none cipher
#NoneEnabled no # uncommented
1 ответ
Edit 6, похоже, решил проблему (по крайней мере, такие журналы атак исчезли):
Изучил конфигурацию SSH в системе Synology DSM. Ну, были некоторые настройки, которые я изменил:
#PermitEmptyPasswords no
-> без комментариев# allow the use of the none cipher #NoneEnabled no # uncommented