Наша совместимая с PCI система CentOS 7 была недавно отмечена Trustwave как FAILED из-за уязвимости OpenSSH, помеченной как CVE-2017-15906, и было сказано, что «OpenSSH sftp-server позволяет создавать файлы нулевой длины в режиме только для чтения». Trustwave также заявил, что обновление до OpenSSH 7.6, по крайней мере, решит проблему.
Мы используем SFTP, и конфигурация была по умолчанию со следующим значением для подсистемы:
Subsystem sftp /usr/libexec/openssh/sftp-server
Поскольку в CentOS 7 еще нет официальных обновлений для обновления OpenSSH 7.4 до 7.6, я попытался обновить пакеты самостоятельно, ссылаясь на это руководство: Обновление OpenSSH на CentOS 6 или 7. Я добился успеха в этом аспекте, однако здесь есть одна большая проблема. У меня был заблокирован доступ к SSH, и все наши ключи больше не работают, даже когда ssh -vvv сообщает, что ключ принят. Нас выгнали сразу после входа в систему. Служба поддержки Google Cloud (мы используем экземпляры Google Cloud CE) считает, что существует несовместимость с 7.6 и CentOS 7, и что RedHat и CentOS еще не выпустили обновления и все еще могут тестировать и исправлять ошибки:
Команда поддержки ответила мне.
Они смогли воспроизвести проблему, развернув собственную машину CentOS 7 [и обновив OpenSSH]. Они также не смогли подключиться к экземпляру по SSH после обновления OpenSSH до версии 7.6.
Судя по вашему предыдущему сообщению, вы были правы. Они тоже считают, что проблема вызвана изменением конфигурации PAM. На самом деле модуль PAM обновился некорректно. Технический специалист по бэклайну сделал резервную копию /etc/pam.d/sshd перед внесением изменений, затем он заметил, что после обновления пропало много строк. Он сравнил два файла. В новой версии /etc/pam.d/sshd всего 6 строк, а в исходном файле не менее 19 строк.
Я хотел бы добавить, что OpenSSH версии 7.6 - это еще не изменение, которое RedHat / CentOS внесло в основной стабильный выпуск. Это означает, что хотя openSSH 7.6p1 выпущен, он еще не находится в стабильном режиме с Redhat (Centos). Команда Redhat все еще работает над исправлением некоторых ошибок.
Поэтому обновление до OpenSSH 7.6 в настоящее время не вариант.
Я также вижу, что эта уязвимость видна только в том случае, если SFTP находится в режиме только для чтения. Но как отключить этот режим я не знаю. Я пытался найти разные ресурсы, но, похоже, нет особого упоминания об этом режиме, а только «как они могут включить чтение только для определенного пользователя». Поскольку я использую файл конфигурации SSH по умолчанию, я не знаю, включен ли по умолчанию режим только для чтения или нет.
Я попытался изменить подсистемную часть /etc/ssd/sshd_config опять же:
Subsystem sftp internal-sftp
И сканирование PCI все равно не удалось.
Я добавил еще одну конфигурацию под ним:
Match Group psacln
ChrootDirectory /var/www/vhosts
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp
Что, я думаю, противоречит цели, потому что теперь я перехожу в основную папку vhosts вместо пользователя, которому назначена папка в vhosts (кажется, я могу назначить ChrootDirectory только папке, принадлежащей пользователю root). Я запросил сканирование на соответствие стандарту PCI после этого изменения и ожидаю результатов на момент написания этой статьи.
Если бы кто-нибудь мог указать мне, как эффективно отключить режим только для чтения на sftp-serverе OpenSSH или внутреннем sftp, я был бы очень признателен, поскольку я считаю, что это единственное, что мне нужно сделать, чтобы закрыть эту уязвимость.
Спасибо.
Вы не можете сделать ничего, чтобы сканирование не завершилось СБОЙ. Это потому, что Trustwave просто проверяет номер вашей версии OpenSSH и сообщает об уязвимости, как если бы она действительно существовала, независимо от вашей реальной конфигурации системы.
Для этого вам нужно будет оспорить вывод и объяснить меры, которые вы приняли.