Nmap é o mais popular port scanner do mercado, foi usado no primeiro filme do Matrix, quando a Trinit invadiu um sistema de segurança para desligar a luz de um quarteirão.
O nmap pode ser instalado tanto em máquinas Windows, Linux e OS X. Para usuários Windows o nmap trabalha com o suporte do WinPCAP. As versões para Windows funcionam muito bem, porém não são tão robustas quanto às versões para o Linux. Em alguns testes que realizei foi notória a diferença principalmente no que diz respeito ao desempenho.
O Windows XP Service Pack 2 apresenta algumas limitações para o uso de raw soquetes. Esta medida de segurança da Microsoft foi destinada a barrar a propagação de worms, vírus e ferramentas para "hacking". Raw sockets é um componente essencial para scanners e outras ferramentas de segurança, que permite o envio e recebimento direto de pacotes na rede pelos aplicativos, contornando todo o encapsulamento do software no sistema operacional.
Os desenvolvedores do nmap têm trabalhado em torno das restrições do SP2 para que os usuários do Windows não sejam prejudicados pelo SP2. Atualmente você pode contornar este problema desabilitando o Firewall do Windows com o comando “net stop sharedaccess”.
O nmap utiliza várias técnicas para fazer o seu trabalho, faz busca por hosts ativos na rede, portas TCP e UDP e utilizar técnicas de camuflagem para dificultar seu rastreamento por IDS/IPS. Antes de começarmos a falar sobre o Nmap, temos que entender como uma conexão TCP se estabelece, conhecer suas flags e discutir sobre algumas técnicas de varredura de portas.
Para que uma conexão TCP seja estabelecida, o cliente manda primeiramente um pacote TCP com uma flag SYN, que indica inicio de conexão. Se existe algum serviço ativo naquela porta o servidor retorna um pacote com as flags SYN e ACK, indicando que recebeu o SYN do cliente, em seguida o cliente mandara um pacote com a flag ACK, indicando que recebeu o último pacote enviado pelo servidor. Todo esse processo é conhecido como TCP three-way handshake.
Veja abaixo algumas flags e suas funções:
SYN: usado para indicar o começo de uma conexão TCP
ACK: usado para notificar que recebeu um pacote anteriormente enviado
FIN: usado para fechar uma conexão TCP
RST: usado para fechar uma conexão TCP de forma repentina
URG: usada para identificar informação que (logicamente) é urgente
PUSH: notifica o receptor o fim da conexão TCP e empurra todos os dados do buffer para o aplicativo do receptor
Tipos de Varreduras
1) Conexão TCP
Este tipo de scan se conecta na porta do serviço ativo e completa os 3 passos do three-way handshake (SYN, SYN/ACK, e ACK). Este tipo de scan é facilmente detectado por IDS e IPS.
2) SYN scan
É chamada também de half-open scanning, porque não estabelece uma conexão TCP completa (three-way handshake). Nesta técnica um pacote SYN é enviado se recebemos um SYN/ACK deduzimos que a porta esta ativa, ou seja, tem algum serviço escutando na porta. Se recebermos um RST/ACK isso indica que não tem nenhum serviço ativo na porta. Um RST/ACK é enviado para que a conexão não seja estabelecida, com isso parando abruptamente a tentativa de conexão. Este método também pode ser usado para realizar um DoS, abrindo várias conexões half-open.
3) FIN scan
Baseado na RFC 793 (http://www.ietf.org/rfc/rfc0793.txt) envia um pacote com a flag FIN habilitada, se o sistema retornar com a flag RST isso significa que a porta esta fechada.
4) Xmas Tree scan
Baseado na RFC 793 (http://www.ietf.org/rfc/rfc0793.txt) envia um pacote FIN, URG e PUSH para a porta do serviço, se for retornado um RST isso significa que a porta não esta ativa.
5) Null scan
Desabilita todas as flags, de acordo com a RFC 793, se retornar um RST significa que a porta não esta ativa.
6) ACK scan
Esta técnica pode ser usada para mapear as regras de firewall, podendo determinar se o firewall esta filtrando pacotes, deixando passar apenas as conexões estabilizadas (conexão com a flag ACK ativa) ou se o firewall esta operando em modo stateful, que guarda o estado de toda conexão para inspecionar a legitimidade do pacote.
7) RPC scan
É usado quando o alvo é um sistema UNIX, para detectar e identificar os programas e suas portas que estão registrados no serviço de Remote Procedure Call (RPC).
8) UDP scan
Envia pacotes UDP para a porta da máquina alvo, se for retornado pacotes de mensagem “ICMP port unreachable” podemos considerar que a porta não esta ativa. Como o protocolo UDP não é orientado a conexão, a utilização dessa técnica depende de muitos fatores relacionados à filtragem da rede de destino. Este tipo de scan é muito lento, se você for usar esta técnica para varrer máquinas da Internet prepare-se para resultados incertos.
Agora que já vimos alguns conceitos e entendemos o básico de varredura de porta vamos ao que interessa. O nmap já torna tudo mais fácil, interpretando todas as respostas do scan, isso quer dizer que você não precisa de todos os conceitos acima para realizar sua varredura, mas é bom saber o que você esta fazendo para decidir qual tipo de scan utilizar e tirar suas próprias conclusões.
Para ver todas as opções do nmap:
#nmap
Buscando Hosts ativos na rede
Se você quer apenas saber quais os hosts que estão ativos na sua rede, use a opção –sP (Ping Scanning) que manda requisições “ICMP echo request” para um determinado range de IP. Muitas máquinas com firewall bloqueiam requisições ICMP, neste caso nmap automaticamente ira tentar uma conexão na porta 80 da máquina, se não tiver nenhuma resposta ele assumira que a máquina não esta ativa. Você pode mudar a porta padrão com a opção –PT. Veja abaixo um exemplo:
A máquina 10.10.10.2 tem um firewall que bloqueia ICMP, veja que o nmap assumiu que a máquina não esta ativa. Automaticamente o nmap tentou conectar na porta 80 desta máquina, mas só a porta 22 esta ativa. No segundo exemplo usamos a opção –PT22 para o nmap tentar se conectar na porta 22. Veja que o resultado é bem diferente.
#nmap -sP 10.10.10.2
Starting Nmap 4.90RC1 ( http://nmap.org ) at 2010-10-20 14:42 BRT
Note: Host seems down. If it is really up, but blocking our ping probes, try -PN
Nmap done: 1 IP address (0 hosts up) scanned in 3.01 seconds
#nmap -sP -PT22 10.10.10.2
Starting Nmap 4.90RC1 ( http://nmap.org ) at 2010-10-20 14:42 BRT
Host 10.1.1.2 is up (0.00070s latency).
Nmap done: 1 IP address (1 host up) scanned in 0.01 seconds
Obs: com o nmap você pode especificar um intervalo de IP 192.168.1.1-192.168.1.254 ou em CIDR 192.168.1.0/24
Scaneando portas TCP
O método básico de scanear portas TCP é simplesmente tentar uma conexão na porta e verificar se há um retorno. Se você não especificar nenhuma porta o nmap usará um scan nas portas de serviços mais comuns.
Starting Nmap 4.90RC1 ( http://nmap.org ) at 2010-10-20 16:10 BRT
Interesting ports on wwwbay3vip.microsoft.com (64.4.31.252):
Not shown: 998 filtered ports
PORT STATE SERVICE
80/tcp open http
443/tcp open https
Nmap done: 1 IP address (1 host up) scanned in 11.93 seconds
Para especificar a porta use a opção –p:
#nmap -sT www.microsoft.com -p80
Starting Nmap 4.90RC1 ( http://nmap.org ) at 2010-10-20 16:15 BRT
Interesting ports on wwwco2vip.microsoft.com (65.55.12.249):
PORT STATE SERVICE
80/tcp open HTTP
Usando o SYN Scan
Com o nmap podemos usar a opção -sS (SYN scan) que manda apenas um pacote com a flag SYN habilitada, assim que ele recebe um SYN/ACK do servidor ele aborta brutalmente a tentativa de conexão com uma flag RST. Com essa técnica podemos burlar alguns sistemas de detecção de intrusão que por padrão registram conexões que completam o three-way handshake. Lembrando que alguns sistemas de IDS, FW e IPS podem fazer o registro de flag SYN, com isso registrando o seu IP. Veja o comando abaixo:
#nmap -sS www.4linux.com.br
Starting Nmap 4.90RC1 ( http://nmap.org ) at 2010-10-21 10:10 BRT
Interesting ports on 41-142-118-66.reverse.priorityonline.net (66.118.142.41):
Not shown: 994 filtered ports
PORT STATE SERVICE
53/tcp open domain
80/tcp open http
443/tcp open https
8000/tcp open http-alt
8001/tcp closed unknown
8080/tcp closed http-proxy
Em algumas situações o nmap vai mostrar que a porta esta “filtered”, isso significa que existe um firewall ou port filter interferindo o trabalho do nmap. Muitos firewalls estão operando em modo “stateless”, fazendo o bloqueio de tráfegos baseado em origem e destino do tráfego ou usando outros valores como referencia (MAC, protocolo etc). Neste caso para testar o firewall basta fazer um ACK scan (-as). Veja que a saída do comando nmap com a opção –as ele mostra as portas que não estão sendo filtradas:
#nmap -sA www.4linux.com.br
Starting Nmap 4.90RC1 ( http://nmap.org ) at 2010-10-21 10:23 BRT
Interesting ports on 41-142-118-66.reverse.priorityonline.net (66.118.142.41):
Not shown: 994 filtered ports
PORT STATE SERVICE
53/tcp unfiltered domain
80/tcp unfiltered http
443/tcp unfiltered https
8000/tcp unfiltered http-alt
8001/tcp unfiltered unknown
8080/tcp unfiltered http-proxy
Usando o UDP Scan
A opção -sU faz com que o nmap mande pacotes vazios UDP e espera receber uma mensagem “ICMP port unreachable”, se nenhuma mensagem é recebida a porta é dita como aberta, se uma mensagem ICMP é recebida então o nmap considera que a porta está sendo bloqueada por um firewall. O nmap interpreta de forma automática todo o processo do envio e recebimento dos pacotes. Abaixo segue um exemplo que tem a porta 53 UDP aberta:
#nmap -sU 10.1.4.5
Starting Nmap 4.90RC1 ( http://nmap.org ) at 2010-10-27 09:39 BRT
Interesting ports on 10.1.4.5:
Not shown: 964 closed ports, 35 open|filtered ports
PORT STATE SERVICE
53/udp open domain
MAC Address: 00:21:5A:D8:50:38 (Hewlett Packard)
Por padrão o nmap faz um ping antes de começar a fazer o scan, isso ajuda na precisão dos resultados de uma varredura UDP. Normalmente o pacote ICMP é bloqueado no firewall, com isso dificultando na precisão da varredura. Vamos ver abaixo alguns resultados de varredura em hosts que estão bloqueando o ping e de que forma podemos utilizar o nmap para burlar esta barreira. A máquina de teste é um servidor DNS que esta escutando na porta padrão 53 (UDP).
Vamos “pingar” para ter certeza que o host esta bloqueando nosso ping:
#ping 10.1.1.2
PING 10.1.1.2 (10.1.1.2) 56(84) bytes of data.
^C
--- 10.1.1.2 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2017ms
Podemos ver pelo resultado que o nosso ping foi bloqueado, obtendo 100% packet loss e sem reposta dos pings.
Executando o nmap:
#nmap 10.1.1.2
Starting Nmap 4.90RC1 ( http://nmap.org ) at 2010-10-27 09:01 BRT
Note: Host seems down. If it is really up, but blocking our ping probes, try -PN
Nmap done: 1 IP address (0 hosts up) scanned in 3.21 seconds
Perceba que não obtivemos nenhum resultado, mesmo a máquina estando ligada e com a porta 53 UDP aberta. Como resposta obtivemos 0 hosts up, porém o nmap recomenda a utilização da opção –PN que admite que o host esteja ativo e pula o processo chamado de “host discovery”. Vamos rodar o nmap de novo com a opção –NP:
#nmap -PN 10.1.1.2
Starting Nmap 4.90RC1 ( http://nmap.org ) at 2010-10-27 14:08 BRT
All 1000 scanned ports on 10.1.1.2 are filtered
Nmap done: 1 IP address (1 host up) scanned in 201.41 seconds
Perceba que o nmap varreu 1000 portas por padrão e desta vez o resultado mostra 1 host up, mas ainda não conseguimos ver a porta 53 UDP aberta. Vamos usar a opção –P0 (zero) que realiza algumas técnicas de scan e não executa o ping:
#nmap -P0 10.1.1.2
Starting Nmap 4.90RC1 ( http://nmap.org ) at 2010-10-27 15:54 BRT
All 1000 scanned ports on 10.1.1.2 are filtered
Nmap done: 1 IP address (1 host up) scanned in 201.39 seconds
Temos o mesmo resultado do anterior. Alguém “scaneando” essa máquina iria pensar que a máquina não tem nenhum serviço habilitado. Só para tirar algumas conclusões vamos ver o resultado especificando a porta 53 utilizando as opções –PN, -P0 e –sU:
#nmap -PN 10.1.1.2 -p53
Starting Nmap 4.90RC1 ( http://nmap.org ) at 2010-10-27 16:15 BRT
Interesting ports on 10.1.1.2:
PORT STATE SERVICE
53/tcp filtered domain
Nmap done: 1 IP address (1 host up) scanned in 2.22 seconds
# nmap -P0 10.1.1.2 -p53
Starting Nmap 4.90RC1 ( http://nmap.org ) at 2010-10-27 16:16 BRT
Interesting ports on 10.1.1.2:
PORT STATE SERVICE
53/tcp filtered domain
Nmap done: 1 IP address (1 host up) scanned in 2.19 seconds
#nmap -sU -P0 10.1.1.2 -p53
Starting Nmap 4.90RC1 ( http://nmap.org ) at 2010-10-27 16:19 BRT
Interesting ports on 10.1.1.2:
PORT STATE SERVICE
53/udp open|filtered domain
Nmap done: 1 IP address (1 host up) scanned in 2.20 seconds
Na primeira e segunda tentativa (-PN e –P0) perceba que o nmap procurou por portas TCP, ele só irá varrer por portas UDP quando você especificar com a opção –sU. Usamos a opção –P0 (para que não pingue e considere a máquina como ativa) e –sU (portas UDP), e como resultado temos a porta 53/udp open/filtered. Isso significa que a porta 53 UDP esta aberta porém sendo filtrada. Conseguimos algum resulta, mas ajudou muito termos especificado a porta, e se queremos varrer uma máquina em que não sabemos nada sobre ela? Neste caso vamos varrer todas as portas UDP. Como mencionado anteriormente “scanear” por portas UDP é um trabalho que demora muito, tente executar o comando abaixo e veja como vai demorar sua busca:
#nmap -P0 -sU 10.1.1.2 -p1-65535
O commando acima vai fazer com que o nmap varra todas as portas (1 até 65535) UDP da máquina 10.1.1.2.
O que podemos fazer para que nossa busca seja mais rápida? A maneira mais fácil e rápida é definir algumas portas que são padrão para serviços UDP e realizar nosso scan nessas portas.
Scaneando Protocolos
Se você mandar um pacote para uma porta UDP sem nenhum serviço nesta porta o host responde com uma mensagem “ICMP port unreachable”. A mesma coisa acontece com o protocolo IP. Cada camada de transporte do protocolo IP possui um número associado, por exemplo, ICMP (1), TCP (6) e UDP (17). O nmap suporta o que chamamos de scan de protocolo (-sO), ele manda um pacote IP sem cabeçalho de camada de transporte e com o número de protocolo 130 (protocolo IPSEC). Se o host retornar uma mensagem ICMP "protocol unreachable" isso quer dizer que o protocolo IPSEC não foi implementado naquela porta.
#nmap -sO 216.92.171.136
Starting Nmap 4.90RC1 ( http://nmap.org ) at 2010-10-28 12:02 BRT
Interesting protocols on chamada.com.br (216.92.171.136):
Not shown: 253 open|filtered protocols
PROTOCOL STATE SERVICE
1 open icmp
6 open tcp
17 open udp
Nmap done: 1 IP address (1 host up) scanned in 6.84 seconds
Veja que ele retornou os protocolos que estão escutando na porta e o número associado ao protocolo.
Descobrindo o Sistema Operacional
Com a opção –O o nmap tenta descobrir que sistema operacional esta rodando na maquina alvo. Analisando a pilha TCP/IP o nmap faz uma comparação com uma base de dados com registros de rastros de sistemas operacionais, esses rastros são conhecidos como traits.
Veja abaixo um exemplo:
#nmap -O www.google.com
Starting Nmap 4.90RC1 ( http://nmap.org ) at 2010-10-28 13:12 BRT
Interesting ports on bs-in-f104.1e100.net (64.233.163.104):
Not shown: 997 filtered ports
PORT STATE SERVICE
80/tcp open http
113/tcp closed auth
443/tcp open https
Device type: general purpose
Running (JUST GUESSING) : OpenBSD 4.X (85%)
Aggressive OS guesses: OpenBSD 4.3 (85%)
No exact OS matches for host (test conditions non-ideal).
OS detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 11.22 seconds
O resultado mostra que existe 85% de chances de ser um OpenBSD 4.x e a mesma porcentagem de ser um OpenBSD 4.3, podemos concluir que é um OpenBSD 4.3.
Identificando o serviço certo
Quando você executa o nmap sem opção ele faz a varredura com base em portas padrões já configuradas no nmap e tenta identificar o serviço que esta escutando nas portas abertas com uma relação já configuradas nele. O nmap não certifica se o serviço naquela porta é de fato o que estar associado na sua relação, por exemplo, se ele detecta que a porta 80 esta aberta, vai notificar que este serviço é WEB, porém não vai certificar que realmente seja este serviço rodando naquela porta. Isto acontece também se você utilizar a opção –sR. Para que possamos ter certeza que tipo de serviço esteja rodando em uma porta usamos a opção –sV. No exemplo abaixo temos o serviço web (Apache) rodando na porta 22, que é a porta padrão do SSHD, vamos analisar o que teremos como resposta do nmap rodando a varredura com a opção –sV e sem essa opção:
#nmap 192.168.2.2
Starting Nmap 4.90RC1 ( http://nmap.org ) at 2010-11-03 10:38 BRT
Interesting ports on 192.168.2.2:
Not shown: 997 closed ports
PORT STATE SERVICE
22/tcp open ssh
139/tcp open netbios-ssn
445/tcp open microsoft-ds
Nmap done: 1 IP address (1 host up) scanned in 0.25 seconds
Veja que a porta 22 foi identificado pelo nmap como sendo o service SSH, mas na verdade sabemos que o service é WEB.
#nmap -sR 192.168.2.2
Starting Nmap 4.90RC1 ( http://nmap.org ) at 2010-11-03 10:43 BRT
Interesting ports on 192.168.2.2:
Not shown: 997 closed ports
PORT STATE SERVICE VERSION
22/tcp open ssh
139/tcp open netbios-ssn
445/tcp open microsoft-ds
Nmap done: 1 IP address (1 host up) scanned in 1.17 seconds
Mesmo com a opção –sR a resposta é a mesma. Agora vamos ver o que acontece com a opção –sV:
#nmap -sV 192.168.2.2
Starting Nmap 4.90RC1 ( http://nmap.org ) at 2010-11-03 10:45 BRT
Interesting ports on 192.168.2.2:
Not shown: 997 closed ports
PORT STATE SERVICE VERSION
22/tcp open http Apache httpd 2.2.11 ((Ubuntu) PHP/5.2.6-3ubuntu4.4 with Suhosin-Patch mod_perl/2.0.4 Perl/v5.10.0)
139/tcp open netbios-ssn Samba smbd 3.X (workgroup: REDE)
445/tcp open netbios-ssn Samba smbd 3.X (workgroup: REDE)
Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 11.46 seconds
Temos um resultado bem diferente agora, o nmap nos retornou a versão do serviço e a versão do módulo PHP.
Escondendo o seu Scan
O nmap utiliza algumas técnicas para dificultar a detecção do seu scan por sistemas que utilizam log, firewall e IDS/IPS.
A varredura utilizando máquinas Zumbis utiliza uma característica do protocolo TCP que é o campo ID do IP. O nmap faz um spoof nos pacotes que estão sendo enviados pela rede onde a máquina de destino pensa que os pacotes estão sendo originados da máquina zumbi.
#nmap –sI 10.1.4.101 –PN 10.1.4.249
Starting Nmap 5.21 ( http://nmap.org ) at 2010-11-04 09:42 Hora oficial do Brasil
Idle scan using zombie 10.1.4.101 (10.1.4.101:80); Class: Incremental
Nmap scan report for 10.1.4.249
Host is up (0.041s latency).
Not shown: 997 closed|filtered ports
PORT STATE SERVICE
22/tcp open ssh
139/tcp open netbios-ssn
445/tcp open microsoft-ds
MAC Address: 00:40:A7:13:02:65 (Itautec Philco S.A.)
Nmap done: 1 IP address (1 host up) scanned in 23.69 seconds
A opção –sI habilita o que chamamos de Zumbi Scan. O IP 10.1.4.101 é a máquina que aparecerá nos logs do nosso alvo (10.1.4.249), lembrando que o IP da máquina que disparou o scan é o 10.1.4.136. Para utilizar este tipo de scan a máquina zumbi tem que ter algum serviço ativo e não pode ter o firewall ou algum tipo de filtro habilitado. Por padrão o nmap se conecta na porta 80, se esta porta estiver fechada o scan não vai funcionar. Para mudar de porta use a opção –PA22 (22 é a porta do sshd). Usei o Zenmap (frontend para o nmap) para realizar este teste. Quando você utiliza somente a opção –sI o Zenmap recomenda a utilização do –PN para prevenir que a máquina de onde esta sendo feito o scan não faça antes um ping permitindo que o real IP seja registrado nos logs da máquina alvo. Fiz os testes sem utilizar esta opção (-PN) e meu IP não foi detectado pelo alvo.
No momento em que disparei o scan usando o Zenmap executei o comando tcpdump na máquina alvo para detectar se o scan realmente funcionou.
Com o comando abaixo todo tráfego vindo da máquina com o IP 10.1.4.136 (de onde o scan foi disparado) iria ser detectado. Como podemos ver nada foi detectado:
#tcpdump -n host 10.1.4.136
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
Estamos agora filtrando o tráfego vindo do IP 10.1.4.101 (máquina zumbi) e o tcpdump vai parar de capturar quando tiver 10 pacotes. Perceba que agora conseguimos detectar algum tráfego e podemos ver que esse é o resultado esperado, onde nosso IP real não foi detectado e sim o IP da máquina zumbi:
#tcpdump -n -c 10 host 10.1.4.101
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
15:13:51.127536 IP 10.1.4.101.80 > 10.1.4.249.39570: R 1866314218:1866314218(0) win 0
15:13:51.177559 IP 10.1.4.101.80 > 10.1.4.249.39570: R 1866314218:1866314218(0) win 0
15:13:51.228289 IP 10.1.4.101.80 > 10.1.4.249.39570: R 1866314218:1866314218(0) win 0
15:13:51.286620 IP 10.1.4.101.80 > 10.1.4.249.39570: R 1866314218:1866314218(0) win 0
15:13:51.608449 IP 10.1.4.101.80 > 10.1.4.249.1723: S 4276844990:4276844990(0) win 4096
15:13:51.608564 IP 10.1.4.249.1723 > 10.1.4.101.80: R 0:0(0) ack 4276844991 win 0
15:13:51.608585 IP 10.1.4.101.80 > 10.1.4.249.25: S 4276844990:4276844990(0) win 1024
15:13:51.608605 IP 10.1.4.249.25 > 10.1.4.101.80: R 0:0(0) ack 4276844991 win 0
15:13:51.608744 IP 10.1.4.101.80 > 10.1.4.249.3306: S 4276844990:4276844990(0) win 4096
15:13:51.608767 IP 10.1.4.249.3306 > 10.1.4.101.80: R 0:0(0) ack 4276844991 win 0
10 packets captured
10 packets received by filter
0 packets dropped by kernel
Você pode usar a opção –P0 para que nenhum ping seja disparado e –n para que nenhuma resolução DNS seja feita, com isso evitando que o IP da máquina de onde esta sendo disparado o scan seja registrada nos logs no alvo. No caso da resolução DNS o IP do servidor DNS do atacante aparecerá nos logs do servidor DNS da máquina alvo.
Servidores FTP escutam na porta 21 esperando por conexão, esta porta faz o controle da conexão e é usada para transmitir comandos FTP. Na transmissão de dados o servidor FTP abre uma conexão separada só para dados. O cliente FTP através do comando PORT envia para o servidor o seu IP e a porta de destino para a transmissão dos dados. O ataque chamado de FTP Bounce usa uma vulnerabilidade do protocolo FTP onde o atacante usa o comando PORT para fazer requisição de acesso em outras máquinas, fazendo com que o servidor FTP seja o “middle man” para a requisição. Essa técnica é muito usada para port scan.
Este método de operação do protocolo FTP é chamado de “active transfer”. O uso de NAT, Proxy e firewall nas redes tornaram o uso do FTP Ativo menos comum. A maioria dos servidores FTP estão operando em modo Passivo porque o cliente inicia a conexão de controle da dados, sendo mais fácil de configurar em ambientes com firewall e NAT.
Os servidores FTP atuais já consertaram este bug restringindo o comando PORT, mas ainda existem muitos servidores desatualizados pela Internet. O que precisamos agora é descobrir um servidor FTP desatualizado, que aceite login anônimo e não esteja em modo Passivo, simples. Mesmo que você encontre um servidor FTP que atenda esses requisitos, você corre o risco dele não permitir que você “scaneie” portas privilegiadas (portas abaixo de 1024) porque clientes FTP não deveriam escutar (LISTEN) em portas privilegiadas para transferência de dados.
Primeiro vamos encontrar os servidores que aceitem login anônimo e seja vulnerável (FTP Bounce), para isso vamos usar o Nmap Scripting Engine (NSE) que são scripts feitos na linguagem LUA para automatizar algumas tarefas tomando como base o retorno do resultado do nmap, por exemplo, você pode criar um script para que assim que o nmap detectar a porta 80 aberta de um servidor ele teste também se o serviço esta vulnerável. Vamos testar os scripts ftpbounce.nse e ftp-bounce.nse. Primeiro vamos atualizar os scripts com o comando abaixo:
#nmap --script-updatedb
Starting Nmap 4.90RC1 ( http://nmap.org ) at 2010-11-05 11:34 BRT
NSE: Updating rule database.
NSE script database updated successfully.
Nmap done: 0 IP addresses (0 hosts up) scanned in 0.51 seconds
O commando abaixo faz com que o nmap busque por toda a rede 192.168.2.0/24 pelas portas 20 e 21 TCP, mostrando apenas as portas abertas (--open), nas portas abertas vai ser rodado o script FTP-bounce (--script=name) e o resultado será salvo no arquivo saidanmap (-o).
#nmap --script=ftp-bounce.nse 192.168.2.0/24 -p20-21 --open -o saidanmap
Abrindo o nosso arquivo “saidanmap” temos alguns resultados com os possíveis IP´s vulneráveis, abaixo segue um exemplo de um servidor vulnerável:
Interesting ports on 192.168.2.30:
Not shown: 1 closed port
PORT STATE SERVICE
21/tcp open ftp
|_ ftp-bounce: bounce working!
Vamos pegar alguns IP´s da nossa lista e testar. Abaixo segue o cenário de teste:
Atacante ---> FTP Server ---> Alvo
A idéia é fazer com que no log do servidor alvo apareça o IP do servidor FTP e não o do atacante. Quando você achar o servidor vulnerável execute o comando abaixo:
#nmap -b anonymous@ftp.server.com.br IP_ALVO –p80
No comando acima ele vai “scanear” a porta 80 do Alvo.
A opção –D (Decoy) é usada pelo nmap para que vários IP´s cheguem no ALVO no momento do seu scan, a idéia é dificultar a detecção do IP que realmente estava realizando o scan.
#nmap -D 10.1.4.101 10.1.4.249
Com o comando acima não só o IP da máquina que disparou o scan aparecerá no log do alvo 10.1.4.249 como também o IP 10.1.4.101. Desta forma o alvo suspeitaria de dois Ip´s. Para dificultar mais o trabalho do Administrador acrescente mais IP´s na linha de comando, ficando assim:
#nmap -D IP_1 IP_2 IP_3 IP_4 IP_ALVO
Com isso os 5 IP´s, contando com o da máquina que disparou o scan, vão aparecer no log do alvo.
CONCLUSÃO
O nmap é uma ferramenta indispensável para qualquer administrador de rede. Neste post procurei mostrar algumas opções do nmap, mas existem outras opções bem interessantes também. Apesar de o nmap agir de forma transparente interpretando os resultados é importante entender como o nmap funciona para escolher a opção adequada conforme o cenário de teste.
fonte: Anti-Hacker ToolKit e Hacking Exposed
By Osvaldo
By Osvaldo
