Existe uma maneira de ver o que realmente está filtrando a comunicação da porta TCP?

Existe uma maneira de ver o que realmente está filtrando a comunicação da porta TCP?
nmap -p 7000-7020 10.1.1.1

Produzirá todas as portas filtradas

Starting Nmap 6.40 ( http://nmap.org ) at 2015-03-04 12:18 EET
Nmap scan report for 10.1.1.1
Host is up (0.00091s latency).
PORT     STATE    SERVICE
7000/tcp filtered afs3-fileserver
7001/tcp filtered afs3-callback
7002/tcp filtered afs3-prserver
7003/tcp filtered afs3-vlserver
7004/tcp filtered afs3-kaserver
7005/tcp filtered afs3-volser
7006/tcp filtered afs3-errors
7007/tcp filtered afs3-bos
7008/tcp filtered afs3-update
7009/tcp filtered afs3-rmtsys
7010/tcp filtered ups-onlinet
7011/tcp filtered unknown
7012/tcp filtered unknown
7013/tcp filtered unknown
7014/tcp filtered unknown
7015/tcp filtered unknown
7016/tcp filtered unknown
7017/tcp filtered unknown
7018/tcp filtered unknown
7019/tcp filtered unknown
7020/tcp filtered unknown

Nmap done: 1 IP address (1 host up) scanned in 2.78 seconds

Existe uma maneira de ver o que exatamente está filtrando essas portas?

Responder1

Isto é o que os documentos do nmap dizem sobre o filteredestado

filtrado O Nmap não pode determinar se a porta está aberta porque a filtragem de pacotes impede que suas sondagens cheguem à porta. A filtragem pode ser proveniente de um dispositivo de firewall dedicado, regras de roteador ou software de firewall baseado em host...

A única maneira de descobrir o que está fazendo a filtragem é saber quais “máquinas” estão entre você e o alvo remoto.

Isto pode ser conseguido usando um utilitário de rastreamento de rota, que tenta determinar hosts entre você e o destino usando pacotes TCP especiais. No seu caso, o comando pode ser algo como:

traceroute 10.1.1.1

Depois de conhecer as máquinas entre você e o alvo, você investiga a configuração de cada uma para descobrir se está filtrando e, em caso afirmativo, como.

Responder2

O Nmap fornece diversas maneiras de obter mais informações sobre o que está causando a filtragem:

  • A --reasonopção mostrará o tipo de resposta que causou o estado da porta “filtrada”. Isso pode ser "sem resposta" ou "proibido pelo administrador" ou qualquer outra coisa.
  • O TTL dos pacotes de resposta é relatado na saída XML como o reason_ttlatributo do stateelemento da porta. Se o TTL de uma porta filtrada for diferente (geralmente maior que) do TTL de portas abertas, a diferença entre os TTLs será a distância da rede entre o destino e o dispositivo de filtragem. Há exceções, como alvos que usam TTLs iniciais diferentes para pacotes ICMP versus pacotes TCP, ou um dispositivo de filtragem que falsifica ou sobrescreve informações de TTL.
  • A --traceroutefunção mostrará informações sobre saltos ao longo de sua rota, qualquer um dos quais pode estar filtrando seu tráfego. Em alguns casos, o nome DNS reverso de um dos saltos será algo como "firewall1.example.com"
  • OfirewalkO script NSE enviará pacotes com TTLs iniciais que atingirão o tempo limite em diferentes saltos ao longo da rota, na tentativa de descobrir onde os pacotes estão sendo bloqueados. Isto é algo como uma combinação das duas técnicas anteriores e geralmente funciona muito bem.

A versão de desenvolvimento do Nmap atualmente não lançada também relata TTL para pacotes de resposta na saída de texto normal com as -v --reasonopções. Por enquanto, porém, você precisa usar a saída XML para obter essas informações.

EDITADO PARA ADICIONAR:Nmap 6.49BETA1foi o primeiro lançamento a mostrar TTL para pacotes de resposta na saída de texto com -v --reasonou -vve foi lançado em junho de 2015.

Responder3

Resposta curta - Não, não há como você ver isso.

Resposta mais longa:

De:https://nmap.org/book/man-port-scanning-basics.html

"o Nmap filtrado não pode determinar se a porta está aberta porque a filtragem de pacotes impede que suas investigações cheguem à porta. A filtragem pode ser de um dispositivo de firewall dedicado, regras de roteador ou software de firewall baseado em host. Essas portas frustram os invasores porque fornecem tão pouco Às vezes, eles respondem com mensagens de erro ICMP, como o código 13 do tipo 3 (destino inacessível: comunicação administrativamente proibida), mas os filtros que simplesmente descartam as sondas sem responder são muito mais comuns. caiu devido ao congestionamento da rede, em vez de filtragem. Isso retarda drasticamente a varredura."

Você pode tentar descobrir a topologia de rede com ferramentas como traceroute.Geralmenteas portas são filtradas no próprio host (ou seja, tabelas de IP), roteador de borda da rede de destino, roteador de núcleo da rede de destino ou switch L3 na parte superior do rack.

Se você estiver na mesma sub-rede que o host de destino, é quase certo que o firewall esteja na máquina de destino.

Responder4

Tente comparar o resultado do tcptrace com uma das portas filtradas com um tcptrace com uma porta aberta (ou um traceroute padrão). Se os tcptraces forem iguais, significa que há algo na máquina de destino filtrando as portas.

Atualização: eu quis dizer tcptraceroute, tenho um alias.

informação relacionada