O nmap é exponencialmente lento ao verificar mais portas

O nmap é exponencialmente lento ao verificar mais portas

Às vezes uso o nmap para verificar meus hosts. Por exemplo: nmap -sS -p- example.com
Mas este comando nunca termina.

Então divido a digitalização em pequenas partes: nmap -sS -p 0-999 example.com(12 segundos para terminar)
E depois nmap -sS -p 1000-1999 example.com(14 segundos para terminar) etc.

Se usar peças mais largas: nmap -sS -p 0-3999 example.com
demora mais de 3 minutos para terminar.

E com nmap -sS -p 0-7999 example.comisso não termina depois de 30 minutos.

Então:
1.000 portas -> 12 segundos
4.000 portas -> 3 minutos
9.000 portas -> 30 minutos

Qual é o problema?
Como posso encontrar portas TCP abertas para um host com o nmap?

Responder1

O Nmap faz o possível para encontrar a velocidade com que pode encontrar com precisão o estado (aberto, fechado ou filtrado) de cada porta. O sistema de cronometragem é complexo e apresenta alguns dos piores cenários que podem levar a varreduras muito lentas. Um desses casos é quando o alvo são redefinições de conexão TCP com limitação de taxa (RST), que são as respostas que o Nmap recebe quando uma porta é fechada. A maioria das portas em um sistema geralmente está fechada e, para economizar recursos ou talvez impedir tentativas de varredura, o sistema operacional do alvo pode optar por emitir um RST apenas uma vez por segundo.

Quando o Nmap detecta limitação de taxa RST, ele deve desacelerar suas sondagens para corresponder a essa taxa, caso contrário, uma porta fechada pode ser marcada como "filtrada" porque nenhuma resposta foi recebida, consistente com um firewall descartando tráfego para aquela porta. Esse comportamento de desaceleração ocorre gradualmente, de modo que as primeiras portas não são tão afetadas quanto as posteriores. Além disso, afeta apenas portas fechadas, portanto, as portas comumente usadas entre 1 e 1000 têm menos probabilidade de contribuir para a lentidão.

Existe uma solução alternativa para esse problema, mas ela apresenta uma perda de precisão. Se você não se importa em saber a diferença entre portas filtradas e fechadas, você pode usar a --defeat-rst-ratelimitopção de não permitir que RSTs com taxa limitada afetem o tempo do Nmap. O Nmap continuará enviando a uma taxa apropriada para a rede, detectando pacotes descartados e desacelerando quando necessário, mas ficando perfeitamente satisfeito em marcar portas fechadas como filtradas. O conjunto de portas abertas deve ser exatamente o mesmo, que é tudo o que a maioria das pessoas deseja. Na verdade, você pode até adicionar --openpara evitar a impressão de informações sobre portas fechadas e filtradas.

Responder2

Você pode adicionar a -T5opção de aumentar a velocidade da digitalização. De acordo comTempo e desempenho do nmapé recomendado usar -T4a opção:

Eu recomendaria sempre usar -T4. Algumas pessoas adoram -T5, embora seja muito agressivo para o meu gosto. Às vezes, as pessoas especificam -T2 porque acham que é menos provável que os hosts travem ou porque se consideram educados em geral. Muitas vezes eles não percebem o quão lento o -T educado realmente é. A verificação deles pode demorar dez vezes mais do que uma verificação padrão. Falhas de máquina e problemas de largura de banda são raros com as opções de tempo padrão (-T3) e por isso normalmente recomendo isso para scanners cautelosos. Omitir a detecção de versão é muito mais eficaz do que brincar com valores de tempo para reduzir esses problemas.

Responder3

Tente executar o nmap com -v(detalhado) para ajudá-lo a descobrir por que há uma lentidão.

A execução nmap -sS -Pn -v -p 1-9999 myserver.comem um dos meus próprios servidores produz o seguinte em algum lugar após 3.000 portas:

Increasing send delay for (ip address) from 0 to 5 due to max_successful_tryno increase to 4
Increasing send delay for (ip address) from 5 to 10 due to 17 out of 55 dropped probes since last increase.
[...]
Increasing send delay for (ip address) from 160 to 320 due to 11 out of 31 dropped probes since last increase.
SYN Stealth Scan Timing: About 17.08% done; ETC: 13:17 (0:02:30 remaining)

Essas mensagens não parecem aparecer abaixo da porta 1024.

informação relacionada