a porta 25 está aberta, mas nenhum serviço está escutando

Question

OS é o Ubuntu 12.04 LTS (servidor; sem GUI). A máquina é um servidor virtual executado a centenas de quilômetros de distância em um farm de servidores remotos.

Eu desinstalei o postfix e todos os seus componentes (courier, dovecot) e até mesmo parei o sendmail e o desinstalei.

Agora parece não haver nenhum programa escutando na porta 25:

netstat -lnptu | grep :25  

não dá entrada (0 linhas). Eu obtenho o mesmo resultado com

netstat -anp | grep :25  

e também 0 linhas resultam com este comando:

fuser -v 25/tcp  

De dentro da porta do servidor 25 é inacessível para o telnet:

> telnet localhost 25  
Trying ::1...  
Trying 127.0.0.1...  
telnet: Unable to connect to remote host: Connection refused

(Quando tento conectar-me à porta 24, recebo exatamente a mesma resposta)

Mesmo que eu substitua 'localhost' pelo endereço IP de minhas máquinas, não consigo me conectar à porta 25 de dentro:

> telnet <IP-address of my server> 25
Trying <IP-address of my server>...  
telnet: Unable to connect to remote host: Connection refused  

Mas ...

... quando eu faço um portscan com o link , a porta 25 está aberta.

Quando tento conectar-me à porta 25 no meu servidor com o telnet do lado de fora, recebo isso:

> telnet <IP-address of my server> 25
Trying <address>...
Connected to <resolved name>.
Escape character is '^]'.
Connection closed by foreign host.  

Então, eu recebo uma conexão, mas ela é fechada imediatamente.

Quando tento me conectar a uma porta fechada, recebo isso:

> telnet <IP-address of my server> 24
Trying <address>...
telnet: connect to address <address>: Connection refused
telnet: Unable to connect to remote host

Eu até tentei adicionar algumas regras ao iptables para a porta 25, mas isso não teve nenhum efeito. A porta 25 ainda parece estar aberta ao olhar para ela de fora, mas nenhum programa está escutando.

Pergunta 1: Como isso pode acontecer?
Pergunta 2: Como posso fechar a porta 25 sob essas circunstâncias?

    

Answer 1

Você provavelmente tem um dispositivo de segurança que está respondendo em nome dos endereços IP em sua rede. O comportamento de "pegar e desligar" é típico. Você pode confirmar esse comportamento observando os valores de IP TTL para a resposta da porta 25 e comparando-os com uma resposta real de porta aberta da sua máquina (respostas de portas fechadas como a porta 24 provavelmente também são provenientes do dispositivo de segurança, portanto comparação não seria útil). Você pode usar o Nmap para esse propósito da seguinte forma:

sudo nmap -sS -p 25,80 target.example.com -oX - | grep reason_ttl

Assumindo que a porta 80 está aberta no seu alvo, e a porta 25 está dando respostas estranhas, você deve ver algo como isto:

<host starttime="1398878935" endtime="1398878935"><status state="up" reason="reset" reason_ttl="52"/>
<ports><port protocol="tcp" portid="25"><state state="open" reason="syn-ack" reason_ttl="54"/><service name="smtp" method="table" conf="3"/></port>
<port protocol="tcp" portid="80"><state state="open" reason="syn-ack" reason_ttl="52"/><service name="http" method="table" conf="3"/></port>

Desculpe a XML eyesore, mas se você olhar o atributo state do elemento reason_ttl , você pode ver que em um caso o TTL da resposta foi menor que o outro, indicando que o pacote viajou mais longe na rede antes de obter uma resposta. Este não é um método infalível, já que o dispositivo de segurança pode mentir sobre TTLs de saída, mas pode ajudar a satisfazer sua curiosidade.

Em qualquer caso, você pode ter certeza, com base na saída do netstat e de outras ferramentas, que a porta não está realmente ouvindo em sua máquina.