O Nmap tem a habilidade de fazer um scan de portas ou de versões em múltiplos hosts em paralelo. O Nmap faz isso dividindo a faixa de endereços IP-alvo em grupos, e então escaneando um grupo de cada vez. No geral, grupos maiores são mais eficientes. A contrapartida é que os resultados dos hosts não pode ser fornecido até que o grupo inteiro tenha terminado. Portanto, se o Nmap começou com um tamanho de grupo igual a 50, o usuário não receberia nenhum relatório (exceto pelas atualizações mostradas no modo verbose) até que os primeiros 50 hosts tivessem completado.

Por padrão, o Nmap assume um compromisso para resolver esse conflito. Ele começa com um tamanho de grupo pequeno, igual a cinco, para que os primeiros resultados venham rápido, e então aumenta o tamanho até que chegue em 1024. O número padrão exato depende das opções fornecidas. Por questões de eficiência, o Nmap usa tamanhos de grupo maiores para o UDP ou para scans TCP com poucas portas.

Quando o tamanho de grupo máximo é especificado com --max-hostgroup, o Nmap nunca irá exceder esse tamanho. Especifique um tamanho mínimo com --min-hostgroup e o Nmap irá tentar manter o tamanho dos grupos acima desse nível. O Nmap pode ter que usar tamanhos menores do que você especificou, se não houverem hosts-alvo suficientes restantes em uma dada interface, para completar o mínimo especificado. Ambos podem ser configurados para manter o tamanho do grupo dentro de uma faixa específica, embora isso raramente seja desejado.

O uso primário destas opções é especificar um tamanho de grupo mínimo grande de forma que o scan completo rode mais rapidamente. Uma escolha comum é 256 para escanear uma rede em blocos de tamanho Classe C. Para um scan com muitas portas, exceder esse número não irá ajudar muito. Para scans com poucos números de portas, um tamanho de grupo de hosts de 2048 ou mais pode ser útil.

Estas opções controlam o número total de sondagens que podem estar pendentes para um grupo de hosts. Elas são usadas para o escaneamento de portas e para a descoberta de hosts. Por padrão, o Nmap calcula um paralelismo ideal e constantemente atualizado baseado no desempenho da rede. Se os pacotes estiverem sendo descartados, o Nmap reduz o ritmo e libera menos sondagens pendentes. O número de sondagens ideal aumenta vagarosamente conforme a rede se mostre mais confiável. Estas opções estabelecem limites mínimo e máximo nessa variável. Por padrão, o paralelismo ideal pode cair até 1 se a rede se mostrar não-confiável e subir até diversas centenas em condições perfeitas.

O uso mais comum é estabelecer --min-parallelism em um número maior que 1 para melhorar a velocidade dos scans de hosts ou redes com desempenho ruim. Esta é uma opção arriscada para se ficar brincando pois configurar um valor alto demais pode afetar a precisão. Configurar isso também reduz a habilidade do Nmap de controlar o paralelismo dinamicamente baseado nas condições da rede. Um valor igual a dez pode ser razoável, embora eu só ajuste esse valor como última alternativa.

A opção --max-parallelism às vezes é configurada para evitar que o Nmap envie aos hosts mais do que uma sondagem por vez. Isso pode ser útil em conjunto com --scan-delay (discutido mais tarde), embora esta última normalmente sirva bem ao propósito por si só.

O Nmap mantém um valor de tempo de expiração (timeout) de execução para determinar quanto tempo ele deve esperar por uma resposta de uma sondagem antes de desistir ou retransmitir essa sondagem. Isso é calculado com base nos tempos de resposta de sondagens anteriores. Se a latência da rede se mostrar significativa e variável, esse tempo de expiração pode subir para diversos segundos. Ele também começa com um nível conservador (alto) e pode ficar desse jeito por um tempo, enquanto o Nmap escaneia hosts não-responsivos.

Especificar valores --max-rtt-timeout e --initial-rtt-timeout mais baixos que o padrão pode reduzir o tempo de scan significativamente. Isso é particularmente verdadeiro para scans sem ping (-P0), e para aqueles contra redes bastante filtradas. Mas não se torne muito agressivo. O scan pode acabar levando mais tempo se você especificar um valor tão baixo que muitas sondagens irão expirar o tempo e serem retransmitidas enquanto a resposta ainda está em trânsito.

Se todos os hosts estão em uma rede local, 100 milissegundos é um valor de --max-rtt-timeout razoavelmente agressivo. Se houver roteamento envolvido, faça um ping de um host da rede primeiro com o utilitário ICMP ping, ou com um formatador de pacotes customizados como o hping2, que pode passar por um firewall mais facilmente. Descubra o tempo máximo de round trip em dez pacotes, mais ou menos. Coloque o dobro desse valor em --initial-rtt-timeout e o triplo ou quádruplo para o --max-rtt-timeout. Normalmente eu não configuro o rtt máximo abaixo de 100ms, não importa quais os tempos de ping. Eu também não excedo o valor 1000ms.

--min-rtt-timeout é uma opção raramente utilizada que poderia ser útil quando uma rede é tão não-confiável que mesmo o padrão do Nmap é muito agressivo. Considerando que o Nmap apenas reduz o tempo de expiração para um valor mínimo quando a rede parece ser confiável, esta necessidade não é comum e deveria ser reportada à lista de discussão nmap-dev como um bug.

Quando o Nmap não recebe nenhuma resposta a uma sondagem de escaneamento de portas, isso pode significar que a porta está filtrada. Ou talvez a sondagem ou a resposta simplesmente se perdeu na rede. Também é possível que o host-alvo tenha habilitado uma limitação de tráfego que tenha bloqueado temporariamente a resposta. Então o Nmap tenta novamente retransmitindo a sondagem inicial. Se o Nmap perceber que a confiabilidade da rede está baixa, ele poderá tentar muitas vezes ainda, antes de desistir de uma porta. Embora isso beneficie a exatidão, isso também aumenta o tempo de escaneamento. Quando o desempenho é crítico, os escaneamentos podem ser acelerados através da limitação do número de retransmissões permitidas. Você pode até especificar --max-retries 0 para evitar qualquer retransmissão, embora isto seja raramente recomendado.

O normal (sem nenhum padrão -T) é permitir dez retransmissões. Se a rede aparentar ser confiável e os hosts-alvo não estiverem limitando o tráfego, o Nmap normalmente fará apenas uma retransmissão. Portanto, a maioria dos escaneamentos de alvos não serão sequer afetados com a redução do --max-retries para um valor baixo, como por exemplo três. Tais valores podem acelerar significativamente o escaneamento de hosts lentos (com limitação de tráfego). Você normalmente perde alguma informação quando o Nmap desiste das portas rapidamente, embora isso seja preferível a permitir que o --host-timeout expire e você perca todas as informações sobre o alvo.

Alguns hosts simplesmente levam tempo demais para serem escaneados. Isso pode ser causado por um hardware ou software de rede com fraco desempenho ou pouco confiável, limitação na taxa dos pacotes ou por um firewall restritivo. Os poucos hosts mais lentos de todos os hosts escaneados podem acabar sendo responsáveis pela maior parte do tempo total gasto com o scan. Às vezes é melhor cortar fora o prejuízo e pular esses hosts logo no início. Especifique a opção --host-timeout com o valor máximo de tempo que você tolera esperar. Eu normalmente especifico 30m para ter certeza de que o Nmap não gaste mais do que meia hora em um único host. Note que o Nmap pode estar escaneando outros hosts ao mesmo tempo em que essa meia hora desse único host está correndo, então não é uma perda de tempo total. Um host que expira o tempo é pulado. Nenhum resultado de tabela de portas, detecção de SO ou detecção de versão é mostrado para esse host.

Esta opção faz com que o Nmap aguarde um tempo determinado entre cada sondagem enviada a um dado host. Isto é particularmente útil no caso de limitação de taxas de transferência. Máquinas Solaris (entre muitas outras) irão normalmente responder à pacotes de sondagens de scans UDP com apenas uma mensagem ICMP por segundo. Qualquer número maior que isso, enviado pelo Nmap, será um desperdício. Um --scan-delay de 1s irá manter uma taxa de transferência baixa. O Nmap tenta detectar a limitação de taxa e ajusta o atraso no scan de acordo, mas não dói especificar explicitamente se você já sabe qual a taxa que funciona melhor.

Quando o Nmap ajusta o atraso no scan aumentando para tentar igualar com a limitação na taxa de transferência, o scan fica consideravelmente mais lento. A opção --max-scan-delay especifica o maior atraso que o Nmap irá permitir. Estabelecer um valor muito baixo pode levar à uma retransmissão de pacotes inútil e à possíveis portas perdidas, quando o alvo utiliza limitação rígida de taxa de transferência.

Outro uso do --scan-delay é para evitar os sistemas de prevenção e detecção de intrusão (IDS/IPS) baseados em limites.

Muitos hosts usam há bastante tempo a limitação de taxa de transferência para reduzir o número de mensagens de erro ICMP (tais como os erros de porta-inalcançavel) enviados. Alguns sistemas agora aplicam limitações de taxa similares aos pacotes RST (reset) que eles geram. Isso pode tornar o Nmap consideravelmente mais lento pois o obriga a ajustar seu tempo de forma a refletir essas limitações de taxa. Você pode dizer ao Nmap para ignorar essas limitações de taxa (para scans de porta como o Scan SYN que não trata portas que não respondem como abertas) especificando --defeat-rst-ratelimit.

Utilizar esta opção pode reduzir a precisão, pois algumas portas irão aparecer como não-respondendo porque o Nmap não esperou tempo suficiente para uma resposta RST com taxa limitada. No caso de um scan SYN, o "não-respondendo" resulta na porta sendo rotulada como filtrada ao invés de no estado fechada que vemos quando os pacotes RST são recebidos. Esta opção é útil quando você se importa apenas com as portas abertas e distinguir entre portasfechadas e filtradas não vale o tempo extra.

Embora os controles de temporização de ajuste fino discutidos nas seções anteriores sejam poderosos e efetivos, algumas pessoas os consideram confusos. Ainda mais, escolher os valores apropriados pode, às vezes, tomar mais tempo do que o próprio scan que você está tentando otimizar. Por isso, o Nmap oferece uma aproximação mais simples, com seis padrões de temporização. Você pode especificá-los com a opção -T e os números (0 - 5) ou os nomes. Os nomes de padrões são paranóico (paranoid, 0), furtivo (sneaky, 1), educado (polite, 2), normal (3), agressivo (agressive, 4) e insano (insane, 5). Os dois primeiros são para evitar um IDS. O modo educado (ou polido), diminui o ritmo de escaneamento para usar menos banda e recursos da máquina alvo. O modo normal é o padrão e, portanto, -T3 não faz nada. O modo agressivo acelera os scans assumindo que você está em uma rede razoavelmente rápida e confiável. Finalmente, o modo insano assume que você está em uma rede extraordinariamente rápida ou está disposto a sacrificar alguma precisão pela velocidade.

Esses padrões permitem que o usuário especifique o quão agressivo desejam ser, ao mesmo tempo que deixam o Nmap escolher os valores de temporização exatos. Os padrões também fazem ajustes pequenos na velocidade onde ainda não existem opções para controle de ajuste fino. Por exemplo, -T4 proibe que o atraso dinâmico de escaneamento exceda 10ms para portas TCP e -T5 corta esse valor para 5 milissegundos. Padrões podem ser utilizados em conjunto com controles de ajuste fino e esses controles que você especificar irão ter precedência sobre o padrão de temporização do parâmetro. Eu recomendo usar -T4 quando escanear redes razoavelmente modernas e confiáveis. Mantenha essa opção mesmo que você adicione controles de ajuste fino, de forma que você possa se beneficiar com as pequenas otimizações extras que ela habilita.

Se você tiver uma conexão ethernet ou de banda-larga decente, eu recomendaria sempre utilizar -T4. Algumas pessoas adoram o -T5 embora seja agressivo demais para o meu gosto. As pessoas às vezes especificam -T2 porque acham que diminui a probabilidade de travar os hosts ou porque elas se consideram educadas no geral. Normalmente elas não percebem o quão lento o -T Polite realmente é. Esses scans podem levar dez vezes mais tempo que um scan padrão. Travamento de máquinas e problemas com a banda são raros com as opções de temporização padrão (-T3) e, portanto, eu normalmente as recomendo para escaneadores precavidos. Omitir a detecção de versão é bem mais eficaz do que ficar brincando com os valores de temporização para reduzir esses problemas.

Embora o -T0 e o -T1 possam ser usados para evitar alertas no IDS, eles irão leva muito mais tempo para escanear milhares de máquinas ou portas. Para um scan tão amplo, prefira estabelecer os valores exatos de temporização que você precisa ao invés de depender dos valores "engessados" de -T0 e -T1.

O principal efeito de T0 é serializar o scan de forma que apenas uma porta é escaneada por vez, e então, aguardar cinco minutos entre o envio de cada sondagem. T1 e T2 são similares mas aguardam apenas 15 segundos e 0,4 segundos, respectivamente, entre as sondagens. T3 é o comportamento padrão do Nmap, que inclui o paralelismo. T4 faz o mesmo que --max-rtt-timeout 1250 --initial-rtt-timeout 500 --max_retries 6 e estabelece o atraso máximo de scan TCP em 10 milissegundos. T5 faz o mesmo que --max-rtt-timeout 300 --min-rtt-timeout 50 --initial-rtt-timeout 250 --max-retries 2 --host-timeout 15m e estabelece o atraso máximo de scan TCP em 5ms.