Linux Forensics: как найти следы взлома в логах /var/log

08.04.2026

Алексей Мишаев

Автор

Когда сервер взломан, первое, что приходит в голову администратору: «Как это произошло? Что сделал злоумышленник?». Ответы почти всегда скрыты в текстовых файлах каталога /var/log. Системные журналы — это, по сути, «черный ящик» Linux. Они фиксируют каждое подключение, каждую попытку аутентификации, запуск процессов, сетевые соединения и даже команды, которые вводил пользователь. Но просто наличие логов не гарантирует успешного расследования. Нужно уметь их читать, сопоставлять и видеть картину целиком, а не отдельные строки.

В этой статье мы рассмотрим наиболее информативные логи и команды, которые позволяют обнаружить следы взлома на типовом Linux-сервере. Мы не будем углубляться в экзотические ситуации, а сфокусируемся на том, что работает в 90% случаев: входы в систему, активность оболочки, веб-доступ и автоматизированные задачи. Каждый раздел содержит практические приемы поиска аномалий — от просмотра файлов до использования специализированных утилит.

Содержание

Краткое введение в форензику

Форензика на логах строится на нескольких ключевых принципах. Первый принцип — цепочка событий. Логи не дают мгновенного ответа, они позволяют восстановить хронологию. Одна запись сама по себе может быть безобидной: неудачная попытка входа, запуск демона, запрос к веб-серверу. Но в контексте они образуют сценарий: сканирование портов, подбор пароля, успешный вход, загрузка скрипта, его запуск, установка обратного соединения. Поэтому анализ всегда начинается с поиска временных меток и выстраивания последовательности.

Второй принцип — целостность источника. Логи, находящиеся на скомпрометированной системе, могут быть изменены злоумышленником. Он может стереть записи о своем входе, удалить историю команд, изменить временные метки. Поэтому опытный аналитик смотрит не только на содержимое, но и на признаки подчистки: пропуски в хронологии, несоответствие прав доступа к файлам, наличие процесса, который в логах не отражен. В идеале логи должны выгружаться на внешнюю систему (syslog-сервер) в реальном времени, чтобы их нельзя было ретушировать.

Третий принцип — внимание к уже упомянутому контексту. Одни и те же строки в разных окружениях означают разное. Например, запись sudo: pam_unix(sudo:auth): authentication failure может быть случайной опечаткой сотрудника в офисе, а может быть частью атаки, если она приходит с неожиданного IP в три часа ночи. Анализ требует знания штатного поведения системы: кто обычно заходит, в какое время, какие процессы должны быть запущены.

Четвертый принцип — корреляция. Следы атаки редко лежат в одном файле. Злоумышленник вошел по SSH — это auth.log, он запустил веб-шелл — это access.log веб-сервера, он скачал скрипт — это syslog и bash_history, он установил бэкдор — это проверка запущенных процессов и cron. Умение связывать события из разных источников в единую картину — главный навык форензика.

Наконец, пятый принцип — документирование. Любое расследование должно фиксировать найденные артефакты. Если вы нашли подозрительный файл, запомните его имя, права доступа, время создания. Если обнаружили аномальную запись в логе, скопируйте строку с контекстом. Это не только поможет вам самому не запутаться, но и может стать доказательством для службы безопасности или правоохранительных органов.

Начнем с самого важного: с логов, которые фиксируют, кто и как пытался получить доступ к серверу.

Куда смотреть в первую очередь: auth.log / secure, syslog, dmesg

Логи в Linux распределены по разным файлам, и понимание их назначения — половина успеха. При подозрении на взлом первые три файла, которые должен открыть аналитик, — это журнал аутентификации, общий системный журнал и лог ядра.

Кирилл Левкин

Проджект-менеджер MD Audit (SL Soft FabricaONE.AI, акционер — ГК Softline)

«Разрывы» во времени, отсутствие ожидаемых записей, несоответствие между разными логами. Например, есть следы активности в syslog, но нет записей об аутентификации. Проверяется целостность: сравнение с удалёнными источниками (SIEM, централизованные логи), анализ метаданных файлов (время изменения), а также наличие ротаций логов вне стандартного расписания. Частично восстановить данные можно через резервные копии, журналы других систем (например, сетевые устройства) или артефакты (временные файлы, кеши, дампы памяти).

auth.log (Debian, Ubuntu) / secure (CentOS, RHEL) — главный «свидетель» по делам о несанкционированном доступе. В этом файле операционная система фиксирует все, что связано с аутентификацией: логины по SSH, через консоль, использование sudo, попытки смены пароля, работу PAM. Опытный аналитик не просто просматривает строки, а ищет аномальные паттерны.

Самый яркий признак вредоносной активности — массовые неудачные попытки входа (словарные атаки). Если в логе десятки или сотни строк с Failed password от одного IP-адреса за короткое время — это почти наверняка брутфорс. Важно отличать автоматический перебор от случайных ошибок: в первом случае IP повторяется, а логин меняется.

Семен Рогачев

Руководитель отдела реагирования на инциденты «Бастион»

Многое зависит от того, была ли распределена инфраструктура, которая использовалась атакующим при взломе пароля, пытался ли он подобрать одну учётную запись или несколько, а также от других факторов. В рамках тестирования гипотезы можно начать с фильтрации успешных и неуспешных событий аутентификации, а дальше группировать по IP-адресу источника или учётной записи.

Следующий симптом атаки — успешные входы с необычных IP или в нестандартное время. Если аналитик видит запись Accepted password из страны, где у компании нет сотрудников, или аутентификацию в 3 часа ночи — это повод заподозрить компрометацию.

Попытки зайти под несуществующими пользователями также являются распространенным событием в ходе инцидентов безопасности. Если в логе есть строки Invalid user с такими именами, как admin, test, ftp, mysql, это говорит о сканировании типовых учеток.

Кирилл Левкин

Проджект-менеджер MD Audit (SL Soft FabricaONE.AI, акционер — ГК Softline)

Важно учитывать, что логи могут использовать разные временные зоны и форматы. Первый шаг — нормализация времени (приведение к одному часовому поясу). Далее события сопоставляются из разных источников: аутентификация, системные логи, веб-сервер, сетевые события. Это позволяет выстроить цепочку: проникновение — закрепление — активность. Эффективным подходом считается построение таймлайна на основе корреляции: когда произошёл вход, какие команды выполнялись, какие процессы запускались. Чем больше источников задействовано, тем точнее восстанавливается картина атаки.

Наконец, никакая кибератака не проходит без манипуляций с привилегиями. Строки sudo: session opened могут указывать на то, что злоумышленник повысил свои права. Следует обратить внимание на то, кто и когда совершал такие действия.

При анализе важно смотреть не на отдельные записи, а на их частотность и взаимосвязь. Например, одна неудачная попытка — это нормально, а 500 попыток за минуту — тревожный сигнал.

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

В частности:

Сообщения от cron о выполнении задач, которые не были запланированы администратором.
Строки, содержащие wget, curl или nc — утилиты, часто используемые для скачивания вредоносных скриптов.
Аномальные перезапуски служб, не связанные с обновлениями.

dmesg (или /var/log/kern.log) — буфер сообщений ядра. В повседневной жизни туда заглядывают редко, но при подозрении на руткит или установку вредоносных модулей это must-have. Здесь можно увидеть сообщения о загрузке неизвестных модулей ядра (например, странные имена hide, rootkit), ошибки, связанные с попытками скрыть процессы или изменить системные вызовы, подозрительную сетевую активность на уровне ядра.

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

Семен Рогачев

Руководитель отдела реагирования на инциденты «Бастион»

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

Фёдор Скворцов

Руководитель BI.ZONE DFIR

В *nix-системах восстановление файлов — не такая прямолинейная задача, как в Windows. Несоответствие временных меток файлов записям в них может свидетельствовать о попытках их подмены (в нашей практике бывали случаи, когда атакующие целиком подменяли файл wtmp, чтобы скрыть свои следы). Пропуски записей в файлах типа /var/log/auth.log и подобных — атакующие могут недостаточно «чисто» удалить записи, что будет заметно при ручном анализе.

Бывают случаи, когда атакующие, например, удаляют записи из журналов /var/log/auth.log, но забывают про существование журналов auditd. Поэтому при расследовании нужно использовать любые журналы или источники информации. В целом, случаи подмены/удаления части данных из журналов могут помочь выявить анализ информации из нескольких источников и построить единый таймлайн.

Практический подход состоит в том, чтобы начинать с анализа auth.log и постараться определить, было ли проникновение. Затем переходите к syslog — ищите команды, которые злоумышленник мог выполнить после входа. И наконец, dmesg — для обнаружения глубокого закрепления (руткиты, бэкдоры). На каждом этапе используйте принцип корреляции: связывайте IP из auth.log с временными метками в syslog, чтобы восстановить полную картину действий атакующего.

Поиск аномалий: last, lastb, .bash_history, скрытые процессы

После первичного просмотра логов аутентификации и системных журналов следующим шагом становится изучение артефактов, которые сами команды и пользователи оставляют в системе. Здесь мы выходим за рамки обычных текстовых файлов — понадобятся утилиты для сбора информации из бинарных журналов, а также анализ действий «оболочки» и текущего состояния процессов.

Кирилл Левкин

Проджект-менеджер MD Audit (SL Soft FabricaONE.AI, акционер — ГК Softline)

Брутфорс — это серия неудачных попыток входа с одного или множества IP. Успешный взлом — это одиночный вход после серии ошибок или вход с нетипичного IP/географии. Веб-атаки видны в access-логах как подозрительные запросы (необычные параметры, попытки обращения к служебным файлам). Майнеры и reverse shell — это аномальные процессы, сетевые соединения на внешние адреса и запуск неизвестных бинарников. Часто сопровождаются изменениями в cron или автозагрузке. Главным признаком всегда остаётся отклонение от «нормального» поведения системы.

Утилита last читает файл /var/log/wtmp, где хранится история успешных входов, выходов и перезагрузок системы. Выполнив ее без аргументов, вы получите список сессий с указанием имени пользователя, терминала, IP-адреса и временных меток. Нужно искать входы из неизвестных IP-адресов, особенно если IP принадлежит другой стране или малоизвестному хостинг-провайдеру.

Если вход зафиксирован в 3 часа ночи, а никто из дежурной смены не заявлял о работе, это повод насторожиться. Также необходимо обращать внимание на случаи, когда один и тот же пользователь входит одновременно из разных IP — возможно, его учетная запись скомпрометирована.

Строки с reboot показывают, когда система перезагружалась. Взломщики иногда перезагружают сервер после внедрения руткита.

lastb — аналог last, но она читает файл /var/log/btmp, содержащий неудачные попытки входа. Если вы видите сотни записей от одного IP с разными логинами — это явная атака перебора паролей.

Фёдор Скворцов

Руководитель BI.ZONE DFIR

Для определения случаев эскалации привилегий будет полезен журнал auditd (обычно находится в/var/log/audit/audit.log). Если в системе используется auditd, то в этом журнале могут быть записаны попытки повышения привилегий, а также различные потенциально опасные системные вызовы. Обязательно стоит отсмотреть файлы .bash_history (и подобные), .lesshst, .viminfo в домашних директориях пользователей (особенно тех, что могли быть скомпрометированы) — в них могли остаться команды, исполняемые атакующими, а также информация о файлах, просматриваемых с помощью less или открываемых с помощью vim. При инцидентах с эксплуатацией уязвимостей веб-приложений начинаем с анализа журналов веб-сервера (access.log, error.log и подобных). В значительной части случаев анализ этих журналов покажет дальнейшее направление исследования.

.bash_history покажет, что пользователь делал после входа в систему. Файлы .bash_history и ее аналоги для других «оболочек» хранят команды, выполненные в интерактивном режиме. Каждый пользователь имеет свой файл в своей домашней директории. Анализ истории позволяет воспроизвести действия злоумышленника после того, как он вошел в систему.

На что обращать внимание:

Команды загрузки внешнего кода: wget, curl, scp, rsync с адресами, не принадлежащими вашей инфраструктуре.
Изменение прав доступа и попытки скрыть следы: chmod +x, chattr +i (установка флага неизменяемости), rm -f.
Запуск интерпретаторов и скриптов: python -c, perl -e, bash -i, nc (netcat) для установки обратного соединения.
Редактирование конфигураций: vi /etc/passwd, nano /etc/ssh/sshd_config, добавление новых пользователей (useradd).
Использование screen или tmux. Эти утилиты часто применяются для удержания сессии и маскировки активности.

Повторим важную деталь: опытный злоумышленник может стереть историю команд (history -c, unset HISTFILE) или удалить сам файл. Поэтому отсутствие .bash_history или его необычно малый размер — тоже сигнал. Также полезно проверить, не является ли файл символической ссылкой на /dev/null — это классический прием скрытия команд.

Для поиска скрытых процессов аналитику понадобятся ps, top и lsof. Атакующий может запускать вредоносные программы, маскируя их под легитимные имена или используя техники инъекции в уже запущенные процессы. Задача состоит в том, чтобы обнаружить аномалии в списке запущенных процессов.

Начать нужно с просмотра дерева процессов. Команда с ключом, показывающим иерархию (например, ps auxf), позволяет увидеть, от какого родительского процесса запущены подозрительные дочерние. Особенно подозрительно, когда процессы веб-сервера порождают оболочку или демон, слушающий сеть.

Следующий шаг — проверка открытых сетевых соединений. С помощью lsof -i или ss -tulpn можно выяснить, какие процессы «слушают» нестандартные порты (8888, 4444, 1337) или устанавливают внешние соединения в момент, когда этого не должно происходить.

Третий этап — поиск скрытых процессов. В Linux существуют руткиты, способные скрывать свои процессы от стандартных утилит. Поэтому имеет смысл сравнить вывод ps с информацией из /proc: количество записей в /proc должно примерно соответствовать числу процессов, отображаемых ps. Резкое расхождение — признак вмешательства.

Дополнительные места для проверки:

Каталог /tmp и /dev/shm — типичные места для размещения вредоносных файлов (скриптов, бэкдоров).
Автозагрузка: файлы в /etc/rc*.d, /etc/systemd/system, а также пользовательские cron-задачи.

Помните, что все эти проверки лучше выполнять с использованием статически скомпилированных утилит, загруженных с доверенного носителя, если вы подозреваете, что системные команды могут быть скомпрометированы. Однако даже в этом случае важно сохранять хронологию событий: сначала фиксируем аномалии, затем пытаемся сопоставить их с записями в auth.log, syslog и .bash_history. Только так можно восстановить полную картину инцидента.

Признаки веб-шелла: анализ access.log веб-сервера (Nginx/Apache)

Если сервер выполняет функции веб-хостинга или на нем работают публичные веб-приложения, то после взлома операционной системы злоумышленник часто оставляет следы именно в логах веб-сервера. Веб-шелл — это скрипт, который позволяет выполнять команды операционной системы через HTTP-запросы. Его могут загрузить через уязвимость в приложении, использовав слабые пароли административной панели или уязвимости компонентов. Анализ логов доступа (access.log) помогает обнаружить такие скрипты и понять, как злоумышленник ими пользовался.

В зависимости от используемого веб-сервера, логи находятся в /var/log/nginx/access.log (для Nginx) или /var/log/apache2/access.log (для Apache). В этих файлах каждая строка соответствует одному HTTP-запросу и содержит IP-адрес клиента, временную метку, метод (GET/POST), запрашиваемый URL, код ответа, размер ответа и, что особенно важно, строку User-Agent — идентификатор браузера или инструмента, которым пользовался клиент.

Семен Рогачев

Руководитель отдела реагирования на инциденты «Бастион»

Если речь об эксплуатации уязвимости, нужно понимать, какое прикладное ПО установлено. В среднем, в рамках расследования инцидентов команда куда чаще сталкивается с эксплуатацией 1-day-уязвимостей, поэтому поиск актуальных PоC для данной версии ПО и понимание оставляемых следов активности (например, URL'ов), часто помогает сократить время на исследование.

На что обращать внимание:

Подозрительные URL и параметры. Веб-шеллы обычно имеют имена, не входящие в штатную структуру сайта, например shell.php, cmd.php, admin.php, 1.php. Если в логе за последнее время появились обращения к таким файлам, которых раньше не было, это первый признак. Также часто злоумышленники передают команды через параметры URL: ?cmd=id, ?c=whoami, ?x=ls. Обнаружение таких запросов — почти гарантия наличия веб-шелла.
Методы HTTP, не характерные для приложения. Если ваше приложение обычно использует GET для отображения страниц, а в логе появилось много POST-запросов к нестандартным страницам (например, /wp-admin/admin-ajax.php), это может быть попытка эксплуатации.
Необычные User-Agent. Многие атакующие используют стандартные инструменты, которые оставляют характерные строки: curl, wget, python-requests, sqlmap, nmap и т.д. Даже если сам запрос выглядит безобидно, User-Agent может выдать автоматизированное сканирование или эксплуатацию.
Коды ответов. Если злоумышленник только ищет возможности, он может запрашивать несуществующие страницы, получая в ответ ошибки 404. Массовое появление таких запросов от одного IP — признак прощупывания периметра. Если же веб-шелл был успешно установлен, он будет возвращать ошибку 200.
Аномальный размер ответа. Веб-шеллы часто возвращают результаты выполнения команд, которые могут быть большими. Если на запрос к подозрительному URL приходит ответ большого объема (десятки килобайт вместо нескольких сотен байт), это тоже указание на работу шелла.
Запросы к системным директориям. Попытки обратиться к /etc/passwd, /proc/self/environ, /tmp/ через веб-сервер — классические тесты после внедрения.

Фёдор Скворцов

Руководитель BI.ZONE DFIR

Основным признаком работы майнера является высокая нагрузка на CPU или GPU — тут поможет просмотр запущенных задач и потребляемых ими ресурсов. Характерными особенностями майнеров также являются массовая очистка журналов (чтобы жертва не смогла определить, через что залили майнер) и изменение множества файлов типа cron и подобных мест автозапуска приложений (т. к. майнеры при установке обычно удаляют все остальные, конкурирующие майнеры из системы).

Вместо просмотра миллионных логов вручную, специалисты обычно используют фильтрацию по подозрительным паттернам. Например, можно отсортировать записи по дате и сконцентрироваться на временном промежутке, когда произошла атака (выявленная по auth.log). Затем выгрузить все POST-запросы или запросы к скриптам с расширением .php, не входящим в базовую установку. Хорошо помогает анализ частоты обращений: если к ранее неактивному файлу за короткое время поступило много запросов, скорее всего, это работа злоумышленника, тестирующего возможности шелла.

План действий после обнаружения подозрительных записей таков:

Убедиться, что файл действительно существует на сервере, и изучить его содержимое (без выполнения!).
Определить, как он появился (по дате создания, по записям в логах доступа или в логах ошибок веб-сервера).
Если есть доступ к логам ошибок (error.log), можно найти сообщения о неудачных попытках загрузки или ошибках интерпретации.
Зафиксировать все подозрительные IP-адреса и сопоставить их с записями в auth.log — возможно, злоумышленник использовал тот же IP для входа по SSH.

Анализ access.log не только помогает обнаружить веб-шелл, но и дает понимание, как злоумышленник проник (через какую уязвимость), какие данные были скомпрометированы и какими инструментами он пользовался. Вместе с другими артефактами (история команд, процессы, автозагрузка) это позволяет восстановить полную картину инцидента.

Полезные инструменты: chkrootkit, rkhunter, ручной анализ cron-задач

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

chkrootkit (Check Rootkit) — один из старейших инструментов для обнаружения руткитов. Он проверяет системные бинарные файлы на предмет подмены, ищет характерные для руткитов строки в памяти и файловой системе, анализирует сетевые соединения. В выводе могут появляться сообщения типа INFECTED или not infected.

Необходимо учитывать возможность ложных срабатываний, особенно на нестандартных конфигурациях. Если chkrootkit показывает INFECTED на файле, который точно является легитимным (например, после обновления версии ядра), это еще не значит, что система скомпрометирована. Но таких сигнатур обнаруживается несколько и они совпадают с другими признаками атаки (наличие подозрительных процессов, аномалии в логах), нужно обратить внимание.

chkrootkit не детектирует новые, неизвестные руткиты и не анализирует бизнес-логику приложений. Это инструмент первичной диагностики, а не финальный вердикт.

rkhunter (Rootkit Hunter) работает по другому принципу. Он создает базу «эталонных» системных файлов (сверяя их хеши) и проверяет, не были ли они изменены. Также он сканирует на наличие скрытых процессов, странных сетевых портов, подозрительных записей в автозагрузке и cron-задачах.

После проверки rkhunter выдает отчет с предупреждениями. Некоторые из них могут быть ложными (например, если вы специально меняли настройки SSH), но каждое предупреждение требует анализа. Особое внимание стоит уделить измененным бинарным файлам (особенно ps, netstat, sshd, ls, find), скрытым процессам (если rkhunter находит процесс, который не виден в ps), подозрительным файлам в /tmp и /dev/shm.

Если руткит подменяет системные утилиты, rkhunter может «видеть» подмененную версию и не обнаружить изменений, если его собственная база была скомпрометирована. Поэтому оба инструмента (chkrootkit и rkhunter) желательно запускать с live-носителя или из доверенной среды.

Фёдор Скворцов

Руководитель BI.ZONE DFIR

Самая популярная утилита для поиска информации — это стандартная юниксовая утилита grep, ее, пожалуй, используем чаще всего. После нее — AWK, тоже классическая утилита. Для того, чтобы найти аномалии или закономерности в журналах действительно большого объема, мы применяем стек ELK (Elasticsearch, Kibana & Logstash).

Автоматические сканеры могут пропустить самое опасное — закрепление злоумышленника через планировщик задач (cron). Если вредоносный скрипт добавлен в cron, он будет перезапускаться даже после перезагрузки и удаления его вручную. Поэтому ручная проверка cron — обязательный этап.

Где искать признаки вредоносной активности:

/etc/crontab — основной системный файл.
/etc/cron.d/ — каталог с дополнительными системными задачами.
/etc/cron.hourly/, /etc/cron.daily/, /etc/cron.weekly/, /etc/cron.monthly/ — скрипты, выполняемые по расписанию.
Пользовательские задачи: crontab -u имя_пользователя -l для каждого пользователя, особенно для root и тех, кто имеет привилегии.

Аналитик должен обратить внимание на задачи, которые скачивают и выполняют скрипты с внешних URL (wget, curl); задачи с именами, маскирующимися под системные (например, ntpdate, logrotate), но содержащие явно вредоносные команды; задачи, которые запускают скрипты из скрытых каталогов (например, /tmp/.hidden/); задачи, созданные недавно (время модификации файлов cron).

При обнаружении подозрительной задачи не нужно сразу ее удалять. Сначала необходимо записать ее содержимое, имя файла и владельца. Это поможет в расследовании: например, если задача добавлена от имени пользователя, учетная запись которого была скомпрометирована, это подтверждает цепочку атаки.

Что делать после обнаружения

С обнаружением руткита или подозрительной cron-задачи расследование только начинается. Даже если chkrootkit показал чистоту, а rkhunter не выдал предупреждений, но вы нашли явные признаки атаки в логах или процессах, доверять инструментам полностью нельзя.

В таких случаях нужно сохранить все логи и копии подозрительных файлов на внешний носитель. Если возможно, сервер необходимо отключить от сети, но не выключать, чтобы не потерять данные в памяти. В идеале рассмотреть привлечение специалистов по расследованию инцидентов — восстановление системы «на глаз» часто оставляет скрытые закладки.

И главное, следует помнить, что автоматические инструменты экономят время, но не заменяют аналитическое мышление. Поэтому инвестиции в специалистов, способных интерпретировать данные и составлять их в целостную картину, — это главная составляющая эффективной форензики.