LINUX.ORG.RU

Кто-то подменяет /usr/sbin/sshd


0

2

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

Поймал момент подмены файла:

7944. 11/27/2013 18:24:33 (null) inode=171308 dev=fc:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 87 yes /usr/bin/install -1 26491
7945. 11/27/2013 18:24:34 /usr/sbin/ 2 yes /usr/bin/install -1 26493
7946. 11/27/2013 18:24:34 (null) inode=172852 dev=fc:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 190 no /usr/bin/install -1 26494
7947. 11/27/2013 18:24:34 (null) inode=172852 dev=fc:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 91 yes /usr/bin/install -1 26495
7948. 11/27/2013 18:24:34 (null) inode=172852 dev=fc:01 mode=0100600 ouid=0 ogid=0 rdev=00:00 82 yes /usr/bin/strip -1 26497
7949. 11/27/2013 18:24:34 /usr/sbin/sshd 90 yes /usr/bin/strip -1 26498
7950. 11/27/2013 18:24:34 /usr/sbin/sshd 92 yes /usr/bin/strip -1 26499
7951. 11/27/2013 18:24:34 /usr/sbin/sshd 90 yes /usr/bin/strip -1 26500
7952. 11/27/2013 18:24:34 /usr/sbin/sshd 90 yes /usr/bin/install -1 26501

Выхлоп auth.log:

Nov 27 18:21:08 i-1930-8513-VM sshd[27690]: debug1: server_input_channel_req: channel 0 request winadj@putty.projects.tartarus.org reply 1
Nov 27 18:21:08 i-1930-8513-VM sshd[27690]: debug1: session_by_channel: session 0 channel 0
Nov 27 18:21:08 i-1930-8513-VM sshd[27690]: debug1: session_input_channel_req: session 0 req winadj@putty.projects.tartarus.org
Nov 27 18:21:08 i-1930-8513-VM sshd[27690]: debug1: server_input_channel_req: channel 0 request winadj@putty.projects.tartarus.org reply 1
Nov 27 18:21:08 i-1930-8513-VM sshd[27690]: debug1: session_by_channel: session 0 channel 0
Nov 27 18:21:08 i-1930-8513-VM sshd[27690]: debug1: session_input_channel_req: session 0 req winadj@putty.projects.tartarus.org
Nov 27 18:21:08 i-1930-8513-VM sshd[27690]: debug1: server_input_channel_req: channel 0 request winadj@putty.projects.tartarus.org reply 1
Nov 27 18:21:08 i-1930-8513-VM sshd[27690]: debug1: session_by_channel: session 0 channel 0
Nov 27 18:21:08 i-1930-8513-VM sshd[27690]: debug1: session_input_channel_req: session 0 req winadj@putty.projects.tartarus.org
Nov 27 18:21:09 i-1930-8513-VM sshd[27690]: debug1: server_input_channel_req: channel 0 request window-change reply 0
Nov 27 18:21:09 i-1930-8513-VM sshd[27690]: debug1: session_by_channel: session 0 channel 0
Nov 27 18:21:09 i-1930-8513-VM sshd[27690]: debug1: session_input_channel_req: session 0 req window-change
Nov 27 18:22:52 i-1930-8513-VM sshd[27690]: debug1: server_input_channel_req: channel 0 request winadj@putty.projects.tartarus.org reply 1
Nov 27 18:22:52 i-1930-8513-VM sshd[27690]: debug1: session_by_channel: session 0 channel 0
Nov 27 18:22:52 i-1930-8513-VM sshd[27690]: debug1: session_input_channel_req: session 0 req winadj@putty.projects.tartarus.org
Nov 27 18:23:32 i-1930-8513-VM sshd[27690]: debug1: server_input_channel_req: channel 0 request winadj@putty.projects.tartarus.org reply 1
Nov 27 18:23:32 i-1930-8513-VM sshd[27690]: debug1: session_by_channel: session 0 channel 0
Nov 27 18:23:32 i-1930-8513-VM sshd[27690]: debug1: session_input_channel_req: session 0 req winadj@putty.projects.tartarus.org
Nov 27 18:23:52 i-1930-8513-VM sshd[27690]: debug1: server_input_channel_req: channel 0 request winadj@putty.projects.tartarus.org reply 1
Nov 27 18:23:52 i-1930-8513-VM sshd[27690]: debug1: session_by_channel: session 0 channel 0
Nov 27 18:23:52 i-1930-8513-VM sshd[27690]: debug1: session_input_channel_req: session 0 req winadj@putty.projects.tartarus.org
Nov 27 18:23:52 i-1930-8513-VM sshd[27690]: debug1: server_input_channel_req: channel 0 request winadj@putty.projects.tartarus.org reply 1
Nov 27 18:23:52 i-1930-8513-VM sshd[27690]: debug1: session_by_channel: session 0 channel 0
Nov 27 18:23:52 i-1930-8513-VM sshd[27690]: debug1: session_input_channel_req: session 0 req winadj@putty.projects.tartarus.org
Nov 27 18:23:57 i-1930-8513-VM sshd[27690]: debug1: server_input_channel_req: channel 0 request winadj@putty.projects.tartarus.org reply 1
Nov 27 18:23:57 i-1930-8513-VM sshd[27690]: debug1: session_by_channel: session 0 channel 0
Nov 27 18:23:57 i-1930-8513-VM sshd[27690]: debug1: session_input_channel_req: session 0 req winadj@putty.projects.tartarus.org
Nov 27 18:24:06 i-1930-8513-VM sshd[27690]: debug1: server_input_channel_req: channel 0 request winadj@putty.projects.tartarus.org reply 1
Nov 27 18:24:06 i-1930-8513-VM sshd[27690]: debug1: session_by_channel: session 0 channel 0
Nov 27 18:24:06 i-1930-8513-VM sshd[27690]: debug1: session_input_channel_req: session 0 req winadj@putty.projects.tartarus.org
Nov 27 18:24:16 i-1930-8513-VM sshd[27690]: debug1: server_input_channel_req: channel 0 request winadj@putty.projects.tartarus.org reply 1
Nov 27 18:24:16 i-1930-8513-VM sshd[27690]: debug1: session_by_channel: session 0 channel 0
Nov 27 18:24:16 i-1930-8513-VM sshd[27690]: debug1: session_input_channel_req: session 0 req winadj@putty.projects.tartarus.org
Nov 27 18:24:26 i-1930-8513-VM sshd[27690]: debug1: server_input_channel_req: channel 0 request winadj@putty.projects.tartarus.org reply 1
Nov 27 18:24:26 i-1930-8513-VM sshd[27690]: debug1: session_by_channel: session 0 channel 0
Nov 27 18:24:26 i-1930-8513-VM sshd[27690]: debug1: session_input_channel_req: session 0 req winadj@putty.projects.tartarus.org
Nov 27 18:24:35 i-1930-8513-VM sshd[10233]: Received signal 15; terminating.
Nov 27 18:24:35 i-1930-8513-VM sshd[15571]: Set /proc/self/oom_adj from -17 to -17
Nov 27 18:24:35 i-1930-8513-VM sshd[15571]: debug1: Bind to port 22 on 0.0.0.0.
Nov 27 18:24:35 i-1930-8513-VM sshd[15571]: Server listening on 0.0.0.0 port 22.
Nov 27 18:24:35 i-1930-8513-VM sshd[15571]: debug1: Bind to port 22 on ::.
Nov 27 18:24:35 i-1930-8513-VM sshd[15571]: Server listening on :: port 22.

Вот конфиг sshd_config:

# Package generated configuration file
# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

AllowGroups ssh
PermitRootLogin no

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel Debug

# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile	%h/.ssh/authorized_keys
AuthorizedKeysFile	/etc/ssh/sshd_files/%u/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

Коннектится могут пользователи из группы ssh, причём только у троих из них есть sudoers-права. Пароли сложные, меняли их несколько раз. Есть авторизация по ключам. Приватные ключи лежат только на компьютерах, откуда происходит коннект.

root запрещён.

Какими щё средствами можно понять, как происходит атака?

Что ето: уязвимость ssh, скомпроментированы ключи, тупо перебор пароля?

А че в конфиге сначала стоит

AllowGroups ssh
PermitRootLogin no
а потом
# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes
Что за дела? Может рут таки разрешен???

black_13
()
Ответ на: комментарий от black_13

Закомментил строку, перестартанул сервер. Может, моя невнимательность, а может и злоумышленник подменил. Он пару раз менял кое-какие скрипты мониторинга.

Хотя, я попробовал до перезапуска демона залогинится под root - меня сервер не пустил

А всё-таки, как может происходить взлом, если пароли менялись, а у root авторизация по ключам не предусмотрена?

Кстати, версия:

aptitude show openssh-server
Package: openssh-server
State: installed
Automatically installed: no
Version: 1:5.3p1-3ubuntu7

abr_linux
() автор топика
Последнее исправление: abr_linux (всего исправлений: 1)
Ответ на: комментарий от abr_linux

Хотя, я попробовал до перезапуска демона залогинится под root - меня сервер не пустил

А через ключи?

Поймал момент подмены файла:

Откуда этот выхлоп лога?

Если систему скомпрометировали, то нужно полностью переустанавливать её, после через проверять при переносе все скрипты.

ktulhu666 ☆☆☆
()
Ответ на: комментарий от ktulhu666

А через ключи?

У root-а нет разрешённых ключей

Откуда этот выхлоп лога?

auditd

Если систему скомпрометировали, то нужно полностью переустанавливать её, после через проверять при переносе все скрипты.

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

abr_linux
() автор топика
Ответ на: комментарий от abr_linux

Уже один раз переезжали на чистую систему.

А ключи пользователей новые после этого или остались старые?

bk_ ★★
()
Ответ на: комментарий от abr_linux

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

Порт кнокинг и vpn, может, юзать? И SELinux?

ktulhu666 ☆☆☆
()
Ответ на: комментарий от bk_

А ключи пользователей новые после этого или остались старые?

Ключи старые лежат. Но приватные навряд ли скомпроментированы

Порт кнокинг и vpn, может, юзать? И SELinux?

Подумываю fail2ban поставить. Да IP-шники меняются. Насчёт selinux дельное предложение. Буду изучать её

abr_linux
() автор топика
Ответ на: комментарий от abr_linux

навряд ли скомпроментированы

Судя по твоему описанию, я бы не исключал такой вариант. А перегенерировать ключи и разослать клиентам - будет большой проблемой? Ведь тогда одной проблемой меньше.

bk_ ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.