OpenWrt/LEDE: sane-backends 1.0.27 e hplip submetido ao repositório oficial

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

Faz longos 2 anos desde a última atualização do sane-backends. Enfim, lançaram uma nova versão: 1.0.27. Se notar a falta da 1.0.26, ela não existiu mesmo.

Mudou algo? Sim, bugs, falhas de segurança, melhorias diversas. Nada de grande nota. Alguns dos patches do pacote também foram aceitos no projeto, reduzindo o meu trabalho de mantê-lo.

As instruções para instalação continuam as mesmas. Com a diferença que o repositório para o LEDE está em http://luizluca.github.io/lede/. Quem já está com o pacote instalado e quer somente atualizar, basta adicionar o repositório (veja no atalho anterior) e trocar o install por upgrade.

router# opkg list-upgradable | grep sane
router# opkg upgrade <os pacotes do sane listados anteriormente)

Por sinal, sempre é bom observar os pacotes atualizáveis pelo "opkg list-upgradable". Normalmente são só correções de bugs (em especial, de falhas de segurança). Para pacotes instalados depois da gravação da firmware, não deve dar problema. Para os que já estavam na firmware, tem que ver se terá espaço livre para instalá-los.

Para quem não está com pressa, a próxima versão do OpenWrt/LEDE já terá a versão atualizada sem a necessidade de adicionar o meu repositório.

Outra novidade importante é que submeti o hplip ao repositório oficial. O entrave até agora era a falta do cups, que ficou sem mantenedor desde a versão OpenWrt CC. Eu criei um pequeno pacote libcups apenas para gerar as bibliotecas necessárias para o SANE compilar. Se for aceito, vai simplificar bastante a instalação do hplip.

Se pintar um problema, tem sempre o fórum deste blog. Até a próxima.

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.