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

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

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

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

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

Вы не можете доверять любым системным инструментам на вашем компьютере. Руткиты заменят 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, netstat, ls и т. Д. Или он может сканировать память в пространстве ядра на наличие известных сигнатур руткитов и отчетов.

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

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

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

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

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

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

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

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