В некоторых своих предыдущих статьях мы уже рассказывали о бесплатной панели управления Vesta CP. Сегодня утром мы получили тревожную информацию — в панели есть критическая уязвимость, позволяющая злоумышленникам получить доступ к серверу и производить с него DDoS атаки либо рассылать спам, что часто приводит к перерасходу трафика. Известные на текущий момент подробности, а также советы по защите чистого и очистке взломанного сервера, под катом.
Первые уведомления о возможной уязвимости в Vesta 0.9.8-19 появились 7 апреля как в английской, так и в русской ветках форума панели. Симптомы у всех были схожими: резкий рост трафика и паразитической нагрузки на сервер. И по утверждениям людей, обслуживающих множество клиентских серверов, общее у них было только одно — Vesta CP.
Вскоре последовали превентивные меры со стороны отдельных провайдеров — блокировка стандартного порта Весты (8083) на уровне сети провайдера, отключение провинившихся. Тем временем разработчики самой панели пытались связать взломы со своим продуктом. И нельзя сказать, что успешно.
По утверждениям самих разработчиков, им не удалось достоверно установить и воспроизвести вектор атаки, однако они выпустили хотфикс, закрывающий некоторые прорехи, которые могли послужить причиной. А именно, поправили авторизацию и сделали проверку паролей более строгой. Пока что не поступало информации об успешных взломах обновлённой Vesta 0.9.8-20, однако тот факт, что разработчики не смогли достоверно установить сам вектор атаки, держит пользователей в некоторой напряжённости. Ниже мы приводим некоторые рекомендации из сети по предотвращению взлома и по борьбе с последствиями.
Большинство приведённых ниже рекомендаций относятся не только к серверам с Vesta CP, но и к любому другому Linux серверу.
Пятна Последствия от данной атаки устраняются достаточно непросто, потому, если у Вас есть такая возможность, советуем использовать Vanish слить бэкапы (о необходимости их делать мы напоминали не раз) и переустановить сервер. Сложность заключается в том, что Trojan.DDoS_XOR-1 (он же Chinese Chicken Multiplatform DoS botnets Trojan), которым было заражено большинство скомпрометированных машин, очень эффективно самовосстанавливается, и для его удаления нужны определённые танцы с бубном (описаны ниже). Другая сложность — возможна банальная перегрузка сервера паразитическими процессами, что существенно усложнит Вашу работу с сервером вне rescue mode (которого может и не существовать в принципе, если Вы используете VPS).
Если же возможности просто переустановить всё нет, попробуйте проделать следующее.
Если Вы — хостер или сисадмин, и Вам нужно оставить доказательство для клиента, остальные файлы можете пока не трогать. Если нет — удалите все остальные «примороженные» файлы. Также, если Вам не удалось самим определить вредоносные файлы, воспользуйтесь ClamAV или RKHunter и посмотрите их отчёт.
Если у Вас есть дополнительная информация о данной проблеме, пишите в комментариях. Подписывайтесь на наш канал и этот топик, мы также будем следить за развитием событий и публиковать в этой статье важные обновления.
Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас оформив заказ или порекомендовав знакомым, 30% скидка для пользователей Хабра на уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps от $20 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).
Dell R730xd в 2 раза дешевле? Только у нас 2 х Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 ТВ от $249 в Нидерландах и США! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
Первые уведомления о возможной уязвимости в Vesta 0.9.8-19 появились 7 апреля как в английской, так и в русской ветках форума панели. Симптомы у всех были схожими: резкий рост трафика и паразитической нагрузки на сервер. И по утверждениям людей, обслуживающих множество клиентских серверов, общее у них было только одно — Vesta CP.
Вскоре последовали превентивные меры со стороны отдельных провайдеров — блокировка стандартного порта Весты (8083) на уровне сети провайдера, отключение провинившихся. Тем временем разработчики самой панели пытались связать взломы со своим продуктом. И нельзя сказать, что успешно.
По утверждениям самих разработчиков, им не удалось достоверно установить и воспроизвести вектор атаки, однако они выпустили хотфикс, закрывающий некоторые прорехи, которые могли послужить причиной. А именно, поправили авторизацию и сделали проверку паролей более строгой. Пока что не поступало информации об успешных взломах обновлённой Vesta 0.9.8-20, однако тот факт, что разработчики не смогли достоверно установить сам вектор атаки, держит пользователей в некоторой напряжённости. Ниже мы приводим некоторые рекомендации из сети по предотвращению взлома и по борьбе с последствиями.
Что делать, если Ваш сервер ещё не взломали?
Большинство приведённых ниже рекомендаций относятся не только к серверам с Vesta CP, но и к любому другому Linux серверу.
- Первым делом, обновите панель, выполнив команду:
v-update-sys-vesta-all
- Смените в /usr/local/vesta/nginx/conf/nginx.conf стандартный порт 8083 на какой-либо другой по Вашему усмотрению.
- Используйте нестандартный порт SSH. По возможности используйте вход по ключам.
Также желательно отключить вход под root из мира. - Скачайте и запустите Linux Environment Security.
- Скачайте и установите Linux malware detect. После установки запустите первичный анализ системы на уже существующие проблемы: maldet -a / (и проанализируйте отчёт). Если всё в порядке, запустите мониторинг: maldet --monitor /. Не забудьте указать свою электронную почту для получения отчётов в /usr/local/maldet.conf.
- Ещё один очень полезный инструмент, который стоит установить — Config Server Firewall. Внимательно изучите файл конфигурации и обязательно включите отслеживание изменений директорий и файлов.
- Если у Вас не ожидается пользователей, клиентов или посетителей из Китая — заблокируйте его весь на уровне фаервола.
- Установите приложение для мониторинга трафика. Например, ntopng.
А если уже взломали?
Если же возможности просто переустановить всё нет, попробуйте проделать следующее.
- Проверьте, есть ли симптомы заражения Trojan.DDoS_XOR. Проявляется он в выводе top как файл со случайным именем вида H8wuaqwiu, S01wefiouh8 и т.п. либо как системная команда, порой даже не предполагающая длительного исполнения: ls, ifconfig, pwd, ping, awk, telnet…
Второй симптом — наличие .sh файла в папке ежечасного крона. Проверить можно командой ls -la /etc/cron.hourly/. Файл часто называется gcc.sh, cron.sh, но возможны и другие имена. - Посмотрите содержимое .sh файла. Например, командой cat /etc/cron.hourly/gcc.sh. Для файла характерно примерно следующее содержимое:
#!/bin/sh
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/usr/X11R6/bin
for i in `cat /proc/net/dev | grep: | awk -F: {'print $ 1'}`; do ifconfig $ i up & done
cp /lib/libudev.so /lib/libudev.so.6
/lib/libudev.so.6 - Вляпались? Не спешите суетиться, троян восстанавливает свои файлы быстрее, чем вы успеете их все удалить. Но он будет пытаться использовать те же самые имена файлов, так что блокировка должна помочь:
chmod 0 /etc/cron.hourly/gcc.sh; chattr +ia /etc/cron.hourly/gcc.sh; chattr + i /etc/crontab
- И процесс полностью убивать тоже бесполезно, рекомендуется сначала его остановить,
чтобы троян не пытался его перезапустить. В выводе команды top найдите процесс, вызвавший подозрение (к примеру, S01wefiouh8), и выполните:
kill -STOP 16621
- Найдите исполняемые файлы и заблокируйте их. Для поиска используйте команду find /etc -name '* S01wefiouh8 *'. Для найденных файлов выполните chmod 0 /имя/файла; chattr +ia /имя/файла.
- Удалите исполняемые файлы, найденные в /usr/bin (с помощью ls -lt /usr/bin | head можете поискать другие, вызывающие подозрение):
rm -f /usr/bin/S01wefiouh8
- Теперь можно добить остановленный процесс:
pkill mtyxkeaofa
- И наконец, удалите тело вируса:
rm -f /lib/libudev*.so
Если Вы — хостер или сисадмин, и Вам нужно оставить доказательство для клиента, остальные файлы можете пока не трогать. Если нет — удалите все остальные «примороженные» файлы. Также, если Вам не удалось самим определить вредоносные файлы, воспользуйтесь ClamAV или RKHunter и посмотрите их отчёт.
Если у Вас есть дополнительная информация о данной проблеме, пишите в комментариях. Подписывайтесь на наш канал и этот топик, мы также будем следить за развитием событий и публиковать в этой статье важные обновления.
Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас оформив заказ или порекомендовав знакомым, 30% скидка для пользователей Хабра на уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps от $20 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).
Dell R730xd в 2 раза дешевле? Только у нас 2 х Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 ТВ от $249 в Нидерландах и США! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
acyp
Правильно ли я понял, что ограничив доступ на VPS в панель по IP, я тем самым предотвратил возможность использования уязвимости?
alex_connor
Не обязательно, так как были случаи, когда пользователи разрешали доступ только для их IP, либо вовсе закрывали порт 8083, и все равно были взломаны. Боюсь панель тут может быть ни при чем…
acyp
Т.е. дело не в VestaSP? Тогда только shh::non_root, но это тоже реализовано. Не святым же духом проникают на сервера?
alex_connor
Точно сказать пока сложно, нужно больше времени для тестов и исследований
scorp13
Судя по некоторым сообщениям с форума
этого может быть недостаточно.