Como especificar o nmap para adicionar o endereço de redirecionamento?

0

Estou tentando ping a integridade das VMs usando o utilitário nmap .

# nmap -v -n -sP  192.168.102.116
 Host 192.168.102.116 appears to be down.
 Note: Host seems down. If it is really up, but blocking our ping probes, try -P0
 Nmap finished: 1 IP address (0 hosts up) scanned in 2.006 seconds

tentei com ping direto, pois mostra o host acessível. então encontrei a diretiva next hop na saída ping .

# ping 192.168.102.116
 PING 192.168.102.116 (192.168.102.116) 56(84) bytes of data.
 From 192.169.64.129: icmp_seq=1 Redirect Host(New nexthop: 192.169.64.149)
 64 bytes from 192.168.102.116: icmp_seq=1 ttl=52 time=15.6 ms

Env: - versão nmap do RHEL 5.11 - 4.11

$ netstat -r
  Kernel IP routing table
  Destination     Gateway         Genmask         Flags   MSS Window  irtt 
  Iface
  10.10.2.0      *               255.255.254.0   U         0 0          0 
  eth0
  169.254.0.0     *               255.255.0.0     U         0 0          0 
  eth0
  default         10.10.2.1      0.0.0.0         UG        0 0          0 
  eth0

Pergunta

Como conseguir o mesmo com nmap utility? especificando para ping host do endereço de redirecionamento?

Eu encontrei uma opção similar com fping utility --icmp-redirect-addr , da mesma forma existe alguma opção pode especificar o próximo endereço de salto de modo que nmap varra o host corretamente

Nota: isso é produção, pois só posso tentar com ping e nmap . Para a varredura de muitos hosts no ping em paralelo levou mais tempo, por isso precisa ficar em nmap .

Sugestão apreciada. ...

    
por user183980 25.07.2018 / 07:01

2 respostas

0

Eu não entendo.

Você está solicitando um ping ping 192.168.102.116 para um endereço privado no intervalo 192.168.x.y , que é um endereço em um dos endereços de bloco RFC1918 . Todos os endereços em um bloco RFC1918 devem ser descartados por qualquer roteador público da Internet (tais endereços não são roteáveis).

A resposta que você recebe vem de um endereço de internet público From 192.169.64.129 que pertence a:

$ whois 192.169.64.129
NetRange:       192.169.64.0 - 192.169.64.255                                                                                               
CIDR:           192.169.64.0/24
....
Organization:   Wayne County Community College (WCCC-3)
....

Isso não deve acontecer.

Além disso, você está recebendo uma rota pública Redirect Host(New nexthop: 192.169.64.149) como a melhor rota para um endereço interno. Essa resposta está pedindo para adicionar uma nova rota à tabela de roteamento local .

Isso deve ser proibido

Entenda que não há entrada de roteamento na tabela de rotas (computador local) para o intervalo de endereços local 192.168.x.y . Como não há entrada de roteamento, o pacote é enviado para o gateway padrão default 10.10.2.1 . Esse roteador envia o pacote para o próximo roteador. Se o próximo roteador na nuvem da Internet, este roteador é um "roteador de borda" e não deve rotear pacotes em intervalos privados de RFC1918 para a Internet de largura.

De qualquer forma, há pelo menos esse problema na sua configuração:

  • Não há rota para o intervalo de endereços na sua tabela de rotas.
  • O roteador em 10.10.2.1 (ou qualquer outro roteador de borda) não possui uma rota específica para 192.168.x.y . Deveria.
  • Pacotes de 192.168.x.y estão sendo roteados para a internet (solicitação de ping).
  • Pacotes para 192.168.x.y estão sendo roteados de volta da Internet (resposta de ping).
  • Você está verificando uma VM em 192.168.102.116 . Acredito que sendo uma VM os pacotes não devem ser enviados para a rede local (e depois para a internet). Esses pacotes devem ser controlados (contidos) pela interface de rede virtual da VM.

Você poderia esclarecer?

Citando RFC 792 (Protocolo da Internet).

The gateway sends a redirect message to a host in the following
situation.  A gateway, G1, receives an internet datagram from a
host on a network to which the gateway is attached.  The gateway,
G1, checks its routing table and obtains the address of the next
gateway, G2, on the route to the datagram's internet destination
network, X.  If G2 and the host identified by the internet source
address of the datagram are on the same network, a redirect
message is sent to the host.  The redirect message advises the
host to send its traffic for network X directly to gateway G2 as
this is a shorter path to the destination.  The gateway forwards
the original datagram's data to its internet destination.

Neste caso, G1 é 10.10.2.1 (eth1: 0 acima), X é 192.168.102.116 e G2 parece ser 192.169.64.129, e a fonte está no intervalo (você não disse) 10.10.2.0/16 (ou seja, o G2 e o host identificado pelo endereço de origem da Internet do datagrama estão claramente NÃO na mesma rede)

    
por 25.07.2018 / 10:38
0

Como o nmap está demorando menos? Eu não consigo reproduzir isso. No seu caso, está lhe dando um tempo menor, já que não pode alcançar o servidor, então esses horários não podem ser comparados.

ping -c1 ip-to-check enviará apenas uma sonda e levará muito pouco tempo.

No seu caso, e de acordo com suas saídas, parece haver algum problema de roteamento. Verifique suas rotas, pois o ping está recebendo um redirecionamento. Use traceroute para ver o hops pelo qual seu ping passa e verifique suas rotas.

Você pode tentar usar nmap -sn --traceroute e ver se esse comando aceita o redirecionamento como ping , mas o melhor seria verificar essas rotas, pois seus IPs estão em uma rede diferente e a rota que você estabeleceu para alcançar seu destino está sendo redirecionado como mostra o comando ping .

Como é mais fácil ver meus resultados aqui, editei minha postagem em vez de responder ao seu comentário:

root@Caronte:~# time ping -c1 10.50.1.105
PING 10.50.1.105 (10.50.1.105) 56(84) bytes of data.
64 bytes from 10.50.1.105: icmp_seq=1 ttl=64 time=0.127 ms

--- 10.50.1.105 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.127/0.127/0.127/0.000 ms

real    0m0,002s
user    0m0,000s
sys     0m0,000s
root@Caronte:~# time nmap -sn -Pn 10.50.1.105

Starting Nmap 7.40 ( https://nmap.org ) at 2018-07-25 15:25 CEST
Nmap scan report for 10.50.1.105
Host is up.
Nmap done: 1 IP address (1 host up) scanned in 0.00 seconds

real    0m0,005s
user    0m0,000s
sys     0m0,004s

Como você pode ver, na minha máquina nmap leva mais tempo do que ping .

    
por 25.07.2018 / 09:21

Tags