Оцінка та захист

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks

Огляд

Хороша оцінка контейнера повинна відповісти на два паралельні питання. По-перше, що може зробити атакуючий з поточного workload? По-друге, які рішення оператора це зробили можливим? Інструменти enumeration допомагають із першим питанням, а рекомендації з hardening — із другим. Наявність обох на одній сторінці робить розділ кориснішим як польовий довідник, а не просто каталог escape трюків.

Інструменти для переліку

Кілька інструментів лишаються корисними для швидкої характеристики контейнерного середовища:

  • linpeas може ідентифікувати багато індикаторів контейнера, змонтовані сокети, набори capability, небезпечні файлові системи та підказки щодо breakout.
  • CDK спеціально орієнтований на контейнерні середовища і включає enumeration плюс деякі автоматизовані перевірки на escape.
  • amicontained легковаговий і корисний для визначення обмежень контейнера, capabilities, експозиції namespace та ймовірних класів breakout.
  • deepce — ще один фокусований на контейнерах енумератор з перевірками, орієнтованими на breakout.
  • grype корисний, коли оцінка включає огляд вразливостей пакетів у image, а не тільки аналіз runtime escape.

Цінність цих інструментів — швидкість і покриття, а не певність. Вони допомагають швидко відкрити загальну позицію, але цікаві знахідки все одно потребують ручної інтерпретації з урахуванням фактичної моделі runtime, namespace, capability і mount.

Пріоритети захисту

Найважливіші принципи hardening концептуально прості, хоча їхня реалізація відрізняється залежно від платформи. Уникайте privileged контейнерів. Уникайте змонтованих runtime socket-ів. Не давайте контейнерам записувані host-шляхи, якщо немає дуже конкретної причини. Використовуйте user namespaces або rootless виконання там, де це можливо. Drop усі capabilities і додавайте назад лише ті, які дійсно потрібні workload. Тримайте seccomp, AppArmor і SELinux увімкненими замість їх відключення для виправлення проблем сумісності додатків. Обмежуйте ресурси так, щоб скомпрометований контейнер не міг тривіально відмовити в обслуговуванні хосту.

Гігієна image та процесу build має таке ж значення, як і runtime-позиція. Використовуйте мінімальні image, перебудовуйте часто, скануйте їх, вимагайте provenance там, де це практично, і не тримайте секрети в шарах. Контейнер, що запускається як non-root з невеликим image і вузькою поверхнею syscall та capability, значно легше відстоювати, ніж великий convenience image, що працює як host-equivalent root з попередньо встановленими debugging інструментами.

Приклади виснаження ресурсів

Контроль ресурсів не виглядає гламурно, але це частина безпеки контейнерів, бо обмежує blast radius компрометації. Без обмежень пам’яті, CPU або PID простий shell може бути достатнім, щоб погіршити роботу хосту чи сусідніх workload.

Приклади тестів, що впливають на хост:

stress-ng --vm 1 --vm-bytes 1G --verify -t 5m
docker run -d --name malicious-container -c 512 busybox sh -c 'while true; do :; done'
nc -lvp 4444 >/dev/null & while true; do cat /dev/urandom | nc <target_ip> 4444; done

Ці приклади корисні, оскільки вони показують, що не кожен небезпечний результат контейнера є чистим “escape”. Слабкі обмеження cgroup все ще можуть перетворити code execution на реальний операційний вплив.

Інструменти для посилення безпеки

Для середовищ, орієнтованих на Docker, docker-bench-security залишається корисним базовим аудиторським інструментом на стороні хоста, оскільки він перевіряє поширені проблеми конфігурації згідно з широко визнаними рекомендаціями бенчмарка:

git clone https://github.com/docker/docker-bench-security.git
cd docker-bench-security
sudo sh docker-bench-security.sh

Інструмент не замінює threat modeling, але він усе ще цінний для виявлення недбалих daemon, mount, network і runtime налаштувань за замовчуванням, які накопичуються з часом.

Перевірки

Використовуйте ці команди як швидкий первинний набір під час оцінки:

id
capsh --print 2>/dev/null
grep -E 'Seccomp|NoNewPrivs' /proc/self/status
mount
find / -maxdepth 3 \( -name docker.sock -o -name containerd.sock -o -name crio.sock -o -name podman.sock \) 2>/dev/null

Що тут цікавого:

  • root процес з широкими можливостями та Seccomp: 0 вимагає негайної уваги.
  • Підозрілі точки монтування та runtime sockets часто дають швидший шлях до впливу, ніж будь-який kernel exploit.
  • Поєднання слабкої runtime posture та слабких resource limits зазвичай свідчить про загалом дозволяюче середовище контейнера, а не про одну ізольовану помилку.

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks