2

У меня установлен чистый стандартный CentOS 7, и теперь (после сканирования безопасности) я хочу обновить пакеты, чтобы исправить известные проблемы безопасности (у них всех есть номера CVE, а некоторые уже устарели).

Так или иначе, CentOS 7 на самом деле не заботится об этих проблемах безопасности (большая проблема также в PHP, который застрял на 5.4, без какого-либо хорошего способа обновления).

Как мне решать проблемы безопасности в CentOS, кроме простого yum update?

2 ответа2

4

Вы заявляете это:

У меня установлен чистый стандартный 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 и установите для «производства», как это:

ServerTokens Prod

После этого найдите ServerSignature и отключите его:

ServerSignature Off

Наконец, найдите TraceEnable и отключите это:

TraceEnable Off

Перезапустите Apache и снова проверьте заголовки - или просканируйте сервер. Теперь вы должны быть в лучшей форме.

Основной концепцией этих простых идей по защите является веб-сайт, который настроен с конфигурацией по умолчанию, которая раскрывает внутреннее устройство миру, отправляет сообщение вредоносным ботам о том, что один сервер находится в состоянии по умолчанию, а два - сервер работает «старше». программного обеспечения. Таким образом, такой незащищенный сервер будет хорошей целью для атаки. Обфусцируя детали в возвращаемых заголовках, вы делаете свой сервер менее желательной целью, так как сценарий не может сказать, что вы уязвимы.

0

С чего вы взяли, что CentOS не заботится об этих проблемах безопасности? Redhat (и, следовательно, CentOS) изменяет бэкпорт, поэтому вполне вероятно, что они перенесли известные проблемы безопасности для ваших проблем.

Что касается PHP, вы можете добавить Webtactic Repo, чтобы получить PHP5.6.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .