terça-feira, 5 de dezembro de 2017

Migrando de iptables para nftables

O assunto de hoje é sobre firewall

Hoje foi 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)


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.

segunda-feira, 10 de outubro de 2016

Choqok 1.6 available for Kubuntu

Se não entendeu nada siga para a versão em Português em: http://www.adilson.net.br/2016/10/choqok-16-disponivel-para-kubuntu.html


After more than one year and half of depvelopment, finally they released Choqok 1.6. Choqok is a microblog client compatible with Twitter and other services. The official annoucement is at http://choqok.gnufolks.org/2016/10/choqok-1-6-released/ released last Sartuday.

With the release, now it's time to package this version since I made them available for some time. I had just stopped when they started to migrate the software from KDE 4 to KDE Frameworks 5. Must packages, which this new Choqok depends, was not available for Debian and Ubuntu. Which made it difficult to create the packages. And I was very busy with another personal tasks so I gave up building.

But, at this last weekend, I take courage and, with more time available, I started to view this version. It was necessary to review all dependencies. But one of them had to be recreated: qoauth.

This Choqok version requires qoauth 2.0.1, which is compatible wit QT5 and no packages for Debian or Ubuntu are available. I had created a package last year but it was failed to build at Launchpad. Now,at this weekend, I applied some fixes and the package was sucessufully built.

After this, I applied one more fixes and, finally, Choqok 1.6 is now available. The packages are available for Xenial and the future Yakkety versions of Ubuntu. I tried to build for Trusty but it breaks on this dependency. And I have no plans to backport libqca-qt5-2 for Trusty.

For those who use Debian I would like to make some packages available but I don't have a place to keep a repository. But the sources  are all compatible with sid and testing versions. The sources for Choqok and qoauth2 can be downloaded from the PPA and compiled on your machine.  Remember to compile qoauth2 first since Choqok depends on it for building the package.

To download the packages just access the PPA . For those who uses Xenial or Yakkety, you can add the repository with these commands:

sudo add-apt-repository ppa:adilson/experimental
sudo apt-get update
sudo apt-get install choqok

Doubts or bugs on the packages (The package does not install or the plugin is on the wrong place), just ask me on the blog or Twitter. If the problem is on the Software, the bug must be addressed to https://bugs.kde.org/component-report.cgi?product=choqok

Have a nice week.

Choqok 1.6 disponível para Kubuntu

If you don't understand Portuguese, go to the English Version: http://www.adilson.net.br/2016/10/choqok-16-available-for-kubuntu.html



Depois de mais de um ano e meio de desenvolvimento, finalmente lanaçaram a versão 1.6 do Choqok, que é um cliente de microblog compatível com o Twitter e muitos outros serviços. O anúncio oficial está em http://choqok.gnufolks.org/2016/10/choqok-1-6-released/ divulgado no últmio sábado.

Com o lançamento, restou apenas empacotar esta versão já que ando disponibilizando os pacotes já a algum tempo. Apenas tinha dado uma parada quando começaram a migrar o software do KDE 4 para o KDE Frameworks 5. Muitos pacotes que dependiam do novo Choqok não estavam disponíveis para Debian e Ubuntu, o que dificultou bastante na criação dos pacotes. Soma-se isso com uma época em que estava ocupado com outras tarefas pessoais que deixei o pacote de lado.

Mas, neste final de semana, tomei coragem para ver esta nova versão já que estou com mais tempo disponível. Uma das preocupações era refazer todas as dependências para gerar os pacotes. Apenas uma dependẽncia precisava ser recriada: qoauth.

A nova versão choqok requer o qoauth 2.0.1,que é compatível com o qt5 e não existia pacotes para Debian ou Ubuntu. Até tinha criado um pacote, no ano passado, mas não consegui gerar os pacotes no Launchpad. Neste final de semana consegui aplicar algumas correções e o pacote finalmente saiu.

Depois disso foi apenas algumas correções e, finalmente, a versão 1.6 do Choqok foi disponibilizado. Ele está disponível para as versões Xenial e a futura Yakkety. Tentei gerar um pacote para Trusty mas ele esbarra nesta dependência  e não há planos para fazer o backporting do libqca-qt5-2 para Trusty.

Para quem usa Debian eu até gostaria de deixar alguns pacotes dispóníveis mas não tenho um local para manter um repositório. Porém os fontes que gerei são todos compatíveis com a versão sid e a testing. Os fontes choqok e do qoauth2 podem ser baixados no PPA e compilados na sua própria máquina. Lembrando que deve-se compilar primeiro o qoauth2 já que o Choqok depende dele para a geração do pacote.

Então, para baixar os pacotes é só acessar o PPA. Para quem usa a versão Xenial ou Yakkety adiciona os repositórios pelos seguintes comandos:

sudo add-apt-repository ppa:adilson/experimental
sudo apt-get update
sudo apt-get install choqok

Dúvidas ou bugs, no pacote (O pacote não instala, ou o plugin está no lugar errado), pode me procurar no blog ou no Twitter. Se for algo no próprio Choqok, neste caso, o bug deve ser endereçado para https://bugs.kde.org/component-report.cgi?product=choqok

Tenham uma boa semana.

sábado, 12 de março de 2016

Fim da tetra entre Mozilla e Debian. Iceweasel volta a ser Firefox.

Já não vamos ter mais Iceweasel

No dia 27 de fevereiro de 2006 foi aberto um bug report em https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=354622 onde um representante da Mozilla reclamava sobre o uso da marca Firefox e Thunderbird nas versões compiladas na Debian. Para manter a qualidade do programa, os desenvolvedores da distribuição aplicava patches de segurança e esses patches não passavam pela Mozilla. A partir deste ponto rolou uma discussão pelo uso da marca que culminou no seguinte: Os desenvolvedores da Debian ainda pegavam o código do Firefox. Porém eles faziam várias modificações para ganhar um novo nome e logo. E aí deu a origem ao Iceweasel e, por consequência, o Thunderbird se tornou o Icedove. Com isso a Mozilla não pertubava mais a Debian sobre a questão da marca.

Mas isso trouxe alguns problemas para alguns usuários. Desde de extensões não funcionando até problemas de acesso a certos sites. Essas falhas foram logo resolvidas, porém ainda tem usuários que preferem utilizar o Firefox ao invés do Iceweasel. Algumas opções existiam por exemplo:


  • Mudar de distribuição aonde tinha o Firefox nativo.
  • Baixar o Firefox do site oficial. Pode gerar alguns problemas de atualizações mas o Firefox tem um aviso quando chega uma versão nova.
  • Pegar os fontes do Iceweasel e tentar reverter para o Firefox. Foi a minha primeira opção. Dava um trabalhão mas conseguia um bom resultado.
  • Pegar os fontes de uma outra distribuição e adaptar para Debian. Foi a minha segunda opção depois de alguns anos. Pegava os fontes do Ubuntu e recompilava na Debian. Esta opção funcionava bem melhor.
A única desvantagem da utilização dos fontes é ter que baixar toda vez e recompilar quando saia uma nova versão. Mas era uma boa opção para mim.

Isso durou anos. Com o tempo alguns desenvolvedores da Mozilla também cuidaram de alguns softwares da Debian até que, no dia 17 de fevereiro de 2016, quase 10 anos depois do inicio da tetra, um novo bug report (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815006) foi aberto para encerrar as divergências e trazer o Firefox e Thunderbird de volta a Debian.

Mozilla: Aí Debian, chega de treta. Podemos ficar de boas e pode usar os logos.
Debian: Claro, vamos ficar de boas.
Isso quer dizer que a questão dos logos e dos patches foram encerradas e a Debian pode novamente disponibilizar o Firefox, o que quer dizer que vai ser o fim do Iceweasel e, por consequencia, o fim do Icedove já que o Thunderbird deve voltar em seguida.

E isso também quer dizer que não preciso mais compilar o Firefox do Ubuntu. :)

Com isso, no dia 10 deste mês, um dos desenvolvedores da Debian publicou em https://glandium.org/blog/?p=3622 anunciando que o Firefox estará disponível e verificando em https://packages.debian.org/sid/firefoxhttps://packages.debian.org/sid/firefox-esr os pacotes já se encontram disponíveis para uso. O Iceweasel ainda continuará na Jessie até o limite da versão ESR que será substituído pelo próximo Firefox ESR.

Com o fim dessa longa tetra, tudo volta ao normal no mundo dos navegadores.

Tenham um bom final de semana e, para usuários da Debian, um bom download do Firefox.