Quando chega a hora de verificar se uma rede é ou não segura, a melhor opção é talvez fazer um scan à rede e verificar se existem falhas ou outras situações que possam comprometer a integridade de uma rede. Basicamente para cada ataque a uma determinada rede é necessário levar em conta dois parâmetros e são eles o endereço de IP e o número da porta do host que vamos “atacar” ou testar. Por exemplo, se tivermos um exploit para o IIS será necessário o endereço de IP do host que esteja a correr o IIS e talvez necessitemos do número da porta no caso de o IIS não estar a usar a porta standard.

Ora temos aqui um obstáculo. É necessário termos estes dois parâmetros para que possamos efectuar qualquer tipo de tentativa quer para atacar quer para testar as defesas de uma rede, mas como é que podemos então saber qual o endereço IP de um host assim como as portas abertas e os serviços que estão a correr nele?

Essa é a função de um network scanner. Na verdade este tipo de ferramentas são muito úteis não só para verificar estes parâmetros, como também para sabermos a topologia de uma rede ou até mesmo verificar as regras de um firewall.

Como é que os scanners funcionam?

Apesar de existir uma grande variedade de scanners, praticamente todos eles seguem os mesmos princípios. Que princípios? Como é que aplicações, como por exemplo o FTP, funcionam? Estas aplicações usam frames para enviar informação. No entanto uma aplicação não começa logo a enviar dados. É necessário primeiro proceder a uma série de averiguações que vão definir por exemplo qual a sequência das frames, qual a quantidade de informação enviada antes de receberem um acknowledgement e muitos outros parâmetros.

Os scanners usam estas “conversas” para fazer o scan, eles enviam frames para o host e depois esperam a resposta. Tão simples como isto. Se for dada uma resposta é bem provável que determinada aplicação esteja a correr. Mas, existe sempre um mas, não se deixem enganar porque existem programas como o PortSentry cujo objectivo é confundir os scans e que alguns administradores instalam para confundir e boicotar as tentativas de scan.

Mas como é que um Network Scanner determina qual a aplicação que está a correr?

Para respondermos a esta pergunta temos que analisar como o protocolo TCP/IP funciona. Grande parte das aplicações usa dois protocolos da Camada 4 do modelo OSI: o protocolo TCP (Transmission Control Protocol) e o UDP (User Datagram Protocol). Ambos os protocolos têm que comunicar com as camadas acima e com diversas aplicações e sessões, assim para não se confundir os dados usam-se portas que permitem múltiplas conexões existir apesar de ser usado apenas um IP.

Tanto o UDP como o TCP podem usar ambos 65536 portas. Muitos protocolos e programas têm portas definidas. Os network scanners (NS) determinam quais as aplicações a correr testando as portas mais usadas e verificar quais aceitam conexões. Além de verificar quais as portas abertas, certos NSs ainda conseguem ir mais longe: conseguem verificar a versão da aplicação que está a correr. Exemplo de um NS que consegue fazer isso é o famoso Nmap.

Vamos então ver como funciona o scanning em TCP e depois em UDP, porque existem certos parâmetros que devem ser conhecidos. Não nos interessa saber usar um programa se não soubermos como ele funciona.

Scanning usando o TCP

O objectivo deste scan é como é óbvio determinar quais são as portas TCP que tem aplicações a correr. Usando o protocolo TCP é possível descobrir quais as portas abertas sem ser necessário para isso completar a conexão. Como?

Bem o protocolo TCP é um protocolo que presta um serviço fiável. Fiável? Sim, no sentido em que aquilo que o TCP recebe é aquilo que envia, contrariamente ao que acontece com o UDP, usando para isso o flow control e uma comunicação connection oriented.

Fonte: www.cgisecurity.com

Temos que compreender que o protocolo TCP, contrariamente ao UDP, é um protocolo que prima pela fidelidade e integridade da conexão. E isso é visto na maneira como o TCP inicia uma conexão, usando o three-way handshake. Como podemos ver pela figura, o host primeiro envia um “acordo de conexão” com um pacote SYN (de sincronização). Depois o server enviam um pacote de ACK (acknowledgment) e estabelece as regras. A sincronização dos pacotes também é definida nesta altura o que requer o tal pacote com o SYN. Por fim o ultimo segmento é também um ACK do host que notifica o server de que as regras de conexão foram aceites e a conexão está estabelecida e que os dados vão começar a ser transferidos.

Assim para verificar se uma aplicação está á escuta numa determinada porta, o NS pode enviar um pacote com TCP SYN e esperar pelo resultado. Se a resposta for um SYN/ACK podemos dizer que a porta está aberta, se for RST podemos dizer que a porta está fechada, se não houver uma resposta podemos dizer que ou uma firewall está a bloquear as conexões a essa porta, ou simplesmente não existe um serviço a escutar naquela porta do host com aquele IP address.

Existem diversos tipos de scans com TCP, isto porque existem 6 tipos diferentes de flags nas frames enviadas:

• URG (URGent pointer);
• ACK (ACKnowledgement);
• PSH (PuSH);
• RST (ReSeT).
• SYN (SYNchronisation);
• FIN (FINished).

A flag URG é usada para identificar informação que (logicamente) é urgente. A vantagem do uso desta flag é que esses segmentos passam á frente de todos os outros e processados imediatamente.

A flag ACK é usada para avisar que a recepção de um pacote foi bem sucedida. Mas já estão a ver como seria se em cada pacote enviado fosse recebido um ACK, por isso é possível definir a quantidade de pacotes a receber antes de se enviar um ACK.

A flag PSH que, similarmente à URG, garante que a informação seja trata com prioridade mas acompanha o processo dos dados do princípio ao fim do envio. Na verdade, é um pouco mais complexo do que isto, mas apenas estamos a fazer um pequeno resumo.

A flag RST é usada quando um segmento chega mas por engano ou quando o serviço que é requisitado não está disponível. Esta é uma das flags usadas para verificar se determinada aplicação está a correr.

A flag SYN talvez a mais conhecida de todas e que é usada no 3-way Handshake, como vimos acima.

A flag FIN é usada para terminar as conexões e caminhos virtuais criadas pela SYN e é acompanhada pela flag ACK para confirmar em ambos os lados que a conexão vai ser terminada.

Como podemos ver neste pequeno resumo, estas flags são usadas pelo TCP/IP para indicar o estado de uma comunicação feita. Por omissão, um scan TCP apenas usa a flag SYN porque é esta a que produz resultados mais fiáveis e também é a que menos dá nas vistas, porque é encarada como tráfego normal, igual a qualquer outro.

No entanto, podem ser usadas diversas combinações de flags que podem retornar resultados interessantes. Com o nmap, para usarmos uma combinação de flags basta fazer, por exemplo, isto:

C:>nmap –scanflags SYNFIN nmap.org

Neste caso dizemos ao Nmap que faça um scan ao nmap.org mas usando para isso apenas as flags SYN e FIN.

Tipos de Scan TCP com Nmap

O Nmap permite a combinação arbitrária de flags mas algumas certamente apresentaram resultados mais úteis que outros. Por isso o Nmap provê atalhos para os mais conhecidos. De seguida mostro alguns:

SYN scan –sS

É o scan feito por defeito pelo nmap.

Connect scan –sT

É similar ao feito com o –sS, mas neste caso a conexão é feita totalmente e depois desligada. É inferior ao –sS porque envolve mais pacotes e tem maior probabilidade de dar nas vistas.

Windows scan –sW

Este scan trabalha da seguinte forma, primeiro faz um scan com o ACK e depois verifica o tamanho da janela TCP enviada pelo host destinatário. Alguns sistemas operativos usam diversos tamanhos da janela dependendo se a porta esta aberta ou não.

ACK scan –sA

Este scan é particularmente útil para descobrir as regras de firewall de certos firewalls. Um host que receba este pacote deverá retornar um RST independentemente se a porta está aberta ou não. Se o RST é enviado o Nmap assume então que a porta não está a ser filtrada por um firewall ao passo que se não houver qualquer resposta da parte do alvo o Nmap deduz então que existe algures um firewall. Mas, claro que isto depende muito do tipo de firewall que esteja a proteger. Apesar disso sempre dá para ficarmos com uma ideia do que se passa.

UDP Scanning

Agora é que as coisas ficam um pouco mais complicadas. Fazer um scan usando o UDP é um pouco mais complicado devido à forma como o protocolo UDP funciona. Contrariamente ao TCP, que tem o cuidado de verificar o estado da ligação e definir até mesmo regras para a transferência de dados, o UDP não usa o handshakes e o primeiro pacote de dados enviado é logo enviado para a aplicação, não existe qualquer tipo de preocupação por parte do UDP em verificar se os dados foram ou não entregues.

Mas mesmo assim este protocolo pode ser usado para fazer um scan, como vamos ver de seguida.

Tipos de scan UDP com o Nmap

Existem dois tipos de scan que podemos fazer usando o UDP: o scan com pacotes vazios e o scan com informação do protocolo.

O primeiro scan, o dos pacotes vazios, envolve enviar pacotes UDP sem nenhum dado para uma porta e esperar o resultado. É um scan muito incerto, mas existe um scanner de nome Unicornscan que produz resultados mais fidedignos em virtude da maneira como trabalha. Para fazê-lo com o Nmap basta:

C:>nmap –sU nmap.org

O scan usando dados de protocolo são mais sofisticados que envolve enviar dados de aplicações válidas em pacotes UDP para portas para ver se alguma aplicação responde. Usando esta técnica apenas são consideradas portas abertas se responderem a esses dados enviados com um nonerror. Mas este tipo não é muito aconselhável porque demora muito tempo, o que aumenta a possibilidade de ser detectado.

Mas mesmo assim se querem fazer este tipo de scan podem fazê-lo com o nmap bastando para isso:

C:>nmap –sU –sV nmap.org

Mas atenção que este scan demora muito tempo, por isso, se possível, limitem as portas a serem testadas.

Mapeamento de Rede

Agora que sabemos como cada protocolo se comporta ao ser feito um scan, podemos passar para outra parte que é o mapeamento da rede, descobrindo quais são os endereços de IP que tem um PC associado a ele.

Quando nos deparamos com um rede desconhecida, uma das primeiras coisas a ser feita é determinar qual o endereço IP que tem um PC associado e isto é importante porque grande parte das redes usa o chamado NAT (Native Address Translation) em que apenas uma pequena percentagem dos IPs são usados. Mas ao fazermos um scan host rapidamente podemos identificar quais os IPs com PCs associados a eles.

Usando o Nmap podemos usar uma opção para fazer este scan host:

C:>nmap –n –sP 12.125.10.1-15

A primeira opção que usamos é a –n que diz ao Nmap para não fazer lookups no endereço IP em que está a ser feito o scan isto porque um reverse DNS lookups demora mais tempo e por isso dá mais nas vistas. Na próxima opção a -sP o Nmap envia um ping assim como também um pacote SYN para a porta 80 para determinar se naquele endereço IP algum PC está a escutar. Acontece também que se estivermos na mesma subrede que o IP a que estamos a fazer o scan o ARP é usado para sabermos quais são os endereços IP em uso.

Como vimos, a opção –sP faz com que o Nmap envie um ping para o endereço IP para verificar se este tem ou não um PC associado, mas é bem provável que exista uma firewall pelo caminho e o que acontece é que estes pings são então bloqueados. Até mesmo a firewall que vem com o Windows XP faz isso.

É claro que existe maneira de dar a volta a esta situação, usando a opção –P0 que diz ao Nmap para se conectar a cada porta apesar de parecer não existir um PC. Como se pode imaginar, é um processo bastante moroso. Mas sendo o Nmap uma ferramenta bastante completa, podemos usar outras opções para chegar quase ao mesmo resultado. Ao usarmos as opções –Psportlis (para os pacotes SYN) e -PAportlist (para os pacotes ACK) bastará definir as portas que queremos que sejam usadas. Estas são algumas das opções que podemos usar, mas existem outras tais como a –PE, -PP e –PM em que se utiliza o ICMP para fazer scans.

É claro que é necessário fazer scans às portas certas e não perder tempo com outras. Quais é que são as mais comuns? E quais é que são as mais propicias a dar bons resultados?

Bem, depende do sistema operativo que está a ser usado pelo endereço de IP que queremos fazer um scan. Esses sistemas operativos requerem que determinadas portas estejam abertas de maneira a que o sistema possa, por exemplo, partilhar recursos. As portas mais usadas em Windows são TCP – 135, 139, 445, 1025-1030, 3389 e em UDP – 137, 138, 445 e 1025-1030. Em sistemas Unix são TCP – 21, 22, 23, 25, 80, 111 e em UDP – 53, 67-69, 111, 161 e 514.

Estas não são as únicas portas que podemos usar, existem muitas outras usadas tanto em sistemas Windows como em sistemas Unix. Por omissão, o Nmap verifica perto de 1700 portas TCP. Mas claro que o Nmap não é limitado só as estas 1700 portas. É possível usar as portas que bem entendermos bastando para isso usar a seguinte opção –p:

C:>nmap –p 135-139,80,3389 12.125.10.1

É possível também usar uma outra opção do Nmap, a –F, que indica ao Nmap para fazer um scan rápido as todas as portas especificadas no ficheiro nmap-services que contém perto de 1200 portas.

Outra possibilidade bastante interessante é podermos combinar no mesmo scan, um scan a portas TCP e outro a portas UDP. No caso de queremos fazer um scan ás portas TCP 1025 a 1030 e nas portas UDP da 67 a 69 e da 111 a 120:

C:>nmap –pT:1025-1030,U:67-69,111-120 12.125.10.1

Reparem que usamos o T: para identificar as portas TCP e o U: para as portas UDP.

Para terminar, é bom salientar que com o Nmap podemos usar 3 maneiras para identificarmos os hosts pretendidos. Pode-se usar a opção de um único host, a opção em que se define uma escala de IP’s e por fim uma não tão conhecida, a CIDR (Classless Inter-Domain Routing) em que basicamente se indica o endereço de IP e a subrede pretendida da seguinte maneira: 10.0.1.2/24.

Conclusão

Chegámos ao fim deste artigo onde foi demonstrado que usando um scanner como o Nmap, pode-se obter muita informação de uma rede. Com paciência e experiência é possível definirmos a cartografia da rede, os sistemas a correr em cada host e até mesmo saber quais são as regras de firewall e se existem falhas. Também vimos como os protocolos TCP e UDP são usados ao ser feito um scan.