OpenWRT/LEDE: Capturando pacotes de dentro do roteador

Mais um artigo da série sobre o OpenWRT/LEDE.

Algumas vezes já me perguntaram o que deveria aprender para ser um bom administrador de redes.  A resposta é sempre a mesma: "Várias coisas, mas principalmente o Wireshark".

O Wireshark é uma excelente ferramenta de diagnóstico e de estudo. Eu normalmente recomendo que qualquer bom administrador de redes deve entender todos os campos até a camada do TCP/UDP/ICMP e boa parte dos protocolos mais usados como DHCP (bootp), DNS, HTTP. Se entender para que cada campo serve, implicitamente vai conhecer quase tudo que precisa.

Além, claro, de capturar pacotes, o wireshark tem diversas ferramentas de análise excelentes para diagnósticos diversos (ver nota [1] no fim do artigo). Ele próprio também faz diversas validações de protocolos conhecidos. Perdi a conta da quantidade de problemas que o próprio wireshark informou. Bastou capturar pacotes, abrir no wireshark e ele já mostrava o pacote com uma cor diferente e uma bela mensagem informando o problema.

Qualquer coisa que eu falar além sobre os recursos do wireshark será superficial demais para ser útil. Então, vamos ao tema propriamente dito deste artigo. Os melhores (e alguns dos ruins também) permitem que você capture de alguma forma o tráfego que passa nas suas interfaces. E o OpenWRT/LEDE? Bem, ele não tem uma forma padrão de fazer isso pois não precisa.

Por ser simplesmente um Linux, existem diversas formas de fazer essa captura de forma simples. Se existir uma unidade de armazenamento no roteador, pode fazer a captura em arquivo e analisar depois. Mas se quiser fazer "ao vivo", pode usar o recurso de pipes. A que eu mais gosto é usando um SSH para rodar o tcpdump no roteador e, por pipe, fazer um wireshark local ler os pacotes enviados pela entrada padrão. Parece complexo mas é só uma linha:

$ ssh root@router tcpdump -U -w - -s0 -i eth0.2 | wireshark -i - -k

A eth0.2 é a interface que quero capturar. Poderia ser outra como a br-lan ou mesmo any para pegar pacotes de todas as redes. Só tome cuidado de excluir o próprio SSH da captura para não criar um processo retroalimentado: "um pacote qualquer capturado é enviado por SSH que é um pacote qualquer e novamente capturado...". Então, use os filtros pcap como argumento do tcpdump para excluir, no mínimo, o SSH da captura (se ele estiver utilizando uma interface capturada). Ex:

$ ssh root@router tcpdump -U -w - -s0 -i any not port 22 | wireshark -i - -k

Ou:

$ ssh root@router tcpdump -U -w - -s0 -i any not host oip.do.meu.pc | wireshark -i - -k

Ah, é preciso antes de tudo instalar o tcpdump no roteador. Recomendo o pacote tcpdump-mini, que deve atender as necessidades básicas para capturar pacotes para análise no wireshark.

Isso vale também para capturar pacotes de servidores remotos que não têm wireshark (e nem deveriam), mas normalmente têm o tcpdump. Só trocar no comando o "router" para o nome do servidor e pode reaproveitar a dica.

Tunelar pelo SSH pode não ser a forma mais eficiente de fazer essa captura mas é a mais simples. Casos especiais onde o excesso de tráfego e os restritos recursos do roteador não aguentarem o trabalho, pode-se pensar em enviar os pacotes por netcat e sem criptografia. Mais inseguro, complicado mas bem mais leve para o roteador. Mas casos especiais são especiais e fica para outra oportunidade.

Alguma dúvida? Criei um fórum para o blog e vou criar um tópico para cada novo artigo.

Até a próxima!

[1] : na verdade, eu nem gosto de capturar pacotes diretamente com o wireshark pois a captura de pacotes exige privilégios especiais, que normalmente são supridos rodando a captura como root. Entretanto, como qualquer software, o wireshark é passível de vulnerabilidades. Um atacante que conheça uma delas pode injetar pacotes que a exploram em qualquer interface que ele tenha acesso, mesmo em uma insegura como a entrada da internet. Se um administrador capturar esse pacotes com o wireshark, ele processará o pacote malicioso e o atacante tomará conta do wireshark. Se o wireshark estiver rodando como root, o atacante rodará o código malicioso com os acessos de root na máquina atual. Então, procurem não rodar o wireshark como root e, na dúvida, use-o com captura remota e rode-o dentro de uma máquina virtual descartável sem acessos especiais.

OpenWRT: Cópia de arquivos de/para o roteador

Mais um artigo da série sobre o OpenWRT.

Um dos problemas comuns dos novatos no OpenWRT é como fazer a cópia de arquivos de e para o roteador. Em geral, não existe grande diferença entre copiar de um computador com Linux ou de um roteador com OpenWRT. Afinal, ele também é um Linux. Porém, pode ser um pouco diferente para usuários acostumados com o ambiente Windows.

Nativamente, o OpenWRT vem com o servidor SSH Dropbear. Tendo um servidor SSH, já podemos realizar a cópia simples de arquivos pela entrada e saída padrão. Basta que seu ambiente seja um UNIX, como um Linux, BSD ou um MacOSX. Ex:

# copiando o /etc/passwd do roteador

# para /tmp/passwd.router na máquina local

ssh root@router cat /etc/passwd | cat > /tmp/passwd.router 

# copiando o /etc/resolv.conf do computador

# para /tmp/resolv.conf.exemplo no roteador

cat /etc/resolv.conf | ssh root@router "cat > /tmp/resolv.conf.exemplo"

O primeiro "| cat" poderia ser otimido mas deixei para uniformizar os dois comandos.

Claro, dificilmente se usa este recurso para cópias. Uma alternativa mais simples é utilizar o scp. Para este, ao menos, temos uma alternativa para usuários do Windows: o winscp. A partir de ambientes UNIX como o Linux ou o Mac OSX, podemos fazer:

# copiando o /etc/passwd do roteador

# para /tmp/passwd.router na máquina local

scp root@router:/etc/passwd /tmp/passwd.router 

# copiando o /etc/resolv.conf do computador

# para /tmp/resolv.conf.exemplo no roteador

scp /etc/resolv.conf root@router:/tmp/resolv.conf.exempl 

Se a ideia é copiar vários arquivos, você pode usar a opção "-r". Alternativamente a opção '-r', você pode utilizar a primeira solução mas com o comando tar. O tar cria arquivos em formato usado para fitas mas, atualmente, é mais usado como um arquivador. Em conjunto com um compactador de arquivo, ele é similar a um zip. Fica assim:

# copia o conteúdo de /overlay do 

# roteador para o diretório atual

ssh root@router tar -cz /overlay | tar -xzv

Inclusive, pode trocar o "tar -xz" por um "cat > overlay.tar.gz" para criar um tar diretamente pela rede, sem criar o arquivo no roteador. Uma ótima forma de fazer um backup de conteúdos do roteador.

Até este ponto, não era necessário instalar qualquer programa no roteador. Agora vamos as alternativas instaláveis.

Um grande software de cópia de arquivos é o rsync. É um programa de sincronização de diretórios, podendo ser ambos locais ou um deles remotos. Na maioria dos casos, eu o uso como ferramenta de cópia no lugar do scp pois você pode "continuar" a cópia de um diretório com grande números de arquivos e, usando as opções corretas, continuar a cópia de um arquivo grande. Para utilizá-lo no OpenWRT, é necessário instalá-lo.

opkg install rsync

E copie de forma similar ao scp

rsync -av root@router:/overlay /tmp/overlay

Outra opção é usar o SFTP, um FTP sobre o SSH. Pelo fato do servidor SSH do OpenWRT ser desenvolvido para ambientes embarcados, alguns recursos foram suprimidos. Como temos o scp, o sftp ficou de fora. Contudo, ele está preparado para utilizar o servidor sftp do openssh. Isto vai exigir, no mínimo uns 700 Kbytes de espaço de disco livre:

opkg install openssh-sftp-server

Depois de instalar, você já pode usá-lo. Não precisa reiniciar o roteador ou mesmo o dropbear. A vantagem do sftp é poder utilizar navegadores gráficos clássicos como o filezilla ou o suporte nativo dos gerenciadores de arquivos no Linux (gnome nautilus e kde dolphin) para o protocolo sftp://root@router/.

Um ponto interessante de todas as opções que foram listadas aqui é que todas operam sobre o canal do SSH e, portanto, utilizam somente a porta do serviço SSH (22). Tudo criptografado e seguro, desde que a sua senha esteja segura. Se quiser fazer o acesso de fora da rede interna, basta liberar a porta 22 do firewall do OpenWRT.

Até a próxima!

OpenWRT: Túneis e Proxy na sua Casa ou "Escapando do Big Brother"

Mais um artigo da série sobre o OpenWRT. Este vai ser um artigo não diretamente um recurso do OpenWRT mas o que você poderá fazer com ele.

Várias vezes fui questionado de qual seria a vantagem de instalar o OpenWRT se corro o risco de não dar certo e, além disto, perder a garantia. O grande diferencial do OpenWRT não são propriamente os recursos desenvolvidos pela comunidade OpenWRT, que já são muito melhores dos originais, mas a possibilidade de usar todos os recursos desenvolvidos para o ambiente Linux diretamente no seu roteador. Vou comentar neste artigo o uso de túneis e proxy SOCKS sobre um conexão SSH.

O SSH surgiu como um substituto seguro dos finados rlogin, rsh e telnet (ainda não muito morto). Ele é usado como uma das formas de gerenciar seu roteador, além da interface WEB. Porém, mais do que reimplementar as funcionalidades dos programas finados, o SSH foi além e acrescentou diversos recursos. Um dos mais interessantes, mas ainda pouco conhecidos, é a criação de túneis.

Os túneis ou encaminhamento de porta no SSH são como despachantes. Você indica onde quer conectar e ele abre a conexão para você. Para quem recebe a conexão, quem está conectando é o despachante e não você. Um bom exemplo de "homem do meio". O SSH pode criar túneis tanto do servidor para o cliente (-R) como do cliente para o servidor (-L). Na conexão com a opção "-L", uma porta local é aberta no computador cliente. Ao receber uma conexão nesta porta, o SSH solicita que o servidor conecte em um destino pré-definido e todo o tráfego fluindo por esta conexão trafegará pelo SSH. Para todos os casos, quem está efetivamente conectando ao destino é o servidor SSH e não a máquina cliente. A opção "-R" é simplesmente o inverso: o servidor abre uma porta local que, ao ser acessava, quem conecta ao destino é o cliente SSH.

Vamos a um exemplo simples. Suponha que você está em casa, sem camisa, na sua folga, tomando uma cervejinha e alguém liga do trabalho que uma conta de um usuário importante no banco de dados está bloqueada. Se você tiver um SSH dentro da empresa acessível pela internet, poderá resolver o problema antes de esquentar a cerveja:

computador-casa$ ssh usuario@servidor-ssh.empresa.net -L 6666:servidor-banco.intranet:5432

servidor-ssh$ 

Ao completar a autenticação, você receberá o shell de sempre. Porém, devido ao comando -L, o cliente SSH local abrirá uma porta local: a 6666. Você poderá verificar isto usando o netstat ou o ss. Aponte o cliente do banco de dados para conectar nesta porta local no computador local:

computador-casa$ psql -h localhost -p 6666 -U usuarioadm -W

Quando o cliente SSH rodando em computador-casa receber o pedido de conexão na porta 6666, ele solicitará ao servidor servidor-ssh.empresa.net que este conecte em servidor-banco.intranet na porta 5432. Tudo isto utilizando uma conexão cifrada entre o computador-casa e o servidor-ssh. Seu cliente de banco de dados vai achar que existe um servidor de banco de dados rodando na máquina local na porta 6666. O servidor de banco de dados vai achar que o servidor-ssh.empresa.net está conectando nele. Simples. Resolva o problema e volte para a cervejinha. 

Nota: se a solução for utilizar um cliente em modo texto, como o psql, normalmente faz mais sentido simplesmente rodar o psql no servidor-ssh ou conectar a partir deste em um computador que o tenha e conectar de dentro da própria rede.

Isto também pode ser usado para a WEB, usando a porta 80. Porém, as inúmeras referências externas do HTML, o uso de referências absolutas e servidores que utilizam virtualhosts baseados em nomes fariam com que esta técnica de tunelamento individual se torne improdutiva. Para sanar este problema, foi criada a opção "-D" para a criação de túneis dinâmicos, simulando um servidor SOCKS.

A opção "-D porta" cria um servidor SOCKS (protocolo de PROXY não específico para HTTP), no computador cliente, fazendo com que as conexões saiam pelo servidor SSH.  Isto funciona com a maioria dos servidores e clientes SSH, incluindo o dropbear presente no OpenWRT. Vamos ao exemplo.

Imagine que você deseja acessar no trabalho um endereço sem o conhecimento do administrador da sua rede local (desde que o administrador não seja eu). Supondo que você instalou o OpenWRT na sua casa e o SSH está liberado para acesso remoto, bastaria você executar:

computador-empresa$ ssh root@ip-do-meu-roteador -D 8888

Isto abrirá uma porta local 8888. Agora, basta configurar o seu navegador para utilizar um proxy SOCKS no endereço localhost:8888. Todas as suas requisições do navegador serão enviadas para o cliente SSH local, cifradas, enviadas ao seu roteador em casa e este sim acessará o site desejado. Simples e seguro. Como seu roteador também vê a rede interna, você pode utilizar o mesmo recurso para acessar um serviço na sua rede local (192.168.x.x). Tudo isto abrindo para a Internet no seu roteador apenas o serviço SSH.

Em geral, os bons programas tem suporte a usar um servidor SOCKS. Para os demais casos, você pode usar uma biblioteca/programa que intercepte as conexões e as envie ao servidor PROXY. Desta forma, funciona para quase todos os casos.

Claro, é bom lembrar que rastros ficam no computador cliente como logs, cache do navegador e essas coisas. Se o objetivo é ser "furtivo", deve tomar mais alguns cuidados.

Não é bem o caso mas, se seu cliente necessariamente é um Windows, o Putty também possui estes recursos de encaminhamento de porta e proxy.

Happy hacking...