-sL(List Scan)
O scan de lista é uma forma degenerada de descoberta de hosts que simplesmente lista cada host da(s) rede(s) especificada(s), sem enviar quaisquer pacotes para os hosts alvo. Por padrão, o Nmap ainda faz a resolução DNS reversa nos hosts para aprender seus nomes. Muitas vezes é surpreendente a quantidade de informação útil que simples nomes de hosts fornecem. Por exemplo, fw.chi é o nome do firewall de Chicago de uma empresa. O Nmap também relata o número total de endereços IP no final. A verificação da lista é uma boa verificação de sanidade para garantir que você tenha os endereços IP adequados para seus alvos. Se os nomes de domínio de esportes de host que você não reconhece, vale a pena investigar mais para evitar a varredura da rede errada da empresa.
Desde que a idéia é simplesmente imprimir uma lista de hosts alvo, as opções para funcionalidade de nível mais alto, tais como varredura de portas, detecção de SO, ou descoberta de host não podem ser combinadas com isso. Se você deseja desativar a descoberta de host enquanto ainda estiver executando essa funcionalidade de nível superior, leia a opção -Pn (pular descoberta de host).
-sn(Sem descoberta de porta)
Esta opção diz ao Nmap para não fazer uma verificação de porta após a descoberta de host, e somente imprimir os hosts disponíveis que responderam às sondas de descoberta de host. Isto é frequentemente conhecido como um “ping scan”, mas você também pode solicitar que os scripts traceroute e host NSE sejam executados. Isto é, por padrão, um passo mais intrusivo do que o scan da lista, e pode ser usado frequentemente para os mesmos propósitos. Ele permite o reconhecimento leve de uma rede alvo sem atrair muita atenção. Saber quantos hosts estão no ar é mais valioso para os atacantes do que a lista fornecida pelo scan de lista de cada IP e nome de host.
Os administradores de sistemas frequentemente consideram esta opção também valiosa. Ela pode ser facilmente usada para contar as máquinas disponíveis em uma rede ou monitorar a disponibilidade do servidor. Isto é frequentemente chamado de ping sweep, e é mais confiável do que pingar o endereço de broadcast porque muitos hosts não respondem a consultas de broadcast.
A descoberta padrão do host feita com -sn consiste de um pedido de eco ICMP, TCP SYN para porta 443, TCP ACK para porta 80, e um pedido de timestamp ICMP por padrão. Quando executado por um usuário sem privilégios, apenas pacotes SYN são enviados (usando uma chamada connect) para as portas 80 e 443 no alvo. Quando um usuário privilegiado tenta escanear alvos em uma rede ethernet local, solicitações ARP são usadas a menos que --send-ip tenha sido especificado. A opção -sn pode ser combinada com qualquer um dos tipos de sonda de descoberta (as opções -P*) para maior flexibilidade. Se qualquer um desses tipos de sonda e opções de número de porta for utilizado, as sondas padrão são anuladas. Quando existem firewalls rígidos entre o host de origem executando o Nmap e a rede alvo, é recomendado o uso dessas técnicas avançadas. Caso contrário, os hosts poderão não ser executados quando o firewall soltar as sondas ou suas respostas.
Em versões anteriores do Nmap, -sn era conhecido como -sP.
-Pn(Sem ping)
Esta opção salta completamente o estágio de descoberta do host. Normalmente, o Nmap usa este estágio para determinar as máquinas ativas para um escaneamento mais pesado e para medir a velocidade da rede. Por padrão, o Nmap só executa sondagens pesadas como varredura de portas, detecção de versão ou detecção de SO contra hosts que são encontrados para cima. A desativação da descoberta de hosts com -Pn faz com que o Nmap tente as funções de varredura solicitadas contra todos os endereços IP de destino especificados. Assim, se uma rede de tamanho /16 for especificada na linha de comando, todos os 65.536 endereços IP são escaneados. A descoberta correta do host é pulada como na varredura da lista, mas ao invés de parar e imprimir a lista de destino, o Nmap continua a executar as funções solicitadas como se cada IP de destino estivesse ativo. Os parâmetros de tempo padrão são usados, o que pode resultar em varreduras mais lentas. Para pular a descoberta de hosts e o scan de portas, enquanto ainda permite a execução do NSE, use as duas opções -Pn -sn em conjunto.
Para máquinas em uma rede ethernet local, o scan ARP ainda será executado (a menos que --disable-arp-ping ou --send-ip seja especificado) porque o Nmap precisa de endereços MAC para fazer um scan adicional dos hosts alvo. Nas versões anteriores do Nmap, -Pn era -P0 e -PN.
-PS (TCP SYN Ping)<port list>
Esta opção envia um pacote TCP vazio com o flag SYN definido. A porta de destino padrão é 80 (configurável em tempo de compilação, alterando DEFAULT_TCP_PROBE_PORT_SPEC em nmap.h). Portas alternativas podem ser especificadas como um parâmetro. A sintaxe é a mesma que para a -p exceto que não são permitidos especificadores de tipo de porta como T:. Exemplos são -PS22 e -PS22-25,80,113,1050,35000. Note que não pode haver espaço entre -PS e a lista de portas. Se múltiplas sondas forem especificadas, elas serão enviadas em paralelo.
A bandeira SYN sugere ao sistema remoto que você está tentando estabelecer uma conexão. Normalmente a porta de destino será fechada, e um pacote RST (reset) será enviado de volta. Se a porta estiver aberta, o alvo dará o segundo passo de um handshake TCP de três vias, respondendo com um pacote SYN/ACK TCP. A máquina rodando o Nmap, então, derruba a conexão nascente respondendo com um RST ao invés de enviar um pacote ACK que completaria o handshake de três vias e estabeleceria uma conexão completa. O pacote RST é enviado pelo kernel da máquina rodando o Nmap em resposta ao inesperado SYN/ACK, não pelo próprio Nmap.
Nmap não se importa se a porta está aberta ou fechada. Ou a resposta RST ou SYN/ACK discutida anteriormente diz ao Nmap que o host está disponível e responsivo.
Em caixas Unix, apenas o usuário privilegiado root é geralmente capaz de enviar e receber pacotes TCP brutos. Para usuários não privilegiados, uma alternativa é automaticamente empregada, onde a chamada de sistema connect é iniciada contra cada porta de destino. Isto tem o efeito de enviar um pacote SYN para o host de destino, numa tentativa de estabelecer uma conexão. Se connect retornar com um sucesso rápido ou uma falha ECONNREFUSED, a pilha TCP subjacente deve ter recebido um SYN/ACK ou RST e o host está marcado como disponível. Se a tentativa de conexão for deixada suspensa até que um timeout seja alcançado, o host é marcado como desligado.
-PA (TCP ACK Ping)<port list>
O TCP ACK ping é bastante similar ao SYN ping recém-discutido. A diferença, como você provavelmente poderia adivinhar, é que a bandeira TCP ACK é definida em vez da bandeira SYN. Tal pacote ACK parece estar reconhecendo dados sobre uma conexão TCP estabelecida, mas tal conexão não existe. Então hosts remotos devem sempre responder com um pacote RST, revelando sua existência no processo.
A opção -PA usa a mesma porta padrão da sonda SYN (80) e também pode pegar uma lista de portas de destino no mesmo formato. Se um usuário sem privilégios tentar isso, o connect workaround discutido anteriormente é usado. Esta alternativa é imperfeita porque connect está enviando um pacote SYN ao invés de um ACK.
A razão para oferecer ambas as sondas SYN e ACK ping é para maximizar as chances de contornar firewalls. Muitos administradores configuram roteadores e outros firewalls simples para bloquear pacotes SYN de entrada, exceto aqueles destinados a serviços públicos como o site da empresa ou o servidor de e-mail. Isto impede outras conexões de entrada para a organização, enquanto permite aos usuários fazer conexões de saída desobstruídas para a Internet. Esta abordagem não estatal consome poucos recursos no firewall/router e é amplamente suportada por filtros de hardware e software. O software Netfilter/iptables firewall do Linux oferece a opção --syn conveniência para implementar esta abordagem sem estado. Quando regras de firewall sem estado como esta estão em vigor, as sondas de ping SYN (-PS) provavelmente serão bloqueadas quando enviadas para portas alvo fechadas. Nesses casos, a sonda ACK brilha ao cortar diretamente através dessas regras.
Um outro tipo comum de firewall usa regras de estado que derrubam pacotes inesperados. Esta característica foi inicialmente encontrada principalmente em firewalls de alto nível, embora tenha se tornado muito mais comum ao longo dos anos. O sistema Linux Netfilter/iptables suporta isso através da opção --state, que categoriza os pacotes com base no estado da conexão. Uma sonda SYN é mais provável que funcione contra tal sistema, pois pacotes ACK inesperados são geralmente reconhecidos como falsos e descartados. Uma solução para este quandary é enviar ambas as sondas SYN e ACK especificando -PS e -PA.
-PU (UDP Ping)<port list>
Outra opção de descoberta do host é o ping UDP, que envia um pacote UDP para as portas dadas. Para a maioria das portas, o pacote estará vazio, embora alguns usem uma carga útil específica do protocolo que é mais provável que obtenha uma resposta.Veja a seção chamada “UDP payloads”: -PS e -PA discutidas anteriormente. Se nenhuma porta for especificada, o padrão é 40125. Este padrão pode ser configurado em tempo de compilação alterando DEFAULT_UDP_PROBE_PORT_SPEC em nmap.h. Uma porta altamente incomum é usada por padrão porque enviar para portas abertas é muitas vezes indesejável para este tipo particular de scan.
Apontando para uma porta fechada na máquina alvo, a sonda UDP deve obter em troca uma porta ICMP inalcançável. Isto significa para o Nmap que a máquina está pronta e disponível. Muitos outros tipos de erros ICMP, tais como host/rede inalcançável ou TTL excedida são indicativos de um host inatingível ou inatingível. A falta de resposta também é interpretada desta forma. Se uma porta aberta for alcançada, a maioria dos serviços simplesmente ignoram o pacote vazio e não retornam nenhuma resposta. Esta é a razão pela qual a porta padrão da sonda é 40125, que é altamente improvável que esteja em uso. Alguns serviços, como o protocolo Character Generator (chargen), irão responder a um pacote UDP vazio, e assim revelar ao Nmap que a máquina está disponível.
A principal vantagem deste tipo de scan é que ele ultrapassa firewalls e filtros que só filtram TCP. Por exemplo, eu já tive um roteador de banda larga sem fio BEFW11S4 da Linksys. A interface externa deste dispositivo filtrava todas as portas TCP por padrão, mas as sondas UDP ainda assim obteriam mensagens de porta inalcançáveis e assim entregariam o dispositivo.
-PY (SCTP INIT Ping)<port list>
Esta opção envia um pacote SCTP contendo um pedaço mínimo de INIT. A porta de destino padrão é 80 (configurável em tempo de compilação alterando DEFAULT_SCTP_PROBE_PORT_SPEC em nmap.h). Portas alternativas podem ser especificadas como um parâmetro. A sintaxe é a mesma do -p exceto que não são permitidos especificadores de tipo de porta como S:. Exemplos são -PY22 e -PY22,80,179,5060. Note que não pode haver espaço entre -PY e a lista de portas. Se múltiplas sondas forem especificadas, elas serão enviadas em paralelo.
A parte do INIT sugere ao sistema remoto que você está tentando estabelecer uma associação. Normalmente a porta de destino será fechada, e um trecho ABORT será enviado de volta. Se a porta estiver aberta, o alvo dará o segundo passo de um aperto de mão de quatro vias do SCTP respondendo com um trecho INIT-ACK. Se a máquina rodando o Nmap tiver uma pilha SCTP funcional, então ela derrubará a associação nascente respondendo com um trecho ABORT ao invés de enviar um trecho COOKIE-ECHO que seria o próximo passo no aperto de mão de quatro vias. O pacote ABORT é enviado pelo kernel da máquina rodando o Nmap em resposta ao inesperado INIT-ACK, não pelo próprio Nmap.
Nmap não se importa se a porta está aberta ou fechada. Ou a resposta ABORT ou INIT-ACK discutida anteriormente diz ao Nmap que o host está disponível e responsivo.
Em caixas Unix, apenas o usuário privilegiado root é geralmente capaz de enviar e receber pacotes SCTP brutos. Usando SCTP INIT Pings não é possível atualmente para usuários não privilegiados.
-PE;-PP;-PM(Tipos de Ping ICMP)
Além dos tipos de descoberta de hosts TCP, UDP e SCTP incomuns discutidos anteriormente, o Nmap pode enviar os pacotes padrão enviados pelo programa de ping ubíquo. O Nmap envia um pacote ICMP tipo 8 (echo request) para os endereços IP de destino, esperando um tipo 0 (echo reply) em retorno dos hosts disponíveis. Infelizmente para os exploradores de rede, muitos hosts e firewalls agora bloqueiam esses pacotes, ao invés de responder conforme requerido pela RFC 1122. Por esta razão, scans apenas ICMP raramente são confiáveis o suficiente contra alvos desconhecidos através da Internet. Mas para administradores de sistemas monitorando uma rede interna, eles podem ser uma abordagem prática e eficiente. Use a opção -PE para habilitar este comportamento de pedido de eco.
Embora o pedido de eco seja a consulta padrão de ping ICMP, o Nmap não para por aí. Os padrões ICMP (RFC 792 e RFC 950 ) também especificam pedido de carimbo de data/hora, pedido de informação e pacotes de pedido de máscara de endereço como códigos 13, 15, e 17, respectivamente. Embora o propósito ostensivo dessas consultas seja aprender informações como máscaras de endereço e horários atuais, elas podem ser facilmente usadas para a descoberta do host. Um sistema que responde está pronto e disponível. Atualmente o Nmap não implementa pacotes de solicitação de informações, pois eles não são amplamente suportados. A RFC 1122 insiste que “um host NÃO DEVE implementar estas mensagens”. As consultas de timestamp e máscara de endereço podem ser enviadas com as opções -PP e -PM, respectivamente. Uma resposta de carimbo da hora (código ICMP 14) ou resposta de máscara de endereço (código 18) revela que o host está disponível. Essas duas consultas podem ser valiosas quando administradores bloqueiam especificamente pacotes de requisição de eco enquanto esquecem que outras consultas ICMP podem ser usadas para o mesmo propósito.
-PO (IP Protocol Ping)<protocol list>
Uma das novas opções de descoberta do host é o ping de protocolo IP, que envia pacotes IP com o número de protocolo especificado definido em seu cabeçalho IP. A lista de protocolos tem o mesmo formato das listas de portas nas opções de descoberta de hosts TCP, UDP e SCTP discutidas anteriormente. Se nenhum protocolo for especificado, o padrão é enviar múltiplos pacotes IP para ICMP (protocolo 1), IGMP (protocolo 2), e IP-in-IP (protocolo 4). Os protocolos padrão podem ser configurados em tempo de compilação alterando DEFAULT_PROTO_PROBE_PORT_SPEC em nmap.h. Note que para o ICMP, IGMP, TCP (protocolo 6), UDP (protocolo 17) e SCTP (protocolo 132), os pacotes são enviados com os cabeçalhos de protocolo apropriados enquanto outros protocolos são enviados sem dados adicionais além do cabeçalho IP (a menos que qualquer uma das opções --data, --data-string, ou --data-length seja especificada).
Este método de descoberta do host procura por respostas usando o mesmo protocolo que uma sonda, ou mensagens inalcançáveis do protocolo ICMP que significam que o protocolo dado não é suportado no host de destino. Qualquer tipo de resposta significa que o host alvo está vivo.
--disable-arp-ping(Sem ARP ou ND Ping)
Nmap normalmente faz a descoberta de ARP ou IPv6 Neighbor Discovery (ND) de hosts ethernet conectados localmente, mesmo que outras opções de descoberta de host como -Pn ou -PE sejam usadas. Para desativar este comportamento implícito, use a opção --disable-arp-ping.
O comportamento padrão é normalmente mais rápido, mas esta opção é útil em redes usando proxy ARP, no qual um roteador responde especulativamente a todas as solicitações ARP, fazendo com que cada alvo pareça estar acima de acordo com a verificação ARP.
--discovery-ignore-rst
Em alguns casos, firewalls podem falsificar respostas de reset TCP (RST) em resposta a sondas para endereços desocupados ou proibidos. Como o Nmap normalmente considera as respostas do RST como prova de que o alvo está acima, isso pode levar ao desperdício de tempo com a varredura de alvos que não estão lá. Usando o --discovery-ignore-rst irá impedir o Nmap de considerar estas respostas durante a descoberta do host. Você pode precisar selecionar opções extras de descoberta de host para garantir que você não perca os alvos neste caso.
--traceroute(Trace path to host)
Traceroutes são executados após a varredura usando informações dos resultados da varredura para determinar a porta e o protocolo com maior probabilidade de atingir o alvo. Funciona com todos os tipos de varredura, exceto a conexão de varreduras (-sT) e varreduras ociosas (-sI). Todos os traços usam o modelo de tempo dinâmico do Nmap e são executados em paralelo.
Traceroute funciona enviando pacotes com um baixo TTL (time-to-live) numa tentativa de obter tempo ICMP Mensagens excedidas de hops intermediários entre o scanner e o host alvo. As implementações do traceroute padrão começam com uma TTL de 1 e incrementam a TTL até que o host de destino seja alcançado. O traceroute do Nmap começa com uma TTL alta e depois decresce a TTL até chegar a zero. Fazendo-o ao contrário permite ao Nmap empregar algoritmos de cache inteligentes para acelerar os traços em vários hosts. Em média, o Nmap envia 5-10 pacotes a menos por host, dependendo das condições da rede. Se uma única sub-rede estiver sendo escaneada (ou seja, 192.168.0.0/24) o Nmap pode ter que enviar apenas dois pacotes para a maioria dos hosts.
-n(Sem resolução DNS)
Diz ao Nmap para nunca inverter a resolução DNS nos endereços IP ativos que encontrar. Como o DNS pode ser lento mesmo com o resolvedor de stub paralelo embutido no Nmap, esta opção pode reduzir o tempo de varredura.
-R(resolução DNS para todos os alvos)
Diz ao Nmap para sempre fazer resolução DNS reversa nos endereços IP de destino. Normalmente o DNS reverso só é executado contra hosts responsivos (online).
--resolve-all(Digitalize cada endereço resolvido)
Se um alvo de hostname resolve para mais de um endereço, digitalize todos eles. O comportamento padrão é verificar apenas o primeiro endereço resolvido. Independentemente disso, apenas os endereços da família de endereços apropriada serão digitalizados: IPv4 por padrão, IPv6 com -6.
--system-dns(Use o resolvedor DNS do sistema)
Por padrão, o Nmap reverte-resolve endereços IP enviando consultas diretamente para os servidores de nomes configurados em seu host e, em seguida, escutando por respostas. Muitas solicitações (muitas vezes dezenas) são realizadas em paralelo para melhorar o desempenho. Especifique esta opção para usar seu resolvedor de sistema em vez disso (um IP de cada vez através da chamada getnameinfo). Isto é mais lento e raramente útil a menos que você encontre um bug no resolvedor paralelo do Nmap (por favor nos informe se você encontrar). O resolvedor de sistema é sempre usado para pesquisas futuras (obter um endereço IP de um hostname).
--dns-servers (Servidores a usar para consultas de DNS reverso)<server1>]
Por padrão, o Nmap determina seus servidores DNS (para resolução rDNS) a partir do seu arquivo resolv.conf (Unix) ou do Registro (Win32). Alternativamente, você pode usar esta opção para especificar servidores alternativos. Esta opção não é honrada se você estiver usando --system-dns. Usar múltiplos servidores DNS é muitas vezes mais rápido, especialmente se você escolher servidores confiáveis para o seu espaço IP de destino. Esta opção também pode melhorar o furto, já que suas requisições podem ser desviadas de praticamente qualquer servidor DNS recursivo na Internet.
Esta opção também vem a calhar quando digitaliza redes privadas. Às vezes, apenas alguns servidores de nomes fornecem informações rDNS adequadas, e você pode nem mesmo saber onde eles estão. Você pode procurar na rede pela porta 53 (talvez com detecção de versão), então tente varreduras de lista do Nmap (-sL) especificando cada servidor de nome um de cada vez com --dns-servers até encontrar um que funcione.
Esta opção pode não ser honrada se a resposta DNS exceder o tamanho de um pacote UDP. Em tal situação nosso resolvedor DNS fará o melhor esforço para extrair uma resposta do pacote truncado, e se não for bem sucedido, ele voltará a usar o resolvedor do sistema. Além disso, respostas que contenham apelidos CNAME voltarão para o resolvedor do sistema.