vsftpd LIST causa erro GnuTLS -15

Question

Eu tenho um sistema Arch Linux executando o vsftpd, que vem funcionando com o FTPES há um ano. Nos últimos dois dias, notei que todos os meus clientes FTP não conseguem se conectar por FTPES. Quando me conecto usando o FileZilla 3.17.0 no Windows 7, percebo que um erro GnuTLS -15 ocorre quando a lista de diretórios está sendo enviada:

Isso é FTPES passivo com o host especificado usando o IP da WAN:

Status: Connecting to ###.###.###.###:21...
Status: Connection established, waiting for welcome message...
Status: Initializing TLS...
Status: Verifying certificate...
Status: TLS connection established.
Status: Logged in
Status: Retrieving directory listing...
Command:    PWD
Response:   257 "/" is the current directory
Command:    TYPE I
Response:   200 Switching to Binary mode.
Command:    PASV
Response:   227 Entering Passive Mode (###,###,###,###,27,163).
Command:    LIST
Response:   150 Here comes the directory listing.
Error:  GnuTLS error -15: An unexpected TLS packet was received.
Error:  Disconnected from server: ECONNABORTED - Connection aborted
Error:  Failed to retrieve directory listing
Status: Disconnected from server

O FileZilla tenta novamente a conexão com resultados idênticos e, em seguida, ele pára de tentar se conectar. Uma versão anterior do FileZilla também mostrou um erro GnuTLS -110, apesar de eu não ter saída salva contendo esse erro.

Li algumas mensagens que sugerem que esse problema é causado por um problema com a configuração de FTP passivo. Passivo FTP tem trabalhado neste servidor por um tempo agora, e eu não fiz nenhuma alteração em nenhum arquivo de configuração relevante. Para ter certeza, tentei conectar usando o modo ativo. Tudo parece normal até que eu receba um erro de comando de porta ilegal, no qual o FileZilla tenta usar passivamente novamente.

Estes são FTPES "ativos" com o host especificado usando o IP da WAN:

Status: Connecting to ###.###.###.###:21...
Status: Connection established, waiting for welcome message...
Status: Initializing TLS...
Status: Verifying certificate...
Status: TLS connection established.
Status: Logged in
Status: Retrieving directory listing...
Command:    PWD
Response:   257 "/" is the current directory
Command:    TYPE I
Response:   200 Switching to Binary mode.
Command:    PORT 192,168,0,7,240,98
Response:   500 Illegal PORT command.
Command:    PASV
Response:   227 Entering Passive Mode (###,###,###,###,27,103).
Command:    LIST
Response:   150 Here comes the directory listing.
Error:  GnuTLS error -15: An unexpected TLS packet was received.
Error:  Disconnected from server: ECONNABORTED - Connection aborted
Error:  Failed to retrieve directory listing
Status: Disconnected from server

O problema aqui parece ser que, mesmo que eu digite meu endereço IP WAN, o modo ativo ainda tenta usar um endereço IP local nesse comando PORT. Outro cliente FTP, o FTP Client Pro versão 3.0.4 no iOS, apresenta o erro "O servidor não parece suportar o modo Ativo". Em seguida, tentei conectar-me ao meu servidor localmente e, embora dessa vez o cliente não tenha entrado no modo passivo, o erro de TLS persiste.

Este é o FTPES ativo com o host especificado usando o IP local:

Status: Connecting to 192.168.0.2:21...
Status: Connection established, waiting for welcome message...
Status: Initializing TLS...
Status: Verifying certificate...
Status: TLS connection established.
Status: Logged in
Status: Retrieving directory listing...
Command:    PWD
Response:   257 "/" is the current directory
Command:    TYPE I
Response:   200 Switching to Binary mode.
Command:    PORT 192,168,0,7,240,129
Response:   200 PORT command successful. Consider using PASV.
Command:    LIST
Response:   150 Here comes the directory listing.
Error:  GnuTLS error -15: An unexpected TLS packet was received.
Error:  Disconnected from server: ECONNABORTED - Connection aborted
Error:  Failed to retrieve directory listing
Status: Disconnected from server

Por fim, tentei me conectar sem usar criptografia. Embora evite, se possível, devo deixar conexões não criptografadas suportadas para se conectar a partir de algumas redes restritivas. Ambas as configurações ativa e passiva no FileZilla funcionam na Internet pública com a criptografia desativada, embora ambos os tipos mostrem a mesma saída:

Este é um FTP simples ativo / passivo com o host especificado usando o IP da WAN:

Status: Connecting to 98.220.249.102:21...
Status: Connection established, waiting for welcome message...
Status: Logged in
Status: Retrieving directory listing...
Status: Calculating timezone offset of server...
Status: Timezone offset of server is 0 seconds.
Status: Directory listing of "/" successful

Como esse servidor está atrás de um roteador, ele é configurado de forma que o FTP passivo não funcione localmente; veja o vsftpd.conf abaixo. No interesse de testar todas as possibilidades de conexão, aqui está a saída do FileZilla para fazer uma conexão ativa e não criptografada localmente. Ele falha, mas não estou muito preocupado, pois nunca uso essa combinação de configurações.

Este é o FTP simples ativo com o host especificado usando o IP local:

Status: Connecting to 192.168.0.2:21...
Status: Connection established, waiting for welcome message...
Status: Logged in
Status: Retrieving directory listing...
Command:    PWD
Response:   257 "/" is the current directory
Command:    TYPE I
Response:   200 Switching to Binary mode.
Command:    PORT 192,168,0,7,240,195
Response:   200 PORT command successful. Consider using PASV.
Command:    LIST
Response:   150 Here comes the directory listing.
Response:   500 OOPS: priv_sock_get_cmd
Error:  Failed to retrieve directory listing
Error:  Connection closed by server

Aqui está o meu /etc/vsftpd.conf , menos os comentários. Este é essencialmente o mesmo arquivo que tenho usado com sucesso no ano passado.

anonymous_enable=NO
local_enable=YES
write_enable=YES
dirmessage_enable=YES
xferlog_enable=YES
port_enable=YES
connect_from_port_20=YES
ftpd_banner=Welcome to HOSTNAME (vsftpd on ArchLinux).
chroot_local_user=YES
allow_writeable_chroot=YES
listen=YES
ssl_enable=YES
force_local_logins_ssl=NO
force_local_data_ssl=NO
ssl_tlsv1=YES
rsa_cert_file=/etc/ssl/certs/vsftpd.pem
rsa_private_key_file=/etc/ssl/certs/vsftpd.pem
pasv_min_port=7000
pasv_max_port=7100
pasv_address=###.###.###.###

A última atualização completa para o meu sistema Arch antes de perceber esse problema ocorreu em 17 de abril de 2016 e incluiu upgraded gnutls (3.4.10-1 -> 3.4.11-1) . A atualização mais recente para o vsftpd ocorreu em 9 de março de 2016 (3.0.3-1 - > 3.0.3-2), então, em vez de fazer o downgrade apenas de gnutls, restaurei todo o sistema ao seu estado em 9 de março de 2016 usando o Arch Linux Arquivo. Isso não ajudou, e eu subseqüentemente atualizei o sistema para corresponder aos repositórios atuais. A saída fornecida aqui foi gerada usando o sistema atualizado até a data deste post (23 de abril de 2016). Não tenho certeza de quando exatamente esse erro começou, pois não uso meu servidor FTP com frequência suficiente para perceber isso imediatamente.

Como afirmei anteriormente, minhas configurações relevantes não mudaram desde que meu servidor FTP estava funcionando pela última vez, além das alterações feitas para postar as informações aqui.

Meu objetivo é fazer com que os FTPES passivos trabalhem novamente na Internet pública. É aceitável se eu tiver que sacrificar FTP ativo não criptografado, mas ainda gostaria de deixar disponível para os raros momentos em que preciso. O que preciso fazer para consertar isso?

    

Answer 1

Eu tive o mesmo problema que você e depois de um longo tempo pesquisando na internet, parece que encontrei uma solução alternativa aqui : Adicione a linha seccomp_sandbox=NO ao seu /etc/vsftpd.conf .

Meu caso de uso é um servidor FTP habilitado para SSL e somente LAN, então YMMV. Uma possível explicação para esse problema pode ser encontrada em mim, sem ter instalado o kernel mais recente disponível nos repositórios devido a um driver de wifi incompatível.

Espero que isso ajude:)