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

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

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

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

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

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

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

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

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

На чистом PHP-уровне есть инструмент PHP-IDS ; цитируя его веб-сайт:

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

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

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

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

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

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

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

См. Hardening WordPress и Hardening WordPress с помощью htaccess на wordpress.org codex.

В WordPress поставьте это

 function remove_header_info() { remove_action('wp_head', 'wp_generator'); } add_action('init', 'remove_header_info'); 

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

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

Я нашел две интересные ссылки, которые могут добавить информацию о WordPress.

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

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