У меня установлена чистая, стандартная версия CentOS 7, и теперь (после сканирования безопасности) я хочу обновить пакеты, чтобы исправить известные проблемы безопасности (все они имеют номера CVE, а некоторые из них уже довольно старые).
Почему-то CentOS 7 не особо заботится об этих проблемах безопасности (большую проблему представляет также PHP, который застрял на версии 5.4 и не имеет возможности обновиться).
Как мне следует решать проблемы безопасности в CentOS, помимо простого yum update?
решение1
Вы утверждаете следующее:
У меня установлена чистая, стандартная версия CentOS 7, и теперь (после сканирования безопасности) я хочу обновить пакеты, чтобы исправить известные проблемы безопасности (все они имеют номера CVE, а некоторые из них уже довольно старые).
Не паникуйте! С вашей установкой CentOS 7 все в порядке.
Реальность такова, что CentOS 7 в полном порядке, и многие из элементов, которые вы считаете «неисправленными», на самом делебэкпортированный. Это означает, что хотя у вас могут быть старые основные версии таких элементов, как PHP, команда CentOS выполняет бэкпорт необходимых исправлений, чтобы сделать пакеты в CentOS 7 такими же стабильными и безопасными на всех уровнях, как и более новые выпуски упакованного программного обеспечения.
Также как веб-разработчик, я определеннонехочу быть на «передовой» новой версии PHP. Мне нравится поддерживать стабильность на известной, поддерживаемой версии. И PHP 5.4 вполне подходит. Многие сайты по-прежнему используют PHP 5.3 (обратно портированную) по тем же причинам. Переход на основную версию PHP сломает больше вещей, чем когда-либо «улучшит» вашу установку.
«Неопределенный» характер сканирования безопасности веб-сайтов.
Но вы также упоминаете «сканирование безопасности». Что вы подразумеваете под «сканированием безопасности»? Некоторые веб-инструменты сканирования безопасности просто перечисляют все недостатки, которые они могут найти, и выдают панические общие оповещения. Многие из этих панических оповещений основаны только на основных версиях, таких как PHP 5.4, и ни на чем другом.
И причина, по которой эти сканирования веб-сайтов реагируют таким образом, заключается в том, чтобы создатьFUD (страх неопределенности и сомнений)в тех, кто их использует, чтобы спонсоры такой услуги могли, например, продать запаниковавшему пользователю какую-нибудь онлайн-услугу или консультационный продукт. Многие из этих сканов полезны в определенной степени, но вы должны воспринимать их ссильная доля скепсисаи долженвсегда исследуйтепретензии далее, если что-то вас беспокоит.
Более серьезная проблема, если вы меня спросите, заключается в том, что ваш сервер каким-то образомраскрытие точной версии PHPмиру. И это не проблема CentOS. Этопроблема с укреплением сервера. Это означает, что хорошо защищенные серверы никогда не раскрывают точную версию используемого основного программного обеспечения, чтобы никто не мог подумать о наличии каких-либо уязвимостей.
Мой совет? Если вы сделали yum updateи он говорит, что все обновлено, значит, все обновлено. Но, как я уже сказал, укрепление сервера — это на 100% другая проблема, которую шаблонные сканирования безопасности, похоже, никогда не решают. Но вот как вы можете справиться с этой специфической проблемой PHP. И процесс довольно прост.
Усиление защиты PHP путем отключения expose_php.
Сначала найдите файл конфигурации PHP ( php.ini) и откройте его следующим образом; в этом примере используется nanoпуть к файлу в Ubuntu, но концепция та же:
sudo nano /etc/php5/apache2/php.ini
Теперь выполните поиск в этом файле для строки, которая настраивает expose_php. Глядя наофициальная документация PHP, expose_phpописывается следующим образом:
Сообщает миру, что на сервере установлен PHP, включая версию PHP в заголовке HTTP (например, X-Powered-By: PHP/5.3.7).
Так что зная это, я уверен, что сканирование безопасности просто увидело X-Powered-Byзаголовок и отреагировало. Но любой, кто занимается настоящим администрированием безопасности, может сказать вам, что проблема не в номере версии, а в том, чтозаголовок вообще не отображается. Поэтому просто измените это expose_phpзначение следующим образом:
expose_php = Off
А затем перезапустите Apache и попробуйте снова это сканирование безопасности. Черт возьми, вы даже можете проверить заголовки для вашего сервера из командной строки, используя curlвот так:
curl -I example.com
Возвращаемые заголовки теперь должнынетсодержать любую информацию о номере версии PHP.
Пока вы этим заняты, укрепите Apache.
Пока безопасность вызывает беспокойство, я бы рекомендовал также усилить Apache, пока вы этим занимаетесь. Просто откройте этот файл конфигурации Apache; снова основан на Ubuntu, но найдите эквивалент в CentOS:
sudo nano /etc/apache2/conf.d/security
Затем найдите ServerTokensи установите значение «production» следующим образом:
ServerTokens Prod
После этого найдите ServerSignatureи отключите его:
ServerSignature Off
Наконец, найдите TraceEnableи отключите и это:
TraceEnable Off
Перезапустите Apache и проверьте заголовки — или просканируйте сервер на безопасность — еще раз. Теперь все должно быть в лучшей форме.
Основная концепция этих простых идей по укреплению безопасности заключается в том, что веб-сайт, настроенный с конфигурацией по умолчанию, которая выставляет внутренние компоненты миру, отправляет сообщение вредоносным ботам о том, что, во-первых, сервер находится в состоянии по умолчанию, а во-вторых, на сервере установлено «старое» программное обеспечение. Таким образом, такой незащищенный сервер может стать хорошей целью для атаки. Запутывая детали в возвращаемых заголовках, вы делаете свой сервер менее желанной целью, поскольку скрипт не может определить, к чему вы можете быть уязвимы.
решение2
Почему вы думаете, что CentOS не волнуют эти проблемы безопасности? Redhat (и, следовательно, CentOS) портируют изменения, так что вполне вероятно, что они портировали известные проблемы безопасности для ваших проблем.
Что касается PHP, вы можете добавитьРепозиторий Webtacticчтобы получить PHP5.6.