Uma resposta detalhada para quem bate a cabeça contra a parede também.
1) Encontre as portas abertas do seu servidor
Primeiro, use o nmap para diagnosticar quais portas estão abertas e quais estão fechadas / filtradas. O Nmap tem digitalização diferente modos para encontrar as portas abertas, você deve tentar todos esses modos.
Você acaba com uma lista de portas abertas, algumas delas são lógicas, mas outras não.
No meu caso, as portas 110, 143, 993, 995 não deveriam ser abertas.
2) Essas portas estão realmente abertas
Use telnet ou nc para testar se essas portas TCP estão realmente abertas
[meandmyself@MacBook ~]$ telnet WWW.XXX.YYY.ZZZ 110
Trying WWW.XXX.YYY.ZZZ...
Connected to mydomain.com.
Escape character is '^]'.
No meu caso, há uma resposta real quando tento acessar a porta 110 do meu servidor.
Aqui é a parte mais assustadora, a porta parece estar aberta.
3) Diagnostique no servidor
A) Existe um processo em execução no meu servidor escutando nesta porta
netstat ou lsof pode mostrar se há processos em execução ouvindo nessas portas abertas.
[21:55] ovh-user@mydomain:~ $ sudo netstat -tanlp | grep LISTEN
[sudo] password for ovh-user:
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 1016/master
tcp 0 0 WWW.XXX.YYY.ZZZ:4444 0.0.0.0:* LISTEN 353/sshd
tcp 0 0 0.0.0.0:5665 0.0.0.0:* LISTEN 2485/icinga2
tcp 0 0 127.0.0.1:8999 0.0.0.0:* LISTEN 826/php-fpm.conf)
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 25433/mysqld
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 346/rpcbind
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 828/nginx -g daemon
tcp6 0 0 :::9000 :::* LISTEN 25477/java
tcp6 0 0 :::111 :::* LISTEN 346/rpcbind
No meu caso, não há processo escutando na porta 110, 993 ... Apenas processa a escuta nas portas 25, 4444, 5665, 8999, 3306, 111, 80, 9000.
B) Meu servidor está permitindo solicitações recebidas para a porta 110
Diagnostique as regras do iptables para INPUT, FORWARD and PREROUTING chains
[21:33] ovh-user@mydomain:~ $ sudo iptables -v -L INPUT
No meu caso, há uma política DROP padrão, o que significa que todas as portas abertas devem ser claramente especificadas para ter a chance de alcançar um processo em execução.
Agora posso concluir que não há chance de que meu servidor responda por solicitação na porta 110.
4) Quem está respondendo a solicitações na porta 110 para o meu servidor?
Todos os nós ativos no caminho entre o meu computador e o meu servidor podem ser os que atendem às solicitações. Lembre-se de que também inclui meu próprio computador.
Para diagnosticar isso, teste com nmap e telnet de:
- Um computador diferente
- Um ponto de acesso / caixa ISP diferente
- Um local diferente (use túneis ssh e outros servidores para fazer proxy de suas solicitações)
No meu caso, testei com outro servidor localizado no mesmo datacenter. O objetivo era ver se um firewall frontal, configurado pelo meu provedor de hospedagem, poderia manipular solicitações na porta 110, 143 ... Eu também testei o telnet na porta 110 com meu telefone e JuiceSSh acima de 4G.
E não houve resposta para solicitações na porta 110 com esses testes.
5) Então é o meu computador que abre essas portas localmente
No meu caso, eu estava testando no OSX 10.11.5. Eu corro lsof e netstat para rastrear se meu computador escutar em portas específicas:
[meandmyself@MacBook ~]$ sudo netstat -anv | grep LISTEN
tcp46 0 0 *.3306 *.* LISTEN 131072 131072 827 0
tcp4 0 0 127.0.0.1.4380 *.* LISTEN 131072 131072 453 0
tcp4 0 0 127.0.0.1.4370 *.* LISTEN 131072 131072 453 0
tcp6 0 0 ::1.12993 *.* LISTEN 131072 131072 352 0
tcp4 0 0 127.0.0.1.12993 *.* LISTEN 131072 131072 352 0
tcp6 0 0 ::1.12995 *.* LISTEN 131072 131072 352 0
tcp4 0 0 127.0.0.1.12995 *.* LISTEN 131072 131072 352 0
tcp6 0 0 ::1.12143 *.* LISTEN 131072 131072 352 0
tcp4 0 0 127.0.0.1.12143 *.* LISTEN 131072 131072 352 0
tcp6 0 0 ::1.12110 *.* LISTEN 131072 131072 352 0
tcp4 0 0 127.0.0.1.12110 *.* LISTEN 131072 131072 352 0
tcp6 0 0 ::1.12443 *.* LISTEN 131072 131072 352 0
tcp4 0 0 127.0.0.1.12443 *.* LISTEN 131072 131072 352 0
tcp6 0 0 ::1.12080 *.* LISTEN 131072 131072 352 0
tcp4 0 0 127.0.0.1.12080 *.* LISTEN 131072 131072 352 0
tcp46 0 0 *.80 *.* LISTEN 131072 131072 321 0
tcp4 0 0 127.0.0.1.49153 *.* LISTEN 131072 131072 78 0
tcp4 0 0 127.0.0.1.49152 *.* LISTEN 131072 131072 78 0
[meandmyself@MacBook ~]$ sudo lsof -i -n -P |grep LISTEN
mtmfs 78 root 4u IPv4 0x7f85fc078645d63b 0t0 TCP 127.0.0.1:49152 (LISTEN)
mtmfs 78 root 6u IPv4 0x7f85fc078645cd43 0t0 TCP 127.0.0.1:49153 (LISTEN)
httpd 83 root 4u IPv6 0x7f85fc0788d37b8b 0t0 TCP *:80 (LISTEN)
httpd 321 _www 4u IPv6 0x7f85fc0788d37b8b 0t0 TCP *:80 (LISTEN)
com.avast 352 root 3u IPv4 0x7f85fc0788dc363b 0t0 TCP 127.0.0.1:12080 (LISTEN)
com.avast 352 root 4u IPv6 0x7f85fc0788d380eb 0t0 TCP [::1]:12080 (LISTEN)
com.avast 352 root 5u IPv4 0x7f85fc078645df33 0t0 TCP 127.0.0.1:12443 (LISTEN)
com.avast 352 root 6u IPv6 0x7f85fc0788d3864b 0t0 TCP [::1]:12443 (LISTEN)
com.avast 352 root 7u IPv4 0x7f85fc0788dc3f33 0t0 TCP 127.0.0.1:12110 (LISTEN)
com.avast 352 root 8u IPv6 0x7f85fc0788d38bab 0t0 TCP [::1]:12110 (LISTEN)
com.avast 352 root 9u IPv4 0x7f85fc0788dc2d43 0t0 TCP 127.0.0.1:12143 (LISTEN)
com.avast 352 root 10u IPv6 0x7f85fc0788d3910b 0t0 TCP [::1]:12143 (LISTEN)
com.avast 352 root 11u IPv4 0x7f85fc0788dc482b 0t0 TCP 127.0.0.1:12995 (LISTEN)
com.avast 352 root 12u IPv6 0x7f85fc0788d3762b 0t0 TCP [::1]:12995 (LISTEN)
com.avast 352 root 13u IPv4 0x7f85fc0788dc5123 0t0 TCP 127.0.0.1:12993 (LISTEN)
com.avast 352 root 14u IPv6 0x7f85fc0788d370cb 0t0 TCP [::1]:12993 (LISTEN)
SpotifyWe 453 kheraud 6u IPv4 0x7f85fc078a53282b 0t0 TCP 127.0.0.1:4370 (LISTEN)
SpotifyWe 453 kheraud 7u IPv4 0x7f85fc078a533123 0t0 TCP 127.0.0.1:4380 (LISTEN)
mysqld 827 _mysql 33u IPv6 0x7f85fc0788d36b6b 0t0 TCP *:3306 (LISTEN)
Lsof me dá uma primeira dica. Como meu trabalho é construir websites enquanto ouço música, não fiquei surpreso em ver o Apache, Mysql e Spotify ouvindo em portas que eles deveriam ouvir ... Mas Avast me aponta na direção certa. Todas as portas abertas (110, 143, 993, 995) são listadas com "127.0.0.1.12XXX" (12110, 12143, 12993, 12995 ...).
Eu não consegui ver como o Avast lida com o pedido real na porta 110 ( @MarkPlotnick me aponta para usar o pfctl mas usá-lo não é tão fácil - qualquer ajuda bem-vinda ).
Eu fechei o Avast e executei o lsof novamente, depois o telnet, depois o nmap ... As portas falsas abertas não estavam mais lá.
Em tal situação, eu me assustei pulando muito rapidamente no stackexchange para encontrar uma pista. Eu deveria ter respirado, outro café e pensar sobre o que está no caminho entre meu computador e meu servidor. Eu teria tentado outros testes de outros locais e descoberto que meu servidor não estava exposto a violações de segurança.
Conclusão : 1) Pense 2) Pense novamente 3) Teste 4) Faça