ДИСТРОСКОПИЯ #08 Tsurugi Linux: чем DFIR-дистрибутив отличается от pentest-системы #Дистроскопия Когда речь заходит о Linux-дистрибутивах для информационной безопасности, обычно вспоминают Kali Linux или ParrotOS. Они известны инструментами исследования защищённости, анализа сетей и тестирования на проникновение. Но существует другой класс задач. Представим, что на корпоративном сервере обнаружены признаки компрометации. Нужно установить, что произошло, какие файлы изменились, какие действия выполнялись и какие следы сохранились. Здесь уже недостаточно найти уязвимость. Нужно собрать цифровые доказательства, сохранить их целостность и провести воспроизводимый анализ. Именно для таких задач создавался Tsurugi Linux. Разберём его архитектуру, инструменты, специальные механизмы защиты и ограничения. 1. Карточка операционной системы Название: Tsurugi Linux [LAB] Актуальный выпуск: 26.03 Дата выпуска: 4 апреля 2026 года Первый публичный выпуск: 3 ноября 2018 года Происхождение: Ubuntu 24.04.3 LTS Архитектура: x86-64 Ядро: модифицированное Linux 6.19.10 libc: glibc (платформа Ubuntu) init / управление службами: systemd (платформа Ubuntu) Пакетная система: DEB, APT и dpkg Установщик: Calamares Модель выпуска: отдельные версии проекта, без публично гарантированного фиксированного цикла релизов Форматы: загрузочный ISO и готовый образ виртуальной машины OVA Назначение: Digital Forensics, Incident Response, исследование вредоносного ПО и OSINT. Проверено: 30 октября 2026 года. Tsurugi представляет собой существенно переработанную Ubuntu, а не самостоятельную ОС с нуля написанным пользовательским окружением. Это означает совместимость со многими привычными механизмами Ubuntu, но не гарантирует полного совпадения поведения с обычной Ubuntu Desktop. Особенно это касается ядра, защиты накопителей, предустановленных инструментов и процедуры обновления. 2. Что означает DFIR DFIR — Digital Forensics and Incident Response. Здесь объединяются два направления. Digital Forensics — исследование цифровых данных для восстановления событий и выявления технических обстоятельств. Incident Response — реагирование на инцидент: определение масштаба, локализация угрозы, устранение последствий и восстановление работы. Например, после компрометации сервера исследователь может изучать: — файловую систему и удалённые файлы; — системные журналы; — историю действий пользователей; — следы запуска программ; — конфигурацию механизмов автозапуска; — содержимое оперативной памяти, если оно было своевременно сохранено; — сетевые артефакты; — временную последовательность событий. Важная особенность: задача не только обнаружить подозрительный объект. Необходимо установить его происхождение, контекст и связь с другими событиями. 3. DFIR и pentest — разные задачи Pentest обычно отвечает на вопрос: Каким способом атакующий потенциально может получить доступ или нарушить защищённость системы? DFIR отвечает на другой: Что фактически происходило в исследуемой системе и какие данные позволяют это подтвердить? Например: Pentest: Проверка уязвимости → подтверждение возможности эксплуатации → оценка риска. DFIR: Получение данных → сохранение целостности → анализ артефактов → реконструкция событий → обоснованный вывод. Инструменты этих направлений частично пересекаются. В pentest-дистрибутивах тоже встречаются forensic-утилиты, а Tsurugi содержит средства исследования безопасности. Различие заключается прежде всего в организации работы. Для pentest важна возможность безопасно и санкционированно проверить защищённость. Для DFIR дополнительно критично не изменить исследуемые доказательства и обеспечить прослеживаемость действий аналитика. 4. Главная особенность Tsurugi — защита от записи При исследовании накопителя существует серьёзный риск. Обычная ОС может автоматически обнаружить устройство, смонтировать файловую систему и выполнить операции записи. Некоторые изменения способны затронуть служебные данные, журнал файловой системы или другие структуры. Для повседневной эксплуатации это нормальные механизмы. Для цифровой криминалистики — потенциальная проблема. Tsurugi применяет специальный механизм ограничения записи на уровне модифицированного ядра. Кроме того, проект принудительно восстанавливает настройки, связанные с автоматическим монтированием устройств, автозапуском и гибернацией. Практическое значение: при подключении исследуемого диска система должна снижать вероятность непреднамеренного изменения его содержимого. Но здесь проходит важная граница: Наличие программного write blocker ≠ доказательство неизменности носителя. Нужно учитывать конкретный контроллер, интерфейс подключения, поведение накопителя и возможность обхода защиты. Для особо важных исследований может потребоваться независимый аппаратный write blocker. А его фактическую работу тоже необходимо проверять. Ни название режима, ни наличие специального ядра не заменяют процедуру контроля целостности. Условная схема. Центральный блок обозначает программную защиту ядра Tsurugi, а не отдельный аппаратный write blocker. 5. Почему Tsurugi можно использовать как Live-систему Tsurugi Linux [LAB] поддерживает запуск с загрузочного носителя без обязательной установки на внутренний диск. Это полезно, когда необходимо исследовать устройство вне его штатной операционной системы. Например: Есть выключенный компьютер с потенциально скомпрометированной Windows. Исследователь загружает контролируемое forensic-окружение и получает доступ к носителям через инструменты Tsurugi. Таким образом, не требуется запускать установленную Windows и позволять ей выполнять обычные фоновые операции. Однако есть серьёзный компромисс. Если компьютер ещё работает, его перезагрузка уничтожит часть энергозависимых данных. Содержимое RAM, активные соединения и состояние процессов могут иметь большое значение для расследования. Поэтому решение о загрузке Live-системы принимается после оценки того, какие данные необходимо сохранить. Live-загрузка ≠ универсально безопасный первый шаг расследования. 6. Получение forensic image Одна из основных задач Tsurugi — создание образов исследуемых накопителей. В версии 26.03 официально перечислены, в частности: — Guymager; — ddrescue; — dc3dd; — ewfacquire; — FTK Imager. Эти инструменты поддерживают разные сценарии получения данных, включая создание побитовых образов и работу с forensic-форматами. Почему образ предпочтительнее непосредственной работы с оригиналом? Потому что анализ может включать операции, способные изменить состояние файловой системы или результаты предыдущих исследований. Типовая модель: Исходный носитель ↓ Контролируемое получение данных ↓ Forensic image ↓ Проверка целостности ↓ Рабочая копия ↓ Анализ Оригинал при этом сохраняется отдельно. Но создание файла образа ещё не означает успешного копирования. Необходимо проверить ошибки чтения, полноту полученных данных, формат образа и результаты верификации. Для повреждённых накопителей особое значение имеют режимы повторного чтения и сохранение карты проблемных блоков. 7. Хеширование — проверка данных, а не вывод о расследовании Tsurugi содержит инструменты расчёта хешей, включая SHA-256 и SHA-512. Они позволяют контролировать неизменность конкретного набора байтов. Например, для RAW-образа: sha256sum disk01.raw Полученное значение можно зафиксировать в материалах исследования и сравнить с результатом повторного расчёта. Если значения совпадают, это сильное подтверждение того, что проверяемые байты образа не изменились. Но здесь есть ограничения. Для формата E01 хеш контейнера и хеш исходных данных — не одно и то же. Верификация должна учитывать формат и его внутренние механизмы проверки. И главное: Совпадение хешей ≠ доказательство правильности всех выводов аналитика. Хеш подтверждает целостность данных в рамках выбранной процедуры. Он не подтверждает автоматически происхождение объекта, корректность временных меток или интерпретацию событий. 8. Исследование файловых систем и артефактов После получения образа начинается анализ. Tsurugi 26.03 включает The Sleuth Kit и Autopsy, а также инструменты исследования NTFS, APFS, Btrfs, XFS и других файловых систем. Это…

ФАКТОСКОПИЯ #08 RAID ≠ backup: что именно защищает массив, а что — нет #Фактоскопия На сервере два SSD объединены в RAID1. В панели управления: RAID Status: Optimal Массив исправен. Но означает ли это, что удалённые или повреждённые данные можно вернуть? Нет: статус характеризует массив, а не возможность восстановления. 1. Что действительно защищает RAID RAID объединяет несколько накопителей в логический массив. Избыточность зависит от выбранного уровня: RAID0 чередует блоки без избыточности: отказ одного диска делает массив непригодным. RAID1 зеркалирует данные: обычное зеркало из двух дисков выдерживает отказ одного. RAID5 использует распределённую чётность и допускает отказ одного диска. RAID6 использует двойную чётность и допускает отказ двух дисков. RAID не всегда означает отказоустойчивость: RAID0 её не обеспечивает. Избыточные уровни сохраняют доступ при предусмотренных отказах, если оставшиеся компоненты исправны. 2. Где проходит граница защиты Представим, что на RAID1 расположен каталог приложения. Администратор по ошибке удаляет его. Массив выполняет корректную операцию записи: изменение файловой системы отражается на обоих дисках. Второй накопитель не хранит независимую прежнюю версию файлов. Та же логика действует при: — случайной перезаписи данных; — шифровании файлов программой-вымогателем; — ошибочных изменениях со стороны приложения; — логическом повреждении данных. RAID может сохранять статус Optimal, хотя нужная информация уже удалена или испорчена. Избыточность дисков ≠ историческая копия данных. Кроме того, RAID не гарантирует сохранность при аварии, затронувшей весь массив: например, пожаре, краже или повреждении нескольких компонентов сверх допустимого числа отказов. 3. А два диска — не две копии? RAID1 содержит два экземпляра текущих данных. Но это не независимые точки восстановления. Механизм зеркалирования не отличает правильную запись от ошибочной. Он должен записать на оба диска и полезное изменение, и ошибочное. RAID отвечает за доступность хранилища при определённых физических отказах. Резервное копирование — за возможность восстановить сохранённое состояние данных после потери или повреждения. Оба механизма нужны, но один не заменяет другой. 4. Что доказывает статус Optimal Статус Optimal показывает, что система управления RAID считает массив исправным в момент проверки. Для более сильного вывода надо установить уровень RAID, фактический состав массива, состояние каждого накопителя, наличие ошибок и выполняющегося rebuild. В Linux Software RAID помогают: cat /proc/mdstat Показывает md-массивы и их текущее состояние, включая синхронизацию. mdadm --detail /dev/md0 Позволяет проверить уровень RAID, число устройств и состояние конкретного массива. Для аппаратного RAID используются средства соответствующего контроллера. Даже успешная проверка массива не подтверждает наличие пригодной резервной копии. 5. Что проверять отдельно Для подтверждения возможности восстановления нужно выяснить: — создаётся ли отдельная резервная копия; — сохраняются ли необходимые предыдущие версии; — не размещена ли единственная копия в той же области отказа; — защищены ли копии от изменения и удаления; — проходило ли восстановление практическую проверку. Snapshots могут помочь откатить изменения, но если они зависят от того же хранилища, его потеря может уничтожить и snapshots. Главное RAID1 может выдержать отказ одного диска и одновременно не защитить от случайного удаления каталога. RAID6 может выдержать отказ двух дисков, но не доказать возможность отката ошибочной записи. RAID ≠ backup. Вопрос для RAID: «Продолжим ли работу при предусмотренном отказе накопителя?» Вопрос для backup: «Из какого сохранённого состояния сможем восстановить данные?» Надёжная архитектура должна отвечать на оба вопроса. RAID: Шпаргалка #Фактоскопия #Linux #RAID #Backup

КЕЙС #05 Браузер доверяет сертификату, а Java — нет: где искать причину #Кейс Представим инфраструктуру. На Linux-сервере работает Java-приложение, которое обращается к внутреннему HTTPS API: https://api.infra.example Сервис использует сертификат, выпущенный корпоративным удостоверяющим центром. Администратор открывает тот же адрес в браузере — соединение защищено, предупреждений нет. Но Java-приложение не может установить HTTPS-соединение. В журнале появляется: javax.net.ssl.SSLHandshakeException: PKIX path building failed sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target Первое предположение: Java не доверяет корпоративному сертификату. Нужно импортировать его в cacerts. Возможно. Но пока это лишь гипотеза. Разберём, что именно нужно проверить, прежде чем изменять доверенные сертификаты JVM. 1. Что подтверждают исходные данные У нас есть два наблюдения. Наблюдение №1. Браузер успешно устанавливает HTTPS-соединение. Это подтверждает, что конкретный браузер в конкретном окружении смог выполнить необходимые TLS-проверки и принять сертификат сервера. Но: Браузер доверяет сертификату ≠ Java доверяет сертификату. Они могут использовать разные источники доверенных сертификатов. Наблюдение №2. Java возвращает PKIX path building failed. В контексте обычной проверки серверного сертификата это указывает на невозможность построить приемлемый путь сертификации к доверенному удостоверяющему центру. Но сообщение ещё не доказывает, что корневой сертификат отсутствует именно в cacerts. Возможны и другие причины. 2. Формируем гипотезы Гипотеза 1. Неполная цепочка сертификатов. Сервер передаёт конечный сертификат, но не предоставляет необходимый промежуточный сертификат удостоверяющего центра. Браузер может достроить цепочку с помощью уже имеющихся данных или дополнительных механизмов, а Java-приложение — не суметь. Гипотеза 2. Java использует другое хранилище доверия. Сертификат корпоративного УЦ установлен в хранилище, которому доверяет браузер, но отсутствует в хранилище, используемом приложением. Гипотеза 3. Проверяется не тот TLS-сервер. Например, браузер и приложение обращаются через разные прокси, разные сетевые маршруты либо получают разные сертификаты из-за конфигурации SNI. Гипотеза 4. Цепочка не проходит другие проверки. Возможны проблемы со сроком действия, ограничениями сертификатов или криптографическими алгоритмами. Необходимо последовательно сузить область поиска. 3. Сначала исследуем сертификаты, которые предоставляет сервер Проверку выполняем с Linux-хоста, на котором работает проблемное Java-приложение. openssl s_client \ -connect api.infra.example:443 \ -servername api.infra.example \ -showcerts </dev/null Здесь важно назначение параметров: -connect — адрес и порт TLS-сервера; -servername — имя, передаваемое через SNI; -showcerts — сертификаты, фактически присланные сервером. Получаем примерно следующее: Certificate chain 0: CN=api.infra.example issuer=Corp Intermediate CA 1: CN=Corp Intermediate CA issuer=Corp Root CA Мы увидели серверный сертификат и промежуточный УЦ. Отсутствие корневого сертификата в переданной цепочке само по себе не является ошибкой: корневой УЦ обычно уже должен находиться в доверенном хранилище клиента. Но -showcerts только показывает переданные сертификаты. Он не доказывает, что цепочка корректна и доверена. Для отдельной проверки используем заранее полученный и независимо проверенный сертификат корпоративного корневого УЦ: openssl s_client \ -connect api.infra.example:443 \ -servername api.infra.example \ -verify_hostname api.infra.example \ -CAfile corp-root.pem \ -verify_return_error </dev/null В нашем сценарии проверка завершается: Verify return code: 0 (ok) Это подтверждает, что OpenSSL смог проверить полученную цепочку и имя сервера при доверии к указанному корпоративному УЦ. Но успешная проверка OpenSSL не доказывает, что Java использует тот же набор доверенных сертификатов и те же правила проверки. 4. Какое хранилище доверия использует Java? Это ключевая развилка расследования. В стандартной реализации JSSE выбор хранилища доверия выглядит следующим образом: Если явно задано: javax.net.ssl.trustStore используется указанное хранилище. Если параметр не задан, Java ищет: <java-home>/lib/security/jssecacerts Если такого файла нет, используется: <java-home>/lib/security/cacerts При этом конкретное приложение может самостоятельно создавать SSLContext и использовать собственный TrustManager. Поэтому важно исследовать не абстрактную Java, установленную на сервере, а конкретный JVM-процесс, выполняющий проблемное приложение. 5. Проверяем работающий JVM-процесс Сначала определяем процесс приложения. Для подходящей JVM можно использовать: jcmd -l Затем запрашиваем системные свойства нужного процесса: jcmd <PID> VM.system_properties Особенно интересны: java.home javax.net.ssl.trustStore javax.net.ssl.trustStoreType Команда jcmd требует соответствующих прав доступа и поддерживаемого механизма подключения к JVM. В нашем примере обнаруживается: java.home=/opt/jdk-21 javax.net.ssl.trustStore= /etc/myapp/client-trust.p12 javax.net.ssl.trustStoreType=PKCS12 Это меняет направление расследования. Приложение настроено использовать отдельное хранилище: /etc/myapp/client-trust.p12 Следовательно, импорт сертификата в стандартный cacerts может вообще не повлиять на работу приложения. Именно этот файл нужно проверить первым. 6. Проверяем содержимое truststore Используем keytool из соответствующей Java-среды: /opt/jdk-21/bin/keytool -list -v \ -keystore /etc/myapp/client-trust.p12 \ -storetype PKCS12 Проверяем не только названия записей, но и сертификаты, их издателей и SHA-256-отпечатки. В нашем сценарии выясняется: хранилище существует и читается; оно содержит несколько ранее добавленных доверенных УЦ; корпоративный Corp Root CA, которому должна соответствовать полученная серверная цепочка, отсутствует; сертификат этого УЦ имеется в доверенном контуре браузера. Чтобы подтвердить отсутствие именно нужного сертификата, сравниваем его отпечаток с содержимым хранилища, а не полагаемся только на название alias. Теперь появляется существенное доказательство. Java-приложение использует собственный truststore, в котором нет необходимого доверенного УЦ. Но прежде чем исправлять конфигурацию, полезно подтвердить, что именно этот truststore участвует в неудачном соединении. 7. Проверяем решение Java о доверии Для этого JSSE предоставляет диагностическое логирование. При контролируемом тестовом запуске приложения можно включить: -Djavax.net.debug=ssl,handshake,trustmanager Оно позволяет исследовать обработку TLS handshake и работу TrustManager. Нас интересует: какой truststore загружается; какие доверенные сертификаты доступны; какая цепочка получена от сервера; на каком этапе проверка завершается ошибкой. В нашем сценарии логирование подтверждает использование: /etc/myapp/client-trust.p12 А проверка серверной цепочки не находит подходящего доверенного удостоверяющего центра. Диагностику следует выполнять ограниченное время: TLS-журналы могут быть объёмными и содержать чувствительную информацию. Теперь данные складываются в последовательность: Сервер предоставляет цепочку ↓ OpenSSL проверяет её с корпоративным корневым УЦ ↓ Java использует отдельный truststore ↓ Нужного доверенного УЦ в нём нет ↓ PKIX path building failed Подтверждённая причина нашего сценария: в явно настроенном хранилище доверия Java-приложения отсутствует необходимый корпоративный корневой УЦ. Это не «Java не поддерживает сертификат» и не неисправность HTTPS-сервера. Это несогласованность конфигурации доверия между клиентскими окружениями. 8. Исправляем установленную причину Получаем сертификат Corp Root CA из доверенного источника — например, от администратора корпоративной PKI. Не следует без проверки импортировать сертификат, случайно скачанный из сети или экспортированный с неизвестного сервера. Сначала проверяем его содержимое и отпечаток: keytool -printcert \ -file corp-root.pem Отпечаток должен совпадать с независимо подтверждённым значением корпоративного УЦ. После резервного копирования truststore и проверки процедуры изменения импортируем сертификат в существующее хранилище приложения: