Привет, Хабрахабр! Сегодня в рамках кампании #nohacked мы хотели бы поговорить о том, как решить проблему с несанкционированным внедрением контента на сайт. Даже если вы не подвергались такой атаке, не пренебрегайте нашими рекомендациями – они помогут защитить ваш ресурс и от других методов взлома. Следите за обсуждением в Twitter и Google+ с помощью хештега #nohacked (см. часть 1, часть 2, часть 3, часть 4).
Взломы бывают совершенно разные. Кто-то просто хулиганит и «дефейсит» сайт (постит на нём провокативную или оскорбительную информацию, портит вёрстку, превращает сайт крупной корпорации в самый дорогой в мире фанклуб My Little Pony). Зачастую, повреждения такого типа лечатся восстановлением последнего бэкапа и удалением всей неугодной информации, правда, без последующего аудита безопасности сайта никто не застрахован от повторения такого безобразия.
Куда опаснее, когда взлом сайта сопровождается кражей данных, подменом информации или осуществляется с целью распространения всяких зловредов. В таком случае самое важное — оградить потенциальных посетителей (пользователей или клиентов) от общения с подобным контентом.
Первое и основное, что требуется сделать — «закрыть» сайт на ремонт. Здесь мы руководствуемся только соображениями безопасности: в метро при ремонте эскалатора вход на него перекрывают? Вот и сайт мы временно закроем. Пользователи не смогут попасть на взломанные страницы, а вы сможете спокойно работать над восстановлением сайта.
Кроме того, если взлом осуществлялся через одну из «дырок» в рабочих файлах, если не закрывать сайт на техническое обслуживание вы рискуете снова столкнуться с вмешательством хакеров, пока будете устранять последствия взлома.
Самое простое восстановление — найти последний backup и развернуть его. К сожалению, бэкапы точно так же могут потереть злоумышленники, или бэкапы могут касаться только контентной части, или… да миллион или. В общем, если волшебное решение в одну кнопку «восстановить» нам не в силах помочь, придётся всё делать самостоятельно.
Конечно, мы все знаем, что перед началом работ стоит сделать бэкап всего, чего только можно. Но статью могут перепостить куда-нибудь ещё, так что напомнить будет не лишним. Да, новая (и на этот раз полная) резервная копия будет содержать взломанный контент, поэтому воспользоваться ею можно будет только в том случае, если в процессе восстановления рабочей версии вы что-то сделаете не так и сайт сломается окончательно. При выполнении дальнейших инструкций обязательно делайте копию каждого файла, который будете удалять, мало ли что? Удалить копии всегда успеете.
Один из самых поплуярных способов взлома: хакеры создают или меняют содержимое файла .htaccess, чтобы добавить собственные страницы или перенаправить пользоватлей на фишинговый сайт-клон.
Проверьте, нет ли в файле .htaccess подозрительных строк. Если вы не знаете, как анализировать его содержание, прочитайте соответствующие материалы на сайте Apache.org, задайте вопросы на справочном форуме или проконсультируйтесь со специалистом. Пример измененного злоумышленниками файла .htaccess:
#Посетители, переходящие на сайт из Поиска Google, будут перенаправлены
#Посетителей перенаправляют на зловредный PHP-файл happypuppy.php
Удалите все обнаруженные элементы вредоносного кода. Если в файле .htaccess их очень много — проще будет создать новый .htaccess, чем чинить имеющийся. Также может оказаться, что он содержит вредоносный файл PHP (мы назвали его happypuppy.php, но нередко в таких названиях используется случайная комбинация двух слов). Это важно учитывать при поиске остальных вредоносных файлов.
Чаще всего хакеры работают с файлами JavaScript и PHP. При этом используются два основных метода: добавление вредоносных файлов и модификация имеющихся. В первом случае на сервер добавляются новые файлы .php или .js, а их названия могут быть очень похожи на стандартные имена, например wp-cache.php маскируется под безопасный файл wp_cache.php. Второй вариант предусматривает, что вредоносный контент добавляется в уже существующие на сервере файлы. Например, если на вашем сайте есть шаблоны или плагины JavaScript, хакеры могут изменить их код.
Разберем пример. В одну из папок на сайте www.example.com был добавлен вредоносный файл happypuppy.php, ранее обнаруженный в файле .htaccess. Помимо этого, хакеры внедрили вредоносный код в файл JavaScript с именем json2.min.js, уже существующий на сервере. На скриншоте ниже этот код, добавленный в самый конец файла, выделен красным. В итоге содержание файла будет выглядеть так:
Чтобы эффективно выявлять вредоносный код, необходимо понимать, как на сайте используются файлы JavaScript и PHP. Если вы занимаетесь вёрсткой, дизайном, контентом или администрированием портала, но не заглядывали «под капот», возможно, вам потребуется изучить документацию по системе управления контентом.
Кроме того, найдите и проверьте на сайте все файлы, которые недавно были изменены, особенно если они относятся к шаблонам. В разделе «Приложение» перечислены инструменты, которые помогут вам обнаружить замаскированные файлы PHP.
Как упоминалось ранее, перед удалением или изменением каких-либо файлов необходимо создавать резервные копии сайта. А если вы делаете это регулярно, то для устранения проблем на сайте достаточно будет восстановить его архивную версию, которая предшествовала взлому.
Но даже если вы не делаете резервные копии, вам доступны другие решения. Во-первых, удалите добавленный хакерами вредоносный контент. Например, на сайте www.example.com это будет файл happypuppy.php. Если же злоумышленник изменил существующие файлы PHP и JavaScript, такие как json2.min.js, загрузите их безопасные версии. Попробуйте заново добавить на сайт ключевые файлы плагинов и системы управления контентом, если вы ее используете.
После удаления вредоносного файла нужно найти и устранить уязвимость, которая привела к взлому сайта, иначе он может подвергнуться повторной хакерской атаке. Это может быть что угодно – от украденного пароля до устаревшего ПО сайта. О том, как найти и исправить уязвимость, читайте в нашем Справочном центре. Если вы не можете понять, как был осуществлен взлом, смените все пароли, полностью обновите ПО на сайте и по возможности обратитесь к специалистам.
Устранив проблемный контент, убедитесь, что робот Googlebot больше не видит взломанные страницы. Используйте для этого инструмент «Просмотреть как Googlebot». Не забудьте проверить на наличие взломанного контента и главную страницу. Если ничего не найдено, значит у вас все в порядке. Если «Просмотреть как Googlebot» по-прежнему находит взломанный контент, вам есть над чем поработать. Вероятно, вы пропустили какой-либо вредоносный файл PHP или JavaScript. Продолжайте поиски.
Прежде чем снова запускать сайт, убедитесь в том, что устранили все уязвимости и последствия взлома. Если в отношении вашего ресурса действуют меры, принятые вручную, войдите в свой аккаунт Search Console и отправьте запрос на повторную проверку. Также продумайте, как защитить сайт от новых атак. Несколько советов на эту тему можно найти в нашем Справочном центре.
Конечно, часть советов кажутся достаточно очевидными, но все мы сильны задним умом, а столкнувшись с подобным впервые можно и дров наломать. Надеемся, что эта статья поможет вам устранить последствия несанкционированного внедрения контента на сайт. Ищите нас в социальных сетях по хештегу #nohacked и не забывайте делиться своим личным опытом и приёмами безопасной работы в Интернете.
Если у вас остались вопросы, их можно задать на справочном форуме для веб-мастеров и в нашем сообществе на Google+. А ещё можно посмотреть запись нашей видеовстречи по вопросам безопасности от 27 августа.
Существуют инструменты, к которым Google не имеет прямого отношения, однако они могут вам пригодиться.
Например, утилиты для деобфускации PHP Decoder и UnPHP. Злоумышленник может исказить файлы PHP, чтобы их было сложнее проанализировать. Однако их можно очистить с помощью указанных выше инструментов и понять, для чего они нужны. Пишите здесь о своём любимом сервисе или инструменте с описанием его работы и тем, как он может помочь в восстановлении сайта, и мы дополним этот список.
Взломы бывают совершенно разные. Кто-то просто хулиганит и «дефейсит» сайт (постит на нём провокативную или оскорбительную информацию, портит вёрстку, превращает сайт крупной корпорации в самый дорогой в мире фанклуб My Little Pony). Зачастую, повреждения такого типа лечатся восстановлением последнего бэкапа и удалением всей неугодной информации, правда, без последующего аудита безопасности сайта никто не застрахован от повторения такого безобразия.
Куда опаснее, когда взлом сайта сопровождается кражей данных, подменом информации или осуществляется с целью распространения всяких зловредов. В таком случае самое важное — оградить потенциальных посетителей (пользователей или клиентов) от общения с подобным контентом.
Временное закрытие сайта на техническое обслуживание
Первое и основное, что требуется сделать — «закрыть» сайт на ремонт. Здесь мы руководствуемся только соображениями безопасности: в метро при ремонте эскалатора вход на него перекрывают? Вот и сайт мы временно закроем. Пользователи не смогут попасть на взломанные страницы, а вы сможете спокойно работать над восстановлением сайта.
Кроме того, если взлом осуществлялся через одну из «дырок» в рабочих файлах, если не закрывать сайт на техническое обслуживание вы рискуете снова столкнуться с вмешательством хакеров, пока будете устранять последствия взлома.
Восстановление сайта
Самое простое восстановление — найти последний backup и развернуть его. К сожалению, бэкапы точно так же могут потереть злоумышленники, или бэкапы могут касаться только контентной части, или… да миллион или. В общем, если волшебное решение в одну кнопку «восстановить» нам не в силах помочь, придётся всё делать самостоятельно.
Конечно, мы все знаем, что перед началом работ стоит сделать бэкап всего, чего только можно. Но статью могут перепостить куда-нибудь ещё, так что напомнить будет не лишним. Да, новая (и на этот раз полная) резервная копия будет содержать взломанный контент, поэтому воспользоваться ею можно будет только в том случае, если в процессе восстановления рабочей версии вы что-то сделаете не так и сайт сломается окончательно. При выполнении дальнейших инструкций обязательно делайте копию каждого файла, который будете удалять, мало ли что? Удалить копии всегда успеете.
Шаг 1: Проверка файла .htaccess
Один из самых поплуярных способов взлома: хакеры создают или меняют содержимое файла .htaccess, чтобы добавить собственные страницы или перенаправить пользоватлей на фишинговый сайт-клон.
Проверьте, нет ли в файле .htaccess подозрительных строк. Если вы не знаете, как анализировать его содержание, прочитайте соответствующие материалы на сайте Apache.org, задайте вопросы на справочном форуме или проконсультируйтесь со специалистом. Пример измененного злоумышленниками файла .htaccess:
<IfModule mod_rewrite.c>
RewriteEngine On
#Посетители, переходящие на сайт из Поиска Google, будут перенаправлены
RewriteCond %{HTTP_REFERER} google\.com
#Посетителей перенаправляют на зловредный PHP-файл happypuppy.php
RewriteRule (.*pf.*) /happypuppy.php?q=$1 [L]
</IfModule>
Удалите все обнаруженные элементы вредоносного кода. Если в файле .htaccess их очень много — проще будет создать новый .htaccess, чем чинить имеющийся. Также может оказаться, что он содержит вредоносный файл PHP (мы назвали его happypuppy.php, но нередко в таких названиях используется случайная комбинация двух слов). Это важно учитывать при поиске остальных вредоносных файлов.
Шаг 2: Поиск других вредоносных файлов
Чаще всего хакеры работают с файлами JavaScript и PHP. При этом используются два основных метода: добавление вредоносных файлов и модификация имеющихся. В первом случае на сервер добавляются новые файлы .php или .js, а их названия могут быть очень похожи на стандартные имена, например wp-cache.php маскируется под безопасный файл wp_cache.php. Второй вариант предусматривает, что вредоносный контент добавляется в уже существующие на сервере файлы. Например, если на вашем сайте есть шаблоны или плагины JavaScript, хакеры могут изменить их код.
Разберем пример. В одну из папок на сайте www.example.com был добавлен вредоносный файл happypuppy.php, ранее обнаруженный в файле .htaccess. Помимо этого, хакеры внедрили вредоносный код в файл JavaScript с именем json2.min.js, уже существующий на сервере. На скриншоте ниже этот код, добавленный в самый конец файла, выделен красным. В итоге содержание файла будет выглядеть так:
Чтобы эффективно выявлять вредоносный код, необходимо понимать, как на сайте используются файлы JavaScript и PHP. Если вы занимаетесь вёрсткой, дизайном, контентом или администрированием портала, но не заглядывали «под капот», возможно, вам потребуется изучить документацию по системе управления контентом.
Кроме того, найдите и проверьте на сайте все файлы, которые недавно были изменены, особенно если они относятся к шаблонам. В разделе «Приложение» перечислены инструменты, которые помогут вам обнаружить замаскированные файлы PHP.
Шаг 3: Удаление вредоносного контента
Как упоминалось ранее, перед удалением или изменением каких-либо файлов необходимо создавать резервные копии сайта. А если вы делаете это регулярно, то для устранения проблем на сайте достаточно будет восстановить его архивную версию, которая предшествовала взлому.
Но даже если вы не делаете резервные копии, вам доступны другие решения. Во-первых, удалите добавленный хакерами вредоносный контент. Например, на сайте www.example.com это будет файл happypuppy.php. Если же злоумышленник изменил существующие файлы PHP и JavaScript, такие как json2.min.js, загрузите их безопасные версии. Попробуйте заново добавить на сайт ключевые файлы плагинов и системы управления контентом, если вы ее используете.
Шаг 4: Поиск и устранение уязвимостей
После удаления вредоносного файла нужно найти и устранить уязвимость, которая привела к взлому сайта, иначе он может подвергнуться повторной хакерской атаке. Это может быть что угодно – от украденного пароля до устаревшего ПО сайта. О том, как найти и исправить уязвимость, читайте в нашем Справочном центре. Если вы не можете понять, как был осуществлен взлом, смените все пароли, полностью обновите ПО на сайте и по возможности обратитесь к специалистам.
Дальнейшие действия
Устранив проблемный контент, убедитесь, что робот Googlebot больше не видит взломанные страницы. Используйте для этого инструмент «Просмотреть как Googlebot». Не забудьте проверить на наличие взломанного контента и главную страницу. Если ничего не найдено, значит у вас все в порядке. Если «Просмотреть как Googlebot» по-прежнему находит взломанный контент, вам есть над чем поработать. Вероятно, вы пропустили какой-либо вредоносный файл PHP или JavaScript. Продолжайте поиски.
Прежде чем снова запускать сайт, убедитесь в том, что устранили все уязвимости и последствия взлома. Если в отношении вашего ресурса действуют меры, принятые вручную, войдите в свой аккаунт Search Console и отправьте запрос на повторную проверку. Также продумайте, как защитить сайт от новых атак. Несколько советов на эту тему можно найти в нашем Справочном центре.
Конечно, часть советов кажутся достаточно очевидными, но все мы сильны задним умом, а столкнувшись с подобным впервые можно и дров наломать. Надеемся, что эта статья поможет вам устранить последствия несанкционированного внедрения контента на сайт. Ищите нас в социальных сетях по хештегу #nohacked и не забывайте делиться своим личным опытом и приёмами безопасной работы в Интернете.
Если у вас остались вопросы, их можно задать на справочном форуме для веб-мастеров и в нашем сообществе на Google+. А ещё можно посмотреть запись нашей видеовстречи по вопросам безопасности от 27 августа.
Приложение
Существуют инструменты, к которым Google не имеет прямого отношения, однако они могут вам пригодиться.
Например, утилиты для деобфускации PHP Decoder и UnPHP. Злоумышленник может исказить файлы PHP, чтобы их было сложнее проанализировать. Однако их можно очистить с помощью указанных выше инструментов и понять, для чего они нужны. Пишите здесь о своём любимом сервисе или инструменте с описанием его работы и тем, как он может помочь в восстановлении сайта, и мы дополним этот список.
Vilgelm
Пару раз сталкивался с таким: вредоносный код находился в файле /images/arrow.png (название может быть разным). Такое отследить сложнее всего, если пытаться найти вручную.
Saiten
Вероятно, в .htaccess также добавлялась директива для обработки png не как файла изображения. Например:
AddType application/x-httpd-php .html .htm