Uma maneira segura de confinar os usuários de login do FTP em um único diretório

Question

Eu precisava fornecer logins FTP de vários usuários, alguns capazes de escrever, alguns apenas para ler, em um único diretório raiz do FTP. Eu queria muito que eles não vissem o sistema de arquivos acima do diretório. Depois de pesquisar - parece que esse é um problema comum - defini a opção de configuração user_local como o diretório raiz e confinei os usuários a esse diretório usando a opção chroot_local_users ou chroot jail. Isso basicamente funciona.

Meu problema é que, embora eu não saiba por quê, confiar na segurança do chroot por causa da segurança é geralmente desaprovado e, o mais importante, pelo menos (um membro da) equipe de desenvolvimento do kernel.

Então, como posso limitar meus usuários de login a (mesmo) não ver nada acima do diretório raiz definido sem o chroot jail ?? (esta é a parte "segura" da questão aludida no título)

Além disso, por motivos de segurança (que ainda não entendi), as versões modernas de vsftpd não permitem que o diretório raiz do usuário seja gravável, deixando assim duas opções: 1. ou para desativar o recurso de segurança e deixar o root writeable ou 2. para remover os bits de gravação da raiz e criar um subdiretório gravável nele. O primeiro está brincando com fogo e este último é feio e propenso a erros (usuários tentando escrever na raiz e recebendo erros ...) Eu escolhi o último.

Então, como o serviço FTP é feito corretamente? O que significa como os usuários podem ser impedidos de ver partes irrelevantes do sistema de arquivos de maneira segura? O FTP é uma maneira intrinsecamente insegura de distribuir arquivos? Se assim for, há um caminho melhor. Tentando acertar isso ...

    

Answer 1

Nota: esta solução funciona bem para mim e é fácil de configurar. Supondo que você use o vsFTPd.

Eu prendi todos os usuários ao diretório inicial deles e compartilhei uma pasta chamada "Compartilhada" entre todos eles.

1. Usuários de prisão para sua casa diretamente

   $ sudo vi /etc/vsftpd/vsftpd.conf
   

   Certifique-se de que esta é a seguinte configuração:

   anonymous_enable=NO
   local_enable=YES
   chroot_local_user=YES
   

   Reinicie o vsftpd:

   $ sudo service vsftpd restart
   

2. Crie uma pasta compartilhada para todos os usuários e conceda permissões 'ftp'

   $ cd /var/ftp
   $ mkdir shared
   $ chmod 777 shared/
   $ chgrp ftp shared/
   $ chown ftp shared/
   

3. Permitir que usuários presos tenham acesso a essa pasta compartilhada

   Vamos pegar o exemplo de um usuário preso Sam:

   Assumindo que você é raiz no momento.

   $ su - sam
   $ cd /home/sam
   $ mkdir Shared
   $ exit
   

   Você está agora de volta à raiz.

   $ mount -o bind /var/ftp/shared /home/sam/Shared
   

   Adicione sam ao grupo de ftp

   $ usermod -a -G ftp sam
   

   Repita o processo para adicionar outros usuários à pasta "Compartilhada".

Sam agora terá acesso à sua própria pasta Pessoal e terá uma pasta "Compartilhada" adicional à qual todos os outros usuários poderão ter acesso.

    

Answer 2

Esta questão está em toda a internet, sem solução clara que eu encontrei.

Então aqui é onde eu estou nisso agora (eu atualizarei quando eu descobrir mais).

Parece que o problema fundamental é que o FTP tem usuários fazendo login e manipulando o sistema de arquivos, ao contrário de um cliente http simplesmente enviando solicitações para um processo de serviço http.

Portanto, é muito difícil limitar um usuário de FTP a fazer coisas que seu usuário tem direitos de fazer no sistema, caso ele faça logon regularmente. Os usuários de FTP precisam ter direitos de execução para diretórios além de onde queremos limitar seu acesso de visualização para que ele possa escrever ou ler a partir de seu ramo de nível inferior. Então, a única maneira fácil de limitar seu acesso à visão é colocá-lo na cadeia chroot.

Chroot jail não é seguro porque ele "modifica as pesquisas de nome de caminho de um processo e seus filhos para que qualquer referência a um caminho que inicie '/' efetivamente tenha a nova raiz, que é passada como argumento único, prefixada na caminho "mas" o diretório de trabalho atual é deixado inalterado e caminhos relativos ainda podem se referir a arquivos fora da nova raiz. " fonte link

O que isso significa em um contexto de segurança e como isso é perigoso em relação ao daemon FTP e aos direitos do usuário não posso dizer, mas significa que o 'jail' em 'chroot jail' é um equívoco.

Parece que com um controle profundo sobre o Linux, é possível definir direitos de processo e de usuário ... usar o chroot neste contexto de segurança, mas nem eu nem a miríade de internautas que lutam com isso ainda estão lá .

Também é possível endurecer a jaula do chroot onde ela realmente se comporta como prisão - Para citar o desenvolvedor do kernel Alan Cox, "o chroot não é e nunca foi uma ferramenta de segurança. As pessoas construíram coisas baseadas nas propriedades do chroot (Cadeias BSD, Linux vserver), mas eles são bastante diferentes.Você provavelmente poderia escrever-se um módulo LSM para fazer isso também. "Eu não estou" lá "ainda, mas eu suspeito que isso no final é" a "solução, e eu também risco de que os sites ftp de distribuição lidem com a segurança ao longo dessas linhas ou similares.

Praticamente falando, tudo o que posso fazer agora é usar o chroot jail, contando com que meu servidor seja um alvo de baixa prioridade, e que meus usuários sejam basicamente confiáveis. Minha estratégia de segurança será limitar o dano que alguém pode fazer, se eles saírem da cadeia . O que implica a configuração adequada dos usuários, possivelmente usuários virtuais, e talvez a execução de todo o serviço em uma máquina virtual.

À medida que progrido nos meus estudos, espero reforçar o conceito chroot () através de um LSM ou algo parecido para segurança, e noto que de acordo com a citação de Alan Cox acima da BSD já tem um conceito de 'cadeias'. Eu poderia procurar no BSD pelas minhas necessidades de FTP.

    

Answer 3

Veja como eu criei um sftpuser preso para que os clientes transfiram arquivos para o meu servidor:

1. Crie o sftpgroup

   # groupadd sftpusers
   

2. Crie o sftpuser:

   # useradd -g sftpusers -d /incoming/client1 -s /sbin/nologin \
         client1srs passwd client1srs
   

3. Modifique o usuário e faça o usuário sftp onluy e coloque na cadeia sftp

   # usermod -g sftpusers -d /incoming -s /sbin/nologin client1srs
   

4. Configure o subsistema sftp-server no sshd_config

   Modifique o / etc / ssh / sshd_config e comente:

   # #Subsystem       sftp    /usr/libexec/openssh/sftp-server
   

5. Em seguida, adicione o seguinte:

   Subsystem       sftp    internal-sftp
   

6. Especifique o diretório Chroot para o grupo

   Adicione as seguintes linhas no final de / etc / ssh / sshd_config:

   Match Group sftpusers
          ChrootDirectory /sftp/%u
          ForceCommand internal-sftp
   

7. Crie o diretório inicial do SFTP

   # mkdir /sftpdir/client1srs/incoming
   # chown client1srs:sftpusers /sftpdir/client1srs/incoming
   

8. Reinicie o sshd

   # /sbin/service sshd restart
   

Answer 4

Outra possível resposta geral (que pode ser errada / impossível, estou realmente esperando feedback):

Crie uma partição separada para atuar como a raiz dos usuários de FTP. Não tem nada além de diretórios relevantes nesta partição raiz. Use as ACLs para remover permissões de execução para todos os usuários de FTP de todos os diretórios nas outras partições. Instale o servidor FTP na partição regular, para que a partição do usuário de FTP não fique sobrecarregada com os arquivos de programa.

Desta forma, os usuários de FTP verão apenas a raiz da nova partição, que eu posso estruturar da maneira mais elegante que eu escolher.

    

Answer 5

A resposta curta: use obrigatório- ou . Veja a atualização 2 abaixo.

Sim, o ftp é inerentemente inseguro. O sftp e o scp resolvem parte dessa insegurança, embora não o problema que o preocupa em esconder partes do sistema de arquivos. Talvez você precise de um volume NFS?

De acordo com o vsftpd faq , o problema com o chroot é o controle de leitura / gravação do usuário torna-se o sistema de arquivos raiz.

O vsftpd fornece as configurações hide_file e deny_file , que podem ser usadas para ocultar arquivos e torná-los inacessíveis, respectivamente, usando correspondência de padrões. Como a documentação afirma, essas opções "são muito simples e não devem ser usadas para controle de acesso sério - as permissões do sistema de arquivos devem ser usadas de preferência".

Dependendo do que seus usuários precisam fazer sobre o ftp, você também poderá aumentar a segurança do seu site limitando a atividade dos usuários do ftp com cmds_allowed ou cmds_denied do vsftpd.

Você pode executar o daemon de ftp dentro de um contêiner docker , com o diretório de dados do host montado no contêiner. O usuário verá o contêiner inteiro, mas nada mais do host. Pode ser possível usar o xinetd para gerar um processo dockerized vsftpd para cada conexão do cliente. Então, tudo no contêiner, mas o volume de dados montado, seria completamente efêmero e desapareceria assim que a conexão fosse fechada.

Atualização: O FTP usa uma conexão separada para transferência de dados . Para executar um servidor FTP dentro da janela de encaixe, é preciso garantir que ele ainda possa negociar e estabelecer a conexão de dados. Isso pode ser feito executando o contêiner com --net = host, ou possivelmente com configuração de rede adicional tanto dentro como fora do contêiner. Para gerar contêineres ftp do docker sob demanda usando o xinetd como sugeri acima, tal configuração teria que ser feita em tempo real para cada contêiner.

Atualização 2: o Docker não é uma garantia de segurança. As explorações foram descobertas e a segurança não é a principal objetivo do projeto. Provavelmente seria melhor usar um contêiner para rodar seu ftpd como um usuário sem privilégios.

A solução real é complementar o mecanismo de controle de acesso em seu servidor com AppArmor , SELinux ou GrSecurity . Eu acredito que qualquer um desses deve ser uma solução suficiente sem recipientes, chroots ou prisões.