Содержание
1. Что такое цифровая криминалистика Docker2. Основы синтаксиса и базовые команды
3. Артефакты: Что сохраняется после docker rm
- 3.1 Тома и хранилища (Volumes)
- 3.2 Образы и слои (Images & Layers)
- 3.3 Сетевые артефакты
- 3.4 Логи и события хост-системы
- 3.5 Остаточные файлы в /var/lib/docker
4. Продвинутые техники анализа
5. Экосистема инструментов для расследования
6. Практические примеры использования (Use Cases)
7. Безопасность и этика использования
8. Часто задаваемые вопросы (FAQ)
9. Заключение
Что такое цифровая криминалистика Docker
Цифровая криминалистика Docker (Docker Forensics) — это процесс сбора, сохранения и анализа цифровых артефактов, связанных с контейнеризированными приложениями, для расследования инцидентов информационной безопасности.Почему это важно для DFIR (Digital Forensics and Incident Response)
Контейнеры по своей природе эфемерны (временны). Однако миф о том, что `docker rm` уничтожает все следы, опасен. Криминалистика Docker позволяет:- Восстановить удаленные базы данных или конфигурационные файлы из "осиротевших" томов.
- Определить вектор атаки через анализ сетевых правил и логов демона.
- Выявить скрытые майнеры или бэкдоры, оставшиеся в слоях образов.
- Соблюсти цепочку сохранности доказательств (Chain of Custody) в облачных средах.
Исторический контекст
С массовым переходом на микросервисную архитектуру после 2015 года, традиционные методы криминалистики (анализ жесткого диска хоста) стали недостаточными. Инструменты вроде `docker-explorer` от Google и интеграция `sysdig` в DFIR-наборы стали стандартом индустрии для расследования инцидентов в контейнерах.Основы синтаксиса и базовые команды
Основные команды Docker для криминалистики
| Команда | Описание | Пример использования |
|---|---|---|
| `docker inspect` | Глубокий анализ метаданных объекта | `docker inspect <volume_name>` |
| `docker volume ls` | Список всех томов (включая осиротевшие) | `docker volume ls -f dangling=true` |
| `docker history` | Просмотр слоев и команд создания образа | `docker history --no-trunc <image>` |
| `docker logs` | Извлечение stdout/stderr контейнера | `docker logs --tail 100 <container>` |
| `docker system df` | Оценка использования дискового пространства | `docker system df -v` |
Логические операторы и фильтры (CLI)
- `grep` - поиск текста в выводе (например, `grep "password"`)- `awk` - извлечение конкретных колонок (например, `awk '{print $2}'`)
- `-f` или `--filter` - фильтрация вывода Docker (по статусу, имени, метке)
- `--no-trunc` - запрет на обрезание длинных идентификаторов (критично для форензики)
- `|` (pipe) - передача вывода одной команды в другую
Артефакты: Что сохраняется после docker rm
Тома и хранилища (Volumes)
*Самый частый источник утечек. Тома не удаляются вместе с контейнером, если не использован флаг `-v`.*1. `docker volume ls` - получить список всех томов.
2. `docker volume ls -f dangling=true` - найти "осиротевшие" (непривязанные) тома.
3. `docker inspect | grep Mountpoint` - узнать физический путь тома на хосте.
4. `ls -la /var/lib/docker/volumes//_data` - прямой просмотр содержимого тома.
5. `find /var/lib/docker/volumes/ -name "*.env"` - поиск файлов окружения во всех томах.
6. `find /var/lib/docker/volumes/ -name "*.sql"` - поиск дампов баз данных.
7. `grep -r "API_KEY" /var/lib/docker/volumes/` - поиск жестко заданных секретов.
8. `docker run --rm -v :/data alpine ls -la /data` - безопасный просмотр тома через временный контейнер.
9. `stat /var/lib/docker/volumes//_data/config.json` - анализ времени создания/изменения файлов.
10. `tar -czvf volume_backup.tar.gz /var/lib/docker/volumes/` - создание криминалистической копии тома.
Образы и слои (Images & Layers)
*Даже если контейнер удален, его базовый образ часто остается на хосте.*11. `docker images -a` - показать все образы, включая промежуточные (dangling).
12. `docker history --no-trunc ` - просмотр полной истории команд (ищет секреты в `RUN` или `ENV`).
13. `docker inspect | grep -i "env"` - извлечение переменных окружения из образа.
14. `docker save -o image_forensic.tar` - экспорт образа для офлайн-анализа.
15. `tar -tf image_forensic.tar` - просмотр структуры экспортированного образа.
16. `find /var/lib/docker/image/overlay2/imagedb/content/ -type f` - поиск метаданных образов на диске.
17. `grep -r "password" /var/lib/docker/image/` - поиск текстовых совпадений в слоях.
18. `docker image prune -a` - *осторожно!* команда для очистки, использовать только после снятия копии.
19. `cat /var/lib/docker/image/overlay2/repositories.json` - просмотр репозиториев и тегов.
20. `sha256sum /var/lib/docker/image/overlay2/imagedb/content/sha256/*` - хеширование слоев для верификации.
Сетевые артефакты
*Сетевые конфигурации могут указывать на несанкционированный доступ или эксфильтрацию данных.*21. `docker network ls` - список всех сетей.
22. `docker network inspect ` - детали сети, включая подключенные контейнеры и IP.
23. `iptables -t nat -L -n -v` - просмотр правил NAT, созданных Docker (проброс портов).
24. `iptables -t filter -L DOCKER -n -v` - просмотр правил фильтрации трафика контейнеров.
25. `ip link show` - просмотр виртуальных сетевых интерфейсов (veth), которые могли не удалиться.
26. `arp -a` - просмотр ARP-кэша хоста для выявления прошлых сетевых взаимодействий.
27. `cat /var/lib/docker/network/files/local-kv.db` - анализ внутренней базы данных сетей Docker (требуется остановка демона или копирование).
28. `tcpdump -i any port not 22 -w docker_traffic.pcap` - захват трафика (если расследование проводится в реальном времени).
29. `netstat -tulnp | grep docker-proxy` - поиск процессов проксирования портов.
30. `docker network prune` - *осторожно!* очистка неиспользуемых сетей.
Логи и события хост-системы
*Демон Docker и ОС хоста хранят историю действий, даже если сам контейнер исчез.*31. `journalctl -u docker.service --no-pager` - просмотр логов демона Docker.
32. `journalctl -u docker.service | grep "container delete"` - поиск записей об удалении контейнеров.
33. `cat /var/log/syslog | grep dockerd` - альтернативный источник логов демона (Ubuntu/Debian).
34. `cat /var/log/audit/audit.log | grep docker` - анализ событий Auditd, связанных с Docker.
35. `ausearch -m execve -k docker_exec` - поиск конкретных запусков команд внутри контейнеров (если настроен auditd).
36. `cat ~/.docker/config.json` - проверка авторизационных данных (credsStore) пользователя, запускавшего Docker.
37. `history | grep docker` - история команд пользователя хоста (часто содержит пароли в открытом виде).
38. `dmesg -T | grep -i oom` - проверка, не был ли контейнер убит из-за нехватки памяти (признак майнинга или DoS).
39. `systemctl status docker` - проверка текущего состояния и времени последней перезагрузки службы.
40. `grep "ERROR" /var/lib/docker/containers/*/*-json.log` - глобальный поиск ошибок в JSON-логах всех контейнеров.
Остаточные файлы в /var/lib/docker
*При аварийном завершении или багах графических драйверов файлы могут оставаться.*41. `ls -la /var/lib/docker/containers/` - проверка, действительно ли директория контейнера удалена.
42. `find /var/lib/docker/ -type f -mtime -1` - поиск файлов, измененных за последние 24 часа.
43. `ls -la /var/lib/docker/overlay2/` - проверка слоев файловой системы (иногда удаленные файлы остаются здесь).
44. `du -sh /var/lib/docker/*` - оценка размера поддиректорий для аномалий.
45. `file /var/lib/docker/overlay2/*/diff/etc/passwd` - проверка типа файлов в скрытых директориях.
46. `strings /var/lib/docker/overlay2/*/diff/bin/sh | grep "http"` - поиск сетевых артефактов в бинарных файлах.
47. `lsof +L1` - поиск открытых, но удаленных файлов (может указывать на скрытые логи или процессы).
48. `cat /var/lib/docker/engine-id` - уникальный идентификатор демона (важен для корреляции логов).
49. `ls -la /var/run/docker.sock` - проверка прав доступа к сокету (признак эскалации привилегий).
50. `debugfs /dev/sda1` - использование низкоуровневых инструментов для восстановления удаленных файлов из `/var/lib/docker` (только для опытных).
Продвинутые техники анализа
Комбинации команд для глубокого анализа
bash
<h2 id="nayti-vse-toma-soderzhaschie-slovo-secret-i-pokazat-ih-put-na-hoste">Найти все тома, содержащие слово "secret", и показать их путь на хосте</h2>
docker volume ls -q | xargs -I {} sh -c 'echo "Volume: {}"; docker inspect {} | grep Mountpoint; find /var/lib/docker/volumes/{}/_data -name "*secret*"'
bash
<h2 id="izvlech-vse-peremennye-okruzheniya-iz-vseh-obrazov-na-hoste-i-sohranit-v-fayl">Извлечь все переменные окружения из всех образов на хосте и сохранить в файл</h2>
docker images -q | xargs -I {} docker inspect --format='{{.Config.Env}}' {} > all_envs.txt
bash
<h2 id="korrelyatsiya-vremeni-nayti-fayly-v-tomah-izmenennye-v-tot-zhe-den-kogda-byl-udalen-konteyner">Корреляция времени: найти файлы в томах, измененные в тот же день, когда был удален контейнер</h2>
find /var/lib/docker/volumes/ -type f -newermt "2023-10-25" ! -newermt "2023-10-26"
Использование Google Docker Explorer
Инструмент `docker-explorer` позволяет анализировать файловую систему Docker без запущенного демона (offline analysis).bash
<h2 id="ustanovka-i-bazovyy-zapusk">Установка и базовый запуск</h2>
pip install docker-explorer
de -r /var/lib/docker list_containers
de -r /var/lib/docker mount <container_id> /mnt/forensic
Экосистема инструментов для расследования
CLI и системные утилиты
- sysdig - мощный инструмент для захвата и анализа системных вызовов (идеален для записи активности контейнера в реальном времени).- auditd - стандарт Linux для аудита безопасности, отслеживает доступ к файлам и выполнение команд.
- fatrace - отчет о доступе к файлам в реальном времени (легче, чем sysdig).
- bulk_extractor - сканирует образы дисков или тома на наличие шаблонов (email, кредитные карты, URL) без учета файловой системы.
Специализированный софт
- Docker Explorer (Google) - криминалистический анализ файловых систем Docker offline.- Autopsy / The Sleuth Kit - классические платформы для цифровой криминалистики, поддерживают анализ образов дисков с хостов Docker.
- Trivy / Grype - сканеры уязвимостей образов (помогают понять, мог ли контейнер быть скомпрометирован через известную уязвимость).
Облачные и веб-инструменты
- AWS CloudTrail / Azure Monitor - если контейнеры работали в ECS/EKS/AKS, логи управления находятся здесь, а не на хосте.- Datadog / ELK Stack - централизованные системы сбора логов, где могут храниться stdout/stderr удаленных контейнеров.
Практические примеры использования (Use Cases)
Сценарий 1: Поиск утечки учетных данных после удаления контейнера
Задача: Злоумышленник запустил контейнер, скопировал `.env` файл и удалил контейнер командой `docker rm -f`.Решение: Поскольку том не был явно удален, он остался в системе как "dangling".
bash
<h2 id="1-nahodim-osirotevshiy-tom">1. Находим осиротевший том</h2>
docker volume ls -f dangling=true
<h2 id="2-montiruem-ego-vo-vremennyy-bezopasnyy-konteyner-dlya-analiza">2. Монтируем его во временный безопасный контейнер для анализа</h2>
docker run --rm -v <имя_тома>:/investigation alpine cat /investigation/.env
*Результат:* Мы извлекли пароли от базы данных, которые считались удаленными.
Сценарий 2: Расследование несанкционированного доступа через сокет Docker
Задача: Подозрение, что злоумышленник получил root-доступ к хосту через `/var/run/docker.sock`.Решение: Анализ логов аудита хоста.
bash
<h2 id="ischem-popytki-dostupa-k-soketu-docker">Ищем попытки доступа к сокету Docker</h2>
ausearch -f /var/run/docker.sock
<h2 id="proveryaem-istoriyu-komand-polzovatelya-kotoryy-mog-ispolzovat-soket">Проверяем историю команд пользователя, который мог использовать сокет</h2>
grep "docker run" /home/suspicious_user/.bash_history
*Результат:* Обнаружена команда запуска привилегированного контейнера (`--privileged`), что подтверждает вектор атаки.
Сценарий 3: Восстановление удаленной базы данных
Задача: Разработчик случайно удалил контейнер с БД без бэкапа.Решение: Использование `docker-explorer` для offline-анализа, если стандартные методы не работают.
bash
<h2 id="nahodim-id-udalennogo-konteynera-cherez-logi-ili-ostatki-v-var-lib-docker">Находим ID удаленного контейнера через логи или остатки в /var/lib/docker</h2>
de -r /var/lib/docker list_containers
<h2 id="montiruem-ego-faylovuyu-sistemu-v-dostupnuyu-papku">Монтируем его файловую систему в доступную папку</h2>
de -r /var/lib/docker mount <container_id> /mnt/recovery
<h2 id="kopiruem-fayly-bd">Копируем файлы БД</h2>
cp -r /mnt/recovery/var/lib/mysql /safe_location/
Безопасность и этика использования
Законные применения
- Incident Response (IR): Расследование взломов и утечек данных по официальному запросу руководства или правоохранительных органов.- Compliance Audits: Проверка соответствия стандартам безопасности (PCI DSS, GDPR) на предмет хранения конфиденциальных данных в томах.
- Red Teaming: Моделирование атак для проверки того, какие артефакты остаются после "зачистки" следов.
Запрещенные действия
- Несанкционированный сбор данных: Извлечение личной информации (PII) из томов без юридического основания.- Модификация доказательств: Любые действия с флагами записи (`-v` при запуске анализатора без read-only) могут изменить временные метки (MAC-атрибуты) и сделать доказательства недопустимыми в суде.
- Саботаж: Использование команд `prune` или `rm` во время активного расследования.
Лучшие практики (White-hat guidelines)
1. Принцип "Read-Only": Всегда монтируйте тома для анализа в режиме только для чтения (`:ro`).2. Снимок состояния (Snapshot): Перед любым анализом сделайте побитовую копию (image) диска хоста или хотя бы архив директории `/var/lib/docker`.
3. Изоляция: Проводите анализ на изолированной криминалистической рабочей станции, а не на продакшен-сервере.
4. Документирование: Фиксируйте хеш-суммы (SHA256) всех извлекаемых файлов и точные временные метки выполнения команд.
Часто задаваемые вопросы (FAQ)
Действительно ли `docker rm -f` удаляет всё безвозвратно?
Нет. Флаг `-f` принудительно останавливает и удаляет контейнер, но не удаляет связанные с ним именованные тома (volumes) и базовые образы. Данные остаются на хосте до явной команды `docker volume rm` или `docker system prune`.Как предотвратить потерю доказательств при расследовании?
Никогда не работайте с оригинальными данными напрямую. Сначала создайте образ диска хоста (например, с помощью `dd` или `ftk imager`), либо сделайте резервную копию директории `/var/lib/docker` и файлов томов. Всегда используйте опцию монтирования `:ro` (read-only).Можно ли восстановить данные, если была выполнена команда `docker system prune -a --volumes`?
Это крайне сложно, но теоретически возможно на уровне файловой системы хоста (ext4/xfs). Потребуется использование инструментов вроде `extundelete` или `photorec` для сканирования свободного пространства диска хоста, так как Docker физически удаляет файлы томов при использовании этого флага.Почему `docker history` не показывает секреты, хотя я видел их в Dockerfile?
Если секрет был добавлен в одном слое, а удален в следующем (например, `RUN echo "pass" > file` и затем `RUN rm file`), он все равно останется в истории нижнего слоя. Однако, если использовались multi-stage builds или секреты передавались через BuildKit secrets (`--secret`), они не сохраняются в финальном образе.Как защитить Docker-хост от криминалистического анализа злоумышленником?
Используйте шифрование дисков (LUKS) на хосте, применяйте минимальные привилегии для демонов, регулярно очищайте неиспользуемые тома и образы, а также настройте централизованный сбор логов (SIEM), чтобы история не хранилась локально.Заключение
Цифровая криминалистика Docker требует сдвига парадигмы: от анализа одного жесткого диска к анализу сложной экосистемы, состоящей из демонов, слоев, томов и сетевых правил. Команда `docker rm` — это не кнопка "уничтожить все следы", а лишь удаление метаданных контейнера. Основные артефакты (данные, логи, конфигурации) продолжают жить в томах, слоях образов и журналах хост-системы.Ключевые takeaways:
- Тома (Volumes) — главные хранилища улик. Они переживают удаление контейнера.- История образов (History) хранит секреты. Команды `ENV` и `RUN` в нижних слоях видны даже после их "удаления" в верхних слоях.
- Хост-система помнит всё. Логи `journald`, `auditd` и история bash часто содержат больше информации, чем сам контейнер.
- Всегда работайте в режиме Read-Only. Изменение временных меток может уничтожить ценность доказательств.
- Автоматизируйте сбор. Используйте скрипты и специализированные инструменты (`docker-explorer`, `sysdig`) для быстрого и воспроизводимого сбора артефактов.
Помните: в цифровой криминалистике скорость реакции и строгое соблюдение методологии имеют решающее значение. Действуйте быстро, но не разрушайте доказательства.
⚠️ Дисклеймер: Данная статья носит исключительно информационно-образовательный характер. Предоставленные команды и методики предназначены для использования сертифицированными специалистами по информационной безопасности, криминалистами и системными администраторами в рамках законных процедур расследования инцидентов (Incident Response) и аудита безопасности. Несанкционированный доступ к компьютерным системам, извлечение или модификация данных без явного письменного разрешения владельца системы является нарушением законодательства (в РФ — ст. 272, 273, 274 УК РФ) и преследуется по закону. Автор и редакция не несут ответственности за любое неправомерное использование предоставленной информации.
