7

Недавно я заметил, что SSHd в нескольких системах, которыми я управляю, начнет порождать неостанавливаемые процессы, которые будут потреблять огромное количество процессоров.

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

Я перепробовал все, чтобы убить эти процессы ... единственный надежный метод, который я нашел на сегодняшний день, это перезапустить весь сервер (что не идеально). Я пытался отключить openssh-сервер для dropbear, но он не ведет себя так, как мне нужно для моих приложений.

Я пробовал:

killall -9 sshd

убить каждого sshd по его идентификатору. Несколько других вещей (htop + sigterm и т.д.)

Мне бы понравились некоторые идеи, как убить эти процессы, так и решить, что вызывает это.

1 ответ1

2

Если это на самом деле OpenSSH sshd, я думаю, что сценарий где-то запускает их в разорванном цикле, и один из их дочерних процессов загружает весь этот процессор.

Как предложил Marki555, strace поможет вам, но вы должны использовать strace -f чтобы strace следовал за дочерними процессами. От man strace:

   -f          Trace child processes as they are  created  by  cur-
               rently  traced  processes as a result of the fork(2)
               system call.

Поскольку strace генерирует так много данных, было бы также неплохо использовать аргумент -e (например, чтобы показывать только вызовы open ()):

   -e expr     A qualifying expression which modifies which  events
               to  trace  or  how to trace them.  The format of the
               expression is:
                         [qualifier=][!]value1[,value2]...

Другая команда, которую вы можете попробовать, - это ps xaf или pstree -a чтобы легко понять древовидное представление процессов и их дочерних процессов, чтобы вы могли определить, какой процесс запустил эти sshd. lsof также может помочь вам, он скажет вам, какие файлы открыты у процесса.

И, конечно же, убедитесь, что вы используете последнюю версию OpenSSH. Я думаю, что rsync + большие файлы + ssh на древнем OpenSSH 3.4p1 было бы проблематично.

Если это на самом деле не процессы sshd, то контрольная сумма MD5 двоичного файла может отображаться правильно, но это может быть не фактическая работающая программа sshd. Также сама команда md5sum может быть версией с резервным копированием, которая модифицирована для сообщения правильной контрольной суммы для определенных файлов (например, sshd).

Вы должны взглянуть на /proc /[sshd pid] /exe и убедиться, что это символическая ссылка на /usr /sbin /sshd (или где бы ни находился ваш sshd), а также /proc /[sshd pid] /environment, чтобы увидеть какие переменные окружения он использует, и /proc /[sshd pid] /cmdline, чтобы увидеть, какая команда на самом деле его запустила.

Хотя злоумышленник мог переименовать вредоносную программу в "sshd", затем выполнить ее, чтобы она выглядела как sshd. Можно было даже переместить /usr /sbin /sshd в /tmp /sshd, а затем переместить вредоносный sshd в /usr /sbin /sshd, чтобы попытаться скрыть его от этого типа анализа /proc, но когда /tmp /sshd вернется в /usr /sbin /sshd символьная ссылка /proc /[sshd pid] /exe будет отображаться в ls как:

   lrwxrwxrwx 1 root root 0 May 19 06:47 /proc/[sshd pid]/exe ->  (deleted)/usr/sbin/sshd

Кроме того, если эти sshd делают что-то для активного предотвращения нормального анализа процесса, вы можете попробовать kill -STOP вместо kill -9 чтобы "приостановить" процесс (используйте kill -CONT чтобы возобновить его. См. Http://en.wikipedia.org/wiki/Job_control_%28Unix%29#Implementation).

Однако, если у злоумышленника есть привилегии root, можно установить руткит, скрывающийся от /proc, netstat, ls и т.д. Если вы действительно взломаны, лучше всего перевести систему в автономный режим и смонтировать ее разделы на другом ( Чистая) система затем выполняет экспертизу (или использует один из этих живых компакт-дисков Linux, созданный для экспертизы).

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .