Prática recomendada para WordPress, atualizações automáticas diretas e acesso SFTP para usuários

Question

Estou tentando configurar um site WordPress seguro em um sistema Debian 8 com os seguintes requisitos:

• atualizações automáticas do núcleo (FS_method "direct")
• acesso SFTP com chroot a / wp-content (para um único usuário)

Tenho certeza de que essa é uma configuração bem padrão. Ainda assim, não consigo encontrar um tutorial sobre como isso se encaixa.

Primeiro, para fazer atualizações automáticas com o método FS_method "direct", a maioria do WordPress deve ser de propriedade da www-data, ou seja:

chown -R www-data.www-data /var/www/wordpress

Além disso, tenho uma conta local "sftp-wordpress", que incluo no grupo "www-data".

Eu fiz wp-content e tudo dentro de group-writable (o grupo é www-data, veja acima), então sftp-wordpress é capaz de escrever, e - para estar no lado seguro - eu fiz "wp-content" e seus subdiretórios setgid:

chmod -R g+w /var/www/wordpress/wp-content
find /var/www/wordpress/wp-content -type d -exec chmod g+s {} \;

Primeiro problema: Para configurar o chroot, coloco o seguinte em / etc / ssh / sshd_config:

Match User sftp_wordpress
    ChrootDirectory /var/www/wordpress/wp-content
    ForceCommand internal-sftp -u 0002
    AllowTcpForwarding no

Isso não funcionará, já que o OpenSSH não gosta das permissões e do proprietário do ChrootDirectory:

fatal: bad ownership or modes for chroot directory "/var/www/wordpress/wp-content"

Então eu tirei o requisito de chroot por enquanto, desabilitando a diretiva ChrootDirectory.

Neste ponto, posso fazer upload de arquivos para o conteúdo do wp. Os arquivos aparecerão com o proprietário "sftp-wordpress" (que pode ser um problema para a atualização do WordPress?) E o grupo "www-data".

O que é definitivamente outro problema é que os arquivos e diretórios enviados não podem ser gravados em grupo, para que o processo do Apache não possa modificá-los. E isso é um problema se o WordPress quiser modificá-los.

A "umask 0002" não ajudará, já que (diferentemente de outras perguntas aqui) ela não reforçará a permissão de gravação em grupo.

Na verdade, os arquivos enviados por upload serão graváveis em grupo no servidor, se eles forem graváveis em grupo no cliente - isso está longe de ser uma solução, já que você não pode esperar que o SFTP conserte isso do lado deles.

Gostaria de saber se existe uma solução consistente para essa configuração do WordPress.

    

Answer 1

O diretório chroot precisa ser de propriedade do root para que o openssh o aceite, é para fins de segurança.

Para mais explicações, consulte: propriedade incorreta ou modos para o componente de diretório chroot

ChrootDirectory
Specifies the pathname of a directory to chroot(2) to after authentication. All components of the pathname must be root-owned directories that are not writable by any other user or group. After the chroot, sshd(8) changes the working directory to the user's home directory.

Acho que uma solução poderia ser separar o local do upload de onde ele poderá ser visto pelo wordpress.

Você pode criar um tipo de área de preparação onde o usuário pode fazer upload de arquivos através do servidor openssh sftp em um local chrooted. Em seguida, seu sistema tem um cronjob que executa um script em intervalos regulares, que verificará o local do upload e fará o que for apropriado com os arquivos enviados.

Poderia enviar um e-mail pedindo intervenção humana, ou fazer algumas verificações automáticas de arquivos, verificações de vírus, o que você achar valer a pena. Em seguida, copie ou mova o arquivo para o local onde o wordpress possa manipulá-lo.

Eu acho que não há realmente uma solução consistente, pois muitas situações são bastante únicas. Mas usar uma área de teste para arquivos enviados não é incomum para muitos propósitos. E isso adiciona um nível de segurança.

    

Answer 2

Uma possível resposta parece ser que essa configuração não é possível (sem uma confusão de reconfiguração de vários componentes).

Uma alternativa seria abandonar o FS_METHOD 'direct' em favor de um método alternativo como 'ssh', 'ftpext' ou 'ftpsocket'. Isso eliminaria o requisito de que o servidor da Web pudesse alterar os arquivos do WordPress. Em vez disso, você diria ao WordPress como ele poderia acessar e alterar seus próprios arquivos via FTP ou SSH.