Como verificar se o firewall foi aberto para uma porta, mas não está escutando na porta

Question

Estaremos implantando um novo aplicativo em um servidor e o aplicativo estará atendendo na porta 8443. Pedimos à equipe da rede para abrir o firewall da porta 8443 nesse servidor antes de implantar o aplicativo. Não há nenhum aplicativo atualmente escutando nessa porta específica no servidor.

Existe de qualquer maneira eu posso ter certeza que o firewall está aberto para a porta 8443

SO: Linux / Windows

    

Answer 1

Se você quiser ver se pode formar uma conexão TCP a partir de uma máquina remota, instale o OpenCSW nele e na máquina de destino e instale o netcat em ambos. Esta é a sintaxe para usar o netcat para testar conexões TCP:

nc -vz targetServer portNum

Por exemplo, para verificar o SSH em "homeServer1":

nc -vz homeserver1 22

Isso permite que você teste a conectividade em nível de TCP do sistema remoto. O Netcat também pode ser configurado para escutar em uma porta, em vez de agir como um cliente. Para obtê-lo para ouvir no TCP / 8443:

No servidor que hospedará o aplicativo: nc -l homeserver1 8443

Em uma máquina que fica fora do firewall: nc -vz homeserver.fqdn 8443

Este é um exemplo de uma execução bem-sucedida:

[jadavis6@ditirlns01 ~]$ nc -vz ditirlns01.ncat.edu 8443
Connection to ditirlns01.ncat.edu 8443 port [tcp/pcsync-https] succeeded!

Uma falha na execução:

[jadavis6@ditirlns01 ~]$ nc -vz ditirlns01.ncat.edu 8443
nc: connect to ditirlns01.ncat.edu port 8443 (tcp) failed: Connection refused

    

Answer 2

Os firewall devem responder com uma mensagem ICMP quando bloqueiam uma solicitação. No entanto, isso não é necessariamente o caso (você estará interessado em este belo artigo ).

Você pode testar de fora para ver se uma porta está acessível por meio de um firewall e, em caso afirmativo, se alguma coisa está sendo ouvida. Aqui estão três cenários diferentes envolvendo uma solicitação tcp que você pode observar com wireshark , ou algum outro sniffer de pacote, e o que você verá:

1) O firewall rejeita a solicitação

Você recebe uma mensagem ICMP de volta, e a ferramenta que faz a solicitação deve informar imediatamente algo com esse efeito ("inacessível, admin proibido", etc.). Por "ferramenta" quero dizer o cliente que você está usando para enviar a solicitação (usei telnet ).

"Nenhuma rota para hospedar" pode indicar isso, mas também pode indicar problemas de roteamento mais sutis.

2) O firewall descarta o pacote

Não há resposta, então a ferramenta aguarda até que o tempo limite ou você fica entediado.

3) Firewall permite pacote (ou não há firewall), mas nada está escutando na porta.

Você recebe uma mensagem TCP RST / ACK de volta. Eu presumo que o protocolo TCP exige isso. Em outras palavras, se nada estiver escutando na porta, o próprio SO envia esta resposta. Pode ser difícil distinguir isso de # 1 apenas com base no que uma ferramenta relata, porque pode dizer a mesma coisa em ambos os casos (no entanto, muito provavelmente distinguir isso como "conexão recusada" vs. # 1, "rede inacessível"). Observado em um sniffer de pacotes na máquina cliente, o cenário 1 (mensagem de rejeição de ICMP) e # 3 (mensagem de TCP RST / ACK) são claramente distintos.

A única outra opção aqui é que o pacote é permitido pelo firewall e algo está escutando, então você obtém uma conexão bem-sucedida.

Em outras palavras: supondo que sua rede em geral funcione corretamente, se você obtiver # 1 ou # 2, significa que um firewall está ativamente impedindo o acesso à porta. # 3 acontecerá se o servidor não estiver em execução, mas a porta estiver acessível e, é claro, (o implícito) # 4 for uma conexão bem-sucedida.

    

Answer 3

Você pode usar o comando netstat para ver se uma porta está aberta e ouvindo.

Exemplo

$ netstat -anp | less
Active Internet connections (servers and established)

Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name   
tcp        0      0 0.0.0.0:111                 0.0.0.0:*                   LISTEN      -                   
tcp        0      0 0.0.0.0:41716               0.0.0.0:*                   LISTEN      -                   
tcp        0      0 0.0.0.0:22                  0.0.0.0:*                   LISTEN      -                   
tcp        0      0 127.0.0.1:631               0.0.0.0:*                   LISTEN      -                   
tcp        0      0 0.0.0.0:17500               0.0.0.0:*                   LISTEN      3034/dropbox        
tcp        0      0 0.0.0.0:17501               0.0.0.0:*                   LISTEN      3033/dropbox        
tcp        0      0 127.0.0.1:2143              0.0.0.0:*                   LISTEN      3191/ssh                       
tcp        0      0 127.0.0.1:2025              0.0.0.0:*                   LISTEN      3191/ssh 

A saída mostra os processos (coluna mais à direita) que estão escutando nas portas TCP. Os números de porta são os números que seguem os dois-pontos após os endereços IP (0.0.0.0:111 seria a porta 111, por exemplo).

Os endereços IP mostram Local e Endereços estrangeiros . Local seria o seu sistema, enquanto Estrangeiro seria qualquer endereço que se conectasse à sua porta TCP ou se conectasse a uma das portas TCP deles.

Portanto, no caso da porta 22, esse é o daemon ssh em execução no meu sistema, que é LISTENING para conexões. Uma vez que alguém tenta se conectar ao daemon ssh , ele copia uma cópia de si mesmo e envia essa conexão para outra porta, mantendo a porta TCP 22 aberta para conexões adicionais conforme elas entram.

    

Answer 4

A configuração e o status da configuração do firewall são específicos do firewall / SO.

O que você pode fazer é tentar do server2:

nmap server1

    

Answer 5

Você pode usar uma ferramenta online como www.firewallruletest.com para ver se hosts externos podem estabelecer conexões tcp.