Ещё 10 уловок для защиты Wordpress'a

браво

2. Убираем показ лишней информации

А разве и так не понятно, что если в админку не пустило, то пароль не верный? Хоть выводи сообщение хоть не выводи

1,4,6,7,10 пункты подойдут не только тем кто пользуется wordpress, в общем взял на заметку

Так же, если есть возможность — можно поставить mod_security на апач.

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

Интересно почему заграничные чуваки так любят писать «10 приемов», «5 правил», «7 способов», «10 возможностей», «8 отличий», «6 уловок».
А вот наши — нет. Наши сделают просто большую простыню текста.
Из гордости за народ хочется предположить, что это от широты души и от необъятности просторов.

Не совсем понял

4. Используем .htaccess для защиты файла wp-config

Ведь апач его и так не отдаст? Или нет?

и

9. Убить админа. (Нет дефолтному юзернейму «admin»)!

UPDATE wp_posts SET post_author = 'Ваш новый логин' WHERE post_author = 'admin';

разве не оптимальнее было бы давать юзерам id, чтобы не хранить тысячи «admin» вместо «1»? И запрос такой не нужен был бы…

Это отсюда? www.smashingmagazine.com/2010/07/01/10-useful-wordpress-security-tweaks/

Неправильно переведен исходный текст «the login_errors() function» как «функция the login_errors()»

Ежегодная статья по защите WP на хабре.

Хоть что-то не меняется

п.4

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

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

Работа этого плагина проста – он проверяет все длинные запросы (более 255 символов) и наличие php-функций eval или base64 в URI.

Судя по коду функции она делает не то что вы написали. Она проверяет ВСЕ запросы на наличие этих строчек и помимо этого выдает ошибку на запросах длиннее 255 символов. Сам код плагина тоже один из шедевров говнокодинга в общем то… Собачки перед header и exit, strpos вместо stripos да и само по себе куча strpos-ов подряд. Буэ…

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

Еще забавно — частота, с которой в статье встречается слово «просто», сильно зашкаливает)

Насчет скрываем версию WordPress, я и на Smashingmagazine писал, что кроме generator, надо бы файл readme.html удалять, не видел еще чтобы кто-нибудь его удалял.

9. Убить админа. (Нет дефолтному юзернейму «admin»)!

>UPDATE wp_users SET user_login = 'Ваш новый логин' WHERE user_login = 'Admin';

Прячем админа.

> UPDATE wp_posts SET post_author = 'Ваш новый логин' WHERE post_author = 'admin';;

Указываем злоумышленнику на нового админа :)

Статья интересная, но многие советы спорные.

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

Проблему личеров можно обойти еще проще — выкладывать картинки на крупные надажные фотохостинги, а не хранить у себя на серваке. Это еще и просто обычный трафик снижает. Риск потери доли поискового трафика мне кажется несущественным для большинства блогов.

5. тем самым и убираем копирайт вордпресса т.е powered by — плохо!

кто-нить может пояснить, зачем писать плагин в п.7, когда проверить URI можно и рерайтом в п.1.

1. Если бы тут было применено это правило, то Вы бы не смогли запостить свою статью. Это в чистом виде лечение насморка отрубанием головы.
4. ни от чего не защищает, так как добираться до этого файла обращаясь к нему никто не будет — только через уязвимости в других файлах.
7 этот пункт спорный очень
8 не все корректно отдают referrer. Сами дураки, конечно, но сути совета не меняет.
В общем, как чтиво — нормально, как руководство к действию — очень неоднозначно.

Что-то много лищнего имхо.

Спамеры дохнут под акисмет
Для персонального блога лучше просто запретить авторизацию и wp-admin по IP
Личеры лично меня не беспокоят совершенно поскольку все картинки хранит пикаса.

1.
Совершенно неоправдан с точки зрения использования XSS (защитит от банального <script>js code</script>, не более.
Запрет переопределений через _REQUEST ни в какие ворота не лезет, вероятно вы не совсем понимаете смысла GPC и _request.
Также не защитит от глобальных переопределений через extract, в принципе единственное что тут можно сделать — перейти на последний пхп, register_globals must die :)

4.
Единственное, от чего это может защитить — «падение» php, тоже не особо оправдано :)

7.
— Запрет eval() ничего не даст. Обычные ошибки движкописателей, при которых можно выполнять пхп код — это preg_replace с #e и, вероятно, create_function. В первом случае будут использоваться {${phpinfo()}}, во втором — в зависимости от ситуации, но вот eval() там точно не будет присутствовать :)
— CONCAT — а что мешает хацкеру не использовать объединения?
— UNION+SELECT — прямой вывод с помощью nion+select обходится многими способами.
1) union/**/select
2) подзапросы (просто select)
3) вывод через ошибки duplicate и многие другие
— base64 не единственная функция кодирования в пхп :))
Но что реально тут поможет, или хотя бы затруднит хацкеру взлом, это фильтрация конкретно «select», «substring». Главное чтобы они не встречалось в ваших ЧПУ :)

8. Ничто не мешает нам поставить реферер :)

как вариант, еще можно добавить во все файлы php в директории /wp-content/ следующую строку

error_reporting (0);

Для примера: адрес blog.ru/wp-content/themes/twentyten/ выдаст нам ошибку обработки php, в котором будет раскрыт путь, и соответственно логин доступа с хостингу.

Как это работает?
Данная строка запрещает вывод ошибок php, то есть при ошибке в файле php не будут выведен путь к файлу с ошибкой.