Por que o chroot_local_user do vsftpd é inseguro?


20

Estou configurando no meu VPS um vsftpd e não quero que os usuários deixem o diretório inicial do ftp. Estou usando o local_user ftp, não anônimo, então adicionei:

chroot_local_user = SIM

Eu li em muitos posts do fórum que isso não é seguro.

  1. Por que isso é inseguro?
  2. Se isso não é seguro por causa do uso do ssh para ingressar no meu VPS, então eu poderia bloquear esses usuários do sshd, certo?
  3. Existe outra opção para obter esse comportamento do vsftpd? (Eu não quero remover permissões de leitura em todas as pastas / arquivos para "world" no meu sistema)

Respostas:


20

Verifique aqui as Perguntas frequentes do VSFTPD para obter a resposta que você procura. Abaixo está o importante trecho que acho que responderá à sua pergunta.

Q) Ajuda! Quais são as implicações de segurança mencionadas na opção "chroot_local_user"?

A) Em primeiro lugar, observe que outros daemons ftp têm as mesmas implicações. É um problema genérico. O problema não é muito grave, mas é o seguinte: algumas pessoas têm contas de usuário de FTP que não são confiáveis ​​para ter acesso total ao shell. Se essas contas também podem fazer upload de arquivos, há um pequeno risco. Um usuário ruim agora tem controle da raiz do sistema de arquivos, que é o diretório inicial. O daemon ftp pode fazer com que algum arquivo de configuração seja lido - por exemplo, / etc / some_file. Com chroot (), este arquivo está agora sob o controle do usuário. O vsftpd é cuidadoso nessa área. Mas, a libc do sistema pode querer abrir arquivos de configuração da localidade ou outras configurações ...


Obrigado por isso, eu não sabia tudo isso. Aprendi alguma coisa! +1
Yanick Girouard

4
Na verdade, vim aqui depois de ler as perguntas frequentes porque não entendo essa declaração preocupante: "O daemon ftp pode fazer com que algum arquivo de configuração seja lido - por exemplo, / etc / some_file. Com chroot (), esse arquivo está agora sob o controle de o usuário.". Presumivelmente, esse seria apenas o caso se vsftpdhouvesse uma falha de segurança (à la buffer overflow) ??? Como a execução vsftpdcom usuários com chroot no diretório home torna esse cenário mais provável? Por favor, explique ...
sxc731 2/17

4

O problema é que você não pode usar contas locais e também desabilitar essas contas no logon do shell. Se você definir o shell de login como / bin / nologin, também não permitirá que você faça o login com o vsftpd.

Um daemon de FTP melhor e mais seguro seria o Pure-ftpd. Procure, está disponível no repositório EPEL e permite criar usuários virtuais. O servidor usa um usuário / grupo comum para definir todas as permissões para as pastas pessoais dos usuários e "mapeia" os usuários virtuais para esse usuário quando ele efetua login para lidar com as permissões. Isso é mais seguro e você não precisa lidar com a segurança de login do openssh.

O Pure-ftpd também suporta muitos recursos, como cotas, proporções e outros. Muito melhor que o vsftpd.

Aqui está um tutorial simples sobre como instalá-lo e configurar um usuário virtual básico: http://blog.namran.net/2011/05/04/how-to-setup-virtual-ftp-server-using-pure-ftpd- in-centos /

Se você ler o documento completo (o que você deve), saberá que a opção -d ao criar o usuário virtual é um chroot automático para esse diretório para esse usuário.


Eu uso a AllowUsers user1 user2diretiva no meu sshd_config, onde não permito que o ftp_user1 entre com o ssh, mas o usuário ftp_user1 ainda pode fazer o login com o ftp. Portanto, está funcionando como pretendido, mas ainda é minha principal pergunta em aberto, por que não é seguro?
P1100i

4
Sim vai! Você só precisa adicionar o "não shell" ao / etc / shells. Em muitos sistemas / bin / false ou / bin / nologin existe em / etc / shells. Se o shell estiver lá, o vsftpd permitirá que você efetue o login, também com o chroot_local_user ativado.
Frands Hansen

11
Eu estou corrigido então. Obrigado por apontar isso!
Yanick Girouard
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.