Аналог PROCMON под UNIX
Снова задачка, связанная с анализом какого-либо приложения, когда нам хочется оперативно посмотреть, как работает программа, какие файлы она читает или порты открывает. На основе таких данных мы найдем кри тичные файлы, возможно какие-то некорректные права в ОС. Это важное подспорье для понимания, как что-то работает. И если с Windows все сво дится к наборчику Sysinternals Tools c его тулзами ProcMon, FileMon, RegMon, с которыми легко можно решить поставленные зада чи, то как обстоят дела с nix’ами, точнее даже с Linux-системами? Как это ни странно — вполне хорошо, и даже лучше, чем под винду. Чаще всего мож но справиться с основными задачами даже без стороннего ПО (и как обыч но для nix’ов — различными путями). Итак, для начала нам поможет команда lsof, которая по умолчанию ото бражает все открытые файлы в ОС и процессы, которые «стоят» за этим. Но так как мы анализируем конкретное ПО, то мы можем ограничить вывод только по нему, а точнее по его PID’у:
lsof -p 111
Тулзень хороша еще и тем, что показывает нам перечень подгруженных
библиотек, а также портов, открытых данным процессом (помним, что в nix-системах каждая сущность является файлом, поэтому мы ее тут тоже видим). Иногда бывает полезно сначала найти, а что же за процесс сидит на конкретном порту:
lsof -i TCP:80
Кроме того, можно «фильтровать» по имени пользователя:
lsof -u user_name
Минус для нас в том, что если файл (с конфигом, например) был открыт, а на момент запуска lsof уже закрыт процессом, то мы его не увидим в списке. Воспользуемся тогда другой тулзой, от которой данные моменты не укроются, — strace (или одним из ее аналогов). Она фактически мониторит системные вызовы для какого-то приложения.
strace -f -e trace=open -p116 -o ~/log
Здесь
• -f указывает, что необходимо трейсить и child’ы (порожденные процессы);
• -e trace=open — что нас интересует только открытие файлов;
• -p116 — PID процесса, к которому приаттачится strace;
• -o ~/log — куда сохранять логи (иначе — на стандартный вывод).
Если хотим оттрейсить с самого запуска, то вместо -p команду с аргументами указываем в конце после параметров.
О’кей, с этой частью разобрались. Если есть процесс, то понять, куда и когда он ползает, мы сможем. А как насчет другой части задачки, когда у нас есть некий файл и надо узнать, кто и когда им пользуется? Strac здесь уже не помощник, так как он не может мониторить системные вызовы от всех процессов.
Рассмотрим пару.
Первый — демон Linux auditd. Похож на strace, также позволяет просматривать системные вызовы, но на уровне всей ОС. Правда, в работе «по-толще» и требует установки (хотя sudo apt-get install auditd и 600 Кб места...). Для работы с auditd нам потребуется две команды. Сначала устанавливаем аудит события, используя auditctl:
sudo auditctl -w /etc/passwd -k passwd_mon -p rw
• -w /etc/passwd — путь до файла, который мониторим;
• -k passwd_mon — ключ, по которому можно будет найти события, относящиеся к данному правилу;
• -p rw — контролировать доступ на чтение и запись.
Далее можно посмотреть события с помощью команды ausearch:
sudo ausearch -k passwd_mon
• -k passwd_mon — как раз ключ, который мы указали ранее.
Две дополнительные команды. Удаление правила (аналогично созданию, только с заглавной W):
sudo auditctl -W /etc/passwd -k passwd_mon -p rw
Список правил:
auditctl -l
Система аудита событий достаточно мощная. Логи содержат много информации. Так что можно читать мануалы и радоваться жизни. С ней главное - не погрязнуть в обилии полученных данных. Если же тебе нравится больше GUI и минимум изменений в ОС, то можно взглянуть на тулзу glsof. Она написана на Java, систематически запускает lsof, парсит его вывод и оставляет только интересующую нас информацию. Кирпично, но работает. С первой задачкой также справится (считай это GUI для lsof). Минус может быть в том, что если за промежуток между запусками lsof процесс успеет обратиться к файлу и закончить с ним работу, то мы этого в логе не увидим.
Еще момент. Одним из первых решений было использование подсистемы inotify, которая дает возможность гибко мониторить доступ к файлам и папкам на уровне файловой системы. Для доступа к ней использовал iWatch. Все заработало быстро и четко, кроме одного важного момента — через inotify нет возможности узнать, какой процесс производит изменения.
Спасибо за внимание и успешных познаний нового!
Автор: xvzL Просмотров: 2518