WordPress: очень подробная инструкция как практически бесплатно сделать свой сайт защищенным и безопасным

Привет! На связи Максим Кульгин, основатель компаний по разработке приложений, защите от скликивания и парсингу сайтов. Если собираетесь сделать сайт на WordPress, то приготовьтесь. «Ты что⁈ WordPress — небезопасный! Срочно спасайся!», — окружающие не дадут вам расслабиться. Напрасно. Все наши сайты на WordPress — и они еще "живы", хотя нас пытаются взломать (зачем-то) каждый день.

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

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

Итак, начнем с базового вопроса: а безопасен ли WordPress вообще?

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

Как же так⁈

А очень просто. WordPress написан на PHP — языке, который на заре своей популярности действительно имел целый ворох проблем, начиная от уязвимостей и заканчивая неконсистентностью во встроенных функциях. Плюс типичный пользователь (который не имеет глубоких знаний о том, как всё работает, а лишь бездумно копирует «проверенные» решения, давно ставшие наихудшими) не добавляет хороших красок к общему портрету WordPress.

Всё изменилось!

Сейчас уязвимость WordPress сильно преувеличена и берет свою историю из темных времен старого PHP. На WordPress созданы миллионы сайтов, в том числе таких гигантов, как Bloomberg, TechCrunch, BBC America, MTV News, The New York Times, Vogue, Chicago Sun Times, Time inc. , Fortune, The New Yorker.

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

Устаревшие версии WordPress, сомнительные плагины, непрофессиональное администрирование операционной системы и управление учетными данными, отсутствие необходимых знаний в области веб-технологий и безопасности у пользователей, не являющихся технарями — вот это всё и позволяет хакерам снова и снова иметь повод откупорить шампанское (купить мороженное, сходить на новые мультики — подчеркните мысленно, что вам больше нравится) .

Банальные вещи?

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

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

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

Повторюсь ещё раз: никто не пытается сказать, что уязвимостей не существует. Но это не мешает сделать WordPress безопасным и позволяет ему оставаться самой популярной платформой: 43,3% всех веб-сайтов в Интернете использует именно его.

По состоянию на 2023 год команда безопасности WordPress состоит примерно из 50 экспертов (по сравнению с 25 в 2017 году) , включая ведущих разработчиков и исследователей. Работа по совершенствованию не стоит на месте, что и позволяет платформе оставаться лидером сайтостроения.

Что ж. Перейдем к технической стороне.

Для начала кратко рассмотрим существующие уязвимости, чтобы понимать с чем имеем дело:

• лайзейки (backdoors)
• фарм-хаки (pharma Hacks)
• атака грубой силой или прямой перебор (brute-force)
• вредоносные перенаправления (malicious redirects)
• межсайтовый скриптинг (сross-site scripting, XSS)
• отказ в обслуживании (denial of service)

Лазейки (backdoors), как ясно из названия, дают возможность обойти систему безопасности с помощью недокументированных, непродуманных, нестандартных методов доступа через wp-Admin, SFTP, FTP и так далее. Взломав один сайт, хакеры зачастую получают возможность скомпрометировать и другие сайты, размещенные на том же сервере.

Та же Sucuri сообщает, что установка новых дополнительных лазеек по-прежнему являются основным действием злоумышленников после взлома: на 71% из зараженных сайтов в той или иной форме внедряется лазейка.

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

Ошибки и слабые места в устаревших версиях платформы — главный источник лазеек. Фиаско TimThumb — яркий пример уязвимости, возникшей в результате использования сомнительных скриптов и устаревшего программного обеспечения, поставившего под угрозу миллионы веб-сайтов.

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

Двухфакторная аутентификация, блокировка IP-адресов, ограничение доступа администратора, предотвращение несанкционированного выполнения PHP-файлов — эти действия легко справляются с распространенными угрозами такого типа. О них поговорим ниже.

Фарм-хаки (pharma-hacks) приводят к тому, что поисковые системы видят рекламу фармацевтических препаратов, когда пытаются проиндексировать скомпрометированный сайт. Уязвимость выглядит больше как спам, нежели как традиционный вредоносный код. Это тем не менее достаточная причина, чтобы поисковая система исключила сайт из выдачи за распространение недопустимой рекламы (во многих странах реклама медикаментов запрещена, а в США и в аптеке без рецепта ничего не купишь) .

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

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

При попытке входа в систему так называемым методом грубой силы (brute-force) используются скрипты автоматизации и эксплуатируются слабые пароли для получения доступа к сайту.

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

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

Вредоносные перенаправления (malicious redirects) создают лазейки при установке WordPress. Подобные редиректы часто размещаются в файле. htaccess, а также в основных файлах WordPress в закодированном виде, направляя трафик на сайты злоумышленников. Ниже мы рассмотрим некоторые способы, которые помогут не стать жертвой данного метода.

Межсайтовый скриптинг (XSS) — это тип атаки, при котором вредоносные скрипты внедряются на безопасные, на первый взгляд, и пользующиеся доверием сайты. Когда пользователь заходит на такой сайт, вредоносный код запускается в его браузере.

Зачем это надо? Что это дает злоумышленникам?

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

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

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

Отказ в обслуживании (denial of service) — атака, результаты которой трудно не заметить.

И это как раз наш случай. В декабре прошлого года я писал: «Автор этого, скажи: зачем? У нас не банк, не крипта — ЗАЧЕМ? Ты недавно повзрослел и хвастаешься соседям по парте в школе? В чем сакральный смысл действий?»

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

Мы, разумеется, отбились. Выпустили тогда, в декабре 22-го, статью о том, как сделать WordPress менее уязвимым. Но тогда мы повели рассказ исключительно о плагинах. Сегодня же рассмотрим более комплексный подход.

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

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

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

Даже последние версии WordPress не могут обеспечить всестороннюю защиту от профессиональных DoS-атак. Да что там WordPress! 21 октября 2016 года во многих местах целый интернет остановился — это был день, когда DDoS-атаке подвергнулся DNS (Domain Name Service, служба доменных имён — та самая, которая по названию сайта подсказывает браузерам целевые IP-адреса и другую необходимую информацию, чтобы попасть на требуемый сайт) .

Согласно статистике, более 100 000 веб-сайтов взламываются каждый день. Чтобы наши читатели никогда не попали в эти грустные списки, мы собрали около двадцати рекомендаций, которые вы найдете ниже. Это ещё один наш вклад в общую безопасность. Мы и дальше будем заботиться об актуальности информации, поэтому подобные публикации вы ещё увидите не один раз.

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

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

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

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

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

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

Сервер должен быть настроен на использование только защищенных сетевых протоколов и протоколов шифрования передачи файлов (таких как HTTPS и SFTP вместо HTTP и FTP) , чтобы у злоумышленников не было шансов подсмотреть конфиденциальный контент.

PHP — язык программирования, на котором написан WordPress, его основа. Поэтому крайне важно, чтобы на сервере была установлена последняя версия. Каждый крупный выпуск PHP обычно полностью поддерживается в течение двух лет после его выпуска. В течение этого времени ошибки и проблемы с безопасностью исправляются на регулярной основе. На данный момент все, кто работает на PHP версии 7.1 или ниже, не получают обновлений безопасности, не имеют поддержки и подвержены незакрытым уязвимостям.

Опять немного статистики.

На момент написания этой статьи более 57% пользователей WordPress все еще используют PHP версии 5.6 или ниже. Если объединить это с PHP 7.0, то получится, что колоссальные 77,5% пользователей в настоящее время используют версии PHP, которые больше не поддерживаются!

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

К тем, у кого уже есть сайт на WordPress: а вы знаете, на какой версии PHP вы сейчас работаете?

Большинство хостинг-провайдеров обычно включают такие данные в заголовок ответа на запрос. Быстрый способ проверить: запустить сайт через Pingdom, нажать на первый запрос и найти параметр X-Powered-By. Обычно это поле показывает версию PHP, которую в данный момент использует веб-сервер.

Такой подход сработает не всегда: многие хостинг-провайдеры удаляют этот заголовок по соображениям безопасности.

Мы рекомендуем использовать только стабильные и поддерживаемые версии PHP, не ниже 8.1 (которая будет ещё поддерживаться до ноября 2023 года) . Версии 8.0, не говоря уже о более древних — давно забыты авторами, их больше нет.

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

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

«Автор, что за детский сад ты развел?» — уже слышу по ту сторону экрана. Действительно, звучит слишком просто.

Что ж, давайте ознакомимся с ежегодным списком самых популярных паролей, добытых SplashData и отсортированных в порядке популярности.

Да, вы угадали! Первое место — «123456». Второй по популярности пароль — это… «пароль»! Ну кто бы мог подумать⁈ Вот топ-10:

• 123456
• password
• 123456789
• 12345678
• 12345
• 111111
• 1234567
• sunshine
• qwerty
• iloveyou

Хакеры этими паролями не ограничатся. «Кто же будет возиться с большим количеством паролей, ведь это так тяжело…» — так мыслят многие из простых пользователей, которые примеряют возможности хакеров по себе. Пользователям невдомек, что вручную никто подбирать пароли не будет — этим займется скрипт, который не знает усталости и легко проработает и миллионы записей (если ему дать такую возможность) .

Это одна из причин, по которой пользователей необходимо именно принуждать к использованию сильных паролей. Подразумевается, что системные администраторы — люди разумные, и их принуждать не надо. Однако лишняя проверка никогда не повредит — «доверяй, но проверяй!».

Конечно, основа основ — ограничить количество попыток входа в систему за единицу времени. Однако пароли где-то хранятся. Да, разумеется не в первозданном виде, а как необратимые хэш-суммы (так называемые «теневые пароли») . Тем не менее, если злоумышленникам удастся выкрасть теневые пароли, они могут без ограничений перебирать все доступные варианты, чтобы потом авторизоваться с первой попытки.

Основная функция WordPress wp_hash_password использует фреймворк phpass и восемь MD5-проходов для хэширования паролей. Такой подход позволяет пока не беспокоиться о взломе даже при краже теневых паролей: вычислительные ресурсы, которые потребуются для расшифровки пока не доступны для человечества. Квантовые компьютеры, когда будут изобретены, обрушат всю сетевую безопасность, если попадут в широкий доступ. Но мы продолжим разговор о настоящем, а не о будущем.

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

Держите ещё банальность! (А безопасность всегда строится на них.)

Крайне важно использовать разные пароли для разных веб-сайтов. Лучший способ хранить их локально — в зашифрованной базе данных. Хорошим бесплатным инструментом для этого является, например, KeePass. Есть онлайн-менеджеры паролей, такие как 1Password или LastPass.

Несмотря на то, что данные хранятся в чьем-то облаке, такой подход всё же намного безопаснее, чем использовать один пароль для всех онлайн-сервисов. (Уже не говоря про наклейки на холодильнике.)

К логину тоже не следует относиться пренебрежительно. Никогда не используйте имя пользователя «admin», которое предлагается по умолчанию. Создайте уникальное имя пользователя WordPress для учетной записи администратора и удалите пользователя «admin», если он существует.

Это можно сделать несколькими способами. Наиболее простой — добавление новой записи в раздел «Пользователи» на панели мониторинга с присвоением ему профиля «Администратор».

После того, как новая учетная запись будет создана, появится возможность удалить старого пользователя «admin». Не забудьте назначить новой учетной записи роль администратора.

Будьте внимательны: перед нажатием кнопки «Удалить» включите опцию «Приписать весь контент» новому пользователю, вместо «Удалить весь контент».

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

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

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

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

• сайт сломается;
• основные модификации исчезнут;
• плагин Икс перестанет работать;
• новая функциональность не нужна.

В принципе, можно все оправдания наклеить на одну сторону колеса «Бинго!» и крутить, чтобы не задумываться, когда кто-то недоуменно спросит о такой политике обновлений. А заодно наклеить на обратную сторону реплики для сообщений в чатах, вроде того, что:

• WordPress небезопасный;
• «дырявый» WordPress;
• хватит уже использовать WordPress…

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

WordFence обнаружила в исследовании (в ходе которого они опросили более тысячи владельцев сайтов WordPress, ставших жертвами атак) , что причина была как раз таки в необновленных плагинах. Именно в плагинах сосредоточились 56% известных уязвимостей, которые эксплуатировали хакеры. Своевременные обновления сделали бы все эти эпизоды несостоявшимися.

Также рекомендуется устанавливать только проверенные плагины. Категории «Рекомендуемые», «Популярные» в репозитории WordPress — вполне безопасный источник. Такие плагины находятся под пристальным вниманием огромного числа исследователей и специалистов по безопасности.

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

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

Разработчики не всегда поддерживают свои плагины в актуальном состоянии. Команда WP Loop провела небольшое исследование того, сколько плагинов WordPress в репозитории не соответствуют текущему ядру WordPress. Согласно их исследованию, почти половина(!) плагинов в репозитории не обновлялись более 2 лет.

Это не означает, что данные плагины не будут работать с текущей версией WordPress. Но мы же говорим о безопасности! А значит, всегда должны выбирать ПО, которое активно обновляется. Устаревшие плагины, скорее всего, содержат уязвимости и стоит перестать ими пользоваться.

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

Кроме того, хорошо бы самостоятельно проверять дату последнего изменения (особенно для плагинов, распространяемых не через репозиторий WordPress) . И не забывать следить за оценками и плохими отзывами, которые могут просигнализировать о возникших угрозах заранее.

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

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

• блоггеры по безопасности WP: потрясающий агрегированный ресурс, состоящий из более чем 20 каналов;
• WPScan: каталогизирует более 10 000 уязвимостей ядра WordPress, плагинов и тем;
• официальный архив безопасности WordPress.

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

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

Существует ещё одна популярная стратегия защиты — с помощью скрытности.

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

Блокировка админки WordPress и входа в систему — хороший способ повышения безопасности.

Для этого понадобиться сделать две вещи:

• изменить URL-адрес для входа в wp-admin по умолчанию;
• ограничить попытки входа в систему.

По умолчанию URL-адрес для входа на сайт следующий: «domain. com/wp-admin». Разумеется, все боты, хакеры и скрипты также знают об этом. Изменив URL-адрес, можно сделать себя менее уязвимой целью и лучше защититься от атак методом перебора. Это не универсальное решение, а просто маленькая хитрость. Но из таких маленьких хитростей и складывается безопасность.

Для изменения URL-адреса входа в WordPress есть два подходящих плагина: платный Perfmatters и бесплатный WPS Hide login. Они оба имеют простое поле ввода. Остается выбрать что-то уникальное, чего нет в списках хакеров.

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

Здесь есть два варианта.

Первый — бесплатный плагин Limit Login Attempts Reloaded — отличный способ легко настроить и продолжительность блокировки, и количество попыток входа в систему, и даже подключить черные и белые списки IP-адресов.

Второй — более простой Login Lockdown, а потому может показаться кому-то более предпочтительной альтернативой. Плагин записывает IP-адрес и временную метку каждой неудачной попытки входа в систему. Если в течение некоторого промежутка времени превышается определенное количества попыток с одного и того же диапазона IP-адресов, то вход в систему отключается для всех запросов из этого диапазона. Немаловажно, что данный плагин полностью совместим с WPS Hide login, о котором мы упоминали выше.

Есть ещё один способ заблокировать админку для праздных визитеров — добавить HTTP-аутентификацию. Так не надо делать, конечно, на коммерческих сайтах, но в некоторых случаях такой подход может быть оправданным. Суть в том, что при добавлении HTTP-аутентификации потребуется ввести имя пользователя и пароль, прежде чем удастся получить доступ к самой админке.

Apache

Те, кто использует cPanel могут задать каталоги, которые защищаются паролем. Это можно сделать как с панели управления, так и вручную. В последнем случае потребуется создать файл. htpasswd в каталоге wp-admin, разобраться с синтаксисом и уже там внести все необходимые правки. Пример пути:

Затем необходимо создать файл .htaccess со следующим кодом и также поместить его в каталог wp-admin. (Убедитесь, что вы обновили путь к каталогу и имя пользователя.)

Это не всё. Пока что наши правки нарушают работу AJAX (точнее, admin-ajax), что затрагивает интерфейс всего сайта. Это, в свою очередь, наверняка нарушит работу некоторых сторонних плагинов. Дабы подобного избежать, добавим в. htaccess следующий код.

Nginx

Те, кто использует Nginx, могут ограничить доступ с помощью базовой аутентификации HTTP. (Ссылка на руководство)

Если используется брандмауэр веб-приложений (WAF) , такой как Cloudflare или Sucuri, то админку можно заблокировать, опираясь на возможности, предоставляемые этими платформами. Суть в том, что можно настроить правило таким образом, что только с допустимого IP-адреса можно получить доступ к URL-адресу входа администратора. Опять-таки, данный рецепт подойдет не всем: некоторые плагины нуждаются в доступе к серверной части.

В Cloudflare есть функция блокировки URL-адресов для учетных записей «Pro» и выше — можно настроить правило для любого URL-адреса или файлового пути.

В Sucuri есть возможность добавления URL-адресов в «черный» и «белый» списки. Можно внести свой собственный IP-адрес в белый список и получить тот же эффект.

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

Двухфакторная же аутентификация включает в себя дополнительный процесс: понадобится ввести не только пароль для входа в систему, но и пройти аутентификацию дополнительным способом. Как правило, это текстовое сообщение (SMS) , телефонный звонок или же одноразовый пароль, основанный на времени (TOTP) .

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

Почему?

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

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

Архитектурно, двухфакторная аутентификация состоит из двух частей: одна на стороне WordPress, другая на стороне хостера.

Та часть, что на стороне хостера имеет важнейшее значение для безопасности. Если злоумышленник получит доступ к данным этой учетной записи, (и соответственно, к панели управления, которую предоставляет поставщик услуг своим клиентам) , то он может изменить все ваши пароли, удалить все ваши сайты, изменить записи DNS — перечислять всевозможные злодейства можно долго.

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

• Duo Two-Factor Authentication
• Google Authenticator
• Two Factor Authentication

У многих из них есть свои собственные приложения для проверки подлинности, которые можно установить на смартфон:

• Android Duo Mobile App
• iPhone Duo Mobile App
• Android Google Authenticator App
• iPhone Google Authenticator App

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

С помощью плагина Duo, можно сначала войти в систему со своими учетными данными, а уже затем выбрать метод аутентификации: Duo Push, телефонный звонок или пароль.

Данный метод очень хорошо сочетается с изменением URL-адреса для входа, о котором мы говорили выше. Получается защита на нескольких уровнях.

Одним словом, двухфакторная аутентификация — пуленепробиваемая защита. Технических средств взлома и проникновения (при условии соблюдения других рекомендаций) уже и не остается. Методы социальной инженерии — единственное средство, на которое может рассчитывать злоумышленник, но это уже совсем другой уровень и в данной (и без того объемной статье) рассматривать его смысла нет.

Использование HTTPS считается одним из важных (и тем не менее, часто упускаемых из виду) способов повысить безопасность сайтов, основанных, в том числе, и на WordPress.

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

Позвольте объясниться. Начнем с основ.

HTTPS — это механизм, который позволяет браузеру или веб-приложению безопасно подключаться к сайту. Это на языке маркетологов. А говоря человеческим языком — трафик надежно шифруется и не доступен для просмотра третьей стороне (на данном уровне развития вычислительных мощностей дешифровка исключена) .

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

В этом-то и кроется распространенное недопонимание того, что есть HTTPS на самом деле с точки зрения бизнеса.

Всё намного сложнее! Рассмотрим эту технологию с практической точки зрения.

1. Безопасность

Конечно, главная причина использования HTTPS — это повышенная безопасность. Для коммерческих сайтов — это критически важно.

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

Насколько такие данные важны (или ценны) для владельца сайта и пользователей? Насколько недопустимо давать хакерам возможность внимательно отслеживать и анализировать всю информацию, передаваемую между сайтом и пользователями?

Звучит как риторические вопросы.

Да, ответ очевиден. Независимо от того, идет ли речь о блоге, новостном сайте, агентстве, интернет-магазине и тому подобном — защищенное соединение попросту необходимо, поскольку гарантирует, что никто посторонний ничего никогда не прочитает и не подменит.

Но это была только присказка. А сказка — вот она!

2. SEO

В Google официально заявили, что «HTTPS является фактором ранжирования». Возможно, это небольшой, лишь один из десятков других факторов. Но разве борьба за первую страницу в выдаче по накалу страстей не является чем-то похожим на спорт высоких достижений, когда любая мелочь становится единственным шансом на опережение конкурентов? Опять риторический вопрос, простите.

3. Доверие

Согласно опросу GlobalSign, 28% посетителей ищут зеленую адресную строку в своем браузере, а 77% из них обеспокоены тем, что их данные могут быть перехвачены или неправильно использованы в интернете. Да! Когда обыватель видит светящийся зелененький замочек — у него на душе состояние покоя и лояльности. Это не троллинг, это правда современного сетевого бытия.

4. Реферальные данные

Многие не догадываются, что данные о переходах с HTTPS-страниц на HTTP-страницы попросту заблокированы в Google Analytics. И что это значит? Большая часть этих ссылок просто свалена в кучу как «прямой трафик». А вот в обратную сторону всё прекрасно: все переходы с HTTPS-страниц на HTTP-страницы должным образом обрабатываются и сохраняются.

5. Предупреждения Chrome

С 24 июля 2018 года Chrome 68 и выше начал помечать все сайты, не использующие HTTPS, как «небезопасные». И да, совершенно независимо от того, собирают они данные или нет!

Когда потенциальный клиент попадает на сайт, а его предупреждают, что здесь небезопасно — это хорошо для бизнеса? Заметьте, мы уже давно не ведем речь про защиту данных. Вот почему HTTPS важен и этим уже нельзя пренебрегать!

Надо отметить, что Chrome — это окно в интернет для подавляющего числа пользователей, и его доля растет и растет. Это значит, что почти все клиенты придут на сайт именно через него. Посмотрите в Google Analitics или Яндекс Метрике (а лучше и там и там для чистоты эксперимента) какими браузерами пользуются ваши посетители и напишите в комментариях — просто любопытно, ведь соотношение будет разниться в зависимости от специфики аудитории.

6. Производительность

Благодаря протоколу, называемому HTTP/2, многие заметят повышение скорости обмена информацией между сайтом и посетителями. Для HTTP/2 требуется поддержка HTTPS (из-за особенностей работы) . Повышение производительности обусловлено целым рядом причин, таких как: поддержка улучшенного мультиплексирования, параллелизм, сжатие HPACK с кодировкой Хаффмана, расширение ALPN, серверный push.

Кстати, отзывчивость страниц — тоже один из факторов ранжирования поисковыми системами.

В российском сегменте повсеместно встречаются страницы, использующие устаревший протокол HTTP. Это проблема. А любая проблема — это возможность. В данном случае — дополнительная возможность обойти конкурентов. Возможность, уходящая в прошлое — завтра уже все перейдут на HTTPS, а на HTTP останутся только заброшенные сайты на бесплатных хостингах. Прогресс не стоит на месте.

В сети можно найти много руководств по переводу WordPress с HTTP на HTTPS, мы не будем перегружать и без того объемную статью. Однако, у HTTPS есть одна особенность, о которой вам не скажет почти никто, и уж тем более не покажет на собственном примере — для работы данного протокола требуется получить сертификат SSL (это и есть та самая криптография, о которой мы говорили вначале: ассиметричное шифрование для обмена ключами, симметричное для обмена данными и тому подобное) .

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

Теперь всё по-другому.

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

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

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

Что ж. Будем считать, что сертификат получен. Осталась всего пара шагов.

Чтобы включить безопасное зашифрованное соединение при входе в админку, необходимо добавить следующую строку в файл wp-config. php:

(Для тех, кто использует устаревшие версии TLS, необходимо погуглить про ERR_SSL_obsolete_version, чтобы не возникало предупреждение в Chrome.)

Файл wp-config. php — это как бы центр разума для сайта на WordPress. Его можно назвать самым важным файлом, когда речь заходит про безопасность. Файл содержит всё для входа в базу данных и ключи, которые работают с шифрованием информации в файлах cookie. Ниже — пара вещей, которые помогут обезопасить данный файл.

1. Перемещение wp-config. php

По умолчанию wp-config. php находится в корневом каталоге установки WordPress «/public HTML». Но его можно переместить и в каталог из сети недоступный.

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

Примечание: путь к каталогу с настоящим файлом может отличаться (это зависит от хостинга и настроек) , как правило, это просто родительский каталог.

Надо сказать, что с выбором каталога для файла надо быть осторожнее: некоторые хостеры не позволяют PHP-интерпретатору лезть куда-то выше ~/public по соображениям безопасности.

2. Обновление ключей безопасности WordPress

Ключи безопасности WordPress — набор случайных величин, которые улучшают шифрование информации, хранящейся в файлах cookie пользователя. Начиная с версии WordPress 2.7, существует четыре разных ключа: AUTH_KEY, secure_AUTH_KEY, logged_IN_KEY и NONCE_KEY.

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

В WordPress есть встроенный бесплатный инструмент, который можно использовать для генерации случайных ключей. (Текущие ключи, хранятся в файле wp-config. php.)

3. Разрешения должны быть строгими

Обычно файлы в корневом каталоге сайта на WordPress получают значение 644 — последняя четверка означает, что читать файлы может кто угодно. Разумно установить разрешения в значение 640 или 600. Последний ноль, говорит о том, что никому постороннему читать его не дозволено.

В сети часто можно встретить и более параноидальные значения — 440 и 400 — файл становится совершенно недоступным для записи и если потребуется что-то изменить, то придется сначала менять разрешения (через SFTP, SSH или как-то ещё) , добавляя бит на запись хотя бы для владельца. Однако, здесь дело не только в неудобстве администрирования, а в том, что некоторые плагины могут нуждаться в возможности записи в этот файл, и сверхстрогие ограничения поломают их функционал.

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

Если сервер поднимаете самостоятельно, то можно начать с самой строгой настроки — 400, а дальше тестировать и если что пойдет не так — смягчать разрешения.

В последние годы XML-RPC становится все более крупной мишенью для атак методом перебора. Как упоминали специалисты Sucury, одной из скрытых особенностей XML-RPC является то, что есть возможность использовать метод system. multicall для выполнения нескольких методов внутри одного запроса. Это очень полезно, поскольку позволяет приложению передавать несколько команд в рамках одного HTTP-запроса. Однако это можно использовать и со злым умыслом.

Есть несколько плагинов WordPress, таких как Jetpack, которым XML-RPC необходим для работы. Но в подавляющем большинстве случаев это не нужно, и хорошо бы просто отключить к нему доступ.

Можно проверить, запущен ли XML-RPC в данный момент. Для этого Данило Эрколи из команды WordPress написал небольшой инструмент под названием XML-RPC Validator.

Чтобы полностью отключить эту возможность, можно воспользоваться бесплатным плагином Disable XML-RPC-API. Некоторые платные плагины тоже поддерживают такую функционал, наряду с другими улучшениями производительности.

Некоторые хостинг-провайдеры уже сделали всё необходимое и при обнаружении атаки через XML-RPC в конфигурационный файл Nginx добавляется небольшой фрагмент кода, останавливающий атакующих на дальних подступах.

Утаивание настоящей версии WordPress — очередной пример подхода к улучшению безопасности через сокрытия необходимых исходных данных для атаки.

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

По умолчанию версия WordPress отображается в заголовке. Можно использовать следующий код, чтобы удалить эту нежелательную информацию — его нужно просто добавить в файл functions. php текущей темы.

Важно! Неаккуратное редактирование исходного кода темы может привести к поломке всего сайта.

Есть и платные плагины, которые могут сделать всю работу, но всё-таки это кажется слишком уж необоснованной тратой денег.

Другое место, где отображается версия WordPress, находится в настройках в файле readme. html файл, который включается в стандартную установку. Файл находится в корневом каталоге domain. com/readme. html и его можно безопасно удалить или перенести в другое место.

Начиная с версии 5.0 данный совет можно было бы считать устаревшим, так как разработчики перестали включать в данный файл версию WordPress. Однако памятуя о том сколько «крутится» программного кода, дошедшего до нас из темных времен, всё-таки оставим эту рекомендацию.

Еще один шаг, который можно предпринять, чтобы усилить безопасность WordPress — воспользоваться преимуществами HTTP-заголовков безопасности. Обычно они настраиваются на уровне веб-сервера и сообщают браузеру, как вести себя при обработке содержимого сайта. Существует множество различных заголовков безопасности HTTP, вот наиболее важные из них:

• Content-Security-Policy
• X-XSS-Protection
• Strict-Transport-Security
• X-Frame-Options
• Public-Key-Pins
• X-Content-Type

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

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

Также важно помнить, что внедрение заголовков безопасности HTTP может повлиять на поддомены. Например, при добавлении Content-Security-Policy придется при необходимости добавлять собственные поддомены вручную.

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

• Sucuri Security
• iThemes Security
• WordFence Security
• WP fail2ban
• SecuPress

Вот некоторые типичные функции и способы использования вышеприведенных плагинов:

• принуждение к использованию сильных паролей при регистрации пользователей;
• назначение паролям пользователей срока действия;
• ведение журнала действий пользователей;
• простое обновление ключей безопасности;
• сканирование на наличие вредоносного кода;
• двухфакторная аутентификация;
• recapthcha;
• брандмауэры безопасности;
• белый список IP-адресов;
• черный список IP-адресов;
• журналы изменений файлов;
• отслеживание изменений DNS;
• блокировка вредоносных сетей;
• просмотр WHOIS-информации.

Очень важной чертой, которой обладают многие подобные плагины, является способность проверки контрольных сумм системных файлов WordPress. Таким образом можно обнаружить изменения, говорящие о произошедшем взломе. Такие проверки рекомендуются разработчиками WordPress, для этого предоставляется специальное API. Утилита WP-CLI позволяет кастомизировать данную работу.

Еще одним замечательным плагином, заслуживающим почетного упоминания, является WP Security Audit Log. Плагин особенно будет полезен тем, кто работает с несколькими сайтами на WordPress или должен взаимодействовать с несколькими авторами. Плагин позволяет администраторам видеть все, что меняется: логины, пароли, темы, виджеты, создание новых постов, обновления WordPress и тому подобное.

Это полноценное решение для ведения журнала активности WordPress. Плагин имеет более 80 000 активных установок с рейтингом чуть менее 5-ти звезд, дополнительные надстройки (в платной версии) , такие как уведомления по электронной почте, управление сеансами пользователей, поиск и отчеты.

Больше про плагины можно почитать в наших статьях «10 бесплатных, полезных и опробованных плагинов WordPress для вашего сайта» и «Атакуют за успешные статьи на vc. ru».

Есть несколько способов повысить безопасность базы данных WordPress.

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

Второй способ — в использовании другого префикса в именовании таблиц. По умолчанию WordPress использует «wp_». Изменение этого значения на что-то вроде «37_dx_» может оказаться гораздо более безопасным. Префикс запрашивается при установке WordPress, но его можно поменять в любое время.

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

Все соединения, которые тянутся к сайту и от него, должны быть защищенными! Все протоколы, которые используются для передачи данных, должны поддерживать шифрование: HTTPS, SFTP, SSH — все!

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

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

Вот несколько простых советов:

• не включайте удаленное управление: обычным людям оно не нужно, они никогда им не пользуются и не знают, что это такое — зато сеть не раскрывается внешнему миру;
• маршрутизаторы по умолчанию используют одни и те же IP-адреса, например, «192.168.1.1» — можно поменять диапазон, например, на «10.9.8.7»;
• выставите самый высокий уровень шифрования на WiFi;
• внесите WiFi в белый список IP-адресов, чтобы подключаться могли только люди с паролем, и только определенным IP-адресом;
• не забывайте обновлять встроенное ПО маршрутизатора.

И нужно быть осторожным при входе на сайт WordPress в общественных местах — там небезопасные сети и часто орудуют злоумышленники. Внимательно смотрите на идентификатор сети, к которой подключаетесь чтобы не попасться на приманку. Желательно использовать сторонние VPN-сервисы, чтобы полностью зашифровать трафик и скрыть свой IP-адрес от любопытных. Подобные меры положительно влияют и на личную безопасность, но это уже совсем другая история.

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

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

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

Вот несколько типичных рекомендаций по разрешениям для файлов и каталогов в WordPress:

• все файлы должны иметь права доступа 644 или 640, за исключением wp-config. php (о котором мы подробно говорили выше) и который должен иметь разрешения 440 или 400, чтобы никто, включая других пользователей сервера не мог прочитать его содержимое;
• все каталоги должны иметь разрешения 755 или 750;
• никаким каталогам никогда не должно присваиваться значение 777, даже каталогам загрузки.

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

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

Там очень легко что-то поправить и неожиданно получить белый экран полностью неработоспособного WordPress.

Гораздо правильнее испытать изменения на отдельном экземпляре WordPress или локально, а затем загрузить изменения по SFTP или еще как-то. Если авторов много и у кого-то ещё есть доступ к редактору — владелец сайта оказывается заложником у случайности, что совершенно неприемлемо и никак не обосновано.

Кроме того, если сайт оказался таки взломан, самое первое место куда полезут злоумышленники — это как раз тот самый «Appearance Editor», с помощью которого они будут пытаться отредактировать какой-нибудь PHP-файл или тему, потому что это самый простой и быстрый способ запустить вредоносный код на сайте.

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

Следующий код отключит возможности опасного доступа edit_themes, edit_plugins и edit_files для всех пользователей:

Концепция hotlinking (горячей привязки, дословно) очень проста. Допустим, кому-то понравилась картинка где-то в интернете и человек размещает её на своем сайте, используя URL-адрес изображения, ведущий на сайт-источник.

Это самая настоящая кража!

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

Apache

Чтобы предотвратить горячую привязку в Apache, можно просто добавить следующий код в файл. htaccess:

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

Nginx

Чтобы предотвратить горячую привязку в Nginx, нужно добавить следующий код в конфигурационный файл:

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

• KeyCDN
• Cloudflare
• MaxCDN

Резервные копии — главный инструмент защиты от бед, начиная от кофе на голову сервера и заканчивая хакерами, как из фантастического фильма. Все знают, что это «надо». Но много ли следуют этому «надо»? А напрасно. Все нормальные сисадмины делают это.

Сложно ли наладить выполнение резервного копирования на регулярной основе? Это же WordPress! Здесь всё делается «в миг» установкой нужного плагина или подключением нужного сервиса.

Сервисы резервного копирования сайтов WordPress обычно берут небольшую ежемесячную плату и хранят резервные копии в своем облаке:

• VaultPress (от создателей WordPress, сейчас сервис — это часть плагина Jetpack)
• CodeGuard
• BlogVault

Плагины для резервного копирования WordPress позволяют загружать резервные копии по сетевым протоколам или подключать внешние источники хранения, такие как Amazon S3, Google Cloud Storage, Google Drive или Dropbox:

• Duplicator
• WP Time Capsule
• BackupBuddy
• UpdraftPlus
• BackUpWordPress
• BackWPup
• WP BackItUp

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

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

DDoS — это распределенный (distributed) вариант DOS-атаки (Denial Of Service, отказ в обслуживании) , при которой несколько систем используются для искусственной перегрузки сайта. В DDoS–атаках нет ничего нового: по данным Britannica, первый задокументированный случай относится к началу 2000 года. В отличие от взломов эти типы атак не наносят вреда самому сайту (не крадут пароли, не меняют содержимое файлов) , а просто выводят его из строя на несколько часов или дней.

Что можно сделать, чтобы защититься? Одна из лучших рекомендаций — использовать авторитетную стороннюю службу безопасности, такую как Cloudflare или Sucuri. Если речь идет про бизнес, то, возможно, имеет смысл инвестировать в премиальные планы. Мы справляемся самостоятельно, о чем уже писали несколькими месяцами ранее.

Усовершенствованная защита от DDoS-атак, которую предоставляют сервисы типа Cloudflare, может использоваться для предотвращения DDoS-атак всех форм и масштабов, включая те, что используют протоколы UDP и ICMP (флуд пакетами), SYN/ACK (переполнение пакетами), DNS-усиление (DNS amplification), «атаки на седьмой (прикладной) уровень» (наиболее простой способ парализовать бизнес) и другие.

Ещё одним преимуществом облачных сервисов является использование прокси-сервера и сокрытие исходного IP-адреса.

Обычно пропускная способность сайта составляла всего 30−40 МБ в день, а посещаемость — пару сотен визитеров в день. Во время DDoS-атаки трафик ни с того ни с сего подскакивает до величин, измеряемых гигабайтами, что увеличивает нагрузку на порядки. (Примечательно, что Google Analytics может и не показать никакого дополнительного трафика — всё зависит от того, как делать атаку.)

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

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

Да, WordPress имеет свои особенности, но всё преодолимо, причем без необходимости прикладывать сверхусилия или тратить большие ресурсы. Всё что нужно — выполнить несколько простых рекомендаций — и о безопасности сайта можно не переживать.

В своем телеграм-канале Русский ИТ бизнес, где без прикрас рассказываю о наших ежедневных успехах и неудачах, я также постоянно делюсь и опытом по использованию плагинов для WordPress — 10 постов в июне и уже 6 в июле — что почти всегда вызывает отклик в комментариях, которые тоже являются источником ценнейшего опыта.

Есть какие-нибудь важные советы по безопасности WordPress, которые не были упомянуты? Если да — то, пожалуйста, не стесняйтесь — все будут рады прочитать об этом в комментариях.