Я пытаюсь создать безопасный сайт WordPress в системе Debian 8 со следующими требованиями:
Я уверен, что это довольно стандартная установка. Тем не менее, я не могу найти руководство, как это сочетается друг с другом.
Во-первых, чтобы автоматическое обновление ядра с помощью FS_method «прямое» работало, в большинстве случаев весь WordPress должен принадлежать www-data, то есть:
chown -R www-data.www-data /var/www/wordpress
Кроме того, у меня есть локальная учетная запись «sftp-wordpress», которую я помещаю в группу «www-data».
Я сделал wp-content и все внутри группы доступными для записи (группа - это www-data, см. Выше), поэтому sftp-wordpress может писать, и - на всякий случай - я сделал «wp-content» и его подкаталоги setgid:
chmod -R g+w /var/www/wordpress/wp-content
find /var/www/wordpress/wp-content -type d -exec chmod g+s {} \;
Первая проблема: Чтобы настроить chroot, я помещаю в / etc / ssh / sshd_config следующее:
Match User sftp_wordpress
ChrootDirectory /var/www/wordpress/wp-content
ForceCommand internal-sftp -u 0002
AllowTcpForwarding no
Это не сработает, так как OpenSSH не любит разрешения и владельца ChrootDirectory:
fatal: bad ownership or modes for chroot directory "/var/www/wordpress/wp-content"
Итак, я отказался от требования chroot, отключив директиву ChrootDirectory.
На данный момент я могу загружать файлы в wp-content. Файлы будут отображаться с владельцем "sftp-wordpress" (это может быть проблема для обновления WordPress?) и группу www-data.
Что определенно другая проблема заключается в том, что загруженные файлы и каталоги не доступны для групповой записи, поэтому процесс Apache не сможет их изменить. И это проблема, если WordPress хочет их изменить.
"Umask 0002" не поможет, поскольку (в отличие от других вопросов здесь) не принуждать групповое разрешение на запись.
Фактически, загруженные файлы будут доступны для групповой записи на сервере, если они были доступны для групповой записи на клиенте - это далеко не решение, поскольку вы не можете ожидать, что SFTP исправит это на их стороне.
Я хотел бы услышать, есть ли последовательное решение для этой настройки WordPress.
Каталог chroot должен принадлежать root, чтобы openssh мог его принять, это в целях безопасности.
Для дальнейшего объяснения см .: неправильное владение или режимы для компонента каталога chroot
ChrootDirectory
Задает путь к каталогу, в который после аутентификации будет использоваться chroot (2). Все компоненты пути должны быть корневыми каталогами, которые не доступны для записи другим пользователям или группам.. После chroot sshd (8) меняет рабочий каталог на домашний каталог пользователя.
Я думаю, что решение могло бы заключаться в том, чтобы отделить место загрузки от того, где он будет доступен для просмотра WordPress.
Вы можете создать своего рода промежуточную область, где пользователь может загружать файлы через sftp-сервер openssh в chrooted месте. Затем в вашей системе есть cronjob, который через регулярные промежутки времени запускает скрипт, который проверяет место загрузки и делает все необходимое с загруженными файлами.
Он может просто отправить электронное письмо с просьбой о вмешательстве человека или выполнить автоматическую проверку файлов, сканирование на вирусы, что, по вашему мнению, может оказаться полезным. Затем скопируйте или переместите файл в место, где Wordpress сможет его обработать.
Я думаю, что на самом деле не существует последовательного решения, поскольку многие ситуации довольно уникальны. Но использование промежуточной области для загруженных файлов не редкость для многих целей. И это добавляет уровень безопасности.
Возможный ответ, кажется, состоит в том, что такая настройка действительно невозможна (без беспорядка перенастройки различных компонентов).
Альтернативой может быть отказ от FS_METHOD 'direct' в пользу альтернативного метода, такого как 'ssh', 'ftpext' или 'ftpsocket'. Это снизит требование, чтобы веб-сервер мог изменять файлы WordPress. Вместо этого вы бы сказали WordPress, как он может получать доступ к своим файлам и изменять их через FTP или SSH.