Нашёл в системе (Ubuntu Server) подозрительный процесс, который сам не запускал. Какие действия предпринять?

От нечего делать на VPS запустил top и увидел со скорбью странный процесс:

24051 webtin    20   0  9084 6680 1364 S    19  4.5 173:22.97 perl



Странен он тем, что perl для меня — абсолютно незнакомая штуковина и сам бы я никакой перловый скрипт, скорее всего, никогда бы не запустил. А он, получается, работает уже несколько суток и в определенные моменты отжирает вон по 19% процессора.


У меня webtin — это системный юзер (которому разрешен bash-шелл, но запрещен ssh-логин). Под этим юзером (через apache-mpm-itk) работает пара сайтов на Wordpress, и примерно месяц назад я уже вычищал с них заразу в виде файлов типа w36122986n.php и w25363287n.php с eval`ами внутри. Wordpress я тогда обновил, но, возможно, не всё плохое вычистил.


В администрировании я, к сожалению, нуб, поэтому буду очень признателен за конкретные рекомендации по анализу и исправлению ситуации.
  • Вопрос задан
  • 6456 просмотров
Пригласить эксперта
Ответы на вопрос 7
darkdimius
@darkdimius
Кстати: есть мааленький шанс что человек перед скармливаем скрипта перлу сохранил его на диск.
Тогда даже если он его удалил после начала выполнения то в /proc все еще будет лежать его дескриптор по которому можно будет увидеть оригинальный файл
Ответ написан
Комментировать
@alz
Может это хостер образы с этим скриптом разворачивает?
Ответ написан
darkdimius
@darkdimius
как уже подсказали поможет strace узнать какие системные вызовы делает, lsof — какие файлы и сокеты открыл.
cat /proc/24051/status | grep PPid
подскажет кто этот процесс создал.
Ответ написан
mastini
@mastini
strace в помощь
Ответ написан
Комментировать
charon
@charon
нужно исследовать дальше, но скорее всего — это зловред. Судя по подключенным либам — он работает с сетью. Тут есть варианты: соединение с командным центром, рассылка спама, брутфорс каких-то удалённых сервисов. Я встречался с похожим, когда работал админом в суппорте хостинга.
Искать исходники сложно, потому что чаще всего в таком случае программа скачивается, запускается и файл сразу прибивается, остаётся только процесс в памяти.
Просто прибейте этот процесс и наблюдайте за ВПС дальше — появятся ли такие процессы еще. Если появятся — у вас есть незакрытая удалённая уязвимость.
Ответ написан
Комментировать
@oleksandr_veles
Был подобный зловред, исходник не нашел -закрывает при запуске и удаляет.
По памяти, кажись, завязаный или на уязвимость в старом sshd или на подмену sshd.
Но могу путать.
Ответ написан
Комментировать
schastny
@schastny
Небольшая предыстория. Однажды зайдя на виртуалку, находящуюся в моей юрисдикции я заметил, что ssh странно подтормаживает, после чего обнаружил в топе кучу питоновских скриптов. Разбор полетов показал, что они брутали какого-то австралийского SIP-провайдера и судя по всему были залиты через уязвимость в веб-приложении, которое самописное кто-то там когда-то написал. Приложение было не critical, поэтому виртуалка была сразу стопнута, скопирована для дальнейшего аудита, а для приложения была развернута новая из шаблона, ну и естественно было делегировано программистам в т.ч. разобраться с дырявым кодом. Вообще хорошая практика такая, что скомпрометированную машину не лечат, а целиком переустанавливают, сняв перед этим копию для аудита, а иногда даже и просто выводят в оффлайн и там ее ковыряют насрав уже на downtime.

Совет практический такой. Посмотреть что происходит с сетью. Посмотреть нет ли чего странного по netstat (открытые порты и сокеты), можно даже послушать трафик tcpdump. Можно действительно потрейсить перл и посмотреть откуда ноги растут.

А вообще рестарнуть нафиг апач, если процесс не исчезнет (а скорее всего так и будет, не помню, чтобы апач юзал перл), убить его к черту по pid и kill -9. Дальше сидеть и смотреть не появиться-ли он вновь. Просмотреть руками все возможные логи и пользовательские директории, вообще полазить по файловой системе по всей. Затем поставить rkhunter и еще одна утилита есть забыл название. Просканировать есть на предмет странной активности. Но все же лучше всего переставить систему.

А вообще надо апдейты вовремя ставить и следить за security issues хотя бы поверхностно, относительно дистра и используемых пакетов, cms всяких и прочего.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы