Рассказывая про зомби-эпидемию в контейнеризированных средах, мы советовали не выставлять открытый Docker API в Интернет, а также вести проактивный поиск угроз в контейнерных инфраструктурах.

С первым советом всё понятно. А вот второй может оказаться непростой задачей, поскольку многие компании не обеспечивают полноценной видимости работающих контейнеров. В таких средах сложно отличить процессы, запущенные внутри контейнера, от тех, что выполняются непосредственно на хосте. Это мешает отследить вредоносную активность.

Однако наши эксперты знают, как найти точку начала атаки на основе анализа логов хоста. Вот некоторые принципы:

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

— Аргументы командной строки родительского процесса (shim или runc) позволяют определить целевой контейнер, в котором запущен подозрительный процесс.

— Определённые события, которые являются нормальным поведением в среде Linux, должны вызывать подозрение, если они выполняются внутри работающего контейнера. Так, установка Docker CLI может быть приемлемой для хоста, но не для контейнера.

— Необходимо внимательно расследовать случаи появления нестандартного для данной ОС процесса оболочки. Например, запуск процесса оболочки BusyBox был бы нетипичным в системе Debian или RedHat.

Подробности и боевые примеры — в новой статье Амжеда Ваги.