Был ли мой SSH-сервер скомпрометирован? Если да, то как и какие шаги я должен предпринять?

Недавно я разрешил ssh доступ к моей машине для работы над групповым проектом с моими одноклассниками. Я прочитал руководство по настройке ssh в Ubuntu и попытался следовать правилам безопасности. Я отключил аутентификацию по паролю, поэтому единственный способ получить доступ был с ключами RSA, и у меня было только 2 ключа, перечисленных в файле авторизованных ключах: мой (использованный при тестировании, чтобы проверить, работает ли ssh) и друзья.

Этим вечером мне было любопытно посмотреть, был ли мой друг в моей системе ssh'd, когда я им пользовался, поэтому я гуглил команду, которая сообщит мне, был ли кто-нибудь в ssh'd, и если да, то , кто. Результат, который я получил, был:

sudo netstat -tnpa | grep ESTABLISHED.*sshd

Я попробовал это, и результат был:

tcp        0      0 192.168.1.86:22         59.47.0.150:44728       ESTABLISHED 7416/sshd: [accepte

Это выглядело неправильно. Я связался со своим другом, и он заверил меня, что он не вошел в систему. Я попробовал команду еще раз и увидел:

tcp        0      0 192.168.1.86:22         59.47.0.150:44728       ESTABLISHED 7416/sshd: root [pr

В этот момент я был немного взволнован словом «корень» и получил сообщение друг, который знал об этом больше, чем я. Он сказал мне попробовать:

 ps aux | grep ssh

, что вывело:

root      3702  0.0  0.0  61364  2872 ?        Ss   Apr12   0:00 /usr/sbin/sshd -D
root      7473  0.0  0.0 112692  3920 ?        Ss   20:46   0:00 sshd: root [priv]   
sshd      7474  0.0  0.0  62784  1516 ?        S    20:46   0:00 sshd: root [net]    
sid       7476  0.0  0.0  22476   936 pts/1    S+   20:46   0:00 grep --color=auto ssh

Теперь я был полностью взволнован, хотя я хотел немного подождать и посмотреть, смогу ли я узнать О том, кто вошел в систему, я решил просто sudo stop ssh.

После еще одного поиска, я обнаружил, что 59.47.0.150 является IP-адресом в / около Шэньяна, Китай, и, кажется, особенно известен за злонамеренные атаки .

Итак, мои вопросы к вам, ребята:

  1. Можем ли мы с уверенностью сказать, что IP-адрес из Китая каким-то образом SSH проник в мою машину? Хотя он только принял авторизацию ключа RSA?

  2. Можно ли с уверенностью сказать, что он / она также получил root-доступ? В моем ssh-config у меня было значение по умолчанию PermitRootLogin without-password. Первоначально я думал, что это означает, что вход в систему root не разрешен (я знаю, что эти два звука противоречивы, но я нашел их в Google, и это был результат, который я получил).

  3. Есть ли способ узнать, какой урон был нанесен до сих пор?

  4. Как я могу защититься от этого в будущем? Мне все еще нужно запустить ssh, чтобы завершить мой групповой проект.

Спасибо за любую помощь, которую вы можете предложить!

РЕДАКТИРОВАТЬ: Согласно совету saiarcot895 и Стивена, я проверил auth.log, в котором много раз повторялись следующие строки:

    Apr 13 20:43:50 PrometheusU sshd[7392]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=59.47.0.150  user=root
Apr 13 20:43:55 PrometheusU sshd[7394]: reverse mapping checking getaddrinfo for 150.0.47.59.broad.bx.ln.dynamic.163data.com.cn [59.47.0.150] failed - POSSIBLE BREAK-IN ATTEMPT!
Apr 13 20:43:55 PrometheusU sshd[7394]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=59.47.0.150  user=root
Apr 13 20:43:58 PrometheusU sshd[7394]: Failed password for root from 59.47.0.150 port 54813 ssh2
Apr 13 20:44:03 PrometheusU sshd[7394]: message repeated 2 times: [ Failed password for root from 59.47.0.150 port 54813 ssh2]
Apr 13 20:44:04 PrometheusU sshd[7394]: Received disconnect from 59.47.0.150: 11:  [preauth]

Означает ли это, что злоумышленник проник в мою систему и не смог войти в систему с правами root, или что он / она пытается напрямую получить доступ к root, не удалось и вообще ничего не получил?

3
задан 14 April 2015 в 05:15

3 ответа

мы можем сказать с уверенностью что IP от фарфора так или иначе SSH'd в мою машину? Даже при том, что это только приняло ключевую авторизацию RSA?

маловероятно, что они аутентифицировались, если им не удалось получить допустимый ключ. Попытайтесь соединиться от хоста, которым Вы управляете без ключа и проверяете рабочие процессы. Они должны быть подобны тому, что Вы видели. Факт эти [net] процесс работает, поскольку sshd указывает, что они не преуспели в том, чтобы войти в систему.

мы можем сказать с уверенностью, что он получил корень также? В моей ssh-конфигурации у меня было значение по умолчанию PermitRootLogin without-password. Я первоначально думал, что это означало, что корневой вход в систему не был разрешен (я знаю два звуковых противоречащих другому положения, но я погуглил его, и это было результатом, который я получил)

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

Если так, как?

можно проверить подлинный журнал, чтобы видеть если любая аутентификация, за которой следуют. Однако, если они действительно успешно выполнялись, они, возможно, перезаписали доказательство.

там какой-либо путь I, видят, какой ущерб был нанесен до сих пор?

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

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

sshd поддерживает использование tcpwrappers для ограничения доступа. Создайте набор правила, который только предоставляет доступ от диапазонов адресов, из которых Вы ожидаете трафик.

3
ответ дан 14 April 2015 в 05:15

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

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

переходят к/tmp и отправляют его вывод от ls - al, если существует корневой набор, который это могло бы разоблачить там.

можно установить, позволяют пользователям в ssh, и fail2ban полезен также.

Набор/tmp и / домой, поскольку неисполняемый файл в fstab, если это возможно, поможет много.

1
ответ дан 14 April 2015 в 05:15

Если это - только атака перебором, заполняющая журналы, просто измените порт.

Большинство сценариев глупо и существует достаточно серверов, которые слушают порт 22. Я всегда устанавливал мой на, например, 30200 или 225. Это может быть сделано легко в

/etc/ssh/sshd.conf

, Просто изменяют номер порта и перезапускают демона.

к системе затем можно получить доступ с дополнительной опцией к журналам мамы ssh

ssh -p224 user@example.com

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

1
ответ дан 3 August 2019 в 19:24

Другие вопросы по тегам:

Похожие вопросы: