что делать если взломали сервер

Взломали сервер и вымогали деньги, куда обращаться?

Сегодня около 02:00 по Хабаровскому времени мне в WebMoney Keeper написал некто barbados. Приводить всю переписку я не буду, т.к. она довольно объёмна.

Если говорить в нескольких предложениях, мне сообщили, что на одном из моих сайтов имеется дыра, продемонстрировали, что могут загрузить на сервер любой файл и потребовали 200 WMZ, иначе они и дальше будут ковырять это всё. В итоге, пока я тянул время, им удалось доковыряться до уровня user (установлена ISPManager, благодаря которой они получили доступ ко всем доменным именам и сайтам. После того, как я сказал, что таких денег у меня нет и в ближайшее время не будет, мне быстро ответили, что тогда я могу сказать своему серверу «До свидания», по крайней мере данным на нём и что восстанавливать из бэкапов бесполезно, т.к. они опять расковыряют эту дырку в одном из сайтов. Причём сказали, что если бы я заплатил, сообщили бы все инструкции как исправить такую уязвимость. После этого я выключил сервер и получил от них сообщение наподобие: «Тогда вам придётся всегда держать его выключенным, как только включится, мы исполним то, что обещали».
После того, как я написал, что завтра пойду с заявлением в полицию, мне написали моё ФИО, место жительства и адрес прописки и сказали, что найти меня будет довольно просто (т.е. поступили уже физические угрозы).
Всё это время я держал связь в скайпе с человеком, с которым работаю и нашу переписку они успешно смотрели (как выяснилось позже, они знали мой пароль).
Далее они написали, что могут не трогать сервер, если я выплачу им все имеющееся у меня средства (около 850 рублей).
И тут я совершил, пожалуй, самую большую ошибку. Я заплатил.
После чего мне указали типичные проблемы в безопасности серверов (большей части из которых у меня не было) и после этого ничего не писали.
Быстрая проверка по сайтам выявила несколько iframe и фрагменты обфусцированного кода. Также в логах ISPManager остался IP с которого заходили.

В связи с этим вопрос: Что мне делать? Куда можно обратиться в таком случае? Хостер явно напишет: «Ваши проблемы, разгребайте сами». Всё, что имеется, так это IP-адрес (который может быть и прокси), WMID которому около 1-го года и два кошелька принадлежащих этому WMID.

Источник

Опыт работы со взломанным сервером

Хочу поделиться своим опытом начинающего системного администратора. Так уж случилось, что мой первый блин комом — это было предложение заняться инфраструктурой в одной маленькой компании. Ситуация сложная. Никакой автоматизации, все вручную и по принципу: работает — не трогай, а если не работает и никто не заметил, то считай, что работает. Предыдущий сотрудник не оставил почти никакой документации. Вот доступ к серверам, кофемашина — там, вроде всё…

Опыт первый: маленькие симптомы большой проблемы

Было решено начать с инвентаря. Всё размещено у крупного публичного оператора: по нескольку виртуальных машин на арендованный сервер с предустановленным гипервизором Xen:

Эксперты могут со мной не согласится, но я нахожу KVM гораздо удобнее Xen для элементарной виртуализации инфраструктуры маленьких предприятий. Xen может привлечь тех, кто предпочитает графический интерфейс управления. Но, к сожалению, возможности данного графического интерфейса довольно ограниченны, а интерфейс управления командной строки Xen сильно уступает по своей простоте KVM/QEMU в случае, если надо зайти за рамки стандартных манипуляций виртуальных машин. Но похоже, что данный вопрос не особо волновал моего предшественника, управлявшего системами с наименьшим приложением усилий. Как оказалось, всё было установлено по умолчанию, а именно: сервера работали на устаревшей Ubuntu 12.4 LTS, вместо привычных для таких целей Debian.

В наставники мне определили программиста, заменявшего уволившегося сисадмина. Вместе мы полезли разбираться с диаграммой развертывания хозяйства на серверах предприятия.

Тут следует сказать, что любой сисадмин, в душе, должен быть немного детектив. Нужно уметь замечать малейшие аномалии, за которыми могут скрываться большие проблемы. В данном случае мое внимание привлекли странные файлы с привилегией root. “Наверное нас хакнули”, пожал плечами коллега, не приняв мое беспокойство всерьез. Простых подозрений было недостаточно, и мы решили пока ничего особенного не делать. Архивируем подозрительные файлы, меняем пароль пользователя и продолжаем инвентарь.

Опыт второй: не злите злых хакеров

А если разозлили, то готовьтесь к последствиям.

“Что-то с сервером…”, наверное одно из самых неприятных сообщений, которое может получить системный администратор по пути на работу. Особенно, если речь идёт о новой работе. Ускоряя шаг, проверяем ситуацию с телефона:

Придя на работу, натыкаемся на комитет из взволнованных сотрудников. Ситуация критическая. Сервер недоступен, но доступен его гипервизор через Xen. Становится ясно, что сервер работает, но полностью утеряна связь с Интернет:

Значит, проблема в маршрутизации. Лезем к оператору:

Заодно находим саму проблему:

Ну, теперь уж точно: сомнений нет — нас взломали! И похоже, что взломщик, огорченный нашей предыдущей интервенцией, решил, раз его обнаружили — терять уже нечего и использовал наш сервер для сетевой атаки. Ладно, зато теперь мне разрешат настроить всё по-своему.

Первым делом — файрвол:

Далее, меняем всем пароли:

Сохраняем и трём ключи ssh. Позже попросим всех пользователей генерировать новые. Сохраняем, для сравнения: чтобы особенно ленивые пользователи не могли использовать старый, возможно скомпрометированный доступ:

И, кстати, больше никакого доступа с паролем: только ключи ssh!

Теперь нас никто не застанет врасплох. Устанавливаем слежку за теми, кто входит в систему. Для этого добавляем в /etc/pam.d/sshd исполнение простого скрипта нотификации (loginlog):

А также подглядываем за ключами:

Hу и под конец, можно установить auditd — это демон, способный отслеживать всё, что происходит на сервере. Для этого достаточно двух строк в /etc/audit/audit.rules:

На сегодня всё. Пишем сотрудникам о том, что в городе новый шериф об изменениях по соображениям безопасности. А завтра постараемся внедрить Nagios или даже начать переезд на Debian. Надеюсь, взломщик больше не пройдет. Или пройдет?

Источник

Сервер взломан – что делать

Порой возникают крайне неприятные ситуации, когда вы потратили достаточно много времени на создание своего сайта, его перенос и отладку на VPS, и вдруг однажды обнаружили, что сервер взломан. От этого, к сожалению, никто полностью не застрахован, а причины взлома бывают самые разные. В этой статье мы разберемся, как определить факт взлома сервера, установить его возможные причины и как предотвратить подобную проблему в будущем.

Содержание

Признаки взлома сервера

1. Рассылка спама с VPS в случае получения доступа к нему злоумышленником.

2. Deface сайта — изменение или полное искажение вида главной страницы сайта, размещаемого на виртуальном сервере. Например, вместо привычной главной страницы интернет-магазина появляется реклама сторонних товаров либо же страница, не имеющая ничего общего с основной тематикой вашего сайта (предупреждение, угроза или шутка). Дополнительно доступ к остальным страницам сайта может быть заблокирован или же оригинальный контент удаляется полностью.

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

4. Значительное повышение расхода трафика на сервере.

5. Аномальная сетевая активность.

6. Перебои в работе VPS.

Возможные причины взлома сервера

В большинстве случаев злоумышленники осуществляют взлом через уязвимости программного обеспечения сервера или кода сайта, неправильно настроенные права доступа к файлам, а также если для root-доступа к консоли VPS, доступа к хостинговой панели или административной панели CMS используются ненадежные пароли (например, 12345678, qwerty123 и т.д.).

Среди программного обеспечения уязвимостью обладают устаревшие версии CMS, Apache, PHP, MySQL и т.д. Также сервер потенциально подвержен взлому в случае некорректной конфигурации установленного на нем программного обеспечения.

Опасность для сайтов представляют инъекции, такие как:

Определение последствий и степени взлома, обнаружение уязвимостей

1. Прежде всего, проверьте свой сайт на предмет наличия вирусов. Это можно сделать при помощи специальных онлайн-ресурсов, например:

2. Проверьте файлы, которые изменялись в течение последних 10 дней. Для этого подключитесь к своему VPS по протоколу SSH и выполните команду

Где, site.com — имя домена вашего сайта.

3. Сделайте проверку почтовой очереди на наличие спама. Это делается с помощью команды

Если на VPS установлен почтовый сервер Exim, то у вас есть возможность просмотреть заголовки сообщений в очереди с помощью команды

Просмотр тела сообщения можно выполнить командой

В тексте результата выполнения команды ищите строку X-PHP-Script. Так вы увидите, какой именно скрипт выполняет рассылку сообщений.

В случае использования другого почтового сервера, информацию о рассылке сообщений необходимо проверять в логах (/var/log/maillog).

4. Дополнительно проверьте свой сайт на вирусы с помощью специального скрипта AI-bolit, инструкцию о работе с которым вы найдете здесь revisium.com/ai/

Изучите результаты сканирования, обязательно сохраните резервные копии файлов.

5. Просмотрите, какие файлы находятся во временных и директориях загрузки. Для этого во время SSH-подключения выполните команды:

Где site.com — имя вашего домена.

Если среди результатов поиска будут обнаружены PHP-скрипты, то они с высокой долей вероятности содержат в себе вредоносный код, поскольку во временных директориях их хранение недопустимо.

7. Сделайте проверку VPS на наличие шеллов (shell — специальный программный код, благодаря которому хакер получает доступ к файловой системе взломанного сервера):

И среди файлов с правами доступа 777:

Внимательно изучите полученные результаты и, если среди них будет найден шелл, смело удаляйте его.

8. Проверьте, актуальна ли версия установленной на виртуальном сервере CMS.

Для Joomla: просмотрите файл changelog.txt, расположенный в корне сайта.

Для WordPress: поищите информацию о версии CMS в файле wp-includes/version.php.

Для Drupal: файл changelog.txt в корневом каталоге сайта или файл /modules/system/system.info. Также версию этой CMS можно увидеть в административной панели.

Для 1C-Битрикс: необходимую информацию вы можете найти в файле /bitrix/admin/update_system.php либо /bitrix/modules/main/classes/general/version.php

9. Проверьте какие права доступа установлены для файлов и папок. Использование прав 777 крайне не рекомендуется из соображений безопасности. Каждая папка должна принадлежать определенному пользователю либо группе пользователей. В случае использования mpm_prefork в качестве владельца может быть установлен apache (www, www-data).

Для того, чтобы обнаружить все файлы/папки с правами доступа 777, выполните команду

Менять права доступа к файлу/папке можно при помощи команды, которая имеет следующий формат:

Например, если вы хотите установить права 644 для файла index.php, находящегося в директории /home/user/data/www/site.com/, то необходимо выполнить команду

10. Выясните, когда на VPS были загружены шеллы командой

11. В логах поищите историю обращений к скриптам шеллов:

Среди найденных результатов обратите внимание на IP-адреса, с которых обращались к скрипту. Это поможет найти уязвимость в модулях и скриптах используемой CMS.

12. Просмотрите какие настроены задания cron для root-а и остальных пользователей:

13. Проверьте записи о попытках доступа к VPS в логах. Нас интересуют записи о событиях auth, authpriv в конфигурационных файлах syslog.conf, rsyslog.conf. Информацию об успешных попытках авторизации можно проверить командами:

Если у вас настроен FTP сервер, то нужно дополнительно проверить записи в файле xferlog:

Исполнив вышеуказанную команду, вы обнаружите все файлы, загруженные во время соединения с виртуальным сервером по протоколу FTP.

Если на вашем VPS установлена панель ISPmanager 4, то проверьте также записи файла /usr/local/ispmgr/var/ispmgr.journal командой

14. Изучите запущенные на VPS процессы, просмотрев результат вывода команд top и ps. Подозрения у вас должны вызвать процессы с ошибками в названии или если названия этих процессов сложно прочесть.

Обнаружив посторонние процессы, постарайтесь выяснить, откуда они были запущены. Для этого выполните команду

Где PID — идентификатор процесса.

Когда искомый файл будет найден, просмотрите его атрибуты командой

Найти дополнительную информацию об этом файле вы можете с помощью команды

15. Сделайте проверку сервера на наличие сторонних сетевых соединений, просмотрите номера портов, через которые они были установлены:

16. Обязательно проверьте свой VPS на наличие уязвимого или устаревшего программного обеспечения.

Если у вас на сервере установлена CentOS:

Для проверки измененных файлов выполните команду

Пример вывода команды:

Для анализа результатов вывода руководствуйтесь следующими данными:

Ищите файлы, для которых отличается содержимое MD5. Вам нужно проверить бинарные значения этих пакетов по типу (file) и времени (stat):

Для Debian значения MD5 можно проверить с помощью утилиты debsums. Эта задача реализуется с помощью следующих команд:

Очистка сервера от вредоносного ПО и нежелательных файлов, повышение мер безопасности

1. Сделайте обновление версии CMS сайта, если она устарела. При этом число подключаемых к ней модулей должно быть минимальным.

2. Обновите версию установленной на сервере операционной системы на актуальную.

Для CentOS используйте команду

3. Установите рекомендуемые настройки PHP, отредактировав php.ini:

expose_php=Off — для отключения в заголовках информации о php; sql.safe_mode=On — для активации SQL safe-mode; post_max_size=8M — для установления ограничения на размер передаваемых на сервер данных.

Кроме этого настоятельно рекомендуется включить в disable_functions следующие функции:

Для доменов нужно включить open_basedir. Дополнительно проверяйте настройки локальных php.ini.

4. Поищите неиспользуемые сервисы и отключите их.

Для CentOS это делается командами:

Где service_name — название сервиса, который необходимо отключить.

5. Проанализируйте обнаруженные во время проверки, описанной в предыдущем разделе, вредоносные файлы и скрипты. Если они содержат в себе код @preg_replace («\x40\50\x2e\53\x29\100\x69\145»,»\x65\166\x61\154\x28\142\x61\163\x65\66\x34, то его можно удалить командой

6. В обязательном порядке измените root-пароль, пароль для входа в контрольную панель и админку CMS на более сложный.

7. Проверьте, установлена ли security-update. Выполните ее установку, если требуется.

Или откройте для редактирования файл /etc/apt/sources.list и добавьте в него такую строку

Затем сделайте обновление системы командой

8. Настройте фаервол, например, можно настроить CSF.

9. Регулярно делайте бэкапы. Для этого, например, идеально подходит услуга CDP бэкапов. Это поможет вам сохранить большую часть своих данных в тех случаях, когда единственным вариантом очистки VPS от вирусов и прочего вредоносного ПО будет разворачивание резервной копии файловой системы сервера.

Если у вас возникли вопросы или требуется наша помощь в борьбе с последствиями взлома VPS — смело обращайтесь в нашу службу поддержки!

Источник

Какие действия предпринять, когда компанию атаковали хакеры

Ведущий инженер техподдержки ESET в России и СНГ

В середине марта всемирно известный производитель компьютерной техники Acer подвергся хакерскому нападению группировки REvil: на корпоративный сервер подселили одноименный вирус-вымогатель, который позволил получить доступ к конфиденциальной информации.

Выполнять ли требования вымогателей, надеясь на их «порядочность», или идти на принцип и мириться с потерей конфиденциальных данных — личный выбор владельца бизнеса. Однозначно одно: атака, даже успешная, требует четких и быстрых действий. Каких именно — рассказал Валентин Поляков, ведущий инженер техподдержки ESET в России и СНГ.

Чего следует опасаться

Качество кибератак постоянно растет: преступники совершенствуют свои методы, пишут новые вирусы, находят слабые места в системах защиты. При этом виды угроз, с которыми чаще всего сталкивается бизнес, не меняются.

При фишинговой атаке сотрудники получают письмо с «официального» адреса известной компании, которая обманом заставляет получателей перейти по вредоносной ссылке, чтобы после украсть личную информацию пользователей. Программы в этом случае могут использовать разные.

Одна из самых опасных — вирус-вымогатель, с которым столкнулись уже упомянутые Acer и Apple. Вирус считывает и шифрует данные с серверов компании. Дальше работает сценарий двойного шантажа: сначала хакеры просят выкуп за возобновления доступа к зашифрованным данным, затем шантажируют вероятностью «слива информации».

Так и получилось с чертежами Apple: данные были похищены с сервера тайваньской компании Quanta Computer. Платить Quanta отказалась, поэтому в день презентации нового ноутбука REvil опубликовала в даркнете подробные чертежи устройства. Теперь хакеры ведут переговоры напрямую с Apple и угрожают в случае неуплаты продолжить «слив».

Кстати, история эта еще может иметь продолжение: помимо Apple Quanta Computer сотрудничает с Dell, Amazon, Lenovo и Sony, и вполне вероятно, что и их данные тоже были похищены.

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

По-прежнему используются старые-добрые DDoS-атаки. Существенное замедление работы сайта или даже полная ее остановка несет многомиллионные убытки компаниям, чей бизнес завязан на онлайн-продажах. В этом случае хакеры как могут воспользоваться «падением» сайта для кражи информации, так и требовать выкуп за быстрое возобновление работы.

Что делать, если кибератака состоялась

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

Шаг 1

Выявите и изолируйте зараженные компьютеры от корпоративной сети. Для этого проверьте логи антивирусов (файл с записями о событиях в хронологическом порядке), после чего отключите зараженные машины от сети.

Также обратите внимание на расширения ваших персональных файлов: если они изменились или вместо них появилось множество других с неизвестными именами, то компьютер заражен.

Шаг 2

Постарайтесь определить первоисточник заражения и уязвимость, которую использовали злоумышленники. Чаще всего источником заражения становятся письма со спамом, зараженные съемные носители, установка вместе с другим программным обеспечением и взломанные или скомпрометированные веб-страницы.

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

Выявить причины помогут и специальные организации, которые проводят расследования подобных инцидентов, или — в минимальном объеме — специалисты технической поддержки антивируса, который использовался в компании.

Шаг 3

Обратитесь за помощью в организацию, специализирующуюся на информационной безопасности: компетенции IT-департамента может не хватить, а время будет упущено.

Шаг 4

Примите все возможные меры по устранению уязвимости и усилению защитных мер, проведите аудит безопасности и выявите другие возможные бреши в защите:

Шаг 5

Обратитесь с заявлением в правоохранительные органы, а лучше сразу в подразделение «К» МВД России, борющееся с преступлениями в сфере информационных технологий. В заявлении нужно отметить, что против вас совершено противоправное действие, в котором могут присутствовать признаки преступлений, предусмотренных статьями 159.6, 163, 272, 273 УК РФ.

Будьте готовы к тому, что устройство могут изъять для экспертизы, чтобы обнаружить и зафиксировать следы вредоносной программы. При этом заранее подготовьте основную информацию о том, когда был обнаружен инцидент, кто имел доступ к компьютеру, а также о последнем установленном ПО и истории посещения сайтов. В случае хищения денежных средств подготовьте выписку из банка, детализацию расходов и др.

Платить или не платить?

Если злоумышленники требуют выкуп, оцените, насколько серьезный ущерб нанесен, какие именно данные были скомпрометированы или зашифрованы, какую ценность они представляют. Если речь идет о шифровании важной информации злоумышленниками с последующим требованием выкупа за расшифровку, стоит выяснить, по силам ли антивирусным системам выполнить дешифровку данных без уплаты выкупа и в какие сроки эта работа может быть выполнена.

Узнайте, пострадали ли другие компании от действий той же группы злоумышленников или того же вредоносного ПО. Соберите и проанализируйте все имеющиеся на этот момент кейсы. Нужные данные, как правило, можно найти на тематических форумах, в специализированных СМИ или узнать у специалистов по информационной безопасности. Вполне возможно, что решение уже найдено.

Что касается атак, организованных с использованием методов социальной инженерии, таких как BEC, рецепт тут один: выстроить систему платежей так, чтобы перевод средств мошенникам был максимально затруднен. Например, сделать перечисления возможными, только после согласования несколькими сотрудниками, в том числе руководством после обязательной идентификации.

Атака позади. Выдыхаем?

К сожалению, с кибератаками принцип снаряда и воронки не работает. Наоборот, повторный взлом — распространенный сценарий. Так, известный вирус-вымогатель WannaCry ходил по миру несколькими волнами, атакуя компании по кругу. Россия стала одной из стран, в которой за несколько лет хождения вируса зарегистрировано наибольшее количество пострадавших. В том числе атакам подверглись Сбербанк, «МТС» и «Вымпелком».

Во-первых, любому бизнесу, даже крупному, необходимо время, чтобы полностью восстановить систему безопасности, оптимизировать защиту и найти слабые места. Этим «люфтом» могут воспользоваться уже новые хакеры.

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

Чтобы избежать новых атак, руководствуйтесь тремя основными принципами:

Источник