🛠 Hacktrick for Application Security
Салют,
Сегодня хочу поделиться с тобой очень объемным материалом, который залетит (как дети в школу) для твоей прокачки и понимание глубоких принципов работы безопасности - от сокета и TLS до namespaces, cgroups и секьюрных профилей ядра и т.д. Материал с описанием и деталями как ломают и как противодействовать на реальных техниках эскалации, а не только best practices из мануалов.
Что важно тебе сразу взять?
• В разделе Pentesting Methodology расписан весь цикл теста: от сбора активов и сканирования до эксплуатации и пост‑эксплуатации, с конкретными командами и тулзами
• Для Windows и Linux есть чек‑листы локальной привилегии: что смотреть в службах, правах, реестре, драйверах, файловой системе, чтобы быстро найти точку эскалации
• Отдельный раздел по Docker Security: как правильно настраивать engine, какие флаги и security‑опции использовать, как работать с сокетом, capabilities, seccomp/ AppArmor
• Есть практические страницы по Docker breakout / privilege escalation — сценарии, когда у тебя есть доступ к контейнеру или docker.sock, и ты шаг за шагом превращаешь это в root на хосте через mount’ы, привилегированные контейнеры и т.п.
• Для AWS/ GCP/ Azure есть отдельные гайды по перечислению ресурсов, поиску мисконфигов, уязвимых политикам и типовым сценариям атак в облаке
• Обучалки формата AWS Red Team Expert / GCP Red Team Expert
• Большой кусок посвящён специфике отдельных технологий: AD, SQL, веб‑фреймворки, криптопримитивы
То есть, сам HackTricks даёт не теоретическую, а операционную картинку атакующего мышления: «какие команды я запускаю, что именно проверяю, что делаю дальше, если нашёл X».
Из этого удобно собирать свои чек‑листы для ревью инфраструктуры: Docker, Windows, облака и т.д. — буквально адаптируешь под себя.
Смотри, вот пример такого чек листа под Docker Security Checklist (приметив)
**Цель:** быстро проверить, не превращён ли ваш Docker‑хост в лёгкую цель
---
## Docker Engine и daemon
- Не светить `docker.sock` — только HTTPS + клиентские сертификаты
- Не поднимать `-H tcp://0.0.0.0:2375` без TLS
- Включить rootless‑режим и обновлять Docker/ host до актуальных патчей
***
## Образы и registry
- Использовать только официальные или свои базовые образы, не наследоваться от случайных `user/some-ubuntu-with-magic`
- В Dockerfile по возможности использовать **COPY вместо ADD**, чтобы не тянуть внешние URL и не распаковывать архивы
- Настроить регулярный пересбор образов, чтобы тянуть security‑патчи
- Подключить сканирование образов (docker scan / Trivy / Grype) — в CI и по расписанию по registry
***
## Секреты и конфиги
- Не класть токены/ ключи в image или в ENV, использовать секреты оркестратора (docker secrets/ k8s secrets/ vault)
- Проверять сохранённые образы/ слои на наличие секретов (git‑history, слои tar внутри image)
***
## Runtime‑ограничения
- Ограничить ресурсы контейнера (CPU, RAM, IO) через cgroups
- Настроить seccomp/ AppArmor/ SELinux‑профили, сузив доступные syscalls и операции до минимума
***
## Capabilities
- Не использовать `--privileged` в проде: он даёт контейнеру почти полный набор прав ядра и сильно упрощает escape
- Базовый подход: `--cap-drop=ALL` и затем точечно `--cap-add` только тех возможностей, без которых сервис не работает (например, `NET_BIND_SERVICE` для портов 80/443)
> Capabilities позволяют вместо «полного root» выдавать контейнеру только необходимые возможности ядра; чем их меньше, тем сложнее атакующему выйти из контейнера
#appsec #devsecops #course #specialty #containersecurity #mast #dast