Я запускаю что-то вроде простого сервера (на основе Ubuntu 11.04) на микроэкземпляре Amazon EC2, цель которого просто координировать деятельность нескольких веб-серверов. Машина работала нормально в течение нескольких недель, но теперь часто зависает, а его ЦП был установлен на 100%.
Я вошел в систему через SSH и запустил top, который показал, что landscape-sysinfo злоумышленник использовал все системные ресурсы. А pstree показал, где он был расположен:
init─┬─atd
├─cron
├─dhclient3
├─dovecot─┬─2*[dovecot-auth]
│ ├─3*[imap-login]
│ └─3*[pop3-login]
├─6*[getty]
├─master─┬─pickup
│ └─qmgr
├─mountall
├─mysqld───11*[{mysqld}]
├─rsyslogd───3*[{rsyslogd}]
├─sshd─┬─sshd───sshd───bash
│ ├─sshd───sshd───bash───top
│ ├─sshd───sshd───bash───pstree
│ └─sshd───sh───run-parts───50-landscape-sy───landscape-sys+
├─udevd───2*[udevd]
├─upstart-socket-
├─upstart-udev-br
└─vsftpd
Процесс нарушения указан здесь как последний дочерний элемент sshd. Если я убью вручную landscape-sysinfo, машина возвращается в нормальное состояние - до тех пор, пока процесс самопроизвольно не возрождается, обычно через несколько мгновений. (Я могу поручиться за другого sshd процессы в приведенном выше дереве. Они были законными.)
Я не имею понятия почему landscape-sysinfo появляется случайным образом. Я вдвойне не понимаю, почему это дитя sshd.
Я явно не в восторге от того, что на моей машине работают процессы SSH, которые я не могу учесть. Изначально я опасался взлома / трояна / бэкдора, поэтому я запустил chkrootkit и rkhunter, но они оба пришли чистыми.
Кто-нибудь знает, что может вызвать разгул этого процесса? Есть мысли о том, как остановить его возрождение?
Некоторое время назад я выяснил настоящую причину проблемы и решил, что должен задокументировать ее здесь для других, у которых могут быть похожие проблемы. Основная причина оказалась сложнее и сложнее, чем я ожидал.
Коротко, run-parts все время работал нормально. Его выход из строя был всего лишь симптомом другой проблемы. Цепочка отказов выглядела примерно так:
1) На совершенно другой машине, lsyncd (утилита для синхронизации файлов, основанная на rsync) по причинам, не зависящим от нас. Однако нас беспокоит то, что lsyncd пытался синхронизировать файлы с этим микроэкземпляром (который проявил проблемы) по SSH.
2) Потому что lsyncd делал десятки одновременных подключений через SSH, каждое из которых, казалось, приветствовалось баннером входа в SSH landscape-sysinfo Ubuntu предоставляет по умолчанию. Это объясняет, что landscape-sysinfo есть и почему он является потомком SSH. Оказалось, что run-parts был виноват, но на самом деле проблема заключалась в том, что на машину засыпали соединения SSH.
3) Проблема усугублялась тем, что это микро-экземпляр на EC2, и С тех пор я обнаружил, что Amazon жестко ограничивает микро-экземпляры, потребление ЦП которых постоянно превышает определенный порог. (Подробное объяснение деталей см. Бродяга Грега. Большое спасибо Грегу за эту статью!)
Таким образом, машина работала медленно в течение нескольких секунд, пока ее забрасывали соединениями SSH, а затем стала непригодно медленно после того, как сработало дросселирование.
Тайна раскрыта!
Это регулярное задание cron, которое собирает данные о производительности.
Смотреть Вот для (легких) инструкций по удалению. Чтобы просто удалить его полностью, если вы не заботитесь о сборе данных, либо удалите пакет (если он вам позволяет), либо просто найдите для него запись crontab и закомментируйте ее.