10 шагов к безопасности блога

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

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

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

Что угрожает безопасности блога?

Разделим угрозы на несколько видов:

• Аппаратные сбои;
• Сбои в движке WordPress и установленных плагинах;
• Ошибочные действия администратора блога («ой, а зачем я это удалил??»);
• Действия злоумышленников;
• Вирусы;

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

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

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

Кроме самого хозяина блогу могут навредить и посторонние люди. Или вы думаете, у вас нет врагов?

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

Шаг 1. Бэкап или резервная копия базы данных

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

1) Бэкап базы данных блога.

2) Бэкап самого блога, то есть движка WordPress, темы оформления и всего прочего, что лежит на хостинге в виде файлов.

Бэкап БД блога на WordPress с помощью плагина WP DB Backuper

Для архивирования базы данных существует масса плагинов, наиболее популярным из которых считается WP DB Backup. Ввести его в дело не сложно:

• устанавливаем обычным способом.

• в консоли на вкладке «Инструменты» появилось «Резервное копирование». Там ставим галочки напротив всех таблиц, которые хотим архивировать, а также галочки «Исключить ревизии постов» и «Исключить спам-комментарии» (если, конечно, вы не хотите включить и их в резервную копию). Внимание: галочки для архивируемых таблиц не запоминаются. Это галочки для единовременного скачивания резервной копии. Для автоматической архивации свой набор галочек.

• выбираем, как получать архив с копией БД: скачивать вручную, сохранить на сервере или отправить на почту. Хранить на сервере, на мой взгляд, неудобно. А вдруг именно сбой на сервере и будет причиной аварии? Лучше завести себе отдельный почтовый ящик для копий БД. Скачать архив вручную, кстати, можно в любой момент, даже если выбран другой вариант получения автоматически созданной копии.

• выбираем, как часто автоматически архивировать БД. Мне кажется, раз в день – нормально. Набор таблиц, подвергающихся автоматической архивации, можно задать отдельно. Я проставил галочки напротив всех таблиц.

• да и всё.

Если подходить к безопасности блога серьезно, то копию БД нужно делать перед любым более-менее ответственным действием: установка или удаление плагина, обновление плагина или движка. Даже после публикации статьи можно сделать копию БД.

Восстановление базы данных блога на WordPress

Возникает вопрос: а что потом делать с валяющимся на почте или на жестком диске архивом БД? Как ее восстановить? Очень просто. Для этого нам понадобится программа phpMyAdmin, которую часто можно найти в панели управления хостингом.

Если найти phpMyAdmin или что-то подобное не удается, надо спросить у техподдержки хостинга. У SprintHost, например, phpMyAdmin расположен тут:

А в самой программе есть кнопка «Импорт»:

Чтобы восстановить БД блога по резервной копии, используйте эту кнопку и присланный плагином (или скачанный вручную) архив. Только не играйте с настройками. Как правило, в этом нет необходимости.

Есть и другой способ восстановления. Откройте файл копии БД в Блокноте, скопируйте весь текст, после чего вставьте в поле для запросов SQl в phpMyAdmin и нажмите ОК:

Так просто? А нет ли подвоха? Я только что сделал резервную копию БД своего сайта «Сеожурнал» и восстановил ее. Проверьте, сайт все еще открывается?

Шаг 2. Резервное копирование файлов на хостинге

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

К счастью, резервное копирование файлов можно выполнить еще проще, чем базы. Просто заходим на свой хостинг с помощью своего любимого FTP-клиента (для меня таковым является FileZilla) и копируем в надежное место на своем винчестере папку public_html:

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

Копия БД и копия файлов – это и есть ваш блог. Если у вас есть две эти своевременно сделанные копии, то вы всегда сможете восстановить свое творение, что бы с ним не случилось.

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

Шаг 3. Правильные пароли

В правильном пароле (неважно на блог или на что-то еще) должны быть большие и маленькие буквы, цифры, тире и подчеркивания. 14 символов – достаточная длина. Пример хорошего пароля: q_12_maba8_KOG. Я его только что придумал.

Шаг 4. Защита от грубой силы

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

Настройки плагина просты:

• Max Login Retries – сколько попыток дадим вводящему логин и пароль?
• Retry Time Period Restriction (minutes) – сколько времени до повторной попытки (чтобы она считалась повторной)?
• Lockout Length (minutes) – на сколько минут блокируем IP-адрес посетителя после того, как все попытки залогиниться исчерпаны?
• Lockout Invalid Usernames – защитываем не только неправильный ввод пароля, но и неправильный ввод логина.
• Mask Login Errors – маскировать ввод неправильных данных.

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

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

Шаг 5. Не забывайте про свой компьютер

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

Шаг 6. У вас новый пользователь!

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

Шаг 7. Не разносите инфекцию!

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

http://2ip.ru/site-virus-scaner/

http://onservis.ru/proverit-sait-na-virusy.html

http://burbon.ru/service/virus.php

http://www.virusnasaite.ru/check.php

http://xseo.in/viruscan

Шаг 8. Универсальный солдат

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

Один из таких плагинов – Better WP Security.

Установка этого плагина создаст целую новую вкладку Security в консоли WordPress. Вам досталась русифицированная версия плагина? Поздравляю. Мне пришлось поднапрячь свои зачатки английского.

Первым делом при переходе на вкладку плагин предложит вам сделать бэкап БД, после чего попросит разрешения изменять файлы ядра WordPress (разрешить – Allow).  А потом мы получаем целый список параметров безопасности, часть из которых тревожно-красная:

Ссылки Click here to fix сбоку от параметра безопасности командуют плагину исправить данную проблему. Можно использовать кнопку “Secure My Site from basic attack”, чтобы исправить много проблем разом.

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

• Удаление со «всеобщего» обозрения: мета-тега Generator, сообщения об ошибке входа, заголовка Windows Live, заголовка RSD, информации о теме, плагинах, обновлениях и т.п.
• Изменение URL входа в админку
• Привязка доступа администратора к IP-адресу или диапазону IP-адресов
• Запрет входа в определенное время (например, ночью)
• Блокировка пользователей после нескольких неудачных попыток залогиниться
• Улучшение .htaccess
• Обнаружение подозрительной активности (атак)
• Переименование учетной записи admin
• Изменение префикса таблиц базы данных
• Обязательное использование SSL для администрирования, если это позволяет сервер
• Изменение пути к папке  wp-content

Как видите, часть функций этого плагина делает ненужными другие плагины. Например, Better WP Security тоже умеет  автоматически создавать и отсылать на почту бэкап базы данных, так же, как и WP DB Backuper.

Если с настройками разбираться тяжело, то сначала нажмите кнопку “Secure My Site from basic attack”, потом переименуйте пользователя admin (отмечено красным на рисунке) и измените префикс таблиц. Это уже даст некоторый минимум защиты. Только когда будете менять префикс, запишите куда-нибудь префикс случайно сгенерированный для вас плагином.

Шаг 9. Сюрпризы от авторов шаблона оформления

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

Чтобы легко вычислить такие ссылки, ставим плагин TAC, после чего: консоль – «Внешний вид» – TAC. Перед нами список установленных на блоге тем и количество статических ссылок, найденных в каждой. Если щелкнуть на синюю кнопку Details, можно увидеть HTML-код ссылки.

Если вы знаете этот HTML-код, вы можете вырезать ссылку из темы. Только осторожнее, испортить шаблон довольно легко. Сделайте бэкап файлов перед редактированием.

Шаг 10. Спамооборона

Об этом я напишу отдельную статью позже.

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

P.S.  Не могу не вспомнить здесь мой случай с флешкой. Эта флешка была великолепна. Ее можно было положить под колесо машины. С ней можно было нырять на сто метров. Данные в ней шифровались марсианскими способами, неподвластными хакерам Земли.

В общем, это была мегазащищенная флешка на 16 Гбайт. Среди всей ерунды, которой я забил эти Гбайты, была пара десятков документов, совершенно необходимых мне для работы. О создании резервной копии документов я не позаботился, всецело полагаясь на обещания фирмы не скажу какой.

Поэтому когда мегафлешка вдруг перестала обнаруживаться компьютером, мне пришлось ради этих 20 файлов выложить около 300 долларов за восстановление ВСЕЙ информации, не особенно нужной мне. Восстановление, к примеру, флешки в 2 Гбайт обошлось бы значительно дешевле. С тех пор я не люблю флешки большого размера и всегда извлекаю флешки правильно.