Пост имеет ознакомительный характер и предназначен для специалистов по безопасности. Автор и редакция не несут ответственности за любой вред, причиненный с применением изложенной информации. Распространение вредоносных программ, нарушение работы систем и нарушение тайны переписки преследуются по закону
Если вы уже внутри контейнера, это еще не значит, что история закончилась. В реальных инцидентах контейнер часто оказывается не крепостью, а тонкой перегородкой. И если в ней есть ошибки, путь к хосту может оказаться намного короче, чем кажется.
Docker Socket: самая опасная находка 🧛
ls -la /var/run/docker.sock
Если внутри контейнера есть
docker.sock, это почти всегда тревожный сигнал. Такой сокет не просто файл, а способ общаться с Docker на хосте. На практике это означает, что контейнер может получить слишком много власти над системой, на которой он запущен. Это один из первых признаков того, что изоляция нарушена.Когда прав у малого слишком много 😮
cat /proc/self/status | grep Cap
capsh --print
Здесь важно понять, какими правами реально обладает процесс. Если в списке видны мощные capability вроде
SYS_ADMIN, это уже не обычный контейнерный режим. Такие права сильно расширяют возможности процесса и делают последствия компрометации куда серьезнее. Проще говоря, чем больше привилегий внутри контейнера, тем меньше он похож на обычную песочницу.Точки монтирования: что контейнеру видно с хоста 😑
cat /proc/mounts
Такие команды показывают, какие каталоги подключены внутрь контейнера. Если в списке появляются неожиданные пути вроде
/, /etc, /home или другие чувствительные области, это означает, что контейнер видит больше, чем должен. А значит, при ошибке в приложении можно получить доступ уже не только к данным контейнера, но и к важным файлам хоста.Устройства в /dev: лишнее лучше не отдавать 👨💻
Каталог
/dev тоже многое рассказывает о конфигурации. В нормальной ситуации контейнеру не нужен широкий доступ к устройствам хоста. Если их слишком много, это повод задуматься, зачем они были проброшены. Чем больше устройств доступно процессу, тем шире поверхность атаки и тем больше неожиданных способов воздействия на систему.Кто я внутри контейнера 👀
Если процесс работает от имени root, это еще не значит, что контейнер уже «сломался». Но это сильно повышает цену любой ошибки. В таком режиме многие ограничения становятся слабее, а последствия проблем с конфигурацией тяжелее. Если контейнер еще и получил лишние права, риск быстро вырастает до уровня инцидента на всем сервере.
Вывод 🍩
Аудит Docker-контейнера всегда начинайте не с приложения, а с изоляции. Смотрите, есть ли
docker.sock, какие capability выданы процессу, что смонтировано внутрь и какие устройства доступны. Именно эти детали чаще всего и показывают, насколько контейнер действительно защищен.Мануал по контейнерам хотите? Классов накидайте пж 🙂
Подписывайтесь на канал