Атака Pterodactyl Crasher: как забивают диск ноды

Проверено с: Panel v1.15.1, Wings v1.13.3, Docker 20.10+ · обновлено 09.10.2026

Короткий ответ: «Pterodactyl Crasher» — это не взлом панели, а злоупотребление тем, что Docker по умолчанию не ограничивает размер диска контейнера. Любой код, запущенный на вашем сервере (вредоносный плагин, скачанное ядро, скрипт от субпользователя), может за секунды зарезервировать весь диск хоста системным вызовом fallocate — и упадут все серверы на ноде сразу. Стандартный лимит диска в панели не спасает: Wings проверяет диск раз в 150 секунд, атака укладывается в 10.

Статью мы писали после реального теста: скрипт на 48 потоков забил 155 ГБ за ~10 секунд на ноде без защиты. Разберём механику и работающие слои защиты.

Как работает атака

1. У контейнера нет дисковой квоты

Wings запускает серверы в контейнерах на overlayfs. Overlay не умеет ограничивать размер верхнего слоя: «лимит диска» в панели — это программная проверка, а не свойство файловой системы. Контейнер может занять весь раздел хоста, где лежат данные серверов.

2. fallocate резервирует место мгновенно

Обычная запись (dd, копирование файлов) заполняет диск со скоростью диска. Системный вызов fallocate работает иначе: он резервирует блоки у файловой системы, не записывая ни байта данных. Сотни гигабайт «занимаются» за миллисекунды:

# упрощённая схема публичных крашеров
import subprocess
from uuid import uuid4
from concurrent.futures import ThreadPoolExecutor

with ThreadPoolExecutor(max_workers=48) as pool:
    for _ in range(1000):
        pool.submit(subprocess.run,
                    ["fallocate", "-l", "1G", f".tmp_{uuid4()}"])

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

3. Реакция Wings опаздывает

По умолчанию Wings проверяет занятое место раз в 150 секунд (параметр disk_check_interval). За это время крашер успевает завершить работу: диск полон, все контейнеры ноды падают с ошибками записи, вместе с ними — новые запуски, установки и сама панель, если она на той же машине.

4. Вариант через иноды

Тот же результат дают миллионы мелких файлов: место на диске остаётся, а заканчиваются иноды (df -i). Атака медленнее, но на неё не реагируют проверки, смотрящие только на df -h.

Признаки того, что вас крашнули

• df -h показывает 100% на разделе с данными серверов (обычно там же, где /var/lib/docker);
• все серверы ноды разом падают или висят с ошибками ввода-вывода;
• в директориях серверов — тысячи файлов вида .tmp_xxxxxxxx огромного размера.

Первая помощь: остановить виновника (docker ps, стоп контейнера в панели), удалить его мусорные файлы, проверить df -i. После — закрывать дыру, потому что атаку повторят.

Слои защиты

Слой	Что делает	Эффект
Seccomp-фильтр fallocate	Docker отклоняет вызов, процесс получает ENOSPC	Атака ломается мгновенно, 0 байт занято
Ускорение проверки диска	disk_check_interval: 5 в конфиге Wings	Реакция за секунды вместо 2,5 минут
Лимит процессов	container_pid_limit в конфиге Wings	Многопоточный крашер не может развернуться
Монитор диска	Демон, проверяющий заполнение каждые несколько секунд	Ловит «медленные» варианты (dd, иноды)
Жёсткие квоты ФС	XFS + pquota на разделе данных	Кап на уровне файловой системы — самый надёжный вариант

Первые четыре слоя собираются в один шаг установкой открытого инструмента DiskGuard — он ставит seccomp-профиль для Docker, правит конфиг Wings и добавляет монитор. Жёсткие квоты XFS/pquota мы разберём отдельной статьёй: они требуют правильной разметки диска при установке ноды.

Заметка

Описанное — не уязвимость кода Pterodactyl: это свойство Docker по умолчанию, поэтому те же приёмы защиты применимы к любой панели на Docker, включая форк Pelican.

Что дальше

• DiskGuard: установка и проверка — ставим защиту на ноду за 5 минут.
• Hardening ноды — базовые практики безопасности официальной документации (SSH, файрвол).

Хочется не администрировать, а играть?

Управляемый хостинг Minecraft от Xipher стартует вместе с открытием продаж — декабрь 2026. Оставьте заявку, расскажем первыми.

В лист ожидания

Атака ломает саму панель Pterodactyl?

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

Разве лимит диска в панели не защищает?

Только частично: это программная проверка с интервалом (по умолчанию 150 секунд), а не квота файловой системы. Она останавливает постепенное разрастание, но не мгновенный fallocate. Работающая защита — seccomp-фильтр и ускоренная проверка, лучше всего вместе с жёсткой квотой ФС.

Работает ли такая атака против Pelican?

Механизм не зависит от панели: если нода запускает контейнеры Docker без жёстких дисковых квот, fallocate заполнит диск точно так же. Защита (seccomp, мониторинг, квоты) тоже переносится.