В некоторых своих предыдущих статьях мы уже рассказывали о бесплатной панели управления Vesta CP. Сегодня утром мы получили тревожную информацию — в панели есть критическая уязвимость, позволяющая злоумышленникам получить доступ к серверу и производить с него DDoS атаки либо рассылать спам, что часто приводит к перерасходу трафика. Известные на текущий момент подробности, а также советы по защите чистого и очистке взломанного сервера, под катом.



Первые уведомления о возможной уязвимости в 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.

А если уже взломали?


Пятна Последствия от данной атаки устраняются достаточно непросто, потому, если у Вас есть такая возможность, советуем использовать Vanish слить бэкапы (о необходимости их делать мы напоминали не раз) и переустановить сервер. Сложность заключается в том, что Trojan.DDoS_XOR-1 (он же Chinese Chicken Multiplatform DoS botnets Trojan), которым было заражено большинство скомпрометированных машин, очень эффективно самовосстанавливается, и для его удаления нужны определённые танцы с бубном (описаны ниже). Другая сложность — возможна банальная перегрузка сервера паразитическими процессами, что существенно усложнит Вашу работу с сервером вне rescue mode (которого может и не существовать в принципе, если Вы используете VPS).

Если же возможности просто переустановить всё нет, попробуйте проделать следующее.

  1. Проверьте, есть ли симптомы заражения Trojan.DDoS_XOR. Проявляется он в выводе top как файл со случайным именем вида H8wuaqwiu, S01wefiouh8 и т.п. либо как системная команда, порой даже не предполагающая длительного исполнения: ls, ifconfig, pwd, ping, awk, telnet…

    Второй симптом — наличие .sh файла в папке ежечасного крона. Проверить можно командой ls -la /etc/cron.hourly/. Файл часто называется gcc.sh, cron.sh, но возможны и другие имена.
  2. Посмотрите содержимое .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
  3. Вляпались? Не спешите суетиться, троян восстанавливает свои файлы быстрее, чем вы успеете их все удалить. Но он будет пытаться использовать те же самые имена файлов, так что блокировка должна помочь:

    chmod 0 /etc/cron.hourly/gcc.sh; chattr +ia /etc/cron.hourly/gcc.sh;  chattr + i /etc/crontab
  4. И процесс полностью убивать тоже бесполезно, рекомендуется сначала его остановить,
    чтобы троян не пытался его перезапустить. В выводе команды top найдите процесс, вызвавший подозрение (к примеру, S01wefiouh8), и выполните:

    kill -STOP 16621
  5. Найдите исполняемые файлы и заблокируйте их. Для поиска используйте команду find /etc -name '* S01wefiouh8 *'. Для найденных файлов выполните chmod 0 /имя/файла; chattr +ia /имя/файла.
  6. Удалите исполняемые файлы, найденные в /usr/bin (с помощью ls -lt /usr/bin | head можете поискать другие, вызывающие подозрение):

    rm -f /usr/bin/S01wefiouh8
  7. Теперь можно добить остановленный процесс:

    pkill mtyxkeaofa
  8. И наконец, удалите тело вируса:

    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 евро за копейки?

Комментарии (5)


  1. acyp
    12.04.2018 09:04

    Правильно ли я понял, что ограничив доступ на VPS в панель по IP, я тем самым предотвратил возможность использования уязвимости?


    1. alex_connor
      12.04.2018 10:21

      Не обязательно, так как были случаи, когда пользователи разрешали доступ только для их IP, либо вовсе закрывали порт 8083, и все равно были взломаны. Боюсь панель тут может быть ни при чем…


      1. acyp
        12.04.2018 10:49

        Т.е. дело не в VestaSP? Тогда только shh::non_root, но это тоже реализовано. Не святым же духом проникают на сервера?


        1. alex_connor
          12.04.2018 10:54

          Точно сказать пока сложно, нужно больше времени для тестов и исследований


    1. scorp13
      12.04.2018 11:23

      Судя по некоторым сообщениям с форума

      i got hacked on debian 9 with blocked port 8083 -> only available to my ip via iptables
      этого может быть недостаточно.