terça-feira, 5 de dezembro de 2017

Migrando de iptables para nftables

O assunto de hoje é sobre firewall

Hoje vou falar sobre o nftables. Um sistema de firewall para Linux que pretende substituir o atual iptables, ip6tables e qualquer outro tables que trabalha com as regras de permissão de acesso e encaminhamento de pacotes. Por ser tudo reunido em um único aplicativo ele tem a vantagem de evitar a duplicação de códigos e qualquer outro problemas em que ocorre em um dos apps em separado.

O pior é que vivi esta parte da pior maneira quando compilei o kernel 4.14 da primeira vez. Na verdade demorou alguns dias já que não notei falhas de rede até que tentei acessar algo, da rede interna, exclusivamente em ipv6. A conexão não ia de maneira alguma, mesmo com todas as regras do ip6tables corretas. Voltando para o kernel 4.13 a conexão ipv6 normalizou.

A regra que deu problema foi essa:

ip6tables -t nat -A POSTROUTING -s fd08:7d11:7db1:1ecb::/64 -j MASQUERADE

Ou seja. Tirando a máquina principal, que é roteadora e o ipv6 funciona de qualquer maneira. Qualquer dispositivo, na rede interna, tem conexão ipv6 normal no kernel 4.13. Mas falha quando utiliza o kernel 4.14. O ipv4 roda normal em todas as situações.

Não entendi nada. Funciona em um e não em outro.


Então foram feitos vários testes com o kernel 4.14 tanto em Debian, quanto em Ubuntu e no CentOS. O resultado foi o mesmo e o ip6tables não encaminhava nenhum pacote para fora.

Então resolvi fazer um teste com um nftables com o kernel 4.14 e ver como se comportava. Fui ver como adiciona uma regra parecida com aquela acima e cheguei no seguinte:

table ip6 nat {
 chain prerouting {
   type nat hook prerouting priority 0;
 }
 chain postrouting {
   type nat hook postrouting priority 0;
   oifname "ens33" masquerade
 }
}
Coloquei a regra em um arquivo do tipo teste.firewall e rodei o seguinte comando.

nft -f teste.firewall

Esse comando carrega as regras contidas nos arquivos. Fui fazer um teste e... funcionou.

Até que enfim deu certo. Então o erro é em algo no ip6tables que ainda não foi identificado. Mas já que a tendência é do iptables se juntar ao antigo ipchans como 'deprecated' nos próximos anos. Então vamos pegar as regras atuais e repassar para o nftables.


Mas como migrar tudo que é feito em iptables/ip6tables para nftables???

Por sorte os desenvolvedores criaram duas maneiras de migrar as regras de um para outro. Um deles é pelo uso do iptables-nftables-compat, aonde não muda as regras atuais e deixa o nftables fazer as coisas, nos bastidores. Mas o melhor é aprender os novos comandos. Por isso foi utilizado ip(6)tables-translate, que pega as antigas regras do iptables e mostra qual o comando equivalente para o nftables.

Depois de rodar o comando em quase todas as regras (depois explico o porquê). Chegou a hora de mudar as regras locais.

A regra do nat é mais fácil já que precisa repetir apenas o a regra, no mesmo arquivo só que muda o ip6 para ip, para uso do ipv4 e colocar para carregar quando rodar o nft -f teste.firewall

As demais regras tem umas pegadinhas:

Antes de rodar qualquer comando é necessário adicionar, no inicio de cada arquivo de firewall, os seguintes comandos:

nft add table ip filter                                                            
nft add chain ip filter INPUT { type filter hook input priority 0\; policy accept\; }                                                                   
nft add chain ip filter FORWARD { type filter hook forward priority 0\; policy accept\; }                                                               
nft add chain ip filter OUTPUT { type filter hook output priority 0\; policy accept\; }


nft add table ip6 filter                                                       
nft add chain ip6 filter INPUT { type filter hook input priority 0\; policy accept\; }                                                                   
nft add chain ip6 filter FORWARD { type filter hook forward priority 0\; policy accept\; }                                                               
nft add chain ip6 filter OUTPUT { type filter hook output priority 0\; policy accept\; }



Detalhe para o \ antes do ; para evitar problemas na hora de executar via shell script.

Esses comandos criam as tables e chains necessárias para o uso das regras. Sem isso qualquer comando pode acarretar em erro.

Depois de criado, pode conferir através do comando 'nft list tables'

yoda:~# nft list tables
table ip6 filter
table ip6 nat
table ip filter
table ip nat

Agora é adcionar as regras. 

Se, antes, foi utilizado a regra:

iptables -A INPUT -i ppp0 -p tcp --destination-port 700 -j REJECT

ele agora pode ser executado dessa maneira:

nft add rule ip filter INPUT iifname ppp0 tcp dport 700 counter reject

O mesmo vale para o ipv6 já que só precisa alterar uma coisa no comando:

nft add rule ip6 filter INPUT iifname ppp0 tcp dport 700 counter reject

O resto pode ser feito em todos os comandos...   Não exatamente...

Apenas um comando no iptables e um comando em ip6tables não dá para ser migrado, por enquanto.

Esse comando é o:

iptables -t mangle -o ppp0 --insert FORWARD 1 -p tcp --tcp-flags SYN,RST SYN
-m tcpmss --mss 1400:1536 -j TCPMSS --clamp-mss-to-pmtu

E o seu equivalente no ip6tables.

Justamente o comando que regula o tamanho do mtu para evitar problemas no envio de alguns pacotes um pouco grandes em conexões ppp. Até hoje ele ainda está no TODO do projeto.

nftables frontend
-----------------
- Define lexical distinction between keywords, symbolic constants and
  identifiers
- Define syntax for changing data (connmark, meta etc.)
- payload syntax for matching on IP headers of IPIP/GRE tunnels etc.
- netlink monitor for CLI

Kernel
------
- netlink set API
- kernel set implementation selection
- TC hookup - use dummy classifier or hook "natively" ?
- kill mangle table, make rerouting a configurable table/chain property
- kill nat table? harder because of more special handling
- multi-family tables

- IPv6 ext header matching
- IP style options (IP/TCP/DCCP) matching
- IPsec policy matching
- hashlimit
- quota
- recent(?)
- TCPMSS target - generic packet editor?
- include NLM_F_ ... flags in notifications?

A solução, neste caso, é manter os antigos comandos, sendo os dois últimos remanescentes do antigo ip(6)tables até que os desenvolvedores criem um comando equivalente.

Com isso a rede interna volta a usar tanto o ipv4, quanto o ipv6. Mas, caso precisem saber como anda as regras, pode usar os seguintes comandos:

nft list tables - Exibe os nomes das tabelas criadas

nft list table ip6 nat - Exibe os códigos utilizados na tabela nat do ipv6. Para ipv4 troque ip6 por ip.

nft list ruleset - Exibe o código completo utilizado no nftables tanto no ipv4 quanto no ipv6.

Mais detalhes:





Tenham uma boa semana.

segunda-feira, 16 de outubro de 2017

Corrigindo falha nas fontes no Firefox e Thunderbird no Linux

Numa das atualizações do sistema acabei notando o Thunderbird abriu com as fontes com a aparência bastante horrível. Mais ou menos no que aparece na figura abaixo:

A figura do exemplo é do Firefox. Mas isso aconteceu apenas no Thunderbird aqui


O que é mais estranho é que isso ocorreu apenas no Thunberbird. Já o Firefox estava normal e sem nenhum problema. Então existe a possibilidade que isso seja algum problema em bibliotecas. Então eu recompilei o Thunderbird para ver se a situação melhora. Mas isso não funcionou.

Depois de algumas pesquisas eu achei a solução neste endereço: http://z-issue.com/wp/ugly-fonts-in-mozilla-firefox-and-thunderbird-under-linux-skia-and-cairo/. Nesta página indicava que a falha era mais por conta da mudança da biblioteca de renderização de fontes que mudou, nos aplicativos da Mozilla, do cairo para o skia. Provavelmente o skia usado pela Debian ficou bugado depois da última atualização. Mas ainda não explica o porque do Firefox estar imune a falha (Ele usa o skia e está normal).

De qualquer forma, no endereço acima, ele explica que tem como corrigir. No Firefox(Vale no Thunderbird, mas é outro caminho) tem que ir no about:config sabendo que verá dragões (Hic sunt dracones) e procurar os seguintes parâmetros:

gfx.canvas.azure.backends
gfx.content.azure.backends

Altera os valores de skia para cairo nos dois parâmetros e reinicia o aplicativo. A partir daí a exibição das fontes será normalizada.

No Thunderbird a configuração pode ser acessada em Editar -> Preferências -> Avançado -> Geral -> Editor de config.

Pelo menos aqui o Thunderbird voltou ao normal com essa configuração.

Tenham uma boa semana.

sexta-feira, 6 de outubro de 2017

AOL Instant Messenger será desativado em dezembro

Sabe aquele que achava que morreu? Pois bem, vai morrer no final do ano.

Uma notícia andou circulando no Twitter e sites de tecnologia lá fora nesta sexta. A AOL, que agora pertence a Verizon, anunciou que o serviço de mensagens instantâneas será descontinuado no dia 15 de dezembro, conforme o último tweet enviado pela empresa:


Quem acessava a Internet nos anos 90 e usou os CDs da AOL sabe como é o AOL Instant Messenger.  Um mensageiro instantâneo criado na mesma época do ICQ, no qual a AOL comprou e fez com que os usuários de um serviço se comunicasse com o outro. O mensageiro só deixou de ser utilizado depois da AOL ter saído do Brasil e da acensão do finado MSN Messenger, no início dos anos 2000. Ainda sim mantinha alguns usuários ativos até hoje no mundo.

Com o fim do AOL Instant Messenger, ainda temos, da primeira geração de mensageiros instantâneos, o ICQ, que pertence, atualmente, a uma empresa russa, e o Yahoo Messenger, este último só está limitado a sua interface web.

Mais informações: (por enquanto é em inglês, mas se aparecer em sites brasileiros, se alguém lembrar, vou informar  Já tem notícia no tecmundo).

https://tech.slashdot.org/story/17/10/06/1649204/rip-aim-aol-instant-messenger-dies-in-december

https://www.usatoday.com/story/tech/talkingtech/2017/10/06/rip-aim-aol-instant-messenger-dies-december/739076001/

https://www.tecmundo.com.br/internet/122782-aol-instant-messenger-dar-adeus-15-dezembro.htm

Tenham um bom final de semana.

quarta-feira, 23 de agosto de 2017

Como uma busca no Google ajudou a pegar o maior mercador da Deep Web.



Hoje vou contar a história de uma das maiores mancadas da Deep Web. Muito por conta de algumas falhas deixadas por um dos maiores mercadores no submundo da rede Tor. A prisão de Dread Pirate Roberts, o administrador da controversa Silk Road.



O Silk Road era bastante conhecido pelo comercio de drogas de forma anonima e as transações eram feitas em Bitcoin, o que dava uma dificuldade enorme para o FBI, que tentava, a dois anos, derrubar o site de qualquer forma.

Isso até que um agente fiscal da Receita dos EUA, Gary Alford, resolveu fazer algumas buscas na Internet para encontrar o administrador e criador do Silk Road. Com algumas pesquisas no Google, ele tentou localizar as primeiras menções do Silk Road. Observando alguns forums do https://bitcointalk.org, ele notou que um usuário estava fazendo várias perguntas sobre bitcoin e comércio e, numa das postagens, este usuário simplesmente divulgou um email do gmail.: rossulbricht@gmail.com.

Como assim alguém que quer se esconder divulga um email do gmail e, o pior, sendo um possível nome e sobrenome: Ross Ulbricht?? De início Gary mostrou o email para os colegas do FBI mas não ligaram a mínima pelo fato que tudo foi encontrado por conta de uma busca no Google. Então o Gary resolveu ir mais a fundo na pesquisa. Conseguiu levantar diversos dados sobre o Ross Ulbricht, descobriu-se que ele estava em São Francisco, achou alguns vídeos e, depois, fez várias pesquisas em fóruns especializados em busca de algo que possa ligar ele ao Silk Road até que encontrou algumas perguntas como essa e essa no Stackoverflow com o username frosty.


Agora que vão ligar A com B nessa.
Ligando tudo isso com a localização do servidor da Silk Road por conta de uma falha no sistema de CAPTCHA, o que deu a localização mais precisa de onde o Dread Pirate Roberts se logava. Gary voltou a entrar em contato com o FBI, já com as informações que ligavam o frosty ao Ross Ulbricht e ao Dread Pirate Roberts. Então foi facil obter um mandado e prepararam uma operação para prender-lo.

Com isso, em outubro de 2013, uma equipe do FBI foi até São Francisco e seguiram Ross Ulbricht até uma biblioteca e esperaram que ele se logasse no laptop na Silk Road, como Dread Pirate Roberts, para que possam prender-lo em flagrante. Assim que se logou, fizeram uma pequena distração e tomaram o laptop dele e, em seguida, o prenderam.


O Gary até que queria assistir, já que foi ele que descobriu tudo, mas não conseguiu a autorização a tempo para que ele possa assistir a cena de camarote. Mas ficou feliz ao receber o email dizendo que estava certo e acabaram prendendo ele.

No final de tudo Ross Ulbricht foi condenado pelos crimes de lavagem de dinheiro, hacking e conspiração para tráfico de drogas. Foi sentenciado a prisão perpétua sem possibilidade de progressão ou condicional.

Isso mostra que, por mais que as ferramentas sejam seguras, o maior ponto de falha sempre está localizado entre o teclado e a cadeira. O fato de publicar um email do gmail com nome real e errado em parte da configuração do site ajudou a tirar a máscara do anonimato do Dread Pirate Roberts. Ou seja, se quiser ficar escondido, cuidado com as pistas que deixa no caminho. Uma pergunta no Google pode te achar mais rápido do que possa imaginar…

Mais detalhes no vídeo da BBC logo abaixo. Infelizmente está todo em inglês mas o texto acima já é totalmente baseado nele.






Tenham uma boa semana.

segunda-feira, 7 de agosto de 2017

Resolvendo o problema de compilação de módulos do VMware na Debian com gcc 7.x

Aqui, em casa, utilizo bastante o VMware Workstation para rodar as minhas máquinas virtuais para testes e ajudar em algumas implementações nos programas que uso. Porém, após as últimas atualizações da minha Debian Sid, com o kernel, aconteceu algo estranho:


Como assim não encontrou o gcc???

Então coloquei /usr/bin/gcc no Location e me retornou isso:


Como assim não achou uma versão compatível???

Então tentei usar a linha de comando rodando o "/usr/bin/vmware-modconfig  --console --install-all". Mas, o que consegui foi:

Failed to get gcc information.

Aí as coisas ficam mais estranhas ainda. Como assim não conseguiu encontrar?? Então resolvi procurar várias soluções para este problema e, tudo que encontrei no Google, não resolveu e o erro ainda persiste.

Então tentei seguir o script /usr/bin/vmware-modconfig. Mas, no final, ele chega no /usr/lib/vmware/bin/appLoader, que é um arquivo binário. Sendo a falha acontecendo no binário, fui verificar os logs e me retornou o seguinte:


2017-08-07T18:46:02.429-03:00| modconfig| I125: Trying to find a suitable PBM set for kernel "4.12.5".
2017-08-07T18:46:02.429-03:00| modconfig| I125: No matching PBM set was found for kernel "4.12.5".
2017-08-07T18:46:02.429-03:00| modconfig| I125: Found compiler at "/usr/bin/gcc"
2017-08-07T18:46:02.431-03:00| modconfig| I125: Got gcc version "7".
2017-08-07T18:46:02.431-03:00| modconfig| I125: Unable to parse gcc version
2017-08-07T18:46:02.434-03:00| modconfig| I125: We are now shutdown.  Ready to die!


De alguma forma a parte do VMware, que gera os módulos, só reconhece as versões do gcc até a 6, acima disso ele não conhece e a compilação é abortada. E o problema só ocorreu porque, durante as atualizações do sistema, a versão do gcc padrão utilizada passou da versão 6 para a 7, e foi aí que a incompatibilidade aconteceu.

Como não quero esperar chegar uma versão mais nova para corrigir, o jeito é criar um script que, pode fazer este papel. O script que criei é esse:

#!/bin/bash

#Cria os módulos de forma manual

/etc/init.d/vmware stop

mkdir /tmp/vmware-build

cd /tmp/vmware-build


tar -vxf /usr/lib/vmware/modules/source/vmmon.tar
tar -vxf /usr/lib/vmware/modules/source/vmnet.tar


cd /tmp/vmware-build/vmmon-only/
make

mkdir /lib/modules/`uname -r`/misc
cp vmmon.ko /lib/modules/`uname -r`/misc/vmmon.ko

cd /tmp/vmware-build/vmnet-only
make


cp vmnet.ko /lib/modules/`uname -r`/misc/vmnet.ko

depmod -a

/etc/init.d/vmware start

cd


rm -rf  /tmp/vmware-build

Este script, descompacta compila e instala os módulos. A vantagem dele é que não precisa verificar qual versão do gcc. Ele já utiliza a última versão, instala e deixa o VMware pronto para o uso.

Após o teste, tudo voltou a funcionar como antes.

Espero que isso ajude a resolver este pequeno problema. Caso tenha erros de compilação, por algum outro motivo, recomendo que dê uma olhada em http://rglinuxtech.com/. Normalmente encontro patches que podem servir para corrigir os módulos do VMware, caso haja problemas após a atualização para a versão mais recente. O site também vale para os módulos da NVIDIA para as placas de vídeo. Vale a pena.

Tenham uma boa semana.


segunda-feira, 31 de julho de 2017

Invadiram o meu computador mas não conseguiram nada...



Infelizmente houve um acesso não autorizado na minha máquina. Por sorte não aconteceu muita coisa. Mas como isso aconteceu???

Apesar de todas as medidas de segurança que tomo para evitar problemas, no último domingo notei que algo estava errado quando a impressora imprimiu diversas folhas de modo bem estranho.

Gastou todo papel que estava na bandeja

A princípio pensei que fosse uma doideira no sistema da HP ou do Google, já que a minha atual impressora utiliza WiFi e todas as máquinas de casa podem imprimir diretamente na impressora.

Como não encontrei nada de errado fui dar uma olhada nos logs do CUPS e encontrei duas coisas estranhas nos últimos trabalhos de impressão. Justamente a impressão que gastou as folhas é que contem uma string semelhante a essa:

smbprn.00000053 Remote Downlevel Document 

E o usuário usado é totalmente diferente dos que normalmente são usado nas impressões. O que seria eu e a, minha esposa, Regiane. Mesmo assim ainda aparece mais o meu nome de usuário já que a Regiane usa um notebook a parte e a impressão é direto na impressora, sem passar pela minha máquina. Então o problema cai direto no Samba (por causa do smbprn). Mas como isso pode acontecer??

Normalmente as portas usadas pelo Samba e, por tabela, pelo sistema de compartilhamento do Windows são bloqueadas pelo Oi Velox já tem anos, juntamente com outras portas. Até aí nada demais e pode ser considerado até uma boa medida de segurança já que deixar um compartilhamento Windows exposto na rede externa é o mesmo que deixar a porta do galinheiro aberta para a raposa entrar. 

O resultado pode ser esse de cima

Claro que, a muitos anos atrás, foram feitos vários portscans e testes que mostraram que a porta 139, a responsável pelo método de compartilhamento do Windows e do Samba, estavam filtrados, o que deixava a minha máquina segura e, consequentemente, ficava tranquilo.

Mas, de alguma data desconhecida até o momento da publicação deste artigo, algum gerente de TI da Oi resolveu revisar os bloqueios e liberou as portas 137, 138, 139 e 445. Tudo isso sem nenhum aviso e em um momento bem perigoso por conta dos ataques que tiraram um monte de máquinas Windows do ar.

Será que foi algum estagiário? Não quero acreditar que a Oi colocou alguém desse tipo para fazer isso.

Como a liberação foi sem aviso prévio, parte dos compartilhamentos ficaram totalmente expostos na rede. Alguns compartilhamentos tinham senhas e nem foram afetados, outros eram somente leitura e havia um, onde guardo programas para instalar no notebook e nas máquinas virtuais, estavam com permissão total de leitura e escrita. É neste compartilhamento onde foi notado a maior alteração. Vários arquivos de instalação foram infectados com alguns malwares e outros apareceram para infectar qualquer máquina que tentar executar na rede.

Sem contar com o compartilhamento da impressora, que estava exposto. O invasor ou algum malware que esteja se espalhando, pensou que a minha máquina era mais uma Windows e enviou um malware, na esperança que o spooler do Windows rodasse e baixasse todos os componentes para que possa infectar ou sequestrar os arquivos, da mesma maneira que o WannaCry fez. Porém estava no Linux e o Samba repassou para o CUPS e o mesmo ignorou o arquivo e repassou para a impressora. O resto da história todo mundo já sabe.

Mas como saber se está em perigo??

Uma página que recomento é essa: https://www.grc.com/x/ne.dll?bh0bkyd2  Nesta página pode mostrar quais portas estão abertas e quais compartilhamentos estão expostas na rede.

O resultado que pode aparecer são esses:

Se o link 'File Sharing' mostrar a mensagem "Unable to connect with NetBIOS to your computer.", isso pode indicar:
  • Ou a sua máquina está protegida, o que significa que está seguro
  • Ou está atrás de um roteador, o que coloca uma barreira antes da sua máquina. Neste caso só deve se preocupar um pouco mais com a segurança do próprio roteador.
Agora se o mesmo link mostrar uma página dizendo o nome da sua máquina e os compartilhamentos, aí tem que se preocupar e muito. Qualquer um pode ver a sua máquina e fazer qualquer coisa para acessar os arquivos que estão nele.

Para evitar isso podemos fazer o seguinte:

No Windows:

Vá nas propriedades do adaptador de rede PPPOE e desmarque o 'Compartilhamento arquivos/impressoras para redes Microsoft'

Esse é um exemplo mostrando uma das placas de redes. Mas a primeira opção deve ser desmarcada caso seja a interface PPPOE

Feito isso refaça o teste e vai notar que os compartilhamentos não estão mais expostos na rede externa.

No Linux;

Esse foi o meu caso, onde o Samba deixou os compartilhamentos expostos. Para resolver isso edite o /etc/samba/smb.conf e adicione o seguinte, no final da seção [global]:

      bind interfaces only = yes
      interfaces = lo eth0
 

Assim, o Samba só vai deixar as portas abertas na interface local (do localhost) e na eth0. Deixando a interface ppp0 com menos falhas para explorarem e fazerem a maior bagunça.

O saldo final de tudo isso foram algumas folhas, que viraram rascunho, provavelmente alguns vídeos fotos e músicas foram copiados (Nada comprometedor já que os arquivos mais particulares estavam em áreas mais seguras do computador ou fora), e alguns instaladores danificados (isso é resolvido com um novo download). Nenhum rootkit foi encontrado, o que é uma notícia melhor ainda.

Isso ainda mostra que o Linux é seguro. Pode não ser totalmente seguro. Mas, mesmo com uma combinação de um descuido meu com uma pisada de bola da Oi, o estrago ficou restrito a apenas alguns compartilhamentos e só. Agora, se fosse uma máquina Windows que não estava totalmente atualizada e com as portas abertas:

Seria "NOW PANIC AND FREAK OUT"

Tenham uma boa semana.

segunda-feira, 3 de julho de 2017

Resolvendo os problemas do Guardião 30 Horas em qualquer sistema (Versão 2017)


Atualização 03/09/2021: Depois de muitos anos o Itaú resolve acabar com o acesso a quem não tem suporte ao Guardião.
Então é possível que esta publicação esteja inválida após o dia 21/09/2021 e sejamos forçados a instalar o Warsaw. Assim que descobrir uma nova forma de contornar isso farei uma nova publicação com o novo método. Por hora segue o texto atual.


Essa é uma atualização completa de http://www.adilson.net.br/2012/02/resolvendo-os-problemas-no-guardiao-30.html e as dicas, a seguir, vale tanto para Linux quanto para Windows, Mac, e qualquer outro sistema operacional. Isso é válido para o Itaú. Como ainda não testei na Caixa, não dá para garantir que esta dica vá funcionar do mesmo jeito.

Antes de mais anda me desculpe pela longa demora em criar algo novo aqui. Ainda tenho algumas idéias mas ainda não coloquei em prática. Como hoje tive problemas em usar o Itaú no celular, resolvi usar novamente no Desktop e aí é que os problemas apareceram:

Já faz algum tempo que o Java deixou de ser suportado na maioria dos navegadores modernos. E quem usa Linux, como eu e muitos por aí, ficaram preocupados já que a outra opção seria usar o Windows com um software muito complicado chamado Warsaw. Também conhecido como G-Buster e, nos sites dos bancos, como Guardião. Chamo de complicado porque ele já entrou em conflito com atualizações do windows, chegou a bloquear a conexão de máquinas utilizando o ipv6, além de deixar alguns processos rodando nos computadores que podem fazer qualquer coisa que não imaginamos o que poderia ser.

Sobre o uso do banco através de máquina windows ainda tem a outra ameaça:



E, consequentemente...


Nisso, o criador deste software complicado, a GAS Tecnologia, resolve portar o mesmo para o Linux. Tanto que, pelo menos nas distribuições Debian, Ubuntu e derivados, ao clicar em instalar o Guardião, ele baixa o pacote deb correspondente.

O que compensa é que os aplicativos para celular evoluíram tanto que vale mais a pena usar eles do que instalar este plugin.

Mas hoje tive um problema no acesso ao celular e, a alternativa, é usar o navegador. Porém não queria instalar o Warsaw na minha máquina principal e de confiança. Mas, como tenho uma máquina virtual com Ubuntu (Também tenho uma máquina virtual com Windows 10, mas não será usada pelos motivos mostrados anteriormente) então resolvi utilizar ela para acessar o banco. Afinal, cria-se um snapshot, instala o Warsaw, usa o banco e, depois restaura o estado anterior.

Então fiz o seguinte, acessei o Itaú, tanto pelo Chrome quanto no Firefox e me deparei com esta mensagem:


Cliquei em Instale agora, continuar e baixou o arquivo warsaw_setup_64.deb. Daí é feita a sua instalação, juntamente com qualquer dependência que solicitar.

Durante a instalação apareceu algo bastante estranho:

Configurando warsaw (1.3.0) ...
/var/tmp /
Generating RSA private key, 4096 bit long modulus
...........................................................................................................................................++
......................................++
e is 65537 (0x10001)
Generating RSA private key, 4096 bit long modulus
..........................................++
......................................++
e is 65537 (0x10001)
Signature ok
subject=/CN=127.0.0.1
Getting CA Private Key
certutil: could not find certificate named "Warsaw Personal CA": SEC_ERROR_BAD_DATABASE: security library: bad database.
Notice: Trust flag u is set automatically if the private key is present.
certutil: could not find certificate named "Warsaw Personal CA": SEC_ERROR_UNRECOGNIZED_OID: Unrecognized Object Identifier.
Notice: Trust flag u is set automatically if the private key is present.

Bad database? Unrecognized Object Identifier?

Será que isso influencia em algo?? Bom, os navegadores foram reiniciados e foi feito um teste inicial no Google Chrome. O resultado foi:


Não sei o porque do Chrome não detectar o Warsaw. Então fui no Firefox e:


Melhorou, então fui digitar a senha e...



Mas como pode isso??? Tudo foi instalado, a máquina virtual reiniciada e o erro permanece. Provavelmente pelos problemas de certificados que apresentou na instalação.

Fui ver os processos e encontrei isso:

adilsond@fett:~$ ps aux |grep warsaw
root       1039  0.0  1.0 742956 21704 ?        Sl   19:41   0:00 /usr/local/bin/warsaw/core
adilsond   2298  0.0  0.5 584392 10280 ?        Sl   19:43   0:00 /usr/local/bin/warsaw/core


Um dos processos roda com o usuário root.

O Warsaw roda como root!

O Warsaw roda como root!


O Warsaw roda como root!
Lembra que falei que não sabemos o que o Warsaw pode fazer numa máquina Windows? Pois bem, se no Windows ele pode fazer bagunça, imagina no Linux, e como usuário root que é o administrador do sistema. Tem que ter em mente como funciona o sistema de permissão do Linux. Um usuário comum pode não ter permissão para mexer e bagunçar o sistema por completo. Mas o usuário root é considerado um "Deus", ou seja, ele pode tudo. Imagina um rm -rf * na pasta raiz (/). Como usuário comum o estrago pode até ser minimo. Mas, como root, o estrago é total. Claro que existem softwares que rodam como root no Linux mas, boa parte deles, tem código fonte disponível, já foi auditado por muita gente ao redor do planeta e as falhas são sanadas rapidamente. Já o warsaw, acho que só tem aqui no Brasil, é de código fechado e ninguém sabe o que ele pode fazer se tiver algum exploit violento do tipo Zero Day(É o exploit que só se descobre depois que se ******). (OBS: Pior que já teve um caso assim).

O aplicativo para celular ainda estava com com problemas, o que foi confirmado posteriormente pelo Itaú:



Entrar no Windows estava fora de cogitação. Então, durante uma pesquisa no Google, encontrei algo que remonta o antigo problema da época do java.


No artigo anterior eu expliquei como alterar o User-Agent, para um outro navegador. Neste caso agora só precisa fazer com que o navegador finja que é um Firefox mais recente num sistema Solaris (Pode ser outro sistema operacional que não seja Windows, Linux ou Mac OS X).

Mozilla/5.0 (Solaris; Solaris x86_64; rv:54.0) Gecko/20100101 Firefox/54.0

Com essa alteração, acessei o Itaú, tanto pelo Firefox quanto pelo Chrome, o acesso foi normal e não apareceu nenhum aviso para instalar ou que está usando o Guardião.  Nos testes o Warsaw nem estava instalado ou rodando. Isso garantiu que eu fizesse as transações sem problema algum, apenas pedindo o código do token no celular.

Com isso foi mostrado que é possível acessar o Internet Banking do Itaú sem a necessidade deste plugin chato. Como a solução é via navegador, ele vale tanto para Linux, quanto para Windows, Mac e qualquer outro sistema onde este warsaw é utilizado.

Como falei, anteriormente, isso só foi testado no Itaú. Em outros bancos aonde o plugin é usado eu não fiz o teste e não há garantias que ele possa funcionar. Nas o ideal mesmo é que este plugin seja abandonado e que os bancos utilizem outras soluções menos invasivas para o usuário final.

Espero que isso seja de grande ajuda para quem tem problemas com este plugin. Vou ver se consigo voltar a publicar mais vezes já que tenho bastante material para publicar e tenham uma boa semana.