Как у меня взломали сайт и как я восстановил его за полтора часа

История со взломом началась 15 марта вечером.

Решил я посмотреть почту и почитать всякое на ночь глядя, а в скайпе такое:

Проблемы с доступом, по которые написал коллега, были в прошлом. Он живёт в Европе, и пару раз мы наблюдали разрыв канала или что-то в этом роде, когда я вижу свой сайт, а он нет. Поэтому я совершенно спокойно открыл свой сайт и увидел страницу «Ошибка 404», любезно предложенную моей хостинговой компанией nic.ru.

Сайта нет. По крайней мере очень похоже.

Я пользуюсь хостингом nic.ru и там один вход для управления несколькими сайтами, к которым я имею отношение. Поэтому первое, что нужно было проверить — масштабы бедствия.

Я полез на сайт leanworker.ru — курс «Бережливый рабочий» сейчас идёт и будет малоприятно, если люди утратят доступ к тем материалам, за которые они заплатили.

А там такое:

Весело, думаю, открываю интернет-магазин leanshop.ru, а там то же самое. Всё чудесатее и чудесатее, как говорила Алиса, будучи в Зазеркалье.

Действие первое. Возвращаю себе контроль над сайтом

Если три сайта дохлые — у меня определённо проблема с доступом к хостингу, на котором все они (и не только эти) находятся.

Сначал нужно убедиться, что я сам еще имею доступ к своему хостингу и пароль не сменился. Открываю сайт хостинга, вхожу — входит…

Убедившись, что доступ есть, набираю телефон техподдержки nic.ru. Время 23:09. Объясняю, что меня взломали и я хочу поменять пароли на хостинг, спрашиваю, где в панели управления их найти.

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

Мне подсказывают, что взломать могли по FTP. Я удивлен, поскольку сам FTP после прошлого взлома, который был лет 5 назад, перестал пользоваться, и вроде бы даже должен был прибить доступ к сайту через этот протокол (тогда мне объяснили, что вскрыть FTP проще, чем административную панель хостинга), но проверяю. Есть пользовательский доступ по FTP. Убиваю пользователя FTP со всеми его данными, потом вспоминаю, что на странице смены административного пароля еще какой-то пароль был, так что возвращаюсь обратно.

В 23:15 я еще раз меняю административный пароль на новый (снова приходит уведомление), меняю кроме него технический пароль и выдыхаю. Первое действие спектакля завершено.

Краткое резюме для тех, кто ничего не понял

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

Действие второе. Выясняю, как давно взломан сайт

Сразу после смены паролей я, конечно, полез смотреть, что с файлами сайта. Открываю рабочий каталог сайта wkazarin.ru на хостинге — а там только один index.html и больше ничего.

«Всё, нажитое непосильным трудом…» (с) х/ф «Иван Васильевич меняет профессию»

Ситуация неприятная, но не катастрофическая: хостинг обеспечивает резервное копирование каждый день и неделю хранит бэкапы, кроме того, сайт сам делает свои бэкапы в облаке Amazon Web Services. Так что я иду и радую супругу вестью о том, что у меня взломали сайт и всё удалили.

Возможно, следующее мое действие не самое критичное в этой ситуации, наверное, нужно было сразу «положить» сайт целиком, то есть остановить его работу, а не оставлять в рабочем состоянии, на тот случай, что кто-то воспользуется его ресурсами для рассылки спама или ещё какой порнографии… Но поскольку внешний вид текущего содержимого не вызывал подозрения в том, что сайт сломали с целью спама (я бы ожидал в этом случае десяток страниц с рекламой), то я пошел другим путём. Любопытство заставило меня выяснить, как давно сайт не работает.

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

Открываю страницу, меняю настройки графика на «по часам» и вижу, что начиная с диапазона 20:00-21:00 по Москве на сайте было не более чем по 2 человека в час. До этого посетителей было больше. Так что не далее, чем три часа назад всё было нормально. Может быть, подмена случилась уже после 22:00, что возможно, а может быть эти 2 посетителя были зафиксированы с кэша страниц на каком-то промежуточном сервере. В любом случае, «время смерти» не превышало трех часов, а значит, не так много народу должно было обалдеть от того, что творилось на сайте за это время — после восьми вечера траффик у меня обычно идет на спад, хотя совсем прекращается только часам к трем ночи.

Действие третье. Оставил себе на память

Открываю снова WKazarin.ru, смотрю что там есть более внимательно. И думаю —  а ведь красиво, ёлки-палки…

Запускаю Movavi Video Suite — «Захват видео экрана», открываю сайт и запускаю запись.

Вот что вышло.

К сожалению, на записи нет звук, он тоже вполне хорош.

В 23:22 запись была готова, в 23:25 был готов ролик для просмотра, а я в это время начал проверять, что у меня с бэкапами.

Действие четвертое. Попытка восстановиться своими силами

Небольшое техническое отступление

Сайт сейчас работает на WordPress — это такая открытая бесплатная платформа для управления сайтами, на которую я перевёл сайт с Joomla в 2013 году. Когда я делал перенос, на сайте уже было под тысячу заметок и было понятно, что такая работа не произойдет в один день. Поэтому мне нужен был «игрушечный сайт» на котором бы я создал копию того, что тогда работало на Joomla, а когда всё будет готово — я планировал заменить один вариант сайта на другой.

Для этого нужно было найти способ сделать перенос сайта максимально простым. И способ, который я нашел, называется «плагин к WordPress под названием BackupBuddy».

Главная задача плагина BackupBuddy, как следует из его названия — это резервное копирование. Но когда у вас есть полный бэкап сайта (как обещали авторы плагина — вообще всё, полностью), то его можно ставить с нуля, разворачивать на голом месте и так далее. В том числе — и переносить с одного домена на другой. И для этого в BackupBuddy есть небольшая утилита под названием ImportBuddy. Это один файл, который ты закачиваешь на пустой сайт, туда же закачиваешь бэкап с другого домена, запускешь ImportBuddy, указываешь ему, где взять архив — и вуаля, сайт развернут на новом домене без всяких проблем. Буквально за пару минут.

Я всё это проверил на практике со своим сайтом и убедился, что всё это так и есть. Мне это так понравилось, что я купил лицензию на BackupBuddy для дальнейшего использования, и настроил на WKazarin.ru процесс резервного копирования всего содержания.

С определённой периодичностью копируется только контент (сейчас это около 31 Мб) и чуть реже делается полная копия вообще всего, что есть на сайте (а это уже более 900 МБ), причем все резервные копии уезжают по защищенному каналу в моё облако на сервисе Amazon We Services. Чрезвычайно удобный сервис, и стоит недорого — мне до сих пор обходится менее 2 долларов за месяц, и стоимость считается по использованному объему и траффику, как в тарифах «посекундно».

Восстановление с BackupBuddy

С тех пор, как сайт заработал в новом виде, бэкапбадди регулярно отправлял бэкапы в облако, и за исключением пары коротких периодов, когда отсылка сбоила, он не требовал к себе внимания. Главное — обновлять регулярно сам плагин. Поэтому шансов проверить систему восстановления у меня не было.

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

И когда настал момент «ну всё, теперь я воспользуюсь бэкапом», я полез искать «где скачать importbuddy». Сайт разработчиков плагина — очень грамотный и продуманный, но, видимо, всё-таки легкая степень паники у меня была, т.к. я никак не мог найти нужной страницы для скачивания importbuddy, тыкался то в FAQ, то в документацию, то вообще в гугле набирал «importbuddy.php download», но везде рассказывалось о том, как использовать importbuddy, но нигде — как его скачать. В конце-концов, потеряв минут 10-15 на суетливые поиски, я взялся за них более системно, понял, что в разделе «восстановление» эта процедура начинается с момента, когда у вас уже есть importbuddy, полез изучать описание установки и настройки и тут понял, в чем дело: importbuddy генерируется на самом сайте, его нужно с него скачать и спрятать в укромном месте «на черный день».

А я этого, конечно, не сделал.

То есть, для меня это означало, что я не смогу восстановить резервную копию «на один щелчок пальцев».

Тоска.

Но это не означало, что все резервные копии — мертворожденные. Ничего подобного. Но без importbuddy ими можно воспользоваться только после того, как установишь с чистого листа WordPress и поставишь на него плагин BackupBuddy. И то и другое делается очень быстро, минут за 10-15, но могут возникнуть сложности с настройкой доступа к СУБД — по хорошему мне нужно было бы вспомнить логин и пароль пользователя СУБД, которыми автоматически пользовался прежний WordPress на работавшем сайте.

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

Действие пятое. Восстановление сайта из резервной копии хостинга

Пока я искал importbuddy наступила полночь. Оказывается.

Перед тем, как заняться восстановлением файлов из другой резервной копии я, наконец, делаю себе отдельную копию того, что всё это время висело на сайте. На самом деле — это один файл html длиной 17,5 кб. Можно будет потом поковыряться во внутренностях, может что интересное узнаю, хотя применение турецкого языка (судя по всему) сильно усложняло понимание надписей.

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

Снова захожу на сайт хостинга и звоню в техподдержку. 0:10.

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

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

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

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

Лезу в это место и вижу: два задания на восстановление резервной копии от 0:14, статус «ожидание выполнения».

Ок. В развернутом виде всё, что было на хостинге, занимало около 6 Гб, так что придется подождать. Переключаюсь в другое окно и иду наливать себе чай — дело будет небыстрым.

Пишу коллеге о состоянии дел:

Примерно в это же время пишу сообщение на Facebook о взломе и получаю первые комментарии на это сообщение. Теперь я знаю, кто еще не спит после полуночи… 😉

Через минут 5-7 проверяю статус очереди заданий на сайте хостинга и вижу статус: «Выполнен успешно». У обоих заданий.

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

Вот тут, наверное, наступает последний страшный момент, когда неопытный человек склонен думать «а вдруг не заработает, страааашно…»

Но я открыл браузер и набрал в адресной строке wkazarin.ru и нажал Enter.

Действие шестое. Готово

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

Открываю сайт «Бережливого рабочего». Работает.

Открываю интернет-магазин leanshop.ru. Работает.

В общем, даже не удалось как следует напрячь мозги или вспотеть от усилий…

Делаю скриншот с отметкой времени (часы в нижнем правом углу) на память:

Заключение и выводы

Первое. Две системы резервного копирования всегда лучше чем одна. Помните «Ералаш»? «А на этот случай у меня есть проездной!»

Второе. Даже если система резервного копирования есть, ее надо проверять в действии в условиях, приближённых к боевым. Например, если бы я попытался восстановить сайт из бэкапа с пустого места на другом адресе, я бы знал, что мне нужно заранее скачать importbuddy. Ну и читать инструкции к таким системам лучше ДО того, как что-то случилось, а не ПОСЛЕ.

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

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

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

Шестое. Будет нужда в обеспечении безопасности ваших сайтов на WordPress (а может и не только) — пишите.

Седьмое. Нужна прописанная процедура. Стандартная операционная процедура. И нужно записать и положить в физически безопасном месте пароли.

Кому это может быть интересно

Узнать, кто эти люди…