O scan SYN é a opção de scan padrão e mais popular por boas razões. Pode ser executada rapidamente, escaneando milhares de portas por segundo em uma rede rápida, não bloqueada por firewalls intrusivos. O scan SYN é relativamente não-obstrusivo e camuflado, uma vez que ele nunca completa uma conexão TCP. Ele também trabalha contra qualquer pilha TCP padronizada ao invés de depender de idiossincrasias de plataformas específicas como os scans Fin/Null/Xmas, Maimon e Idle fazem. Ele também permite uma diferenciação limpa e confiável entre os estados aberto (open), fechado (closed), e filtrado (filtered).

Esta técnica é freqüentemente chamada de escaneamento de porta entreaberta (half-open scanning), porque você não abre uma conexão TCP completamente. Você envia um pacote SYN, como se fosse abrir uma conexão real e então espera uma resposta. Um SYN/ACK indica que a porta está ouvindo (aberta), enquanto um RST (reset) é indicativo de uma não-ouvinte. Se nenhuma resposta é recebida após diversas retransmissões, a porta é marcada como filtrada. A porta também é marcada como filtrada se um erro ICMP de inalcançável é recebido (tipo 3, código 1,2, 3, 9, 10, ou 13).

O scan TCP connect é o scan padrão do TCP quando o scan SYN não é uma opção. Esse é o caso quando o usuário não tem privilégios para criar pacotes em estado bruto ou escanear redes IPv6. Ao invés de criar pacotes em estado bruto como a maioria dos outros tipos de scan fazem, o Nmap pede ao sistema operacional para estabelecer uma conexão com a máquina e porta alvos enviando uma chamada de sistema connect(). Essa é a mesma chamada de alto nível que os navegadores da web, clientes P2P, e a maioria das outras aplicações para rede utilizam para estabelecer uma conexão. É parte da interface de programação conhecida como API de Sockets de Berkeley. Ao invés de ler as respostas em pacotes em estado bruto diretamente dos fios, o Nmap utiliza esta API para obter informações do estado de cada tentativa de conexão.

Quando um scan SYN está disponível é normalmente a melhor escolha. O Nmap tem menos controle sobre a chamada de alto nível connect() do que sobre os pacotes em estado bruto, tornando-o menos eficiente. A chamada de sistema completa as conexões nas portas-alvo abertas ao invés de executar o reset de porta entreaberta que o scan SYN faz. Isso não só leva mais tempo e requer mais pacotes para obter a mesma informação, mas também torna mais provável que as máquinas-alvo registrem a conexão. Um sistema IDS decente irá detectar qualquer um deles, mas a maioria das máquinas não tem esse tipo de sistema de alarme. Muitos serviços na maioria dos sistema Unix irão acrescentar uma nota no syslog, e às vezes uma mensagem de erro obscura, quando o Nmap se conecta e então fecha a conexão sem enviar nenhum dado. Serviços verdadeiramente patéticos irão travar quando isso acontecer, embora isso seja incomum. Um administrador que vê um punhado de tentativas de conexão nos registros vindos de um único sistema deveria saber que foi escaneado com connect().

Embora os serviços mais populares na Internet trafeguem sobre o protocolo TCP, os serviços UDP são amplamente difundidos. O DNS, o SNMP, e o DHCP (registrados nas portas 53, 161/162, e 67/68) são três dos mais comuns. Pelo fato do escaneamento UDP ser normalmente mais lento e mais difícil que o TCP, alguns auditores de segurança ignoram essas portas. Isso é um erro, pois serviços UDP passíveis de exploração são bastante comuns e invasores certamente não ignoram o protocolo inteiro. Felizmente o Nmap pode ajudar a inventariar as portas UDP.

O scan UDP é ativado com a opção -sU. Ele pode ser combinado com um tipo de escaneamento TCP como o scan SYN (-sS) para averigüar ambos protocolos na mesma execução.

O scan UDP funciona enviando um cabeçalho UDP vazio (sem dados) para cada porta almejada. Se um erro ICMP de porta inalcançável (tipo 3, código 3) é retornado, a porta está fechada. Outros erros do tipo inalcançável (tipo 3, códigos 1, 2, 9, 10, ou 13) marcam a porta como filtrada. Ocasionalmente um serviço irá responder com um pacote UDP, provando que está aberta. Se nenhuma resposta é recebida após as retransmissões, a porta é classificada como aberta|filtrada. Isso significa que a porta poderia estar aberta, ou talvez que filtros de pacotes estejam bloqueando a comunicação. Scans de versões (-sV) podem ser utilizados para ajudar a diferenciar as portas verdadeiramente abertas das que estão filtradas.

Um grande desafio com o escaneamento UDP é fazê-lo rapidamente. Portas abertas e filtradas raramente enviam alguma resposta, deixando o Nmap esgotar o tempo (time out) e então efetuar retransmissões para o caso de a sondagem ou a resposta ter sido perdida. Portas fechadas são, normalmente, um problema ainda maior. Elas costumam enviar de volta um erro ICMP de porta inalcançável. Mas, ao contrário dos pacotes RST enviados pelas portas TCP fechadas em resposta a um scan SYN ou connect, muitos hosts limitam a taxa de mensagens ICMP de porta inalcançável por padrão. O Linux e o Solaris são particularmente rigorosos quanto a isso. Por exemplo, o kernel 2.4.20 do Linux limita a quantidade de mensagens de destino inalcançável a até uma por segundo (no net/ipv4/icmp.c).

O Nmap detecta a limitação de taxa e diminui o ritmo de acordo para evitar inundar a rede com pacotes inúteis que a máquina-alvo irá descartar. Infelizmente, um limite como o do Linux de um pacote por segundo faz com que um scan de 65.536 portas leve mais de 18 horas. Idéias para acelerar o escaneamento UDP incluem escanear mais hosts em paralelo, fazer um scan rápido apenas das portas mais comuns primeiro, escanear por detrás de um firewall, e utilizar --host-timeout para pular os hosts lentos.

Esses três tipos de scan (existem outras opções, possíveis com a opção --scanflags descrita na próxima seção) exploram uma brecha sutil na RFC do TCP para diferenciarem entre portas abertas e fechadas. A página 65 diz que “se a porta [destino] estiver FECHADA .... um segmento entrante que não contenha um RST irá causar o envio de um RST como resposta.” Então a página seguinte discute os pacotes enviados à portas abertas sem os bits SYN, RST ou ACK marcados, afirmando que: “é pouco provável que você chegue aqui, mas se chegar, descarte o segmento, e volte.”

Quando se escaneia sistemas padronizados com o texto desta RFC, qualquer pacote que não contenha os bits SYN, RST, ou ACK irá resultar em um RST como resposta se a porta estiver fechada, e nenhuma resposta se a porta estiver aberta. Contanto que nenhum desses três bits estejam incluídos, qualquer combinação dos outros três (FIN, PSH e URG) é válida. O Nmap explora isso com três tipos de scan:

Esses três tipos de scan são exatamente os mesmos em termos de comportamento, exceto pelas flags TCP marcadas no pacotes de sondagem. Se um pacote RST for recebido, a porta é considerada fechada, e nenhuma resposta significa que está aberta|filtrada. A porta é marcada como filtrada se um erro ICMP do tipo inalcançável (tipo 3, código 1, 2, 3, 9, 10, ou 13) for recebido.

A vantagem principal desses tipos de scan é que eles podem bisbilhotar através de alguns firewalls não-orientados à conexão e de roteadores que filtram pacotes. Outra vantagem é que esses tipos de scan são um pouco mais camuflados do que o scan SYN. Mas, não conte com isso -- a maioria dos produtos IDS modernos podem ser configurados para detectá-los. O maior problema é que nem todos os sistemas seguem a RFC 793 ao pé-da-letra. Diversos sistemas enviam respostas RST para as sondagens independentemente do fato da porta estar aberta ou não. Isso faz com que todas as portas sejam classificadas como fechadas. A maioria dos sistemas operacionais que fazem isso são Microsoft Windows, muitos dispositivos Cisco, BSDI, e o IBM OS/400. Esse scan realmente funciona contra a maioria dos sistemas baseados em Unix. Outro ponto negativo desses scans é que eles não conseguem diferenciar portas abertas de alguns tipos de portas filtradas, deixando você com a resposta abera|filtrada.

Esse scan é diferente dos outros discutidos até agora pelo fato de que ele nunca determina se uma porta está aberta (ou mesmo aberta|filtrada). Ele é utilizado para mapear conjuntos de regras do firewall, determinando se eles são orientados à conexão ou não e quais portas estão filtradas.

O pacote de sondagem do scan ACK tem apenas a flag ACK marcada (a menos que você use --scanflags). Quando se escaneia sistemas não-filtrados, as portas abertas e fechadas irão devolver um pacote RST. O Nmap então coloca nelas o rótulo não-filtradas (unfiltered), significando que elas estão alcançáveis pelo pacote ACK, mas se elas estão abertas ou fechadas é indeterminado. Portas que não respondem, ou que devolvem certas mensagens de erro ICMP (tipo 3, código 1, 2, 3, 9, 10, ou 13), são rotuladas como filtradas.

Scan da Janela é exatamente o mesmo que o scan ACK, exceto que ele explora um detalhe da implementação de certos sistemas de forma a diferenciar as portas abertas das fechadas, ao invés de sempre mostrar não-filtrada quando um RST é devolvido. Ele faz isso examinando o campo Janela TCP (TCP Window) do pacote RST devolvido. Em alguns sistemas, as portas abertas usam um valor positivo de tamanho de janela (mesmo para pacotes RST), enquanto que as portas fechadas tem um valor igual a zero. Então, ao invés de sempre mostrar uma porta como não-filtrada quando se recebe um RST de volta, o scan da Janela mostra a porta como aberta ou fechada se o valor da Janela TCP no reset for positivo ou zero, respectivamente.

Este scan se baseia em um detalhe de implementação de uma minoria de sistemas na Internet, portanto não se pode confiar sempre nele. Sistemas que não suportam isso irão normalmente devolver todas as portas como fechadas. É claro que é possível que a máquina realmente não tenha nenhuma porta aberta. Se a maioria das portas escaneadas estiver fechada mas uns poucos números de portas comuns (tais como 22, 25, 53) estão filtrados, o sistema muito provavelmente está vulnerável. De vez em quando, os sistemas irão mostrar exatamente o comportamento oposto. Se o seu scan mostrar 1000 portas abertas e 3 fechadas ou filtradas, então essas três podem muito bem ser as verdadeiramente abertas.

O scan Maimon recebeu o nome de seu descobridor, Uriel Maimon. Ele descreveu a técnica na Phrack Magazine, edição 49 (Novembro de 1996). O Nmap, que incluiu essa técnica, foi lançado duas edições mais tarde. A técnica é exatamente a mesma que os scans Null, FIN e Xmas, exceto que a sondagem é FIN/ACK. De acordo com a RFC 793 (TCP), um pacote RST deveria ser gerado em resposta a tal sondagem se a porta estiver aberta ou fechada. Entretanto, Uriel notou que muitos sistemas derivados do BSD simplesmente descartavam o pacote se a porta estivesse aberta.

Usuários verdadeiramente avançados do Nmap não precisam se limitar aos tipos de scans enlatados oferecidos. A opção --scanflags permite que você desenhe seu próprio scan permitindo a especificação de flags TCP arbitrárias. Deixe sua imaginação correr solta enquanto dribla sistemas de detecção de intrusão, cujos fabricantes apenas olharam rapidamente a página man do Nmap adicionando regras específicas!

O argumento do --scanflags pode ser um valor numérico da marca (flag) como o 9 (PSH e FIN), mas usar nomes simbólicos é mais fácil. Apenas esprema alguma combinação de URG, ACK, PSH, RST, SYN, e FIN. Por exemplo, --scanflags URGACKPSHRSTSYNFIN marca tudo, embora não seja muito útil para escaneamento. A ordem em que essas marcas são especificadas é irrelevante.

Além de especificar as marcas desejadas, você pode especificar um tipo de scan TCP (como o -sA ou -sF). Esse tipo-base diz ao Nmap como interpretar as respostas. Por exemplo, um scan SYN considera nenhuma-resposta como uma indicação de porta filtrada, enquanto que um scan FIN trata a mesma como aberta|filtrada. O Nmap irá se comportar da mesma forma que o tipo de scan-base escolhido, exceto que ele irá usar as marcas TCP que você especificar. Se você não escolher um tipo-base, o scan SYN é utilizado.

Este método avançado de scan permite um scan TCP realmente cego das portas do alvo (significando que nenhum pacote é enviado para o alvo do seu endereço IP real). Ao invés disso, um ataque canal-lateral (side-channel) explora a previsível geração de seqüencia de ID, conseqüencia da fragmentação do IP, no host zumbi, para juntar informações sobre as portas abertas no alvo. Sistemas IDS irão mostrar o scan como se viessem da máquina zumbi que você especificou (que deve estar ativa e obedecer a alguns critérios). Este tipo fascinante de scan é complexo demais para se descrever completamente aqui, neste guia de referência, então eu escrevi e postei um trabalho informal com detalhes completos em http://nmap.org/book/idlescan.html.

Além de ser extraordinariamente camuflado (devido à sua natureza cega), este tipo de scan permite mapear relações de confiança baseadas em IP entre máquinas. A listagem de portas mostra as portas abertas da perspectiva do host zumbi. Portanto você pode tentar escanear algo usando vários zumbis que você acha que podem ser confiáveis (via regras de roteador/filtro de pacotes).

Você pode adicionar o sinal "dois-pontos", seguido do número da porta, ao nome do host zumbi se quiser sondar uma porta em particular no zumbi, verificando as mudanças de IPID. Do contrário o Nmap irá utilizar a porta que ele normalmente usa por padrão para pings tcp (80).

Scans do Protocolo IP permitem que você determine quais protocolos IP (TCP, ICMP, IGMP, etc.) são suportados pelas máquina-alvo. Isso não é, tecnicamente, um scan de portas, pois ele varia os números do protocolo IP ao invés dos números de portas TCP e UDP. Ainda assim, ele utiliza a opção -p para selecionar os números de protocolos a escanear, mostra os resultados dentro do formato normal da tabela de portas e usa o mesmo mecanismo de escaneamento dos métodos de descoberta de portas. Portanto ele é parecido o suficiente com um scan de portas e por isso pertence à este lugar.

Além de ser útil de seu jeito, o scan de protocolo mostra o poder do software de código aberto. Embora a idéia fundamental seja bastante simples, eu não havia pensado em adicioná-la e nem havia recebido nenhuma solicitação para essa funcionalidade. Então, no verão de 2000, Gerhard Rieger concebeu a idéia, escreveu uma excelente alteração (patch) implementando-a, e a enviou para a lista de discussão nmap-hackers. Eu incorporei a alteração na árvore do Nmap e lancei uma nova versão no dia seguinte. Poucos produtos de software comercial tem usuários entusiasmados o suficiente para desenhar e contribuir com melhorias!

O scan de protocolo funciona de uma forma similar a um scan UDP. Ao invés de ficar repetindo alternando o campo de número de porta de um pacote UDP, ele envia cabeçalhos de pacote IP e faz a repetição alternando o campo de protocolo IP de 8 bits. Os cabeçalhos normalmente estão vazios, sem conter dados, e nem mesmo contendo o cabeçalho apropriado do suposto protocolo. As três exceções são o TCP, o UDP e o ICMP. Um cabeçalho de protocolo apropriado para estes é incluído, uma vez que alguns sistemas não os enviarão caso não tenham, e porque o Nmap tem as funções para criá-los Ao invés de observar as mensagens de erro ICMP de porta inalcançável, o scan de protocolo fica de olho nas mensagens ICMP de protocolo inalcançável. Se o Nmap recebe qualquer resposta de qualquer protocolo do host-alvo, o Nmap marca esse protocolo como aberto. Um erro ICMP de protocolo não-alcançável (tipo 3, código 2) faz com que o protocolo seja marcado como fechado. Outros erros ICMP do tipo inalcançável (tipo 3, código 1, 3, 9, 10, ou 13) fazem com que o protocolo seja marcado como filtrado (embora eles provem, ao mesmo tempo, que o ICMP está aberto). Se nenhuma resposta for recebida após as retransmissões, o protocolo é marcado como aberto|filtrado.

Uma característica interessante do protocolo FTP (RFC 959) é o suporte à conexões denominadas proxy ftp. Isso permite que um usuário conecte-se a um servidor FTP, e então solicite que arquivos sejam enviados a um terceiro servidor. Tal característica é sujeita a abusos em diversos níveis, por isso a maioria dos servidores parou de suportá-la. Um dos abusos permitidos é fazer com que o servidor FTP escaneie as portas de outros hosts. Simplesmente solicite que o servidor FTP envie um arquivo para cada porta interessante do host-alvo. A mensagem de erro irá descrever se a porta está aberta ou não. Esta é uma boa forma de passar por cima de firewalls porque os servidores FTP de empresas normalmente são posicionados onde tem mais acesso a outros hosts internos que os velhos servidores da Internet teriam. O Nmap suporta o scan de ftp bounce com a opção -b. Ela recebe um argumento no formato <nomedousuário>:<senha>@<servidor>:<porta>. <Servidor> é o nome ou endereço IP de um servidor FTP vulnerável. Assim como em uma URL normal, você pode omitir <nomedousuário>:<senha>, neste caso as credenciais de login anônimo (usuário: anonymous senha:-wwwuser@) serão usados. O número da porta (e os dois-pontos) podem ser omitidos, e então a porta FTP padrão (21) no <servidor> será utilizada.

Esta vulnerabilidade espalhou-se em 1997 quando o Nmap foi lançado, mas foi corrigida amplamente. Servidores vulneráveis ainda estão por aí, então pode valer a pena tentar se tudo o mais falhar. Se passar por cima de um firewall é o seu objetivo, escaneie a rede-alvo procurando por uma porta 21 aberta (ou mesmo por qualquer serviço FTP se você escanear todas as portas com a detecção de versão), então tente um scan bounce usando-as. O Nmap irá dizer se o host é vulnerável ou não. Se você estiver apenas tentando encobrir suas pegadas, você não precisa (e, na verdade, não deveria) limitar-se a hosts na rede-alvo. Antes de sair escaneando endereços aleatórios na Internet, procurando por servidores FTP, considere que os administradores de sistemas podem não apreciar o seu abuso nos servidores deles.