Архивные бомбы: как распознать и безопасно анализировать подозрительные архивы

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

Что такое архивная бомба и почему она работает

Сжатие данных основано на устранении повторов. Если файл состоит из одинаковых байтов или повторяющихся блоков, алгоритм описывает его очень компактно. Классический пример — последовательность из миллиардов нулей: она сжимается до нескольких килобайт, потому что достаточно записать «ноль, повторить N раз». Этим свойством пользуются и легитимные форматы (логи, дампы памяти сжимаются отлично), и злоумышленники.

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

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

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

Известные примеры и пределы сжатия

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

• 42.zip — классическая рекурсивная бомба: архив около 42 килобайт, внутри слои вложенных zip-архивов; теоретический результат распаковки всех уровней — петабайты данных.
• Droste.zip — архив, использующий особенности формата zip так, что распаковка создаёт копию самого архива внутри себя; процесс не завершается естественным образом.
• zip quine — архив, побайтово совпадающий со своим собственным содержимым; интересен скорее как демонстрация возможностей формата, но ломает наивные парсеры.

Теоретический предел сжатия определяется алгоритмом. Для Deflate (базовый алгоритм zip и gzip) максимальный коэффициент составляет порядка 1032:1. Современные алгоритмы вроде zstd, LZMA и xz достигают бо́льших коэффициентов на специально подготовленных данных, поэтому ориентироваться только на «зиповский» предел нельзя. Практический вывод: коэффициент сжатия выше нескольких сотен для обычного файла — почти всегда повод остановиться и разобраться.

Признаки архивной бомбы до распаковки

Хорошая новость: подавляющее большинство архивных бомб выявляется метаданными, которые можно прочитать, не распаковывая содержимое. Проверка занимает секунды и не требует выполнения кода из архива.

1. Соотношение размера архива и заявленного объёма содержимого

Каждый архив хранит в заголовках (центральном каталоге для zip, заголовке потока для tar.gz) сведения о несжатом размере каждого файла. Достаточно сравнить сумму этих размеров с фактическим размером архива. Коэффициент сжатия 10–50:1 нормален для текстов, логов и баз данных. Значения в тысячи и миллионы раз — красный флаг. Для чтения метаданных подходят утилиты вида unzip -l, 7z l, tar -tvf, библиотеки Python (модуль zipfile), libarchive — все они читают каталог, не извлекая данные.

2. Глубина вложенности

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

3. Количество файлов

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

4. Аномальные имена и структура путей

Обратите внимание на:

• очень длинные пути и имена файлов — они способны обходить проверки длины и ломать обработчики;
• пути с переходами вверх по дереву (../) — признак path traversal, попытки записать файлы вне целевой папки;
• абсолютные пути и пути с буквами дисков;
• файлы без расширения или с двойными расширениями рядом с исполняемыми типами.

5. Несоответствие контексту

Часто самый надёжный сигнал — банальное несоответствие ожиданиям. Вам прислали «сканы договора», а архив весит 4 килобайта и заявляет внутри 8 гигабайт. Ожидается документ PDF, а внутри исполняемый файл или макрос. Контекст источника (неизвестный отправитель, неожиданное вложение, странная тема письма) усиливает любые технические признаки.

6. Поведение автоматических систем

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

Методы безопасного анализа

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

Шаг 1. Статическое чтение метаданных

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

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

Шаг 2. Ограниченная распаковка

Если метаданные выглядят приемлемо, но требуется содержимое, используйте инструменты с жёсткими лимитами:

• лимит суммарного распакованного объёма (например, не более 100 МБ);
• лимит числа файлов;
• лимит глубины рекурсии для вложенных архивов;
• таймаут на операцию;
• распаковка в отдельную директорию на файловой системе с квотой или небольшим свободным местом — тогда даже ошибка в лимитах упрётся в физическую границу.

Современные версии распространённых архиваторов поддерживают такие опции напрямую либо через обёртки; при интеграции в собственные скрипты лимиты задаются на уровне библиотек. Отдельно следите за symlink-записями в архивах формата tar: символическая ссылка может перенаправить запись за пределы целевой папки, поэтому ссылки лучше либо отбраковывать, либо разрешать только внутрь директории распаковки.

Шаг 3. Изолированная среда

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

• отключённые общие папки с хостом и сетевые адаптеры (либо сеть через контролируемый шлюз с логированием);
• снимок состояния перед началом работы, чтобы откатить систему после эксперимента;
• понимание, что виртуализация не даёт абсолютной изоляции: истории известны случаи побега из ВМ через уязвимости гипервизора, поэтому для особо опасных образцов применяют физически отдельные машины без ценной информации.

Шаг 4. Мониторинг ресурсов

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

Защита автоматических обработчиков архивов

Для администраторов ключевая зона риска — не ручная работа пользователя, а автоматика: почтовые шлюзы, антивирусы, сервисы приёма файлов, CI/CD-пайплайны, распаковывающие артефакты. Для них обязательна настройка лимитов:

Компонент	Что ограничить	Типичные значения ориентира
Почтовый шлюз / антивирус	Максимальный распакованный размер, глубина вложенных архивов, таймаут сканирования	Десятки–сотни МБ, глубина 2–3, минуты вместо часов; точные значения зависят от бизнес-процессов
Веб-сервис приёма файлов	Размер загружаемого архива, распакованного объёма, числа файлов, типов расширений	Жёсткая белая список допустимых типов; отклонение всего остального до обработки
Резервное копирование и антивирус на серверах	Исключение бесконечных циклов (quine-архивы), лимиты на обработку одного объекта	Настройка на стороне движка сканирования; проверяется тестовым образцом
CI/CD и сборочные агенты	Объём и время шагов распаковки, квоты на дисковое пространство раннера	Квоты файловой системы + таймауты шагов пайплайна

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

Типичные ошибки при работе с подозрительными архивами

• «Антивирус всё проверит». Антивирус сам является распаковщиком и сам становится целью атаки. Без настроенных лимитов он первым исчерпает ресурсы.
• Оценка только по размеру файла. Маленький архив — не значит безопасный; именно маленькие файлы с гигантским заявленным содержимым и есть классические бомбы.
• Распаковка «просто посмотреть» на рабочей машине. Даже если содержимое кажется безобидным, распаковка уже расходует ресурсы, а отдельные элементы могут оказаться исполняемыми или использовать уязвимости распаковщика.
• Двойной клик по архиву в проводнике. Многие оболочки показывают содержимое, но некоторые действия (предпросмотр, индексация поиска) запускают частичную распаковку незаметно для пользователя.
• Игнорирование вложенных архивов. Проверяют верхний уровень и пропускают то, что лежит на третьем-четвёртом уровне вложенности.
• Отсутствие лимитов в собственных скриптах. Скрипт, написанный «для своих файлов», рано или поздно получает на вход чужой архив — через форму загрузки, почту или общую папку.

Сценарии: что делать в зависимости от ситуации

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

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

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

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

Практические рекомендации

1. Никогда не запускайте полную распаковку архива из недоверенного источника без предварительного просмотра метаданных.
2. Настройте лимиты (объём, число файлов, глубина, таймаут) во всех автоматических обработчиках архивов и периодически проверяйте их тестовыми образцами.
3. Используйте файловые квоты на директории, куда распаковываются внешние данные, — это страховка на случай ошибки в лимитах.
4. Следите за symlink-записями и путями с выходом за пределы целевой папки.
5. Мониторьте заполнение временных директорий и длительность операций сканирования — аномалии часто видны раньше, чем наступает отказ.
6. Для исследования содержимого применяйте изолированные среды со снимками и без доступа к рабочей сети.
7. Обучите сотрудников правилу минимальной достаточности: неожиданный архив — это вопрос к отправителю, а не повод для двойного клика.

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

Может ли архивная бомба навредить системе сама по себе, без распаковки?

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

Чем архивная бомба отличается от обычного сильно сжатого файла?

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

Защищает ли облачное хранилище от архивных бомб?

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

Нужно ли удалять найденную архивную бомбу?

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

Что делать дальше

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

Материал носит информационный характер и описывает общие подходы к безопасности. Действия с потенциально вредоносными файлами и настройку защитных механизмов при существенном риске для инфраструктуры доверяйте квалифицированным специалистам по информационной безопасности.