Não é possível abrir a porta ftp 21 no centos usando o firewalld

Question

Estou tentando instalar o vsftpd no Centos 7. Posso conectar-me ao servidor a partir do host local, mas não conectá-lo a partir de máquinas remotas. Eu sou um pouco novo no tópico de administração de sistemas e redes.

Aqui estão alguns lugares que eu procurei por respostas: Can não abra a porta ftp via firewalld
O Centos não abre porta / s depois que as regras são anexadas
Porta nmap filtrada 80

Eu tenho o serviço vsftpd instalado e funcionando:

> netstat -plnt | grep ':21. '
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      12393/vsftpd

e eu posso logar usando ftp localhost bem. Mas quando eu tento um login remoto, fico com o tempo de conexão esgotado após alguns segundos. Então, estou suspeitando de um problema de firewall.

(também, de porta FTP fechada para o serviço vsftpd

lsof -i:21
COMMAND   PID USER   FD   TYPE   DEVICE SIZE/OFF NODE NAME
vsftpd  12393 root    3u  IPv4 63746670      0t0  TCP *:ftp (LISTEN)

Como este é o Centos, estou usando o firewalld. Porta 21 aparece para ser aberta:

> firewall-cmd --list-services
dhcpv6-client ftp https ssh

e:

> firewall-cmd --list-ports
433/tcp 21/tcp 80/tcp 20/tcp

Além disso:

> firewall-cmd --get-default-zone
public
> firewall-cmd --get-active-zone
public 
  interfaces: enp0s25

e recarreguei o firewalld via firewall-cmd --reload

Mas se eu tentar o nmap a partir de uma máquina remota, ele afirma que as portas 20 e 21 estão filtradas:

> nmap -p20,21 my.ftp.server.com
Starting Nmap 6.40 ( http://nmap.org ) at 2017-03-27 13:48 PDT
Nmap scan report for rrcs-xx-xx-xx-xx 
(xx.xx.xx.xx)
Host is up (0.035s latency).
PORT   STATE    SERVICE
20/tcp filtered ftp-data
21/tcp filtered ftp

Eu até rastreei examinava todas as regras do iptables, seguindo as várias cadeias do firewalld e encontrei estas:

> iptables -S IN_public_allow
-N IN_public_allow
-A IN_public_allow -p tcp -m tcp --dport 21 -m conntrack --ctstate NEW -j ACCEPT
-A IN_public_allow -p tcp -m tcp --dport 20 -m conntrack --ctstate NEW -j ACCEPT

Estou feliz em postar toda a saída de iptables -S se alguém achar que isso ajudaria.

Por fim, desliguei o SELinux por tempo suficiente para determinar que obtenho o mesmo comportamento com ele do que com ele.

Então, minhas perguntas são:

Alguma outra máquina poderia estar filtrando o tráfego da porta 21 antes que chegue à minha máquina? (Há também um servidor web nesta máquina que eu posso conectar muito bem). Se sim, como posso determinar isso?

Existe alguma outra coisa que eu possa verificar para depurar este problema?

Toda e qualquer ajuda é apreciada.

    

Answer 1

nmap "filtrado" por si só não significa que seu acesso FTP está bloqueado - pode significar que um firewall intermediário detectou que você está executando uma varredura nmap & sondar e soltar os pacotes. É um "recurso" bastante comum. Infelizmente, depois que o firewall começar a descartar seus pacotes ftp, você terá que esperar um pouco para que o estado desapareça, para que você possa, legitimamente, tentar fazer o login.

Além disso, existem outros serviços de controle de usuário / porta além do firewalld e iptables que podem interferir. Um é /etc/hosts.allow ou /etc/hosts.deny, que é fornecido por tcp_wrappers

Tente adicionar uma linha ao seu arquivo hosts.allow que diz:

ALL : YOUR_IP_ADDRESS_HERE : allow

Isso diz "todas as portas": IP: permitir acesso.

Outra pergunta a ser feita é se você pode efetuar login a partir do servidor por meio de sua interface externa, em vez do alias de loopback do host local. ftp MY_IP . O host local geralmente tem permissão para efetuar login mesmo quando "ouvir" está desativado, por exemplo, /etc/vsftpd.conf

LISTEN=NO # é isso no seu arquivo vsftpd.conf?

Isso ocorre porque, na verdade, ele não está "escutando" a interface externa do ipv4 ou ipv6.

Verifique também o seu arquivo /etc/services , as seguintes linhas foram comentadas ou excluídas?

services:ftp-data        20/tcp
services:ftp-data        20/udp

Com relação ao iptables, se você está preocupado com o fato de as regras estarem interferindo, basta liberá-las:

iptables -F

Então, acho que a ordem das operações / cheques é esta:

1. Tente fazer o FTP para o IP externo do servidor
2. Se não conseguir se conectar, verifique netstat -al e verifique seu /etc/vsftp.conf, / etc / services, /etc/hosts.allow - tente novamente.

Se OK , a filtragem de pacotes intermediária ou baseada em fonte é sua inimiga  3. Se falhar, descarregue iptables, tente novamente  4. Se ainda falhar, ainda há algum outro problema impedindo que você faça o login através do servidor local.

Se no ponto 2, você pode logar, você ainda quer tentar liberar seus iptables e checar se há mensagens de erro no syslog. Ele geralmente diz que a "conexão caiu da fonte ..." para conexões de entrada que falham em tcp_wrappers.

Veja também estas linhas em vsftpd.conf

pam_service_name=vsftpd
userlist_enable=YES
tcp_wrappers=YES

Se você não conseguir restringir a conexão em seu servidor, será hora de começar a pesquisar a rota para o servidor traceroute MY_SERVER_IP de seu host ou traceroute MY_CLIENT_IP do servidor. Este comando também pode ser tracepath . Eu diria que é bastante improvável que um firewall próximo ao servidor em uma instalação de hospedagem esteja bloqueando suas conexões. Se for um ambiente corporativo, é bem possível, até mesmo provável, mas se o ambiente em que seu servidor está é uma instalação de hospedagem ou uma instituição educacional, o bloqueio de portas FTP no roteador é muito menos comum. Também é incomum para ISPs clientes, como a Comcast.

A que distância estão as máquinas remotas? por exemplo. quantos saltos de rede? Se você está na mesma sub-rede com o servidor, então obviamente é a configuração do servidor.