Опять сломали!!!

В очередной раз разработчики WordPress ломают совместимость… Хотя справедливости ради стоит отметить, что затронуты будут далеко не все плагины, а только те, которые полагаются на то, что функция wp_nonce_field() создаёт в форме поле с именем _wp_http_referer. Далее »

Автор: Vladimir, опубликовано в: WordPress, комментариев: 1

9
Дек
2009

Скажи «Нет!» взломщику: часть 2

Продолжение статьи Скажи «Нет!» взломщику.

Прошлый раз мы использовали swatch и iptables для защиты от нехороших ботов, пытающихся сделать наш компьютер частью ботнета. У приведённого способа был существенный недостаток: IP-адреса блокировались навсегда. Это плохо, так как IP-адреса можно подделывать.

Tamdiu discendum est, quamdiu vivas, поэтому сегодня рассмотрим вариант с блокированием атакующего на заданный промежуток времени. Далее »

Автор: Vladimir, опубликовано в: Linux, Безопасность, комментариев: 1

8
Дек
2009

Безопасный логин в WordPress с использованием nginx

WordPress, начиная с версии 2.6, имеет улучшенную поддержку работы с HTTPS.

У администратора есть две возможности:

Использование HTTPS для работы в панели управления (wp-admin).
Использование HTTPS только для входа в систему.

Первое достигается путём добавления строки

[-]

View Code PHP

define('FORCE_SSL_ADMIN', true);

в wp-config.php, второе — путём добавления строки

[-]

View Code PHP

define('FORCE_SSL_LOGIN', true);

Добавляем одну из этих двух строк в wp-config.php и проблема решена? Но в действительности всё не так, как на самом деле
Далее »

Автор: Vladimir, опубликовано в: WordPress, Безопасность, комментариев: нет

5
Дек
2009

Профиль AppArmor для nginx

Данный профиль AppArmor предназначается тем, кто знает, что такое AppArmor и сознательно решил использовать профиль для nginx. Профиль не является законченным решением, работающим из коробки, а должен рассматриваться только как шаблон.

При построении профиля молчаливо предполагалось:

рабочие процессы nginx выполняются от имени www-data:www-data;
файлы конфигурации nginx находятся в /etc/nginx (/etc/nginx/sites-enabled, /etc/nginx/sites-available, /etc/nginx/conf.d/*.conf, /etc/nginx/ssl);
пользовательские сайты расположены в /home/<user>/htdocs;
логи записываются в /var/log/nginx/*.log

Автор: Vladimir, опубликовано в: Linux, Администрирование, комментариев: 4

21
Ноя
2009

ACL как одно из решений проблемы работы web-сервера под root

Я довольно часто встречал конфигурацию, когда web-сервер работает под root, чтобы обойти жёсткие права доступа, установленные на каталоги пользователей. Рассмотрим на примере: предположим, что пользовательские сайты расположены в /home/<username>/, при этом права на каталог home установлены в 0711 (rwx--x--x), а права на пользовательские каталоги установлены в 0700 (rwx------). Такие права устанавливаются, чтобы изолировать пользователей друг от друга — один пользователь не сможет зайти и посмотреть домашний каталог другого пользователя. Такая мера популярна у администраторов виртуального (shared) хостинга.

Для того, чтобы web-сервер мог нормально обслуживать сайты, обычно используется одно из следующих решений:

web-сервер работает под учётной записью root;
права на домашний каталог устанавливаются в 0750 (rwxr-x---), а пользователь, под которым работает web-сервер, вносится в группу, которой принадлежит пользователь.