Как защитить сайт от взлома: 7 способов + 3 плагина

Как защитить сайт от взлома? После создания, запуска и настройки веб-ресурса, этот вопрос является наиболее обсуждаемым. Существует множество видов взлома страницы в сети Интернет – столько же применяется и способов защиты: от простых до автоматизированных.

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

Реальные причины защитить сайт от взлома

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

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

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

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

В РФ действует Закон о персональных данных, в Европе — GDPR (General Data Protection Regulation). Бизнес обязан соблюдать их: утечка персональных данных грозит большими штрафными санкциями. Именно поэтому так важно знать, как защитить сайт от взлома.

Чем опасен взлом сайта? Хакеры, получая к нему доступ и заражая вирусами, получают доступ к важной информации и могут использовать ресурсы хостинга.

Также взлом сайта грозит следующим:

• потеря финансов владельцами или клиентами;

• резкое снижение трафика, в том числе из-за потери доверия и ухудшения репутации компании;

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

Информацию о взломе можно получить с помощью:

• онлайн-сервисов;

• антивирусов;

• панелей вебмастеров Яндекс.Вебмастер и Google Search Console.

Третий вариант является наиболее простым и быстрым.

Чтобы отследить взлом в Яндекс.Вебмастерe, нужно пройти следующим маршрутом: "Диагностика" -> "Безопасность и нарушения". Если нарушений нет, появится сообщение "На сайте не обнаружено нарушений и угроз, которые могут отображаться в этом разделе".

В Google Search Console нужно войти во вкладку "Проблемы безопасности и меры, принятые вручную" -> "Проблемы безопасности".

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

5 шагов по защите сервера сайта от взлома

Как защитить сайт от взлома? Рассмотрим 5 основных шагов.

Шаг 1: Выбор безопасного хостинга

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

Шаг 2: Регулярная смена пароля администратора

Надежный пароль – это:

• длина не менее 30 символов;

• сложное сочетание букв и цифр;

• уникальность (не применялся на других ресурсах);

• отсутствие личных данных.

Пароли нельзя пересылать с помощью почтовых клиентов и мессенджеров. Хранить их на компьютере можно в специальных программах вроде KeePass Password Safe. Для создания безопасного пароля используются генераторы.

Шаг 3: Отслеживание входящих данных

Чтобы обеспечивать безопасность сайта, необходимо проверять все данные, которые поступают на него. Этим занимается файрвол (WAF — web application firewall), представляющий собой фильтр между сайтом и информацией, приходящей извне. Он сканирует ее, блокируя вредоносный код и пропуская только безопасные запросы. Файрволы могут работать на уровне DNS (трафик проходит через прокси-сервер), сервера клиента или плагина CMS. Первый тип считается наиболее безопасным.

Для сайтов на WordPress, которые чаще других подвергаются атакам через формы ввода данных, используют Wordfence Security, Sucuri Security или iThemes Security.

Шаг 4: Ограничение прав пользователей

Права необходимо распределить сразу после размещения сайта на хостинге.

Стандартные условные обозначения:

• r — чтение данных,

• w — изменение содержимого,

• x — исполнение файла/вход в папку.

При доступе через FTP-клиент:

• 4 — чтение,

• 2 — запись,

• 1 — исполнение.

Права формируются путем сложения: 4+2= 6 (чтение и запись), 4 (только чтение), 4+2+1=7 (полный доступ) и т.д.

Пользователи делятся на три группы:

• u — администратор,

• g — административная группа,

• — остальные.

Образуются сочетания букв и цифр, которые обозначают особенности доступа к сайту. Например, 754 можно записать как rwx-rx-r, этот код предоставит полные права администратору, чтение и исполнение файла (вход в папку) административной группе, только чтение остальным. Следует установить коды 755 для папок и 644 для файлов.

Замена доступов осуществляется с помощью бесплатного FTP клиента FileZilla. Для этого нужно скачать программу, потом кликнуть по файлу правой кнопкой мыши и выбрать пункт «права доступа к файлу».

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

Шаг 5: Закрытие доступа к хостингу сторонним IP

Это необходимо исключительно тем, кто использует статический IP-адрес! Через панель управления прописывается нужный код в файле .htaccess:

Инструкцию по управлению доступом к файлам через .htaccess можно найти здесь: https://snipp.ru/htaccess/access-htaccess.

7 способов защитить сайт от взлома

Попробуем рассказать о главных принципах безопасности, которые должны ложиться в основу программирования каждого сайта. Чтобы понять их, вы должны владеть базовыми навыками веб-программирования и поиска информации в сети. Кроме того, мы опишем основные способы взлома веб-ресурсов и дадим рекомендации по поводу того, как защитить сайт от взлома. Главным образом речь пойдет о применении платформы PHP+MySQL, хотя основные принципы должны быть применимы и для других платформ.

Один из основных принципов безопасности сайта – недоверие к любой поступающей извне информации, даже несмотря на предварительную проверку данных с помощью JavaScript в браузере пользователя. Даже если это название (User-Agent) браузера пользователя или cookie, которые выставил сайт ранее. Дело в том, что вся входящая информация может быть подделана.

Например, один из популярных форумных движков ранее взламывался хакерами с помощью отправления запроса с подделанным cookie, что вызывало SQL-инъекцию (об этом чуть позже).

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

1. Взлом сайта через загрузку файлов

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

   

   При загрузке файла PHP в переменной $_FILES['userfile']['type'] возвращает mime-тип файла, для JPEG-изображения это будет image/jpeg. Может показаться, что проверка этого типа достаточна для уверенности в том, что загружено именно изображение. Также встречается идея пытаться читать файл изображения функциями getimagesize или imаgecreatefromjpeg. Однако тип файла здесь определяется на основе содержания, так что правильное JPEG-изображение, сохраненное с расширением .php, определится как image/jpeg. И будет иметь название формата xxxxx.php.

   Веб-сервер, который принимает решение об обработчике (handler) для того или иного файла, оценивает именно расширение. Мошенник использует изображение и приписывает к нему в конец (или в EXIF-данные) php-скрипт, в итоге сервер его исполняет, а сайт оказывается взломан.

   Получается, что контроль безопасности осуществляется с помощью изучения расширения файла. Проверять файлы с помощью определения mime-type и открытия функцией getimagesize стоит только для выявления мусора, который сам по себе вреда сайту не несет, но картинкой не является.

   Помимо этого, файлы могут попадать в директорию, недоступную для посещения пользователями. Отдаются они через скрипт. Но это приводит к более серьезной нагрузке на сервер и требует реализации базовой функциональности веб-сервера (выдачи даты последнего изменения и реакции на условные запросы типа "If-Modified-Since", выдачи корректных mime-type и поддержки докачки).

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

2. Register Globals

   

   В PHP имеется функциональность "Register Globals" — автоматическое заведение переменных при поступлении их в запросе (GET, POST, COOKIE). Скрипт <?php echo $a;?>, который вызывают как script.php?a=hello, напечатает "hello" при включенных register_globals. Если специалист не следит за начальной инициализацией переменных, может возникнуть уязвимость. Она выглядит так:

   if ($login == 'admin' && $password == 'пароль админа') $is_admin = true;

   ......

   if ($is_admin) {какие-то действия, разрешенные только админу}

   Можно подумать, что для установки переменной $is_admin в true обязательно требуется пароль администратора, без него она останется неопределенной, а if($is_admin) не выполнится. Однако переменную $is_admin можно установить с помощью вызова скрипта с аргументом ?is_admin=1. Взлом сайта произошел из-за того, что была пропущена переменная из запроса (например, в начале скрипта не написали $is_admin = false).

   Для отслеживания подобных ситуаций стоит включить в PHP отображение всех ошибок, предупреждений (warnings) и замечаний (notices) директивой error_reporting. В приведенном примере в этом случае было бы видно замечание об использовании неинициализированной переменной $is_admin. Поэтому так важно писать скрипты, включив все диагностические сообщения PHP.

3. SQL-инъекции

   

   Разработчикам и программистам часто приходится думать о том, как защитить сайт от взлома при возникновении атак SQL-инъекциями. Они направлены против сайтов, на которых нет правильного разделения SQL-запросов и вставляемых в них данных. Как выглядят SQL-инъекции продемонстрируем на примере.

   Имеется сайт, представляющий собой доску объявлений, которые размещают пользователи. Им разрешено удалять свои записи через интерфейс. Код PHP-скрипта выглядит так:

   mysql_query('DELETE FROM messages WHERE id='.$message_id.' AND user_id='.$user_id);

   В данном случае переменная message_id приходит от ссылки "Удалить" ($_REQUEST['message_id']), она содержит идентификатор удаляемой записи (целое число). Переменная user_id хранится в сессии, в нее записывается идентификатор пользователя при его успешной авторизации на сайте.

   Допустим, злоумышленник смог подделать адрес ссылки для удаления и вместо «?message_id=15» отправил «?message_id=15 OR 1=1». После подстановки этого значения в запрос он станет таким:

   DELETE FROM messages WHERE id=15 OR 1=1 AND user_id=3

   Видно, что данные стали выражением, в выражение попало логическое "или" (OR), в результате чего взломщик "выключает" проверку user_id и может удалять чужие записи.

   Приведем еще один пример – проверка логина и пароля пользователя, которые поступают в переменных $login и $password:

   mysql_query('SELECT id FROM users WHERE login="'.$login.'" AND password="'.$password.'"');

   Если в $login злоумышленник отправляет «admin" OR 1="1», то его пустят на сайт под логином admin даже без знания пароля:

   SELECT id FROM users WHERE login="admin" OR 1="1" AND password=""

   А если напишет «" OR 1=1 OR 1="1», то вообще войдет на него под первым попавшимся в базе данных пользователем.

   То есть чтобы предотвратить SQL-инъекции, необходимо следить за тем, чтобы данные не интерпретировались как выражения. Нужно либо насильно приводить значения в ожидаемый тип (функции intval, floatval, если ожидается число), либо просто заключать их всех в кавычки и экранировать содержащиеся внутри них спецсимволы.

   В языке PHP есть специальная функция mysql_real_escape_string, которая позволяет экранировать текст перед вставкой в MySQL-запрос. Иногда вместо нее используют mysql_escape_string, addslashes и htmlspecialchars, однако они неэффективны или просто направлены на другое (речь о последней).
   

   

4. bp.blogspot.com

   В языке PHP имеются так называемые «Волшебные кавычки» (Magic Quotes). Данная функция позволяет PHP самому добавлять обратную косую черту перед всеми кавычками (и уже имеющимися обратными косыми чертами) в данных, которые приходят извне. Благодаря этому скрипт оказывается защищен, что просто прекрасно, особенно если разработчик не позаботился о безопасности самостоятельно.

   Но при этом происходит влияние на все данные подряд, включая те, которые не рассчитаны на поступление запросов к базе. Никто не желает видеть на сайте приветствие в духе "Здравствуйте, д\'Артаньян". Соответственно возникает необходимость чистить данные функцией stripslashes или вовсе отключать «волшебные кавычки» в настройках сервера.

   Собственно говоря, magic_quotes не обеспечивают сайту абсолютной защиты. Они не смогут предотвратить инъекцию с конструкцией «WHERE id='.$message_id» из примера выше — кавычек вокруг аргумента и так нет, взломщику не придется вставлять закрывающие кавычки. Также не учитывается кодировка соединения с базой данных. Да и сами разработчики языка PHP не советуют использовать «волшебные кавычки». Их поддержка не ведется, начиная с 6-ой версии PHP.

   Итак, не нужно полагаться на magic_quotes, важно использовать функции mysql_real_escape_string / pg_escape_string для обработки данных перед вставкой в SQL-запросы и обязательно заключать значения в SQL-запросе в кавычки. Следует обрабатывать таким образом все данные, участвующие в SQL-запросах, даже если они поступают из надежного источника.

   Некоторые специалисты советуют применять для этого специальные конструкторы SQL-запросов, которые сами обеспечивают требуемое разделение запроса и данных.

5. XSS

   

   XSS (Cross Site Scripting, "межсайтовый скриптинг", аббревиатура XSS используется для предотвращения путаницы с CSS, таблицами стилей) – это атака, суть которой в публикации на сайте специального скрипта (допустим, на языке JavaScript), который исполняется, когда человек открывает страницы сайта. Так как это происходит прямо в браузере, скрипт получает доступ к информации в cookie, а также может выполнять действия от имени пользователя (если он вошел в систему под своим логином) – допустим, читать, писать и удалять сообщения.

   Это означает, что данная атака по большей части представляет опасность для сайтов, на которых пользователи могут зарегистрироваться и оставить какую-то личную информацию, то есть для форумов, досок объявлений, блогов и т.п. Однако стоит быть начеку и администраторским интерфейсам, содержащим модули, которые предназначены для просмотра данных, вносимых пользователями. Допустим, сообщения из форм обратной связи, заказа или отзывов, статистическая информация об адресах, с которых приходили посетители (поле HTTP-запроса "Referer"), и браузерах, которыми они при этом пользовались (поле "User-Agent").

   Как защитить сайт от взлома, который осуществляется с помощью XSS-атак? Необходимо тщательно фильтровать входящие данные, размещающиеся на сайте. В основном достаточно заменять символы "<" и ">" на "&lt;" и "&gt;" соответственно (php-функция htmlspecialchars). Это ведет к тому, что текст, который вводит пользователь, теряет HTML-оформление, а скрипты, что содержатся в нем, перестают быть вредоносными.

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

6. XSS и BB-коды

   

   Взломать сайт можно с помощью BB-кодов (Bulletin Board). Это альтернативные теги, которые, как правило, пишутся в квадратных скобках. Движок сайта заменяет их потом на HTML-аналоги. Набор этих псевдотегов обычно очень ограничен, иногда они даже не могут иметь атрибутов (а если имеют, то их набор также очень мал). Вообще, можно реализовать различные языки разметки – главное, чтобы они четко отслеживались разработчиком.

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

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

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

   Приведем пример. С помощью тега [b][/b] происходит оформление жирного текста, атрибут color меняет его цвет. То есть пусть [b color="red"]...[/b] заменяется на <b style="color:red">...</b>. Кажется, все нормально. Но это не так.

   Хакер может в значение атрибута color записать не название цвета, а нечто иное. Например, строку «red" onmouseover="скрипт» или «expression(скрипт)». Если отсутствует фильтрация значения цвета, на выходе мы увидим скрипт, выполняющийся у посетителей.

   Имеет смысл заниматься не чисткой данных, которые могут представлять опасность (к примеру, слово expression или кавычки), а допуском тех из них, что точно относятся к корректным. В случае с цветом это последовательность латинских букв и цифр, возможно, с символом «#» в начале (например, регулярное выражение «^[#]?[a-zA-Z0-9]+$»). При желании можно заняться отсеиванием цветов, которые равны цвету фона или похожи на него. В итоге будет организована нормальная фильтрация.

7. DOS

   

   Особое место среди угроз безопасности занимают DOS-атаки — Denial Of Service (отказ в обслуживании). Когда мы читаем новости про то, что хакеры нарушили работу сайта, речь идет именно об атаке, то есть это не взлом. Сервер атакуют множеством запросов, которые он не в состоянии обработать, в результате чего создается впечатление, что сайт не функционирует.

   В принципе «положить» таким образом можно любой ресурс. Даже если стоит ограничение на количество обращений с одного IP-адреса, атака может быть произведена с сотен или тысяч разных компьютеров. Она называется DDOS (distributed — распределенный).

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

   Надо сказать, что отсутствие оптимизации на сайте приведет к нарушениям в его работе даже без сторонних атак. К примеру, если сайт долго генерирует страницы, если для каждого пользователя производятся существенные выборки и расчеты, то даже элементарное увеличение трафика приведет к сбоям – сайт просто не справится с увеличением нагрузки на него. Соответственно необходимо оптимизировать скорость выполнения, объем занимаемой памяти, добавлять кэширование и т. д.

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

   Разумнее ограничить количество попыток залогиниться с одного IP-адреса в определенное количество времени. К примеру, не более 5 в 10 минут. Когда лимит исчерпан, появляется сообщение "подождите" или предложение ввести CAPTCHA (некоторые системы предлагают это вообще при каждой попытке логина.

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

   К сожалению, абсолютной защиты от DOS атаки не существует.

8. Самовредительство

   

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

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

   Это может быть и система фильтрации HTML, где убираются только известные программисту теги <script>, а остальное остаётся.

   Это также может быть очень опасная для сайта система замены Register Globals. В этом случае программист через $$var=$_REQUEST[$var] или даже eval('$'.$var.'=$_REQUEST["'.$var.'"]') заводит переменные, пришедшие из запроса, однако он не понимает, что создает окно, через которое можно без труда испортить имеющиеся переменные (к примеру, массив $_SERVER). Через eval так и вовсе можно выполнить произвольный код.

   Разумеется, такие проблемы создают специалисты, не обладающие достаточной квалификацией в данной сфере.

3 плагина для защиты сайта от взлома

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

Расскажем о наиболее популярных плагинах для WordPress.

1. iThemes Security

Обеспечивает 30 видов защиты от:

• SQL-инъекций;

• шеллов;

• XSS;

• взлома через FTP или SSH;

• взлома phpMyAdmin;

• взлома через соседей по хостингу;

• взлома через уязвимости в движке;

• брутфорс-атак и ботов, ищущих уязвимости ресурса;

• защита от DDOS-атак на сайт.

Плагин имеет бесплатную версию, а платная обойдется в сумму от 80 до 200 $ в год в зависимости от количества ресурсов.

2. Wordfence

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

Плагин защищает сайт от DOS-атак, а также предотвращает:

• SQL-инъекции;

• шеллы;

• XSS;

• взлом через FTP или SSH;

• взлом phpMyAdmin;

• взлом через соседей по хостингу;

• взлом через уязвимости в движке.

Одна лицензионная версия стоит 99$ в год. Цена варьируется в зависимости от количества проверяемых сайтов и срока лицензии.

3. Sucuri Security

На картинке представлен общий вид страницы в случае обнаружения программой сторонних файлов (добавленных, измененных, удаленных).

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

Способен отражать:

• Dos и Ddos-атаки;

• SQL-инъекции;

• шеллы;

• XSS-атаки.

Плагин совместим с WordPress, Joomla, Drupal, Magento и другими платформами и CMS.

Стоимость Sucuri Security — от 200 $ в год.

Скачайте полезный документ:

Чек-лист: Как добиваться своих целей в переговорах с клиентами

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

Простая инструкция по обнаружению взлома сайта

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

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

Рассмотрим алгоритм действий в случае обнаружения взлома

• Нужно проверить компьютер на наличие вирусов. Это делается с помощью специальных программ-антивирусов, платных и бесплатных.

• Затем следует скачать и установить программу «FireWall» (есть платная и бесплатная версии), которая мешает хакерам проникать в систему и устанавливать там вредоносные программы.

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

• Важно изменить все пароли ко всем ресурсам и разделам.

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

• Необходимо произвести бэкап имеющихся данных и файлов.

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

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

• Затем выполняется обновление по новейшей версии CMS.

• Нужно сразу выяснить, какие именно файлы были заменены. Это может быть index.php, файлы шаблонов, изображений и т.д.

• Сделать скриншоты последствий для сайта.

• Сообщить провайдеру хостинга и обсудить с ним дальнейшие действия.

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

• Восстановить сайт из резервной копии самостоятельно или с помощью хостера.

• Скачать логи ошибок и доступа к сайту или попросить хостера их предоставить. Эти данные стоит скопировать в отдельный каталог, чтобы они не удалились при ротации логов.

• Проанализировать время изменения файлов и сопоставить его с записями в логах. Это даст возможность понять характер используемой уязвимости и IP-адрес злоумышленника.

• Обновить скрипты либо отказаться от использования уязвимых модулей.

Хакеры постоянно мониторят слабые места в системе и ищут новые способы взлома. Это обязывает владельцев сайтов усиленно следить за их безопасностью. Говорят, что если сайт пока еще не взломан, то это только потому, что он не представляет интереса для злоумышленников. Крупные корпорации даже специально нанимают специалистов, которые пытаются проникнуть в систему их сайта – так они стараются найти свои уязвимости и предотвратить настоящий взлом. Но даже их ресурсы в итоге взламываются.

Автор статьи

Дмитрий Свистунов

Руководитель SEO-отдела и разработки

Статья опубликована: 05.10.2021

Последние статьи этого автора:

• Адаптивная верстка сайта: гайд для начинающих
• Анкор ссылки: виды, правила составления, влияние на продвижение
• Белая раскрутка сайта без перехода на темную сторону

Забрать гарантированный подарок

Полезные
материалы
для руководителей

Скачать 3,2 MB