![]()
Miss Content
V.I.P. |
Зарегистрирован: 05.03.2010
Сообщений: 7881
|
Обратиться по нику
|
| Miss Content |
Ответить с цитатой | | |
|
Ежедневно мы получаем большое количество писем от начинающих веб-мастеров, которые просят дать рекомендации по лечению сайтов от вирусов и защите от взлома. Предыстория примерно у всех одинакова: в течение какого-то времени сайт функционировал стабильно, радовал посетителей своим контентом, помогал продавать и генерировать доход. Но в один прекрасный день все пошло не так: пользователи стали жаловаться на недобросовестную рекламу, страницы сайта стали выпадать из поискового индекса, а хостер прислал уведомление, что сайт распространяет вредоносное ПО/спам/фишинг.
До момента обращения в нашу компанию веб-мастер, как правило, уже пытался справиться с проблемой самостоятельно: он откатил сайт до незараженной, по его мнению, версии; обновил CMS; поменял все пароли и даже попытался удалить вредоносный код. Но сайт почему-то заражался снова и снова.
В ходе беседы с веб-специалистами выяснялись отдельные нюансы, но так или иначе ошибки, совершающиеся новичками, были типичны. В данной статье мы расскажем об основных из них. Оговоримся сразу, мы не проводили специальных исследований и опросов, а всего лишь систематизировали информацию, полученную нами в результате многолетнего практического опыта по лечению и защите сайтов.
Условно все ошибки веб-мастеров можно разделить на три большие группы: до начала лечения, во время лечения и после него. Что ж, начнем по порядку.
Предупреждён, но не вооружен
Сайт, над которым потрудился хакер, какое-то время может себя никак не выдавать. Часто веб-ресурсы заражаются в несколько этапов. На первом этапе хакер находит уязвимость на сайте и незаметно загружает на него шелл. Он даже может аккуратно «заштопать» после себя брешь, чтобы не отдавать кусок пирога коллегам по цеху. Если регулярно не проверять сайт сканером вредоносного кода, например AI-BOLIT, который определяет хакерские шеллы и бэкдоры, то можно упустить возможность своевременной безболезненной ликвидации незваного гостя на сайте.
Через пару недель хакер обратиться к веб-ресурсу снова, но уже с целью загрузить вирусы, внедрить редирект или разместить спам-рассыльщики. С того момента как на сайте начнут зарабатывать до момента, когда вы это обнаружите, может пройти довольно много времени – все зависит от масштаба бедствия. За рассылку спама или размещение фишинговых страниц хостер может заблокировать сразу, поисковики могут также оперативно отреагировать на вирусный код на страницах или дорвеи. Но иногда заражение проявляется в вялотекущей, не столь заметной форме. Вроде бы периодически жалуются посетители, иногда возникает уведомление в панели веб-мастера о том, что на сайте вирус. Но уже на следующий день пользователи спокойно продолжают совершать покупки в вашем интернет-магазине, а поисковики молчат. В итоге веб-мастер «расслабляется» - приятнее думать, что у пожаловавшегося пользователя заражен браузер, а поисковая система просто ошиблась.
Увы, в реальности все не так просто. Как уже говорилось, существуют разные виды заражения. Вирус может быть активным в определенные дни, определенные часы, для пользователей определенных устройств и регионов. И если поисковый бот проверяет ваш сайт в момент, когда зловред неактивен, то уведомление из панели веб-мастера исчезнет.
Поэтому не игнорируйте любое предупреждение, касающееся безопасности веб-проекта. Даже если вас не заблокирует хостер или поисковая система, есть и другие, более серьезные последствия – ведь доступ к вашему сайту есть у кого-то еще кроме вас. И это может быть доступ не только к файлам и базе данных, но и к резервным копиям. А значит есть риск потерять сайт без возможности его восстановления.
В нашей практике были случаи, когда подобное игнорирование ситуации заканчивалось шантажом со стороны злоумышленника – хакер, получивший административный доступ к веб-ресурсу, вымогал деньги, угрожая уничтожить веб-проект полностью, и наша команда подключались уже в «пожарном» режиме для срочного решения проблемы.
Есть подозрение на вредоносную активность – не поленитесь проверить сайт на предмет взлома и заражения.
Некорректная работа со сканером вредоносного кода
Сканеры вредоносного кода на сайте позволяют быстро диагностировать проблему – находить деструктивные элементы, подлежащие обязательному удалению. Но одни и те же фрагменты встречаются как в легитимных скриптах, так и вредоносных, и главная задача веб-мастера заключается в том, чтобы определить, к какой категории относится выделенный фрагмент кода. Собственно, недостаточная компетентность в данном вопросе может привести к нескольким развязкам – вы удаляете фрагмент на удачу и избавляетесь от проблемы; вы не решаетесь удалить выделенные фрагменты, и заражение происходит повторно; вы удаляете все подозрительные элементы, но перестает работать сайт.
Совет тут может быть только один, если чувствуете, что пока не готовы решить проблему самостоятельно – обратитесь к специалистам, закажите услугу на коммерческой основе, а потом проконсультируйтесь у исполнителя относительно ваших подозрений.
Кроме того, разработчики инструментов для поиска вирусов на сайте, как правило, могут проконсультировать вас по отчету бесплатно (до определенного уровня). Не рискуйте, копите знания, получайте новые – это поможет справляться с проблемой в будущем самостоятельно.
Обман поисковых систем
Так или иначе успешность веб-проекта во многом зависит от его взаимоотношений с поисковиками. И, наверное, одно из самых бесполезных занятий пытаться их обмануть.
Предположим, сайт оказался в списке «угрожающих безопасности компьютера или мобильного устройства…». В панели веб-мастера отразятся страницы, на которых был обнаружен вредоносный код. Но вместо того, чтобы искать источник заражения некоторые специалисты удаляют зараженные страницы, что вовсе не решает проблемы безопасности. Хуже того, иногда веб-мастера целиком блокируют доступ к сайту с помощью правил в robots.txt, полагая, что это поможет избежать проверки сайта антивирусном ботом.
Запрещение индексации – опасный шаг. Во-первых, это может привести к выпадению страниц сайта из поискового индекса, а, во-вторых, правила, которые распространяются на поисковые механизмы, не работают для роботов антивирусных сервисов.
Да и опять же, нельзя оставлять без внимания тот факт, что сайт уже эксплуатируется злоумышленниками – ведь пока вы тратите время на обман Яндекса и Google, ваш веб-проект находится под серьезной угрозой.
Лечение сайта с помощью антивируса для компьютера
Начинающие веб-мастера часто пытаются лечить сайты, используя антивирусники для десктопов. Веб-мастер делает бэкап сайта и «натравливает» на него антивирусное программное обеспечение, предназначенное для компьютера. Такой подход не даст желаемых результатов, поскольку вирусы, написанные для сайтов, отличаются от вирусов, заражающих компьютеры пользователей, и антивирус для десктопа не сможет найти большинство вирусов в файлах и базе данных сайта.
Для проверки сайта необходимо использовать специализированные сканеры вредонсоного кода, база данных которых регулярно пополняется новыми экземплярами вредоносных элементов.
Восстановление сайта из бэкапа вместо лечения
Нередко при появлении вируса на сайте веб-мастера пытаются решить ее простым откатом сайта до незараженной версии. И продолжают делать это каждый раз, как только происходит новое заражение. Разберемся. А что считается чистой версией сайта? Ведь, как мы уже знаем, хакерский шелл может находиться на сайте довольно долго и никак себя на проявлять. То есть точкой возврата становится взломанный сайт только без редиректа или спам-рассыльщика, но уже с шеллом?
Предположим, что восстановить чистый сайт из резервной копии удалось. Но вопрос безопасности остается открытым: если на ваш сайт несанкционированно проникли один раз и вы ничего не предприняли для предотвращения этой ситуации, то будет и второй раз, и третий.
Откат сайта – весьма неудобный, непрактичный и уж точно небезопасный вариант. Любое возвращение назад означает лишение всех ваших трудов за последние дни – отказ от изменений, которые вы внесли в скрипты, недавно установленных плагинов, новых текстов и фотографий. Зато вы сохраняете возможность несанкционированного проникновения. Сомнительная тактика борьбы с вирусами.
Удаление вредоносного кода без закрытия уязвимостей и установки на сайт защиты
Есть особая категория веб-мастеров, весьма терпеливых, настойчивых и трудолюбивых. Они уже знают, какой конкретно вредоносный код и куда будет подсажен. И свой день начинают с того, что проверяют одни и те же папки и удаляют из них один и тот же код. Парадоксально, но иногда это длится месяцами. В конце концов несправедливая игра надоедает, и к нам приходят с просьбой о помощи.
Дело даже не в том, что веб-мастер нецелесообразно тратит свое время, «вычерпывая воду из дырявой лодки» (как правило, владелец сайта удаляет код вручную, тогда как хакер подсаживает вредоноса в автоматическом режиме) – сайт находится под угрозой, он марионетка в руках хакера.
Главная задача в сложившейся ситуации – не просто избавиться от вируса на сайте, но предпринять необходимые действия по ликвидации уязвимостей в плагинах и скриптах. В 80 случаях из 100 повторное заражение происходит в результате эксплуатации хакером все тех же брешей.
Практические рекомендации
Закрытие уязвимостей
Наиболее популярные типы уязвимости/атак, приводящих ко взлому сайта, можно разделить на следующие типы (полная классификация уязвимостей доступна на сайте OWASP TOP 10):
RCE (Remote Code Exection) – удаленное исполнение вредоносного кода;
AFU (Arbitrary File Upload), которые позволяют загружать файлы на хостинг, эти файлы могут быть исполняемыми скриптами;
SQL-инъекции, с помощью которых выполняются манипуляции с базой данных (добавление нового администратора сайта, извлечение паролей, вставка вирусов, “слив” базы и пр);
XSS (Cross Site Scripting) - атака, в результате которой код внедряется на страницу сайта, и злоумышленник получает несанкционированный доступ к данным: «куки», сессионным ключам, значениям полей и т. п
Как защититься:
• Удаленное исполнение кода исправляется в исходном коде скриптов (установкой патчей безопасности, исправление ошибок разработчика). Частично проблему можно исправить, используя виртуальный патчинг средствами WAF (Web Application Firewall), который будет блокировать запросы, содержащие исполняемый код или вредоносные фрагменты.
• Проблем с AFU можно избежать путем запрета выполнения PHP-скриптов в каталогах загрузки. Для этого размещается специальный конфигурационный файл .htaccess, который будет блокировать доступ к файлам, кроме доверенных, или отключает обработку PHP-сценариев.
• Вопрос с SQL-инъекциями решается с помощью виртуального или реального патчинга исходного кода (исправление ошибок разработчика, который недостаточно хорошо фильтрует входные данные скрипта). Для виртуального патчинга также подойдет WAF, который отфильтрует запросы с SQL инъекциями.
• Для защиты от XSS необходимо прописать набор правил в .htaccess файле или настроить веб-сервер, чтобы в HTTP заголовках содержались специальные параметры, блокирующие возможность проведения атаки.
Небезопасное размещение сайтов на хостинге
Большинство начинающих веб-мастеров игнорируют тот факт, что если на аккаунте хостинга находится несколько сайтов, и при этом взломан и заражен только один, то остальные можно оставить без внимания. Это большая ошибка.
Если жалобы со стороны пользователей, хостера или поисковых систем поступают на один из ваших сайтов, обязательно проверьте соседние. Возможно, взломан весь аккаунт, и хакерские шеллы уже загружены на другие сайты. Просканируйте сайты сканером вредоносного кода и выполните необходимые действия по устранению уязвимостей и укреплению защиты сайтов. В противном случае непроверенные и незащищенные сайты будут угрожать безопасности уже вылеченных внутри аккаунта.
Оказывая услуги по лечению и защите сайтов, мы часто становимся свидетелями того, что на мультисайтовых аккаунтах некоторых веб-мастеров царит полный беспорядок: веб-мастер уже и сам не помнит, какие сайты у него рабочие, а какие давно лежат мертвым грузом, занимая место на хостинге и … служат “пристанищем” для хакерских шеллов и бэкдоров. Если забытый вами сайт все еще открывается в браузере и ранжируется в поисковой выдаче, то он может стать объектом хакерской атаки, а через него могут взломать остальные сайты.
Не используете сайт в работе, нет времени на его проверку и защиту? Заблокируйте или удалите его с хостинга. Возможно, это избавит вас от больших проблем с безопасностью в будущем.
В заключение
Ну, и последнее, не забывайте про элементарные правила безопасности при работе с сайтами. Они просты и понятны, но, к сожалению, часто игнорируются начинающими веб-мастерами:
Регулярно проверяйте компьютеры, с которых выполняете администрирование сайта, коммерческими антивирусами;
Не забывайте менять пароли от хостинга и административной панели сайта, используйте сложные комбинации;
Не храните пароли в программах (ftp-клиентах, браузере, электронной почте);
Храните резервные копии сайта не только на хостинге, но и локального на компьютере;
Работайте в открытых сетях через защищенное соединение (VPN);
Откажитесь от небезопасного FTP – переходите на безопасные SFTP и SCP протоколы.
Всегда помните, лучше защитить сайт превентивно, не дожидаясь, когда слабое звено на вашем сайте найдет хакер. |
|
|
|
|
