Какие дополнительные меры безопасности вы добавляете к своим установкам CMS с открытым исходным кодом?

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

Я использую Wordpress и Joomla в некоторых проектах своих клиентов и всегда стараюсь создать какую-то дополнительную безопасность. За исключением постоянного обновления ваших файлов до последней версии, что вы обычно делаете, чтобы повысить безопасность в этом сценарии? Некоторые из моих мыслей:

  • Я всегда меняю имя «admin», когда это применимо;

  • Я хотел бы не указывать явно, какие технологии я использую, но, поскольку я хочу продвигать CMS (я думаю, это минимум, который я должен сделать), я просто не говорю точную версию, чтобы злоумышленники не знали какие именно уязвимости они могут атаковать (например, wordpress автоматически создает метатег в html со словами «Wordpress 2.8.4»);

  • Установите правильные разрешения в каталогах и сценарии bash на моем сервере, которые запускаются каждый день в 0 часов, устанавливая 755 для каталогов, которые я, возможно, изменил на 775 в течение дня и забыл вернуться;

  • Когда это применимо, я устанавливаю конфигурацию apache для ограничения ips.

Что еще я должен попытаться сделать? Какие готовые решения вы обычно применяете для своих установок?


person GmonC    schedule 22.08.2009    source источник


Ответы (5)


Используя что-то вроде mod_security или mod_evasive Модули Apache тоже могут быть идеей — хотя я полагаю, что они требуют некоторой настройки; и вы должны проверить, что ваш веб-сайт все еще работает нормально, прежде чем использовать их на своем рабочем сервере.
Поскольку они являются модулями Apache, для этого также требуется, чтобы вы могли установить новый модуль Apache, что означает, что вы должны быть администратором сервера.


На чистом уровне PHP существует инструмент под названием PHP-IDS ; цитируя его сайт:

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

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


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

person Pascal MARTIN    schedule 22.08.2009

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

Если приложение позволяет изменить путь администратора, как правило, это тоже хорошая идея. Например, с помощью поиска и замены довольно просто изменить администратора Wordpress по умолчанию с /wp-admin на что-то совершенно другое (например, /my-admin). Хотя это не всегда возможно.

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

Другие вещи включают отключение или удаление любых модулей/расширений/плагинов, которые не являются на 100% необходимыми для работы системы. Личная проверка всех пользователей MySQL, чтобы убедиться, что никто не может подключиться к серверу удаленно. Вы также можете настроить chroot-тюрьму для всех пользователей на сервере (кроме root, конечно), чтобы они были заперты в каталоге и не могли выбраться из него.

person Steven Surowiec    schedule 22.08.2009

См. Усиление безопасности Wordpress и Усиление безопасности Wordpress с помощью htaccess в кодексе wordpress.org.

В Wordpress поместите это

function remove_header_info() {

remove_action('wp_head', 'wp_generator');
}

add_action('init', 'remove_header_info');

в файле functions.php темы, чтобы удалить версию WP из вывода wp_head в header.php.

person markratledge    schedule 22.08.2009

В Joomla я бы изменил префикс базы данных на что-то отличное от jos_.

person giraff    schedule 24.08.2009

Я нашел две интересные ссылки, по которым можно добавить информацию о Wordpress.

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

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

person GmonC    schedule 08.09.2009