Existem basicamente 4 coisas que fazem uma varredura demorar muito:
- Envio de probes que você não precisa enviar
- Latência
- Pacotes ignorados
- Taxa de limitação de respostas por metas
Acelerar sua varredura geralmente é realizado medindo e planejando cada um desses aspectos até atingir a velocidade desejada, mantendo a precisão.
Com relação a 1, o maior problema que você tem aqui é -Pn
, que desativa a descoberta de host. Descoberta de hosts é como o Nmap sabe quais endereços valem a varredura de portas ("up") e quais não responderão de qualquer forma, geralmente devido a nenhum host ter esse endereço configurado. Em uma rede / 16, você estará examinando 65536 endereços. Se você sabe que tem apenas 5.000 ativos na rede, então 92% de sua verificação será desperdiçada. Brinque com as várias opções de -P*
usando -sn
para evitar a varredura real da porta até encontrar um conjunto de testes que funcionem bem em sua rede. Agora, se você puder fazer descobertas de alguma outra forma, como usar -iL
para importar uma lista de endereços ativos de seus sensores internos de IDS, então -Pn
pode ser usado para evitar pular um endereço que você sabe que está apenas porque não responda às sondas de descoberta padrão.
Outro potencial desperdício de probes que você pode estar faltando é a resolução reversa de nomes DNS. Esta é uma grande fonte de informação, e o Nmap é muito rápido, mas se você não precisa saber o nome DNS (registro PTR) para cada endereço, adicionar -n
irá cortar essa fase completamente, economizando algum tempo precioso.
Para 2, a latência geralmente é algo que você não pode controlar. Mas você pode ser esperto em deixar o Nmap saber quais latências você espera. Se você estiver em uma LAN, então definir --max-rtt-timeout
pode ajudar a acelerar a varredura informando ao Nmap para não esperar muito tempo para ouvir um pacote em particular. Mas tenha cuidado para não ser muito otimista; se o Nmap desistir muito cedo, ele contará o pacote como descartado e diminuirá a velocidade para evitar quedas adicionais. Use as informações de latência de uma avaliação de -sn
para ter uma idéia do pior caso e, em seguida, dobre para ser seguro. Ainda será menor que o padrão se sua rede for razoavelmente rápida.
Falando em pacotes descartados (número 3 em nossa lista), essa é a principal fonte de imprecisão quando você tenta digitalizar muito rápido. Você pode sobrecarregar seu próprio link ou os recursos do próprio destino se ele for muito restrito por recursos (como os dispositivos ICS ou IoT podem ser). Se sua rede é rápida e capaz o suficiente para não ter muitos pacotes descartados, você pode definir --max-retries
para um número menor que o padrão (que é 10) para acelerar um pouco, com o risco de ter alguma imprecisão. Como o Nmap detecta pacotes perdidos e fica mais lento, você provavelmente não acabará afetando o tráfego de mais ninguém por mais de alguns segundos, a menos que você esteja usando --min-rate
para continuar a disparar os pacotes.
O número 4, limitação de taxa por alvo, é complicado porque não está sob o seu controle (a menos que você possa ter sua máquina de varredura na lista de permissões por qualquer coisa que esteja limitando a taxa). Existem alguns truques: para um tipo específico de ratelimiting TCP RST, a opção --defeat-rst-ratelimit
permitirá que você mantenha a velocidade de varredura ao custo de ter algumas portas rotuladas como "filtradas", que provavelmente estão "fechadas". As portas abertas não serão afetadas, e geralmente isso é tudo de que você está interessado.
Modelos de tempo (como -T4
que você mencionou) definirão algumas dessas opções para você, mas você está sempre livre para substituí-los por opções mais específicas. Verifique a página do manual para a versão do Nmap que você está usando para ver exatamente quais opções são definidas por cada modelo. Esteja ciente de que -T5
define a opção --host-timeout
, portanto, se algum destino demorar mais de 15 minutos para ser concluído (muito possível com uma varredura de todas as portas), ele será descartado e nenhuma saída será mostrada.
Definir um valor IPL TTL mais baixo com --ttl
não reduzirá o ruído da rede, a menos que você tenha loops de roteamento. Ele impedirá que seus testes atinjam destinos que estejam a mais de 10 saltos, se isso for importante para você.
Por fim, certifique-se sempre de usar a última versão do Nmap disponível . Estamos sempre fazendo melhorias que tornam a digitalização mais rápida e confiável.