У нас есть ящик, который, как мы подозреваем, был внедрен на работе. Вопрос в том, как его найти? Я не системный администратор, но меня пригласили в команду, чтобы разрешить ситуацию, и мне любопытно, где можно найти хорошие места для поиска такой проблемы?
Причина, по которой мы подозреваем это, заключается в том, что мы заметили более высокое, чем обычно, использование сети на машине с высоких (что кажется случайным) портов.
Что мы можем сделать, чтобы найти проблемного ребенка? Что мы можем сделать, чтобы от этого защититься в будущем? Есть ли мониторинг, который мы можем запустить, чтобы узнать об этом в будущем? (Помимо сетевого мониторинга, над которым мы уже работаем более пристально.)
Заранее благодарим, при необходимости я могу предоставить более подробную информацию. Цени свое время.
Вы не можете доверять никаким системным инструментам, установленным на вашем компьютере. Руткиты заменят ps, netstat, ls и другие, чтобы скрыть свое присутствие. Вы должны выключить машину, вынуть ее жесткий диск, сделать судебную копию (думаю, dd), а затем работать с этого на второй машине для сканирования руткита.
Если вы настаиваете на работе на живой машине (что обычно бесполезно), вы можете попробовать загрузить аварийный дистрибутив на компакт-диск (очень важно, чтобы копия была доступна только для чтения) и использовать его копии ps, lsmod и т. Д.
Даже это может потерпеть неудачу, поскольку руткит может устанавливать модули ядра, чтобы скрыть записи в / proc, где обычно работают такие инструменты, как ps.
Удачи!
Лучший способ узнать, был ли ваш сервер «рутирован», - это запустить систему обнаружения вторжений (HIDS). К сожалению, если вы сейчас не используете HIDS, то устанавливать его уже поздно. Подходящее время для установки HIDS - это при первой установке сервера и перед он помещен в сеть.
Вкратце, большинство HIDS работают, вычисляя криптографические хэши всех системных двоичных файлов и сохраняя эти хэши (вместе с многочисленной другой статистикой файлов) в базе данных, называемой базовой базой данных. Затем, периодически, HIDS повторно сканирует вашу систему, сравнивая все файлы в своей базовой базе данных с реальными системными файлами.
Да, конечно, руткит может изменить вашу базовую базу данных, поэтому вам нужно взять копию этой базы данных и хранить ее отдельно от сервера. перед вы ставите сервер в оперативный режим. Затем, если вы подозреваете, что у вас «root-права» (и вы подозреваете, что ваша базовая база данных также была изменена), вы можете загрузить свою систему с установочного носителя, восстановить заведомо исправную базу данных из резервной копии, а затем запустить сканирование на заведомо-хороший. Однако гораздо более вероятно, что руткит не будет ожидать, что ему придется победить ваш конкретный HIDS, и поэтому вы получите уведомление от HIDS об изменении системных файлов, что указывает на возможное вторжение в систему.
Поскольку вы не использовали HIDS, у вас нет быстрого способа точно определить, получили ли вы root-права или какие системные файлы были изменены. Вы можете потратить много времени на сравнение ваших системных файлов с заведомо исправными файлами, извлеченными с заведомо исправного установочного носителя, но это время, скорее всего, лучше потратить на переустановку системы с этого носителя. Если вы хотите выяснить, как вы были рутированы постфактум, лучший способ - сделать образ вашей системы, прежде чем стирать его и переустанавливать.
Проблема с хорошо сконструированными руткитами в том, что они изменяют команду вашей системы; например, ps и top, чтобы не отображать процессы руткита, и ls, чтобы не отображать файлы руткита.
Итак, что вам нужно сделать, это получить эту команду, возможно, из исходного кода или в форме двоичных файлов. (Обязательно хорошо подписанный). Но хитрость корневого комплекта (я его видел) в том, что они, возможно, тоже испортили ваш компилятор. Поэтому, когда компилятор знает, что он компилирует ls или ps или любую другую команду, он также заражает их.
Когда я увидел эту проблему, я сказал: «Хорошо, давай перекомпилируем gcc, но нет того, что мне нужно для компиляции gcc ... зараженный gcc .... поэтому, когда он знает, что компилирует сам себя, он заражает его, чтобы он мог заразить команду.
Вы скажете, что это большой и трудный для обнаружения, да, но редко бывают настолько пуленепробиваемые корневые наборы, что я только что привел вам худший случай.
Серьезно, если вы уверены, что на вашем сервере есть рут-комплект, переустановите его!
Пожалуйста, обратитесь к более раннему сообщению
Боль при удалении руткита Perl
Очень важно, чтобы вы это прочитали ..
Как ответить на ваши вопросы ..
Обычно я использую систему IDS / IPS (система обнаружения / защиты от вторжений), например snort ... она отлично справляется с нечестной игрой, и я видел, как она отлично работает ...
Я также использую серверы системного журнала для хранения сообщений журнала с производственных серверов, чтобы вы могли отслеживать проблемы и изменения / руткиты.
Я также часто использую инструменты управления, такие как cacti, которые отображают ЦП, память, диск, использование сети и сообщают, если что-то необычное.
Использование руткитов - серьезная проблема, обязательно попробуйте выяснить причину ..
Надеюсь, это поможет ..: D
Случайные высокие порты - это временные порты, что указывает на то, что у вас, вероятно, есть одна или несколько программ, подключенных к внешней стороне этой системы.
Если он не внедрен, то netstat -np | grep -v ^unix может дать вам подсказку о том, какие программы генерируют трафик.
Вы также можете сканировать трафик из соседней системы, используя tcpdump, чтобы выгрузить пакеты, исходящие из системы, которая, по вашему мнению, имеет root-доступ. Если проблемная программа запущена не от имени root, вы можете сделать это из зараженной системы.
Чтобы избежать укоренения, можно сделать несколько вещей:
РЕДАКТИРОВАТЬ: если у вас есть root-права, то использование статически связанных программ ps и ls может указывать на разницу между запущенными программами, обнаруженными двумя инструментами. Различия в списке также могут возникать из-за отмирания недолговечных программ.
Настоящее исправление для системы, которая может быть рутирована, - это переустановить ее из безопасных источников. Нравится установочные диски. Тогда восстановите свой только данные из резервной копии. Любые двоичные файлы или скрипты в вашей резервной копии могли быть скомпрометированы и сохранены в вашей резервной копии.
Один из способов найти корневой комплект в работающей системе - это скомпилировать модуль ядра, предназначенный для обнаружения руткитов. Скомпилируйте его на другом компьютере с той же версией ОС. Затем скопируйте его и выполните insmod.
В модуль ядра детектора руткитов будут встроены инструменты для создания дампа таблицы запущенных процессов, проверки таблицы системных вызовов (для поиска перехватов системных вызовов) и других функций. У него могут быть сценарии, которые будут принимать выходные данные модуля и сравнивать их с выходными данными ps, netstat, ls и т. Д. Или он может сканировать память в пространстве ядра на предмет известных сигнатур руткитов и создавать отчеты.
Это как мыши: если вы видите одну, там живет сотня. Если вы видите признаки компрометации, вы должны предполагать, что вся система скомпрометирована. Вот почему все предлагают переустановить систему, а не тратить много времени на ее поиски. Я столкнулся с несколькими ситуациями, когда машина была взломана, и системные администраторы думали, что они убрали беспорядок, но позже пожалели об этом.
Очень часто руткиты заменяют системные двоичные файлы, такие как ps, top, netstat. И это также характерно для троянских ssh. Итак, поиск странностей контрольной суммы в этих файлах - главный подход. Если вы используете систему на основе rpm, обычно хорошим инструментом является rpm -V или dpkg-verify в Debian / Ubuntu. Или вы можете проверить контрольные суммы напрямую (но следите за предварительной ссылкой, которая изменяет двоичные файлы на лету из соображений скорости). Это ненадежно, но многие атаки «скрипт-кидди» не скрывают этих следов. (Другими словами, если вы что-то найдете - хорошо. Если вы чего-то не найдете, это не доказывает, что вы чисты.)
Другие вещи, на которые стоит обратить внимание: показанные порты открыты с внешнего nmap которые не выглядят открытыми через netstat на автомате и пидс в /proc которые не появляются в ps. А если у вас включен удаленный системный журнал, поищите логины ssh, для которых нет записей в последнем журнале.
Возьмите себе копию RKhunter и chkrootkit. Обычно они неплохо помогают находить то, чего не должно быть.
Всегда хорошо запускать mod_security на уровне Apache вместе с брандмауэром. Обычно они находят устаревшее веб-приложение или сценарий и расширяют доступ оттуда с помощью сценариев оболочки Perl и других забавных вещей.
ps auxfww обычно отлично подходит для поиска ненужных процессов.
Также: netstat -anp, чтобы узнать, что прослушивает определенные порты.
Опять же, это хорошо, если вас не внедрили, а просто скомпрометировали.