Что делать после того, как Ваш сайт взломали?

Active SecurityX
Добрый день!
Многие сталкивались с ситуацией, когда сайт подвергся хакерской атаке.
В этой заметке мы попробуем разобраться с последовательностью действий после взлома.

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

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

Очевидно, что произошел инцидент, и его необходимо исследовать.
Я бы разделил действия на 2 части:
1) Неотложные
2) Плановые

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


1.1. Выяснить масштабы взлома
Вариаций этого пункта может быть множество, во-первых откуда Вы узнали, что сайт взломали?
Также хотелось бы указать несколько вариантов мотивации взломщика для взлома Вашего ресурса:
a) Целенаправленный взлом
Взлом может быть с разными мотивами:
— кража конфиденциальных паролей, таких как email, пароли, данные кредитных карт и т.п.
— обход ограничений с целью получения каких либо привелегий в корыстных целях. Например пополнение игрового баланса в онлайн-играх, зачисление на счет денег на купонных сайтах, и интернет-магазинах, накрутка рейтинга на блогах и форумах и т.п.
— взлом сайта с целью получения контроля над соседним сайтом. Такая практика часто используется.
К примеру необходимо получить доступ к сайту aaa.kz, на одном с сервером с которым находится сайт bbb.kz. На сайте aaa.kz отсутствуют видимые уязвимости, тогда взламывают сайт bbb.kz, и получив доступ к нему, обходят серверные ограничения и получают доступ к целевому сайту.
— другие цели. Мотивов взлома огромное количество, я привел лишь некоторые для наглядности. Вполне возможно, что Вы не заняли денег на опохмел соседу, и он из-за злости взломал Вас :)
b) Массовый взлом однотипных ресурсов
Из названия понятно. К примеру выходит 0day эксплоит для Вашей CMS, и школохакеры начинают массово взламывать все сайты, которые только найдут.

1.2. Проверить, имеет ли взломщик доступ в систему на данный момент
Следующим пунктом обязательно следует проверить, есть ли доступ у взломщика в данный момент.
Для этого существует множество способов, например посмотреть, пишутся ли до сих пор логи с его IP адресом, есть ли подозрительные процессы (команда ps ax), залогинен ли еще кто-либо в систему (команда w) и т.п.
К слову сказать, приведенные выше примеры легко обходятся, но в основном взломщики народ не особо дисциплинированный, и наследить могут сильно.

1.3. Сделать полный бекап взломанной системы (клонировать виртуальную машину/Скопировать все файлы, в том числе и измененные)
Еще один немаловажный пункт. Не спешите удалять всё инородное с сервера, все файлы залитые взломщиком, все изменения, внесенные им — понадобятся.
Сделайте резервную копию, и только потом переходите к следующему пункту.
1.4. По возможности устранить последствия взлома
По возможности необходимо найти и устранить все последствия, как то — веб-шеллы, бекдоры, зараженные файлы, измененные файлы конфигурации и т.п.
1.5. Попытаться восстановить картину взлома
Далее необходимо понять, как действовал взломщик, это позволит обнаружить уязвимость, через которую он проник.
В этом нам помогут лог-файлы, и косвенные признаки.
В лог файлах веб-сервера можно увидеть какие запросы посылал взломщик серверу, например sql-инъекции в GET. В лог файлах системы можно найти попытки авторизации по ssh и т.д.
Чем больше информации в логах, тем лучше для Вас.

2. Действия, которые необходимо выполнить планово, дабы избежать инцидентов в дальнейшем.


2.1. Сменить все пароли, используемые в системе — пароли от административной панели, от ftp, MySQL, панели управления и т.п.
Естественно необходимо сменить все пароли в системе на новые, возможно не было прямой уязвимости в системе, а злоумышленник просто перехватил вашу сессию, или пароль.
Я бы также посоветовал сменить пароли на электронную почту, доступы с которой оформлены в системе — почту, на которую регистрировался домен, хостинг, административная учетная запись в CMS.

2.2. Если Вы используете публичную CMS — проверить наличие обновлений движка, плагинов и дополнений
Зачастую происходят взломы в паблик CMS — Joomla, WP, DLE и т.п.
Как правило (но не всегда), авторы CMS после публикации эксплоита публикуют заплатку. Необходимо найти обновления для всех элементов CMS и обновить её.

2.3. Если Вы используете свой выделенный сервер/VDS то необходимо обновить все пакеты, в особенности те, которые могут иметь отношение к взлому — ftp-сервер, СУБД, веб-сервер, ssh-сервер, различные панели управления.
После взлома необходимо обновить библиотеки и софт на сервере, периодически выходят эксплойты под разные сервисы, многие из которых позволяют поднять привелегии в системе. Производители софта обычно быстро выпускают патчи. Следите за актуальностью установленного софта.
2.4 Разобраться в инциденте
Этот пункт является продолжением пункта 1.5..
Когда проведены мероприятия по устранению последствий взлома необходимо вдумчиво восстановить картину взлома, выяснить мотивы проникновения, оценить ущерб.
Лучше доверить это специалистам, которые смогут квалифицированно провести все мероприятия.

2.5. Устранить уязвимости в системе.
Наконец необходимо устранить все уязвимости, для этого необходимо провести аудит web-сервисов и аудит web-сервера.
Важно провести аудит еще по той причине, что взломщики в основном действуют только по принципу «black box», «черный ящик», т.е. извне. А аудит проводится также по исходным кодам сервиса, что позволяет найти и устранить большее количество уязвимостей, которые тяжело определить при пентесте.
Этот пункт, также, как и предыдущий, лучше доверить специалистам, которые специализируются на аудите, и владеют необходимыми знаниями.

Вывод

Помните, безопасности много не бывает, нужно всегда быть готовым к тому, что рано или поздно Ваш сайт попытаются взломать. Последствия могут самыми различными. Вплоть до краха бизнеса.
Я люблю приводить в пример сайты банков.
Вот представьте себе ситуацию, Вы — крупный бизнесмен, держите свои миллиарды в банке «BankName», и в один прекрасный день обнаруживаете на его сайте примерно такую картину:
Hacked by Turkey
Подрывает доверие к такой компании, не так ли?) Я бы забрал свои миллиарды из этого банка и навсегда забыл о нем.

Но, никто не застрахован на 100% от взломов, и если всё таки Ваш ресурс взломали, то не паникуйте и проводите все мероприятия вдумчиво. А еще лучше, если этим займется специализированная компания.
Будьте в курсе последних новостей в сфере ИБ, и держите руку на пульсе.

И самое главное, помните — безопасность превыше всего.

18 комментариев

twost
Получилась вот такая простенькая заметка.
Буду рад вопросам и дополнениям.
Denisc
Клиенты обычно делают так:

1. На сайте что-то повесили или начали с сайта рассылать спам.

2. Восстановили с бекапа или удалили файлы, которые были найдены техподдержкой.

3. Все работает некоторое время и повторяется.

Советы все полезные, как для клиентов, так и для хостинг компаний, но можно еще дополнить или разделить для разных клиентов.

Виртуальный хостинг — ничего нельзя проверить со стороны софта, только версии. Разбираетесь с Вашей CMS

VPS хостинг и Выделенные сервера — можно проверить все-все-все.
twost
Абсолютно согласен!
В этом то и ошибка владельцев сайтов, не разобравшись удалять файлы и восстанавливать из бекапа нельзя!

Как минимум нужно разобраться где были внесены изменения, и главное — когда.

К тому же, взломщики не всегда оставляют следы в виде отдельных php файлов, т.н. веб-шеллов, а очень часто делают бекдоры — скрытые «лазейки» в исходном коде, которые могут оставаться незамеченными годами.
Denisc
Про взломы, которые могут висеть годами нужно написать отдельно — храните свою копию сайта на своем компьютере или в архиве на каком-то сервисе, пусть будет тот же dropbox.

Проходят месяцы, чистые бекапы перезаписываются бекапами со взломом и чистой копии уже нет.
Arik
К тому же, взломщики не всегда оставляют следы в виде отдельных php файлов, т.н. веб-шеллов, а очень часто делают бекдоры — скрытые «лазейки» в исходном коде, которые могут оставаться незамеченными годами.

Используем mercurial, который в одну команду может сказать какие файлы изменили. Если потратить вечер, так вообще можно будет узнать сразу когда на сервере что-то начали делать.
twost
Это хорошо, но тоже не панацея)
К примеру, Вы будете поднимать тревогу, когда изменится файл /tmp/sess_ce1f6ab6ae5088dd3bdda70ebdcd64d5 например?
Arik
конечно нет. Мы сейчас говорим только об исходниках сайта, польз. файлы и т.д. лежать в отдельных папках, которые в исключении меркуриал. Сейчас лишь говорю, что у исходников сайта есть какой то снимок, проверив который можно сразу понять, что кто-то правил исходники сайта. Я писал это к посту в котором говорили что изменения могут оставаться незамеченными очень долгое время.
Denisc
Для чего еще могут быть взломы:

1. Атаки на другие сервера. В начале года массово ломали жумлы с плагинами для выполнения атак на банкофамерика

2. Рассылка спама — много и часто
Denisc
Отправляем клиентам такой текст:

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

— регулярная смена паролей доступа к системе управления (в частности, после увольнения сотрудников, имевших доступ к сайту);

— запрет на хранение паролей на компьютере, подключенном к сети Интернет;

— разделение прав доступа сотрудников, работающих с сайтом (например, редактор контента сайта имеет доступ только к редактированию контента, но не других разделов сайта;

— обновление версий антивирусных программ, CMS, модулей и т.д.;

— ограничение физического доступа к компьютерам сотрудников, имеющих полномочия по управлению сайтом.

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

Устранять уязвимости он не умеет.
Что он делает дальше? Он обращается к хостеру — «Я ВАМ ДЕНЬГИ ПЛАЧУ КАЖДЫЙ МЕСЯЦ, ДЕЛАЙТЕ МНЕ ВСЁ!11» Естественно, хостер тут помочь не в силах.

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

В итоге так и получается, что сайты ломают, а ответить за это некому, и соответственно устранить тоже. А платить деньги дополнительно за безопасность многие пока не готовы.
yakooobin
уже многие готовы
выходи на рынок дядя Саша
twost
Выхожу, сейчас подготавливаю материалы, скоро отдам на Ваш суд, дядя Андрей.
summerwind
В итоге так и получается, что сайты ломают, а ответить за это некому, и соответственно устранить тоже. А платить деньги дополнительно за безопасность многие пока не готовы.
Справедливости ради стоит отметить, что ответить есть кому, если после разработки сайта заказчик заключает с веб-студией договор о тех. поддержке, которая помимо прочего включает в себя регулярный мониторинг работоспособности сайта и оперативное исправление вот таких вот ошибок, связанных со взломами, вирусами и подобными вещами. Но многие просто не хотят регулярно платить «за какой-то там мониторинг» до последнего, пока жареный петух не клюнет. Почему-то думают, что если один раз заплатили за разработку сайта, то потом любые проблемы будут решаться сами собой или бесплатно веб-студией.
Claus
Написано прям как сам думал, но писать самому было влом )
Большая часть веб-разработчиков, не думает о безопасности, что уж говорить про заказчиков…
После массового дефейса тупо восстанавливают копию и мысль не проскакивает, что кто то может повторно зайти через ту же дверь и сделать повторный дефейс…
Благодарю за пост!
bsl_zcs
Меня смущает фраза «По возможности устранить последствия взлома».

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

Если всё совсем плохо и у них были права рута, то они вполне могли поставить злобный руткит, который кроме как в другой системе (например, загрузкой с live cd) ни вычистить, ни просто обнаружить не удастся. Даже если имеется возможность получить полный список изменений, которые были в системе произведены, по каждому из них придётся принимать решение в условиях нехватки данных. Надо понимать, что уязвимости – это, как правило, проявления ошибок, а в глюках нет логики. Несколько совершенно безобидных изменений (типа изменённого бита в правах на какой-нибудь глубоко закопанный каталог) по отдельности или вместе могут обеспечивать хулиганам возможность вернуться в любой момент.

На новом разделе ставится операционка, инсталлируются распоследние свежепатченные версии всех пакетов, чистая сборка своего софта, параноидально закручиваются все гайки, старый раздел монтируется в подкаталог в readonly и с noexec, оттуда, просматривая всё глазами, копируются конфиги и данные, там же ведётся детальный анализ инцидента. Потом гайки с матом дозакручиваются. :)

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

Одно из неотложных мероприятий – попытаться определить от кого ушёл доступ.

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

Потом принудительно проверить всех на вирусы – масса троянов крадёт пароли из браузеров/фаров/тоталкоммандеров, не редкость когда от какого-нибудь «вебмастера» разом уходит доступ к ресурсам всей его клиентуры.

Потом с пристрастием допросить каждого на предмет того как доступ производится – тут уже может быть всё что угодно. Например, даже вполне прокачанные в плане паранойи разработчики иногда наступают на грабли с доступом по незащищённому каналу: какой-нить вайфай неизвестного происхождения, или вовремя не отключенный способ добираться за спеками на заботливо закрытый нашими властями сайт w3c, найденный по запросу «vpn халява». :)
twost
Хороший комментарий, спасибо!
muynak
Всем привет что делать ПРОВЕРЯЕТ, МОЖНО ЛИ ВЗЛОМАТЬ ВАШ САЙТ И
ПРОВОДИТ АУДИТ КАЖДЫЙ ДЕНЬ не кто не знает а я знаю знайте почему потому что я нашел сайт просто супер metascan.ru/ заходите узнаете много интересных задания
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.