Назад | Перейти на главную страницу

RHEL 6.3 Обновление OpenSSH и Apache

Мы только что запустили внешнее сканирование безопасности из 403Labs на одном из наших серверов (RHEL 6.3 x86_64) на соответствие PCI, и результаты, по-видимому, в основном говорят о том, что у нас есть несколько приложений, которые необходимо обновить, чтобы пройти сканирование.

Как уже было сказано, проблема, с которой я сталкиваюсь, заключается в том, что менеджер пакетов (yum) и использование репозитория remi не имеют версий, которые мне нужны для Apache и OpenSSH. Я уже выполнил следующее:

yum update
yum --enablerepo=remi,remi-test install httpd mysql mysql-server php php-common

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

Необходимые обновления:

   Current            Required
Apache 2.2.15 to >= Apache 2.2.23
OpenSSH 5.3   to >= 5.7

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

Кроме того, если у меня нет выбора, кроме установки из исходного кода, может ли кто-нибудь помочь мне определить, какие пакеты исходных текстов будут подходящими, чтобы я знал, что устанавливаю правильные версии для своей ОС?

Большое спасибо за любую помощь.

Отталкивать...

Red Hat Enterprise Linux так не работает. Установка из источника в соответствии с требованиями аудита открывает перед вами дополнительные проблемы безопасности и дополнительные расходы на управление.

Подход Red Hat к своим корпоративным операционным системам заключается в создании согласованной цели на протяжении всего жизненного цикла поддержки ОС. Более крупным корпорациям и корпоративным приложениям необходимо гарантировать двоичную совместимость на протяжении более 7 лет поддержки этих операционных систем. Red Hat не будет изменять второстепенные номера версий пакета, а вместо этого будет переносить изменения и исправления безопасности из более новых версий в более старый пакет.

Например, вы никогда не увидите Apache 2.2.23 в RHEL 5, но вы увидите соответствующие исправления безопасности (и некоторые функции), перенесенные из более новых версий Apache в версию 2.2.3.

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

Вот Журнал изменений EL Apache.

Сделайте перекрестную ссылку на CVE- * числа против CERT / Национальная база данных уязвимостей. Например, CVE-2011-3368 перечисляет уязвимость, которая затрагивает версии Apache до 2.2.21. Очевидно, что RHEL имеет только 2.2.3 в качестве основной версии, поэтому исправление безопасности было разработано, протестировано и перенесено на старую версию.

Не делай этого!

Перед тем, как выйти за пределы структуры поддержки поставщика ОС, вы должны убедиться, что это правильно.

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

Например (из старого сканирования Nessus) он объявляет, что Apache, поставляемый CentOS, уязвим, если его версия <2.2.14. Если вы вникнете в подробности об уязвимостях, вы обнаружите CVE-2009-3095, CVE-2009-3094 и т.п.

Просматривая их, вы обнаруживаете, что они были исправлены в текущих версиях комплектующих Apache, купленных RH и, следовательно, CentOS.

Я столкнулся с этим и с моей реализацией соответствия PCI, хотя я знал об обратном портировании патчей, упомянутых выше. Наше решение с apache заключалось в том, чтобы установить ServerTokens на «Prod» и ServerSignature на «Off» в /etc/httpd/conf/httpd.conf. Этот мудрый параметр указывает apache не сообщать номера версий и не сообщать обо всех модулях, которые он использует. Затем мы прошли сканирование.

Что касается SSH, идеальной настройкой является отключение доступа брандмауэром, чтобы только ваш офис мог подключиться к порту. Таким образом, сканирование не обнаружит его.

Если это невозможно, аудиторы PCI могут убедиться, что вы в безопасности, если докажете, что вы исправлены (обычно с помощью какой-либо утилиты для совместного использования экрана вы показываете, что `` yum update '' не показывает доступных обновлений) и у вас есть процедура для регулярных тестов . Я только что показал, что подписан на список рассылки по безопасности RedHat и что мы немедленно планируем обновление, если используемый нами компонент уязвим.

За исключением всего этого, вы должны иметь возможность подать апелляцию и пройти надлежащий тест на проникновение.