Криминалист работает с изъятыми образами дисков: изолированный сервер

MAATRIX

Вам передали образ изъятого носителя — и первый вопрос не «какой инструмент открыть», а «на чём это вообще можно анализировать». Рабочий ноутбук с личной почтой, синхронизацией Dropbox или iCloud и постоянным доступом в интернет для этой задачи не годится в принципе: любой процесс на такой машине может незаметно обратиться наружу, любой облачный клиент — утащить файл в фоне, любая посторонняя программа — оставить в системе следы, которые потом придётся объяснять на суде. Ниже — как устроить для конкретного расследования отдельную изолированную среду на арендованном сервере, где вы сами определяете, что и куда имеет право ходить.

Почему рабочая машина не подходит для анализа образов

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

Для расследования это создаёт сразу две категории риска:

• Риск для доказательства. Если анализ велся на машине с недокументированными сетевыми подключениями и синхронизациями, вы не можете с уверенностью сказать, что образ и производные от него файлы не покидали контролируемый периметр. Это подрывает саму идею цепочки сохранности доказательств (chain of custody) — принципа, что от момента изъятия до момента представления результата должно быть ясно и подтверждаемо, кто, когда и при каких условиях имел доступ к материалу.
• Риск для среды. Образ диска — это не абстрактный набор байт, а слепок системы, которая могла быть скомпрометирована: в ней может лежать активный троян, шифровальщик, руткит с автозапуском при монтировании. Открыть такой образ на машине, откуда есть путь в вашу личную почту, к рабочим документам или в общую сеть офиса — значит дать потенциальной угрозе шанс распространиться дальше периметра одного дела.

Профессионально оба риска снимаются одним и тем же решением: анализ должен идти в среде, изолированной от всего постороннего, созданной под конкретное расследование и уничтожаемой (или полностью очищаемой) по его завершении.

Цепочка сохранности доказательств и при чём тут инфраструктура

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

Отдельный сервер под дело закрывает этот вопрос предметно:

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

Это не замена процессуальным требованиям, а техническая база, которая делает соответствие им реальным, а не декларативным.

Изолированный сервер как контролируемая среда: что это значит на практике

Идея простая: вы арендуете отдельный сервер конкретно под расследование (или заводите отдельный виртуальный сервер на площадке с несколькими делами в работе — но обязательно разделёнными между собой) и сами определяете условия доступа и изоляции, а не подстраиваетесь под то, что уже настроено на общей инфраструктуре офиса.

Практически это означает несколько решений, которые вы принимаете осознанно, а не по умолчанию:

1. Сеть. Сервер не имеет причин быть открытым в интернет по всем портам. Управление — только через SSH по ключу (не по паролю), желательно с ограничением по IP или через VPN-туннель. Никакого веб-интерфейса аналитического инструмента, торчащего наружу без аутентификации.
2. Программное окружение. Только то, что нужно для анализа конкретного дела: инструменты для работы с образами, минимум системных пакетов, никаких личных аккаунтов, почтовых клиентов и облачных синхронизаций на самой машине.
3. Хранилище. Диск для образов и производных артефактов зашифрован, а объём выделен заранее под ожидаемый размер материалов дела — не «куда придётся».
4. Жизненный цикл. У среды есть чёткое начало (создание сервера под дело) и чёткий конец (полное уничтожение диска после сдачи заключения и истечения срока хранения, определённого вашими внутренними регламентами).

Дальше — конкретные шаги, как это собрать на арендованном Linux-сервере.

Разворачивание изолированной среды: базовая настройка

Возьмём типовой сценарий — выделенный или виртуальный сервер под управлением Ubuntu или Debian, доступный только вам и, возможно, ограниченному кругу коллег по делу.

Первый шаг — закрыть доступ по паролю и оставить только ключи:

# на сервере, в /etc/ssh/sshd_config
PasswordAuthentication no
PermitRootLogin no
AllowUsers forensic_analyst

sudo systemctl restart sshd

Второй шаг — минимальный firewall, который по умолчанию режет всё, кроме явно разрешённого:

sudo apt install ufw -y
sudo ufw default deny incoming
sudo ufw default deny outgoing
sudo ufw allow out 53/udp    # DNS для установки пакетов
sudo ufw allow out 443/tcp   # обновления системы и репозитории
sudo ufw allow in 22/tcp from <ваш_рабочий_IP>
sudo ufw enable

Обратите внимание на default deny outgoing — это важнее, чем закрытие входящих. Именно исходящий трафик — тот канал, по которому потенциально заражённое содержимое образа могло бы «дозвониться» наружу или по которому случайно утекли бы данные через забытый облачный клиент. Если для работы конкретного инструмента понадобится дополнительное исходящее направление — открывайте его точечно и осознанно, а не общим разрешением.

Третий шаг — учётная запись без личных сервисов. Никакой привязки к вашей личной почте, никакого браузера с сохранёнными паролями, никакого мессенджера. Сервер — рабочий инструмент под одну задачу, и чем меньше на нём лишнего, тем меньше поверхность для случайной ошибки.

Работа с образами: монтирование, целостность, хранение

Сам образ на изолированный сервер попадает уже готовым — как он был снят на месте изъятия, тем инструментом и в том формате, которым вы обычно пользуетесь (E01, raw/dd, AFF и так далее — выбор формата и метода снятия образа не в фокусе этой статьи, это отдельная профессиональная область). Здесь важнее то, что происходит после передачи файла на сервер.

Первое, что стоит сделать сразу после копирования — проверить контрольную сумму и зафиксировать её в рабочих записях по делу:

sha256sum evidence_image.dd > evidence_image.sha256
cat evidence_image.sha256

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

Монтировать образ для анализа стоит только в режиме «только чтение», чтобы исключить случайную запись в исследуемую файловую систему:

sudo losetup -f -r --show evidence_image.dd
sudo mount -o ro,loop /dev/loop0 /mnt/evidence

Для анализа файловых систем, восстановления удалённых файлов и построения таймлайна событий на Linux-сервере обычно разворачивают связку из открытых инструментов — Sleuth Kit и Autopsy остаются одним из самых распространённых бесплатных наборов для такой работы:

sudo apt install sleuthkit -y
mmls evidence_image.dd     # разметка разделов
fls -r -m / /dev/loop0 > timeline_bodyfile.txt

Сам образ и все производные от него файлы (выгрузки, извлечённые артефакты, отчёты) должны лежать на зашифрованном разделе. Если сервер арендован именно под это дело, логично зашифровать весь диск данных целиком:

sudo cryptsetup luksFormat /dev/sdb1
sudo cryptsetup open /dev/sdb1 evidence_storage
sudo mkfs.ext4 /dev/mapper/evidence_storage
sudo mount /dev/mapper/evidence_storage /mnt/case_data

Ключ шифрования при этом стоит хранить отдельно от самого сервера — например, в вашем офлайн-менеджере паролей, а не в файле рядом с образом. Тогда даже физический доступ к диску сервера (в теории — на стороне провайдера) не даёт доступа к содержимому без ключа, которым владеете только вы.

Доступ, аудит и завершение работы над делом

Если к делу подключены несколько специалистов, у каждого должен быть собственный ключ SSH и своя учётная запись — не общий логин «forensic», а именованные записи с возможностью впоследствии сказать, кто именно и когда заходил на сервер:

sudo adduser --disabled-password analyst_ivanov
sudo mkdir -p /home/analyst_ivanov/.ssh
sudo nano /home/analyst_ivanov/.ssh/authorized_keys   # публичный ключ коллеги
sudo chown -R analyst_ivanov:analyst_ivanov /home/analyst_ivanov/.ssh
sudo chmod 700 /home/analyst_ivanov/.ssh

Журнал входов и команд стоит сохранять за весь период работы над делом — он же становится техническим приложением к заключению, подтверждающим состав лиц с доступом:

last -F > /mnt/case_data/logs/ssh_logins.txt

По объёму и сроку хранения таких логов единого стандарта нет — это тоже вопрос ваших внутренних регламентов и специфики дела, здесь не буду называть конкретные цифры или сроки, которые не смогу подтвердить универсально.

Когда работа над делом завершена и заключение сдано, у сервера должен быть предсказуемый конец, а не бессрочное существование «на всякий случай» с чужими образами внутри:

• если сервер арендовался под одно дело — после истечения регламентного срока хранения материалов диск затирается и сервер удаляется;
• если используется общая площадка под несколько дел — данные конкретного дела выгружаются в архив, раздел с образами перезаписывается, ключ шифрования уничтожается.

Для гарантированного затирания зашифрованного раздела достаточно уничтожить ключ — без него данные на диске остаются криптографически бессмысленным набором байт, что для большинства внутренних регламентов эквивалентно надёжному удалению:

sudo cryptsetup luksErase /dev/sdb1

Где брать такой сервер и что учитывать при выборе

Для этой задачи не нужен мощный сервер — важнее контроль над сетью и дисковым пространством, чем количество ядер. Подойдёт как виртуальный сервер (VPS) с выделенным диском под каждое дело, так и выделенный физический сервер, если объём материалов и число параллельных дел большие. Несколько практических моментов:

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

Смежные темы, которые пригодятся при подготовке такого сервера: чек-лист безопасности нового сервера — что проверить сразу после разворачивания, шифрование дисков и что оно защищает — если нужно разобраться в модели угроз перед выбором схемы, и как разграничить доступ команде без выдачи root — если над делом работает больше одного специалиста.

Частые вопросы