Боль, удаляющая perl руткит

Итак, мы размещаем веб-сервер геосервиса в офисе.

Кто-то, по-видимому, взломал этот ящик (возможно, через ftp или ssh), и поместил какую-то руткит с IRC-управлением.

Сейчас я пытаюсь все исправить, я нашел pid процесса, который пытается соединиться через irc, но я не могу понять, кто является вызывающим процессом (уже посмотрел с помощью ps, pstree, lsof). Этот процесс является perl Скрипт принадлежит пользователю www, но ps aux |grep отображает поддельный путь к файлу в последнем столбце.

Есть ли другой способ отследить этот пид и поймать призывателя?

Забыл упомянуть: ядро ​​2.6.23, которое можно использовать, чтобы стать пользователем root, но я не могу слишком трогать эту машину, поэтому я не могу обновить ядро

РЕДАКТИРОВАТЬ: lsof может помочь:

lsof -p 9481
КОМАНДА PID ПОЛЬЗОВАТЕЛЬ FD ТИП РАЗМЕР УСТРОЙСТВА ИМЯ УЗЛА
Perl 9481 WWW CWD DIR 8,2 608 2 / сс
perl 9481 www rtd DIR 8,2 608 2 / ss
perl 9481 www txt REG 8,2 1168928 38385 /usr/bin/perl5.8.8ss
perl 9481 www mem REG 8,2 135348 23286 /lib64/ld-2.5.soss
perl 9481 www mem REG 8,2 103711 23295 /lib64/libnsl-2.5.soss
Perl 9481 www mem REG 8,2 19112 23292 /lib64/libdl-2.5.soss
perl 9481 www mem REG 8,2 586243 23293 /lib64/libm-2.5.soss
Perl 9481 www mem REG 8,2 27041 23291 /lib64/libcrypt-2.5.soss
perl 9481 www mem REG 8,2 14262 23307 /lib64/libutil-2.5.soss
perl 9481 www mem REG 8,2 128642 23303 /lib64/libpthread-2.5.soss
perl 9481 www mem REG 8,2 1602809 23289 /lib64/libc-2.5.soss
perl 9481 www mem REG 8,2 19256 38662 /usr/lib64/perl5/5.8.8/x86_64-linux-threa d-multi / auto / IO / IO.soss
perl 9481 www mem REG 8,2 21328 38877 /usr/lib64/perl5/5.8.8/x86_64-linux-threa d-multi / auto / Socket / Socket.soss
Perl 9481 www mem REG 8,2 52512 23298 /lib64/libnss_files-2.5.soss
perl 9481 www 0r FIFO 0,5 1068892 pipess
perl 9481 www 1w FIFO 0,5 1071920 pipess
perl 9481 www 2w FIFO 0,5 1068894 pipess
perl 9481 www 3u IPv4 130646198 TCP 192.168.90.7:60321->www.****.net:ircd (SYN_SENT)

Источник

5 ответов

Решение

Если я могу дать вам какой-нибудь совет, это значит прекратить тратить ваше время на уборку. Создайте образ ОС для криминалистики на потом и просто переустановите сервер.

Извините, но это единственный безопасный способ избавиться от руткитов.

Позже вы можете проверить изображение, по определенным причинам, почему это произошло.

Исходя из моего личного опыта, я сделал это, а позже нашел внутреннего пользователя, у которого был ключ SSH, содержащий недостаток openssl в 2008 году.

Я надеюсь, это проясняет ситуацию.

Замечания:
Если вы собираетесь создать образ / сделать резервную копию сервера перед переустановкой, будьте очень осторожны, как вы это делаете. Как сказал @dfranke, загрузитесь с доверенного носителя для резервного копирования.

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

Источник

Командная строка может быть изменена, если процесс изменяет argv[0]. Пытаться ls -l /proc/[pid]/exe

От man 5 proc

этот файл является символической ссылкой, содержащей фактический путь к исполняемой команде. Эта символическая ссылка может быть разыменована как обычно; попытка открыть его откроет исполняемый файл. Вы даже можете набрать /proc/[number]/exe, чтобы запустить другую копию того же исполняемого файла, который запускается процессом [number]. В многопоточном процессе содержимое этой символической ссылки недоступно, если основной поток уже завершен

ps auxwf | less дает вам "представление леса" о процессах, которое может показать вам, какой процесс запустил этот процесс (если руткит не скрывает его, или родительский объект приложения не вышел и не был переопределен для init).

Это будет в основном академическое и, вероятно, просто время, но strings -n 10 /proc/[pid]/mem может быть весело смотреть прокрутку мимо. Вы могли бы также echo 0x7 > /proc/[pid]/coredump_filter и использовать GDB gcore заставить coredump со всем возможным в нем, но затем процесс умирает, что может заблокировать дальнейший анализ.

Но обязательно примите совет Аренстара. Создавайте резервные копии только данных, восстанавливайте все исполняемые файлы из резервных копий и начинайте заново. Вероятно, вам следует также восстановить сайт из резервных копий, поскольку в каждый html или php файл может быть добавлен вредоносный javascript. Если вы рассматриваете судебный иск, вам нужно просто отложить машину в сторону, отключить ее от сети и прекратить все, что вы делаете, пока судебные эксперты не выполнят свою работу.

Источник

Вы должны переустановить, я согласен. Вы пытались убежать от персонажей на пути? Возможно, один из этих слэшей на самом деле является частью имени файла, а не каталога. По крайней мере, вы должны использовать iptables для блокировки исходящего трафика на этот хост или общий IRC до исправления. Проверьте также netstat.

Источник

Попробуйте "cat /proc/[идентификатор процесса]/cmdline". Хотя, если это настоящий руткит, он может изменить ядро, чтобы лучше спрятаться.

Источник

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

Источник
Другие вопросы по тегам