TrustWave стал немного лучше приспособлять CentOS к сканированию - теперь я могу по крайней мере выбрать «У меня есть резервное программное обеспечение», когда я подаю спор. Но они по-прежнему обеспечивают отличную гарантию занятости, требуя часов кропотливого наведения на свой веб-сайт каждый месяц.
Теперь к моему вопросу. CVE-2016-10009 не был исправлен разработчиками RHEL, и есть нет прямого исправления для CentOS. В ответе TrustWave на мой первоначальный спор есть следующее примечание:
Поскольку этот вывод влияет на соответствие стандарту PCI DSS, необходимо подтвердить, что он каким-то образом был устранен. Требования, перечисленные в отчете о сканировании, заключаются в обновлении системы или использовании упомянутых компенсирующих элементов управления (например, никогда не загружать модули PKCS # 11 с путей вне доверенного белого списка (настраивается во время выполнения)).
Последний патч OpenSSH содержит исправления, перенесенные до OpenSSH 7.3, и мне неясно, будет ли устранена эта конкретная уязвимость. Упомянутый «компенсирующий контроль» - разрешающий только модули из белого списка - это именно то исправление, которое было внесено в 7.4, так что это бесполезно, и в отчете о сканировании ничего не перечислено.
Поэтому я ищу изменение конфигурации, которое удовлетворит сканер, но я не смог его найти. Вот достойное объяснение вопроса. Что я могу сделать? Полностью отключить PKCS # 11?
Это уязвимость, при которой вредоносный ssh сервер может атаковать клиент если клиент подключился с помощью ssh-agent forwarding, и каким-то образом установил вредоносный файл в файловую систему клиента.
Я также думаю, что TrustWave сильно переоценила важность этого вопроса.
Тем не менее, очевидный обходной путь - отключить пересылку агента в /etc/ssh/sshd_config.
AllowAgentForwarding no
Имейте в виду, что если сервер скомпрометирован, злоумышленник может просто удалить его, а затем ждать, пока несчастные администраторы соединятся со своими агентами. Так что это своего рода нелепый обходной путь.
Я думаю, как предположил @pilcrow, это уязвимость на стороне клиента, поэтому обходной путь будет на стороне клиента, чтобы установить флаг ForwardAgent no в файле ssh_config.
Я считаю, что это спорный вопрос.
Насколько я понимаю, Trustwave проверил уязвимость и скорректировал свой рейтинг CVSS / серьезности, чтобы обнаружение больше не считалось ошибкой PCI.
(Также стоит повторить, что AllowAgentForwarding no это глупый отвлекающий маневр. Это конфигурация на стороне сервера, а это уязвимость на стороне клиента.)