EdgeRouter vulnerável a ShellShock ( Corrigido )

Recentemente foi divulgada uma falha muito grave no bash, tão perigosa quanto a recente Heartbleed.

Mais informações AQUI

Verifiquei os sistemas do EdgeRouter PRO e ele estava vulnerável.

Para fazer o teste se o seu também está, entre no com o seguinte comando na edgerouter:

sudo env x='() { :;}; echo vulneravel' bash -c "echo teste"

Se estiver, você verá a palavra vulnerável, caso contrário o bash vai gerar um erro.

Na minha versão está com a falha e tentei das diversas formas atualizar o bash para uma versão de um debian novo, até agora todas sem sucesso e após procedimento tive que resetar o equipamento.

Enquanto não é lançado o pacote de atualização do bash para essa versão de Debian, para então ser lançado um novo firmware, recomendo desativar o serviço de ssh ou configurar o firewall para aceitar conexões ssh somente da sua rede.

Você pode desativar o ssh com o comando:

 delete service ssh

Caso eu encontre alguma atualização compatível, atualizo aqui.

ATUALIZAÇÃO: APLICANDO A CORREÇÃO

A única versão de pacote que tem a correção é a

bash_4.2+dfsg-0.1+deb7u1_mips.deb

E somente para debian wheezy, então a solução que encontrei ( E TESTEI, INCLUSIVE JÁ ESTÁ EM EQUIPAMENTO QUE ESTÁ EM PRODUÇÃO ) é a seguinte:

Entre no bash:

sudo bash

Edite o arquivo /etc/apt/sources.list e apague todo o conteúdo que há nele. Depois adicione esses repositórios:

# main-updates
deb http://ftp.br.debian.org/debian/ wheezy main contrib non-free
deb http://ftp.br.debian.org/debian/ wheezy-updates main contrib non-free

# security-updates
deb http://security.debian.org/ wheezy/updates main contrib non-free

Após, execute os seguintes comandos:

apt-get update
apt-get install --only-upgrade bash

ATENÇÃO: Não execute o upgrade completo do sistema, execute exatamente como está acima, caso contrário você corre o risco de ele não iniciar novamente e você terá que resetá-lo. Feito isso é só rebootar e executar o comando de novo para verificar. Você verá que a falha foi corrigida.

Lembrando que se você resetar o equipamento terá que atualizar novamente. Agora é esperar a versão oficial.

  

 

EdgeRouter: Erro na leitura de CPU

Não sei se intencional ou não ( até acredito que não ), mas o fato é que a versão atual do firmware da linha edge faz uma leitura errada do consumo de cpu. Como o processador tem 2 cores, a leitura que é mostrada no dashboard é somente a do segundo core ( o menos utilizado ) o que leva o administrador a pensar que o consumo de cpu está realmente baixo.

Ou algum programador não se tocou disso, ou alguém tentou ser malandrinho hehehe

Lembrando, que a ideia não é denegrir a imagem do produto ( até porque uso, aprovo e recomendo ), mas sim manter documentado e informar os demais administradores.

Para quem quiser acompanhar, abri um tópico no fórum oficial demonstrando o problema...

CLIQUE AQUI PARA IR PARA O POST NO FÓRUM OFICIAL

e segue AQUI o link do vídeo ( que não está como público ).

Neste momento, já houve respostas no fórum indicando que seria uma média dos dois, se for.. o cálculo está errado, pois a diferença é gritante.

Façam os testes, se puderem reportar aqui ou no fórum oficial, agradeço.

VyOS + GNS3: Problema com Nomes da Interfaces

Certamente quem já trabalhou com servidores linux já teve problemas com a questão de nomes de interfaces.

Seja criando nomes novos ou simplesmente invertendo o nome das interfaces, o udev sempre deu bastante trabalho nesse sentido.

No VyOS não é diferente, e quando precisamos emular várias imagens, a cada uma delas "resetamos" os macs, para que em cada imagem tenhamos macs diferentes.

Porém, quando você boota a primeira vez o VyOS, ele armazena os macs e nome das interfaces ( assim como qualquer outro linux ), depois de feito isso, se você clonar essa imagem, seja no VirtualBox ou no Qemu, você terá problemas, pois ele vai encontrar um novo mac e criar um novo nome para cada interface.

Assim, pode acontecer de em uma máquina você ter a eth0, e em outra, clone da mesma, não.

Para ter certeza de que as interfaces serão criadas da forma certa e que não haverá mudanças em cada boot ou ao clonar, execute essas configurações:

Logue no VyOS normalmente, depois execute o comando abaixo para ter acesso ao bash.

sudo bash  

Agora, precisamos renomear o arquivo vyatta_net_name que fica dentro de /lib/udev se o sistema for 32bits ou em /lib64/udev se for 64.

cd /lib/udev/
mv vyatta_net_name vyatta_net_name.old 

Precisamos adicionar o seguinte conteúdo no arquivo 75-persistent-net-generator.rules ( se você já estiver na pasta udev, basta entrar na rules.d ).

ENV{MATCHADDR}==”0*”, ENV{MATCHADDR}=””

O caminho completo para o arquivo é:

/lib/udev/rules.d/75-persistent-net-generator.rules
/lib64/udev/rules.d/75-persistent-net-generator.rules

Adicione o conteúdo acima utilizando o editor vi.

Feito isso, basta desligar a máquina e clonar a vontade.

Conectando no VyOS via GNS3 no Linux

Um dos maiores problemas encontrados por mim que utilizo linux 99% do tempo ( e com certeza para quem já tentou utilizar o gns3 em alguma distribuição ) é fazer a conexão dos dispositivos do GNS ( Seja Mikrotik/RouterOS ou VyOS ) ao Linux.

Testei de diversas formas, diversas versões e em todas sempre ocorria algum bug que incomodava bastante e dificultava os laboratórios quando necessitávamos de diversos dispositivos.
Uma das formas menos problemáticas é fazer a ligação da nuvem à uma interface real, porém, em alguns cenários não creio que seja a maneira mais eficiente ( fazer testes conectados com uma interface real ).

Para solucionar o problema, de uma vez por todas, passei a utilizar interfaces virtuais no linux e não tive mais problemas. Abaixo descrevo como configurar o gns e o linux para tal conexão.

OBS: Em mikrotik/routeros você pode ter problemas de não identificar via "mac", mas se colocar um ip na interface que esteja na mesma classe da virtual se consegue a conexão normalmente.

Primeiramente abra um terminal ( No ubuntu ctrl+alt+t ) e execute o comando:

sudo tunctl  

Com esse comando a sua interface tap0 já deve ser criada automaticamente, é ela que vamos utilizar no gns3. Você pode conferir se ela foi criada corretamente utilizando o seguinte comando:

ifconfig tap0  

Você verá algo como na imagem abaixo:

Vamos adicionar o ip 10.1.1.2/24 à interface tap0 com o comando:

ifconfig tap0 10.1.1.2/24  

E vamos ao GNS. No GNS3, adicione o seu dispositivo VyOS, um Switch ( ou HUB ) e uma Nuvem.

Para que possamos conectar o GNS à nossa interface tap0, precisamos configurar a nuvem. Para isso, clique com o botão direito do mouse em cima dela, vá em configurações, clica na aba  NIO TAP, no campo TAP Interface digite tap0, clique no botão Add, depois em Aplicar e OK.

Seu cenário deve ficar parecido com este:

Feito isso, vamos dar um start no lab e aguardar o vyos iniciar.

Nele, vamos configurar o endereço 10.1.1.1/24 na interface ether1 para colocarmos o dispositivo na mesma rede da nossa tap0 ( 10.1.1.2/24 ).

Para isso, vamos logar no vyos ( user: vyos  senha: vyos ) e executar os seguintes comandos:

configure

set interfaces ethernet eth1 address 10.1.1.1/24

commit

save 

E então, é só correr pro abraço, do seu linux, execute um ping para o vyos.

Caso você não consiga comunicação, verifique se suas interfaces estão corretas, veja qual está com o status UP através do comando:

show interfaces ethernet details

Um abraço e até a próxima!