Аналог ProcMon под Linux

Опять-таки задачка, связанная с анализом какого-либо приложения, когда нам хочется оперативно посмотреть, как работает программа, какие файлы она читает или порты открывает. На основе таких данных мы найдем критичные файлы, возможно какието некорректные права в ОС. Это важное подспорье для понимания, как что-то работает. И если с 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 команду с аргументами указываем в конце после параметров.
О’кей, с этой частью разобрались. Если есть процесс, то понять, куда и когда он ползает, мы сможем. А как насчет другой части задачки, когда у нас есть некий файл и надо узнать, кто и когда им пользуется? Strace здесь уже не помощник, так как он не может мониторить системные вызовы от всех процессов.

Рассмотрим пару.
Первый — демон 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 (goo.gl/2XUGEw). Она написана на Java, систематически запускает lsof, парсит его вывод и оставляет только интересующую нас информацию. Кирпично, но работает. С первой задачкой также справится (считай это GUI для lsof). Минус может быть в том, что если за промежуток между запусками lsof процесс успеет обратиться к файлу и закончить с ним работу, то мы этого в логе не увидим.

Еще момент. Одним из первых решений было использование подсистемы inotify, которая дает возможность гибко мониторить доступ к файлам и папкам на уровне файловой системы. Для доступа к ней использовал iWatch (goo.gl/adaJ78). Все заработало быстро и четко, кроме одного важного момента — через inotify нет возможности узнать, какой процесс производит изменения.