У меня есть полностью исправленный сервер CentOS 5.5, который не проходит проверку соответствия Trustwave PCI. Объекты, на которые он жалуется, - openssl <0.9.8.o.
rpm -q openssl показывает: openssl-0.9.8e-12.el5_5.7
Баннер заголовка apache показывает: Сервер: Apache / 1.3.41 (Unix) PHP / 5.2.14 mod_psoft_traffic / 0.2 mod_ssl / 2.8.31 OpenSSL / 0.9.8b mod_macro / 1.1.2
(обратите внимание: этот баннер apache даже не показывает установленную версию)
У openssh и php аналогичная ситуация (заявленная версия меньше минимальной для соответствия PCI).
Нужно ли мне собирать все эти библиотеки из исходного кода, чтобы получить их в последней версии? Или есть способ сообщить CentOS yum об установке новой версии вместо исправленной версии с обратным переносом? Я бы предпочел не выходить за пределы yum, если это возможно, чтобы упростить дальнейшее обслуживание
Все сканирования PCI выполняют проверку версии на основе заголовков, а затем жалуются на около тридцати проблем, которые у вас есть. Что они не принимают во внимание, так это то, что исправления безопасности переносятся обратно в пакеты RHEL. Пока вы используете самые свежие пакеты, все будет в порядке. Что вам нужно сделать после неудачного сканирования, так это открыть заявку на оспаривание результатов. Затем вам нужно показать, какая версия действительно установлена
rpm -q httpd
Затем вам нужно покопаться в журнале изменений rpm, чтобы найти каждый упомянутый экземпляр CVE.
rpm -q --changelog httpd
Где можно найти такие вещи:
* Thu Dec 03 2009 Joe Orton <jorton@redhat.com> - 2.2.14-1
- add partial security fix for CVE-2009-3555 (#533125)
Наконец, вы должны сделать ссылку на соответствующую ссылку на сайте Redhat, чтобы показать, что она была рассмотрена, поскольку никто на стороне сканирования PCI на самом деле не будет смотреть на RPM.
https://www.redhat.com/security/data/cve/CVE-2009-3555.html
Вы, вероятно, будете ходить туда и обратно несколько раз, а затем, наконец, получите чистый счет здоровья, если действительно обновитесь. После того, как вы закончите, обязательно поместите все документы поддержки в свою вики, так как сканирование PCI будет сбрасываться каждые квартал или около того и удалит все упоминания предоставленной вами информации, и вам нужно будет сделать это снова.
Обратное портирование исправлений кажется предпочтительным путем для многих дистрибутивов. Это не решение, но вы должны подавить идентификацию сервера, установив "ServerTokens Prod" и "ServerSignature Off" в вашем httpd.conf.
Это может показаться мне спорным, но я не думаю, что очистка баннера учитывается при сканировании уязвимостей, поскольку это часто приводит к множеству ложных срабатываний. Я думаю, что сканер действительно должен пытаться увидеть, существуют ли известные уязвимости для конкретной версии библиотеки, а не делать простых предположений. В некоторых случаях они действительно прилагают определенные усилия, чтобы увидеть, существует ли уязвимость. Примером может быть ssl-шифр и протокол сканирования.
Конечно, проблема, с которой сталкивается при подавлении идентификации сервера, заключается в том, что о многих уязвимостях, о которых ранее сообщалось, больше не сообщается, и администратор рискует потерять свои обязанности по установке исправлений. Однако это немного парадоксально, потому что другие типы сканирования уязвимостей жалуются на проблемы с раскрытием информации, если для ServerTokens не задано значение Prod.
Вы должны скомпилировать все из исходников, по сути, создав свой собственный дистрибутив apache, но с частотой обновлений вы будете часто компилировать новые сборки, и не у всех есть время для этого.
Это не ответ на ваш вопрос, но я подозреваю, что apache сообщает версию openssl, для которой он был скомпилирован, а не версию, которую он фактически использует. В Fedora яснее:
[Fri May 13 03:45:05 2011] [info] mod_ssl/2.2.17 compiled against Server: Apache/2.2.17, Library: OpenSSL/1.0.0a-fips
[Fri May 13 03:45:05 2011] [notice] Apache/2.2.17 (Unix) DAV/2 PHP/5.3.6 mod_ssl/2.2.17 OpenSSL/1.0.0d-fips configured -- resuming normal operations
$ rpm -q openssl.x86_64
openssl-1.0.0d-1.fc14.x86_64