Методы защиты блога от взлома

как вариант заблуждения взломщика можно использовать в файлах index.php, находящиеся в служебных директориях, следующий код:

<?php
sleep(rand(15, 35));
include('/home/site/httpdocs/public/errordoc.php');
?>

который будет ждать 15..35 секунд и выводить содержимое файла errordoc.php, в который можно вписать дефолтный код а-ля "500 Internal Server Error", что взломщика смутит и подпортит нервы при исследовании сервера

Смысл? Оно ему надо? Определил версию WordPress, скачал соответствующий скрипт и все дела. 😉

Для WordPress самый действенный способ – это обновляться до последней стабильной версии.

2.0.* -> 2.0.11
2.1.* -> 2.2.3
2.3.* -> 2.3.1 (пока beta)

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

Может в "лишние" index.php троянов напхать? Для введение взломщика в заблуждение, переходящее в помешательство. 🙂

Если папку wp-admin запаролить через .htaccess — это будет хорошей защитой?
т.е. получается двойная авторизация: сначала пароль-логин к папке, затем пароль-логин в админку.

Если папку wp-admin запаролить через .htaccess — это будет хорошей защитой?
т.е. получается двойная авторизация: сначала пароль-логин к папке, затем пароль-логин в админку.

Я так и сделал плюс прочитал о советах Катса по защите блога, где он посоветовал убрать из хедера meta name generator. Это хорошо, но еще не все. Этот generator светится также во всех видах фидов в ВП, так что оттуда их тоже советую вычистить.

Как защитить WordPress-блог

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

А мы будем защищать самое ценное - свой блог на WordPress.

Пункт первый. У бесплатного движка есть недостаток - любой может скачать, поставить и изучить. И изучают, и находят ошибки. Регулярно. Не будем этого ждать - закроем админку Http-авторизацией средствами веб-сервера. Для этого нужно сгенерировать файл .htpasswd, что можно сделать утилитой htpasswd, обычно входящей в состав дистрибутива Apache. Синтаксис её такой:

htpasswd -mbc .htpasswd USER PASSWORD

Где USER - имя пользователя, а PASSWORD - его пароль. Можно поступить и проще - сгенерировать файл .htpasswd более наглядной программкой Htpasswd generator. Полученный файл кладется в папку wp-admin вместе с .htaccess со следующими инструкциями:

AuthUserFile /full/path/to/.htpasswd
AuthType Basic
AuthName “Access_Control”
Require valid-user

Вместо “/full/path/to/” нужно прописать полный путь до файла .htpasswd от корневого каталога. Всё, админку WP не зная этого пароля больше скорее всего никто не откроет. Ну а каким должен быть пароль я уже писал.

Важная поправка: существует плагин AskApache Password Protect, делающий это автоматически.

Пункт второй. Лишаем взломщика информации. В папке с темой есть файл header.php, из которого можно удалить строчку:

<meta name=”generator” content=”WordPress <?php bloginfo(’version’); ?>” />

Но лучше всего её поправить, скажем так:

<meta name=”generator” content=”Serendipity v.1.2-beta4” />

Военная хитрость, пусть развлекаются. Глядишь, после скупки эксплойтов к Serendipity, на WordPress сил и денег не останется… Также упоминания о платформе и версии могут быть в sidebar.php и footer.php - их тоже лучше убрать.

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

Пункт четвертый. Нужно ли говорить о том, что e-mail админа блога должен быть хорошо защищен и находиться под присмотром? Нужно ли говорить о том, что выходящие патчи, заплатки и обновления к WP и плагинам нужно ставить? Надеюсь, не нужно. Вы избавили свой блог от угрозы взлома процентов на 90%.

Пункт первый. У бесплатного движка есть недостаток - любой может скачать, поставить и изучить. И изучают, и находят ошибки. Регулярно. Не будем этого ждать - закроем админку Http-авторизацией средствами веб-сервера. Для этого нужно сгенерировать файл .htpasswd, что можно сделать утилитой htpasswd, обычно входящей в состав дистрибутива Apache. Синтаксис её такой:

htpasswd -mbc .htpasswd USER PASSWORD

Где USER - имя пользователя, а PASSWORD - его пароль. Можно поступить и проще - сгенерировать файл .htpasswd более наглядной программкой Htpasswd generator. Полученный файл кладется в папку wp-admin вместе с .htaccess со следующими инструкциями:

AuthUserFile /full/path/to/.htpasswd
AuthType Basic
AuthName “Access_Control”
Require valid-user

Вместо “/full/path/to/” нужно прописать полный путь до файла .htpasswd от корневого каталога. Всё, админку WP не зная этого пароля больше скорее всего никто не откроет. Ну а каким должен быть пароль я уже писал.

Вот онлайн тулза для генерации .htpass: http://www.askapache.com/online-tools/htpasswd-generator/

А вообще, советую при изменении тега generator просто найти все файлы, в которых этот текст есть и править.

Вот онлайн тулза для генерации .htpass: http://www.askapache.com/online-tools/htpasswd-generator/

А вообще, советую при изменении тега generator просто найти все файлы, в которых этот текст есть и править.

Это не моя статья, это статья Жилинcкого Владимира

Спасибо В.Жилинскому за интересную и познавательную статью. Отдельное спасибо Virtual’у за то, что эту статью вынес на всеобщее обсуждение. А автор ругаться не будет?;)

А автор ругаться не будет?;)

Из-за чего? Из-за того, что я его процитировал да еще и ссылку на его блог дал?

Спасибо В.Жилинскому за интересную и познавательную статью. Отдельное спасибо Virtual'у за то, что эту статью вынес на всеобщее обсуждение. А автор ругаться не будет?;)

Пожалуйста 😀
Нет, не будет, наоборот. 😎

Мой сайт: www.97h.ru, хостинг – Advanta. WordPress усановил сам, хотя и помучился. Проблема у меня в том, что при наборе в браузере УРЛа: www.97h.ru на экране монитора отображается эмблема Адванты и все, дальше хода нет, хотя по ФТП на сайт захожу без проблем, все папочки видны и делать я могу с ними все, что угодно. Как админ без проблем захожу в WordPress, создаю страницы, делаю записи и т.д., только просмотреть эти страницы в браузере не могу, хотя и даю команду: опубликовать!
cPanel также для меня открыта. И там все работает, по крайней мере то, с чем я пробовал работать.
Если кто знает в чем проблема подскажите, пожалуйста.

Удалите index.htm(index.html) из корня сайта

заметил за собой – после правки сорсов оставляю иногда файлы *.bak или *.old. всё ничего, но могут уйти конфиденциальные данные. Решаем таким образом: в корне правим файл .htaccess, добавляя в него:

<Files ~ ".(bak|old)$">
  order allow,deny
  deny from all
</Files>

в случае с WordPress MU будет не лишним закрыть доступ извне к таким файлам, как wp-settings.php (возможно открытие полного пути), к примеру.

Вообще великий минус в WP в том, что все нормальные КМС и движки, файлы в которых пути, пароли, настройки имеют приблуду .inc. в имени файла, чтобы можно было корректно их закрывать 🙁 а тут приходится с бубном бегать, все wp- не закроешь… приходится писать нехилые правила

ну.. с этим можно поспорить – ничего нехилого нет. всё на уровне доступа любому желающему. сходил не багтраг, сделал нужные выводы, пофиксил. всё просто 🙂

WordPress 2.5
Надо чтобы блог имел несколько пользователей с правами Upload files.
Ни в стандартной конфигурации ни в сочетании с Flexible Upload не осуществляется фильтрация.

Т.е. легко можно загрузить файл .PHP и потом его замечательно выполнить.
Можно ли как-то настроить чтобы загружались только разрешенные mime-types?

Как минимум нужно запрещать через .htaccess выполнение чего бы то ни было в директории uploads.

Мысль действительно замечательная.
Пробую вот так:

Options -ExecCGI +Indexes
не работает. не показывает даже картинки в папке

RemoveHandler .php .phtml .pl
AddType text/html .php .phtm .htm .html .phtml .pl
работает но не нравится — завязано на расширение, не универсально

Что можете посоветовать?

P.S. это "как минимум". а как максимум?

WordPress 2.5
Надо чтобы блог имел несколько пользователей с правами Upload files. 
Ни в стандартной конфигурации ни в сочетании с Flexible Upload не осуществляется фильтрация.

Т.е. легко можно загрузить файл .PHP и потом его замечательно выполнить.
Можно ли как-то настроить чтобы загружались только разрешенные mime-types?

RemoveHandler .php .php5 .php4 .php3 .phtml .pl
AddType text/plain .php .php .htm .html .shtml .phtml .pl .asp

Спасибо. Это работает. Пока так и закрою папки
Почему бы не автоматизировать эту настройку?

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

Про картинки это понятно. Речь шла о злонамеренном upload исполняемого кода. Тогда можно сделать все что угодно.

можно так-же включить в аплоадер проверку на наличие исполняемого кода (наличие <? и #usr) – это раз. в довесок к этому чекать имя загружаемого файла (расширение). это теоретически, но и к практике применить, думаю, будет не сложно. если есть необходимость можно и попробовать поковырять, ибо интересно..

Про картинки это понятно. Речь шла о злонамеренном upload исполняемого кода. Тогда можно сделать все что угодно.

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

вот еще нашлась статья по теме топика:
http://yakto.ru/inet/bezopasnost-wordpress-uyazvimost-wordpress-i-13-sposobov-oborony.html

А еще как средство защиты использовать ЧПУ.

вот вчера взломали сайта на джумле, нашли его через гугл по запросу "ru/index.php?option=com_user", все закрыли исправили и обновили, через 6 часов опять взломали 😆

Как ни скрывай движок, а определить не долго site.ru/category/nazvanie-categorii/
или /wp-login.php?action=lostpassword

если category заменить к примеру на NEWS или еще что подобное, сложнее разобраться
и чпу реализовать для админки что бы скрыть wp-login

я только ещё собираюсь ставить wordpress, ни разу не юзал

а если в админу директорию кинуть .htaccess с правами
denny from all
allow from "мой единственный ip"

ну и ещё куданить кинуть ?

а на файлы которые не надо менять поставить root-вские права, их не исправишь уже вроде как, только под root доступом…
собственно списочек файликов и папок надо составить, на которые такие права поставить можно 🙂

и папок, куда выставить denny from all Ж)

Йодированная соль для печенья.

http://wordpress.org/extend/plugins/askapache-password-protect

вот еще нашлась статья по теме топика:
http://yakto.ru/inet/bezopasnost-wordpress-uyazvimost-wordpress-i-13-sposobov-oborony.html

прочитал эту статью

в статье:
2.Удаление информации о версии WordPress
не нашёл у себя файлы header.php,sidebar.php и footer.php

но это не важно наверно, только вот в пункте
7.Создание файла robots.txt
они сами предлагают вписать строки типа:
Disallow: /wp-content/
Disallow: /wp-includes/
Disallow: /wp-admin/
Disallow: /images/
Disallow: /wp-login.php
Disallow: /wp-register.php
Disallow: /xmlrpc.php

robots.txt читается, любой сразу определит по этим строкам, что wordpress 🙂

Марна праця, як то кажуть у нас 🙂 Чтобы сделать WP совсем неузнаваемым, нужно его полностью переписать, но тогда это уже будет не WP.

А еще как средство защиты использовать ЧПУ.
вот вчера взломали сайта на джумле,  нашли его через гугл по запросу "ru/index.php?option=com_user", все закрыли исправили и обновили, через 6 часов опять взломали :lol:
Как ни скрывай движок,  а определить не долго site.ru/category/nazvanie-categorii/ 
или /wp-login.php?action=lostpassword
если category заменить к примеру на NEWS или еще что подобное, сложнее разобраться
и чпу реализовать для админки что бы скрыть wp-login

ЧПУ в защите не как не поможет! Как ты скроешь wp-login в чпу, у нему в таком случае можно и по чпу пройти и по wp-login.php!!! Другое дело переименовать в абракодабру wp-login вот это совсем другое дело, (ток над будет подправить некоторые файлы в вп)
Впринцепе как я и сделал. и

хорошая статья