Как обнаружить скрытый процесс в Linux?

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

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

Что мы можем сделать, чтобы определить местонахождение проблемного ребенка? Что мы можем сделать, чтобы защититься от этого в будущем? Можно ли провести мониторинг, чтобы мы знали об этом в будущем? (Помимо мониторинга сети, над которым мы уже работаем, следим за этим.)

Спасибо заранее, и я могу предоставить более подробную информацию, если это необходимо. Цените свое время.

8 ответов

Решение

Вы не можете доверять любым системным инструментам на вашем компьютере. Руткиты заменят ps, netstat, ls и другие, чтобы скрыть свое присутствие. Вы должны перевести компьютер в автономный режим, вынуть его жесткий диск, сделать криминалистическую копию (например, dd), а затем поработать с ней на обычной машине для поиска руткита.

Если вы настаиваете на работе на работающей машине (что обычно бесполезно), вы можете попробовать загрузить загрузочный дистрибутив на CD (очень важно, чтобы копия была только для чтения) и использовать его копии ps, lsmod и т. Д.

Даже это может не сработать, поскольку руткит может установить модули ядра, чтобы скрыть записи в / proc, где обычно работают такие инструменты, как ps.

Удачи!

Проблема с хорошо сконструированным руткитом состоит в том, что они изменяют команду вашей системы; как ps и top, чтобы не показывать процессы руткита, и ls, чтобы не показывать файлы руткита.

Итак, что вам нужно сделать, это получить эти команды, возможно, из источника или в виде бинарий. (Обязательно будьте хорошо подписаны). Но хитрость корневого набора (я видел это) заключается в том, что они могут испортить и ваш компилятор. Поэтому, когда компилятор знает, что он компилирует ls или ps или любую команду, он также заражает их.

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

Вы скажете, что это большое и трудное для обнаружения, да, но редкий набор рулеток настолько пуленепробиваемый, что я только что дал вам худший случай.

Серьезно, если вы уверены, что на вашем сервере есть корневой набор, переустановите его!

Лучший способ узнать, был ли ваш сервер "рутован", - это запустить систему обнаружения вторжений (HIDS). К сожалению, если вы не используете HIDS сейчас, то слишком поздно устанавливать его. Подходящее время для установки HIDS - это когда сервер впервые установлен, и до того, как он подключен к сети.

Вкратце, большинство HIDS работают путем вычисления криптографических хэшей всех системных двоичных файлов и сохранения этих хэшей (вместе с многочисленными другими статистическими данными) в базе данных, называемой базовой базой данных. Затем периодически HIDS повторно сканирует вашу систему, сравнивая все файлы в ее базовой базе данных с фактическими системными файлами.

Да, конечно, руткит может изменить вашу базовую базу данных, поэтому вам нужно взять копию этой базы данных и сохранить ее отдельно от сервера, прежде чем перевести сервер в оперативный режим. Затем, если вы подозреваете, что у вас есть "root" (и вы подозреваете, что ваша базовая база данных также была подделана), вы можете загрузить систему с установочного носителя, восстановить заведомо исправную базу данных из резервной копии, а затем запустить сканирование на заведомо исправный. Однако гораздо более вероятно, что руткит не будет ожидать победы над вашим конкретным HIDS, и поэтому вы получите уведомление от HIDS об изменении системных файлов, что указывает на возможное вторжение в систему.

Поскольку вы не использовали HIDS, у вас нет быстрого способа точно определить, были ли у вас права root или какие системные файлы были изменены. Вы можете потратить много времени, сравнивая системные файлы с заведомо исправными файлами, извлеченными с заведомо исправного установочного носителя, но это время, скорее всего, лучше потратить на переустановку системы с этого носителя. Если вы хотите выяснить, как вас укоренили после свершившегося факта, лучше всего сделать снимок вашей системы, прежде чем стереть его и переустановить.

Пожалуйста, обратитесь к предыдущему посту

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

Это действительно важно, что вы читаете это..

Как ответить на ваши вопросы.

Я обычно использую IDS/IPS (систему обнаружения / защиты от вторжений), например, snort... он отлично справляется с нечестной игрой, и я видел, что он делает БОЛЬШУЮ работу в действии...

Я также использую серверы Syslog для хранения сообщений журнала на рабочих серверах, чтобы вы могли отслеживать проблемы и изменения / быть rootkit'd

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

Быть rootkit'd - серьезная проблема, определенно попытайтесь выяснить причину..

Надеюсь, это поможет..:D

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

Если это не рутировано, то netstat -np | grep -v ^unix может дать вам подсказку о том, какие программы генерируют трафик.

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

Есть несколько вещей, которые вы можете сделать, чтобы избежать рутирования:

  • Держите вашу систему исправленной, особенно ядро. Следите за причинами выпуска ядра, чтобы определить векторы атаки.
  • Устанавливайте и используйте только необходимые программы. Сделайте минимальную установку, насколько это возможно.
  • Запустите как можно меньше прав root. Многие программы преобразуются в непривилегированные идентификаторы пользователей после завершения установки, требующей привилегий root.

РЕДАКТИРОВАТЬ: Если вы root, то использование статически связанных программ ps и ls может указывать на разницу между запущенными программами, найденными этими двумя инструментами. Различия в списке также могут возникать, когда недолговечные программы отмирают.

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

Очень часто руткиты заменяют системные двоичные файлы, такие как ps, top, netstat. И это также характерно для трояна SSH. Таким образом, поиск странностей контрольной суммы в этих файлах является основным подходом. Если вы работаете в системе на основе rpm, rpm -V обычно является хорошим инструментом или dpkg-verify в Debian/Ubuntu. Или вы можете проверить контрольные суммы напрямую (но следите за предварительной ссылкой, которая изменяет двоичные файлы на лету по соображениям скорости). Это ненадежно, но многие атаки сценаристов не охватывают эти следы. (Другими словами, если вы что-то найдете, хорошо. Если вы что-то не найдете, это не доказывает, что вы чисты.)

Другие вещи, которые нужно искать: открытые порты с внешнего nmap которые не выглядят открытыми через netstat на машине, и пидс в /proc которые не появляются в ps, И если вам случится включить удаленный системный журнал, поищите логины ssh, у которых нет записей в последнем журнале.

Реальное исправление для системы, которая может быть рутирована, состоит в том, чтобы переустановить ее из безопасных источников. Like the installation CDs. Then restore your data only from backup. Any binaries or scripts in your backup may have been compromised and saved into your backup.

To find the root kit on a running system, one way to do it is to compile a kernel module designed to detect rootkits. Compile it on a different machine that is running the same OS version. Then copy it over and insmod it.

Детектор руткитов будет иметь встроенные в модуль ядра инструменты для вывода таблицы запущенных процессов, проверки таблицы системных вызовов (для поиска перехватов системных вызовов) и других функций. Он может иметь сценарии, которые будут брать выходные данные из модуля и сравнивать их с выходными данными от ps, netstat, ls и т. Д. Или он может сканировать память в пространстве ядра на наличие известных сигнатур руткитов и отчетов.

Хватай себе копию Р.Хунтера и чкрооткит. Они обычно довольно приличны, помогая найти вещи, которых там быть не должно.

Всегда хорошо запускать mod_security на вашем уровне Apache вместе с брандмауэром. Обычно они находят устаревшее веб-приложение или скрипт и расширяют доступ оттуда с помощью сценариев оболочки Perl и других забавных вещей.

ps auxfww обычно замечательно находит процессы, которые не принадлежат.

Также: netstat -anp, чтобы увидеть, что слушает на определенных портах.

Опять же, это хорошо, если вы не были укоренены, просто скомпрометированы.

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