Комментарии 11
Чтобы запретить использовать cron пользователю confluence - достаточно указать этого пользователя в файле /etc/cron.deny.
Убить процессы отправкой сигнала KILL вы не сможете, так как со временем они запустятся снова.
Сложности перевода похоже сказываются... Убить-то никто не помешает, малварь не под модулем ядра работает. А то что запустится снова - факт.
В статье нет расследования как малварь проникла на сервер. Что явилось причиной?
Нарочно или по незнанию автор упустил один важный пункт - свежую уязвимость в confluence, которую активно используют. Так что даже если малварь будет вычищена, а контейнер развернут заново с той же уязвимой версией confluence, малварь снова вернётся.
Запрет на cron файл пользователя вообще крайне поверхностное решение, ведь из первого что приходит в голову - всегда можно планировать задания в at, особенно учитывая то что в некоторых дистрибутивов (RHEL/CentOS) - atd запущен по умолчанию
Причиной распространения малвари являются службы, которые доступные извне и конечно же уязвимости в ПО. Например, разработчик случайно пробросил порт в Docker с опцией -p 5432:5432 для контейнера postgre с кредами по умолчанию или последняя уязвимость в Confluence позволяющая злоумышленику удаленно выполнять произвольный код на сервере. Следует отметить, что малварь использует различные IP-адреса для подключения "агентов", а также различные порты в случае, если вы решите заблокировать обращения по адресу или порту. Например, в контейнере я заблокировал весь исходящий трафик на порты 80/tcp и 5555/tcp, чтобы остановить работу майнера. В случае с Confluence, достаточно аттрибута immutable для крона пользователя confluence это не даст процессу малвари запуститься снова и можно будет спокойно накатить хотфикс: https://github.com/httpvoid/writeups/blob/main/Confluence-RCE.md
Как работает малварь Kinsing? Я думаю этот вопрос заслуживает отдельной статьи.
Причиной распространения малвари являются службы, которые доступные извне
Тогда продолжая ваши рассуждения - причиной будет наличие подключения к интернету.
Для установки iptstate в RHEL, введите команду:
yum install iptstate -y
Для просмотра исходящих соединений достаточно стандартных для RHEL netstat, ss.
Поиск ID контейнера:
docker ps
Зачем? Если нет расследования, почему бы не выключить скомпрометированный контейнер ?
Тэг "Информационная безопасность" тут кажется лишним.
Для просмотра исходящих соединений достаточно стандартных для RHEL netstat, ss.
На хосте докера вы не сможете увидеть соединения контейнеров с netstat или ss, так как соединения проходят через цепочку FORWARD в виртуальную сеть докера, а не на сам узел (цепочки INPUT и OUTPUT). А устанавливать на каждый контейнер пакет с net-tools или собирать кастомный образ не особо хочеться.
Зачем? Если нет расследования, почему бы не выключить скомпрометированный контейнер ?
И остановить работу бизнеса)
И остановить работу бизнеса)
Если нет резервирования, то о какой бесперебойной работе может идти речь?
А действительно ли остановка confluence критична для бизнеса?
На какой промежуток времени остановка сервиса критична?
по итогу - необходимо не ограничиваться установкой флага immutable для файла cron пользователя, а делать следующее если для бизнеса это действительно сервис с критичными данными:
- останавливать/изолировать контейнер.
- уносить его для анализа.
- разворачивать и резервной копии.
На хосте докера вы не сможете увидеть соединения контейнеров с netstat или ss, так как соединения проходят через цепочку FORWARD в виртуальную сеть докера, а не на сам узел (цепочки INPUT и OUTPUT). А устанавливать на каждый контейнер пакет с net-tools или собирать кастомный образ не особо хочеться.
имея доступ к хостовой системе на которой крутятся docker контейнеры есть куча возможностей:
nsenter -t $(docker inspect -f '{{.State.Pid}}' container_name_or_id) -n netstatip -all netns exec ss -p -utip -all netns exec netstat -ltup
Если вам удобно выполнять процедуру непосредственно в самом контейнере - ваше право. Но скомпрометированный контейнер уже никогда не вернёт доверия и спокойствия, если не будет отправлен на покой после анализа.
И снова не стоит забывать про резервное копирование.
В статье нет расследования как малварь проникла на сервер. Что явилось причиной?
Кажется в прошлом году один сервак к которому у меня есть доступ её подцепил. Проникновение было через дырку в laravel Ignition при включенном дебаге.
Да, вот это и есть проблема. Я подцепил непонятно где этот dbused. Вот только у меня на сервере (Ubuntu 20) никогда не было confluence. Этот майнер работал от имени www-data. Значит есть где-то дырка или в апаче или в каком-то сайте под ним. Сам майнер я прибил. Но причину так и не выявил. Также хочу упомянуть, что в куче с ним работает /tmp/bashirc и некий процесс linuxsys.
Боремся с майнером Kinsing на зараженных серверах Linux