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

Неудачное соответствие PCI - удаленный SMTP-сервер уязвим для переполнения буфера.

Привет, ребята, я попытался разрешить прием IP-адресов сканеров через IPTABLES в порт SMTP, но сканирование все равно не удается.

Это ошибка: удаленный SMTP-сервер уязвим для переполнения буфера.

Сервер SMTP даже не падает. Я пробовал белый список IP в Exim, но сканер все еще выдает сервер и говорит, что сервер уязвим для открытого ретранслятора. Это на сервере CentOS cPanel / WHM. Я также включил настройку SMTP.

Кто-нибудь знает, как это исправить?

Спасибо

Результат вашей службы сканирования PCI, скорее всего, будет ложным, хотя его трудно сказать. Скорее всего, они совпадают с номером версии вашей SMTP-программы, обычно это объявляется при подключении к порту 25 и проверяется этот продукт и номер версии по списку известных уязвимых программ. И нашел совпадение.

Поскольку вы работаете на Centos, вам необходимо просмотреть всю историю изменений выпусков RPM службы SMTP в поисках журнала изменений, в котором указаны исправления безопасности. Скорее всего очень хорошо что RedHat перенес уязвимость переполнения буфера в более старую версию, но вам нужно вернуться, чтобы быть уверенным. Как только это будет сделано, вы можете пометить это как ложное срабатывание.

Резервное копирование исправлений безопасности - одно из основных преимуществ использования Linux с контрактом на поддержку. Centos - то же самое, но вы не можете ни о чем звонить, вы просто получаете исправления безопасности.

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

** РЕДАКТИРОВАТЬ: ЭТО НЕПРАВИЛЬНО - ИЗВИНИТЕ: Кроме того - в последний раз, когда я читал спецификации (около 3 лет назад), соответствие PCI не означает, что вы должны пройти какие-либо тесты инструмента сканирования уязвимостей - для этого требуется только наличие процедур для регулярного сканирования и решения проблем, а также средств управления, обеспечивающих это. **

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

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

Независимо от того, что сканер сообщает вам об этом, он должен выдавать вам справочный номер уязвимости из какой-либо общедоступной базы данных уязвимостей. Прочтите это, а затем проверьте, исправлена ​​ли эта конкретная уязвимость в установленном вами пакете, а затем задокументируйте этот факт и двигайтесь дальше.

Если вы платите внешней аудиторской фирме за подготовку к аудиту PCI, а они не предоставляют вам эти данные, вы должны спросить их - и если они не предоставят их, запустите nessus самостоятельно, он вам скажет.

Открытое реле верное - служба внешнего сканера предполагает, что оно имеет такое же представление о вашей сети, что и остальная часть Интернета. Если вы занесете его в белый список, ретрансляция разрешена, и предполагается, что все остальные тоже. Если порт 25 обычно заблокирован для публики, вы должны оставить его заблокированным для целей сканирования - это часть вашей безопасности.

Просто расширение для @ sysadmin1138, но вам нужно найти номер CVE, который они предоставили для уязвимости (вероятно, CVE-200something-numbers). Найдите в Google эту уязвимость и нажмите любую ссылку с надписью «RedHat», «CentOS» или даже «Fedora». Эта страница сообщит вам, была ли она решена, и в каких версиях она была решена. Сравните вашу версию Exim с этим, а затем объясните свои выводы ASV, который отметит, что это ложное срабатывание.

Возможно, вам не повезло с CPanel (а не с использованием стандартных репозиториев, если я правильно помню).

Подождите, какая у вас ошибка и какой сканер используется против вашего почтового сервера? eEye Retina? Нессус?

В одном предложении вы говорите: «Это ошибка: удаленный SMTP-сервер уязвим для переполнения буфера».

... позже в своем вопросе вы скажете: «Я пробовал внести IP в белый список в Exim, но сканер по-прежнему выдает сервер и говорит, что сервер уязвим для открытия ретранслятора».

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

Переполнение буфера чаще всего приводит к компрометации учетной записи пользователя, запускающего рассматриваемый демон. Переполнение буфера иногда является отказом в обслуживании, но, как правило, не является и часто приводит к компрометации на уровне системы после завершения дальнейшего исследования. Если на самом деле проблема, это может иметь большое значение. Я бы поставил его между средним и высоким, в зависимости от того, где он касается моей инфраструктуры, и от размера занимаемой площади.

Вам нужно будет проверить две основные вещи:

  • Сканер должен точно определить рассматриваемую уязвимость. Изучите его и попытайтесь воспроизвести / проверить уязвимость.
  • Сканер должен идентифицировать точный метод, используемый для определения уязвимости, который обычно является самым простым способом определения легитимности. В случае ложного срабатывания должно быть достаточно ясно, в каких методах используются используемые методы и какая уязвимость предположительно входит в область действия.

Я обнаружил, что Scan Alert (теперь McAfee) редко дает ложные срабатывания. Если ваш утвержденный поставщик сканера не имеет истории ложных срабатываний, я предполагаю, что это законная уязвимость, пока вы доказать в противном случае.

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