Solução para acessar o home banking do Banco do Brasil no Ubuntu (com warsaw)

[jacovieira]

O Iptables esta desativado.
----------------------------------------------------------------------------------------------------------
root@notebook:~# iptables -L -xvn
Chain INPUT (policy ACCEPT 4514 packets, 2321203 bytes)
    pkts      bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 4140 packets, 387632 bytes)
    pkts      bytes target     prot opt in     out     source               destination         
root@notebook:~#
----------------------------------------------------------------------------------------

[Sampayu]

Conforme comentei aqui e aqui, não adianta apenas desativar o firewall UFW: é necessário excluir as regras de bloqueio, "resetar" o netfilter e em seguida reiniciar o computador.

Caso o firewall (G)UFW não esteja instalado, ou esteja instalado porém desativado, basta executar este comando, para resetar o netfilter e reiniciar o computador:

Código Selecionar Expandir

sudo iptables -F ; sudo iptables -X ; sudo telinit 6

Após o reboot, o módulo warsaw será detectado.

O problema disso é que o sistema estará desprotegido. Particularmente, estou preferindo não usar o warsaw e manter o firewall ligado. Existem métodos alternativos de se acessar o banco sem depender do warsaw. O que está faltando é configurar as portas TCP 30800 e 30900 de modo que o firewall, mesmo ativo, possibilite o funcionamento do warsaw. Por enquanto, não consegui fazer isso. No fim de semana vou tentar de novo. Espero que alguém consiga (se não eu, que outra pessoa consiga. Alguém precisa encontrar uma solução pra isso).

[gr9942]

Boa Tarde.
Sou novo aqui e passei pelo mesmo problema. Consegui uma solução parcial para o problema. Funcionou comigo e resolvi compartilhar com todos. Dando uma pesquisada pela net descobri que o problema é que o sistema pensava que havia um ataque de SYN FLOOD (eu acho que é assim que se escreve) e bloqueava a porta 30900. sem desativar o ufw, eu usei este comando:


echo 1 > /proc/sys/net/ipv4/tcp_syncookies

e funcionou, consegui acessar minha conta no BB.
O problema é que depois que reinicia a máquina, volta ao normal e o acesso é bloqueado.
Funcionou comigo e espero que com vocês também.
Eu não sei como colocar este comando na inicialização e nem se isso vá comprometer alguma coisa no sistema.

Fui!!!!

[Sampayu]

Boa Tarde.
Sou novo aqui e passei pelo mesmo problema. Consegui uma solução parcial para o problema. Funcionou comigo e resolvi compartilhar com todos. Dando uma pesquisada pela net descobri que o problema é que o sistema pensava que havia um ataque de SYN FLOOD (eu acho que é assim que se escreve) e bloqueava a porta 30900. sem desativar o ufw, eu usei este comando:


echo 1 > /proc/sys/net/ipv4/tcp_syncookies

e funcionou, consegui acessar minha conta no BB.
O problema é que depois que reinicia a máquina, volta ao normal e o acesso é bloqueado.
Funcionou comigo e espero que com vocês também.
Eu não sei como colocar este comando na inicialização e nem se isso vá comprometer alguma coisa no sistema.

Fui!!!!

gr9942: OBRIGADO pela dica. Funcionou! Era mesmo esse o problema. Tô aqui me perguntando por que foi que não pensei nisso antes, ao invés de ficar me matando com o iptables, rs.

A respeito da mudança de argumento dentro do arquivo /proc/sys/net/ipv4/tcp_syncookies: mudar o valor de 0 para 1 não apenas não compromete nada no sistema como é recomendável que se faça, pois na realidade aumenta a segurança do sistema. Isso porque a mudança no valor para 1 torna mais difícil (e reduz bastante o eventual impacto de) um ataque denominado "localhost SYN flood". Portanto, pode ativar isso sem medo de ser feliz. 


Método para o Warsaw já instalado não dar erro de soquete / socket / websocket

Conforme comentei aqui, o serviço "Warsaw" utiliza as portas TCP 30800 e 30900, porém o firewall do Linux bloqueia a porta TCP 30900, deste modo inviabilizando o funcionamento do (web)socket.
Para resolver esse problema, acesse o terminal do shell e execute este supercomando:

Código Selecionar Expandir

sudo apt-get install ufw gufw --reinstall -y ; sudo sed -i -e 's|syncookies=0|syncookies=1|' "/etc/ufw/sysctl.conf" ; sudo ufw enable

...e depois acesse https://www2.bancobrasil.com.br/aapf/login.jsp para verificar se agora os campos "Agência", "Conta" e "Senha de autoatendimento" aparecem. Se eles aparecerem é porque o módulo está funcionando e foi detectado, dentro do seu navegador.

Obs.: se após executar o supercomando acima você não conseguir acessar sua conta no website do Banco do Brasil, reinicie o computador e tente novamente.

O supercomando acima ativará o firewall do Linux com algumas proteções adicionais (impedirá conexões de entrada e pedidos de encaminhamento de porta que não façam parte da lista de exceções do firewall), mas ao mesmo tempo permitirá ao Warsaw utilizar as portas TCP 30800 e 30900 (porque essa conexão será executada com uma proteção adicional contra um tipo de ataque denominado "SYN Flood").

Nota: em alguns casos, pode acontecer de https://seg.bb.com.br não detectar o módulo de segurança, embora o módulo esteja instalado, funcionando, acessando as portas TCP e você consiga acessar sua conta por intermédio do URL https://www2.bancobrasil.com.br/aapf/login.jsp. Essa é a razão por que não se deve confiar no resultado mostrado em https://seg.bb.com.br.  Esse problema que ocorre com https://seg.bb.com.br também ocorre com http://www.dieboldnixdorf.com.br/warsaw, portanto também não confie no resultado que http://www.dieboldnixdorf.com.br/warsaw lhe mostrar. A única maneira de realmente confirmar se o módulo está ou não funcionando no seu navegador é acessar https://www2.bancobrasil.com.br/aapf/login.jsp e verificar se os campos "Agência", "Conta" e "Senha de autoatendimento" aparecem.

Se após executar o supercomando acima e reiniciar o computador você continuar não conseguindo acessar sua conta no website do Banco do Brasil, execute este segundo supercomando:

Código Selecionar Expandir

if [ -a /etc/rc.local ]; then sudo mv /etc/rc.local /etc/rc.local.bak; fi; echo \#\!/bin/bash | sudo tee /etc/rc.local; echo ' ' | sudo tee -a /etc/rc.local; echo \echo 1 \> /proc/sys/net/ipv4/tcp_syncookies | sudo tee -a /etc/rc.local; echo ' ' | sudo tee -a /etc/rc.local; echo exit 0 | sudo tee -a /etc/rc.local; sudo telinit 6

O segundo supercomando reiniciará seu computador. Após ele reiniciar, acesse novamente o website do Banco do Brasil, para tentar acessar sua conta.


Um dos aspectos mais bacanas da comunidade Linux, na minha opinião, é essa capacidade de atuarmos colaborativamente: cada um vai investigando o problema, tentando contribuir com o que consegue descobrir, e no fim das contas o resultado (e o "prêmio") é que chegamos a uma solução completa para o problema.

=> Caso queira "zerar tudo" e fazer uma instalação e configuração "limpa", leia este post.

[jacovieira]

Boa dica Pessoal...

Mas pra mim aqui nao funcionou!

No Diagnostico aparece tudo verde, mas não detecta o modulo de segurança!

[Sampayu]

Boa dica Pessoal...

Mas pra mim aqui nao funcionou!

No Diagnostico aparece tudo verde, mas não detecta o modulo de segurança!

Bom, isso já é outro problema (não tem a ver com porta TCP, firewall etc.). No seu caso, parece que o módulo não foi instalado. Execute este comando, no terminal do shell:

Código Selecionar Expandir

ps -ef |grep -i warsaw

O resultado do comando acima deverá ser algo assim:

Código Selecionar Expandir

root      1187     1  0 14:14 ?        00:00:00 /usr/local/bin/warsaw/core
user   2212  1734  0 14:14 ?        00:00:01 /usr/local/bin/warsaw/core
user   2249  2212  0 14:14 ?        00:00:00 /usr/local/bin/warsaw/wsatspi
user   7257  7233  0 14:40 pts/2    00:00:00 grep --color=auto -i warsaw

No caso, o que nos interessa são as três primeiras linhas (a última é gerada pelo próprio comando grep e não nos diz nada de útil): a primeira linha tem de mostrar que a conta root está executando o processo /usr/local/bin/warsaw/core, a segunda tem de mostrar que a conta user (substitua a palavra "user" pelo seu nome de usuário / nome da sua conta, aí no seu sistema Linux) também está executando o processo /usr/local/bin/warsaw/core, e a terceira tem de mostrar que a conta user está executando o processo /usr/local/bin/warsaw/wsatspi

Se nenhuma (ou somente uma ou duas) dessas linhas aparecer, a instalação do módulo está incompleta (ou falhou por completo). Em tal caso, experimente realizar a:

Instalação manual do Warsaw


1) Desinstale o Warsaw porventura instalado via pacote DEB e/ou shell script RUN:

Código Selecionar Expandir

sudo apt-get purge warsaw -y ; if [ -a /usr/bin/warsaw_uninstall ]; then sudo /usr/bin/warsaw_uninstall; fi

2) Reinicie o computador:

Código Selecionar Expandir

sudo telinit 6

3) Baixe o instalador do Warsaw para Linux:

Código Selecionar Expandir

wget https://cloud.gastecnologia.com.br/bb/downloads/ws/warsaw_`getconf LONG_BIT`_installer.run -O /tmp/instalar.warsaw

PS: o comando acima detecta a arquitetura do seu sistema operacional (32 ou 64 bits) e já pega o instalador correto.

4) FECHE TODOS OS SEUS NAVEGADORES WEB e daí execute o comando abaixo, que tornará o instalador executável e em seguida o executará:

Código Selecionar Expandir

sudo chmod +x /tmp/instalar.warsaw ; sudo /tmp/instalar.warsaw

5) Quando a instalação terminar, reinicie o computador:

Código Selecionar Expandir

sudo telinit 6

6) Acesse https://www2.bancobrasil.com.br/aapf/login.jsp para testar se o módulo está funcionando e sendo detectado.

Nota: em alguns casos, pode acontecer de https://seg.bb.com.br não detectar o módulo de segurança, embora o módulo esteja instalado, funcionando, acessando as portas TCP e você consiga acessar sua conta por intermédio do URL https://www2.bancobrasil.com.br/aapf/login.jsp. Essa é a razão por que não se deve confiar no resultado mostrado em https://seg.bb.com.br.  Esse problema que ocorre com https://seg.bb.com.br também ocorre com http://www.dieboldnixdorf.com.br/warsaw, portanto também não confie no resultado que http://www.dieboldnixdorf.com.br/warsaw lhe mostrar. A única maneira de realmente confirmar se o módulo está ou não funcionando no seu navegador é acessar https://www2.bancobrasil.com.br/aapf/login.jsp e verificar se os campos "Agência", "Conta" e "Senha de autoatendimento" aparecem.

=> Caso queira "zerar tudo" e fazer uma instalação e configuração "limpa", leia este post.

[druidaobelix]

Boa Tarde.
Sou novo aqui e passei pelo mesmo problema. Consegui uma solução parcial para o problema. Funcionou comigo e resolvi compartilhar com todos. Dando uma pesquisada pela net descobri que o problema é que o sistema pensava que havia um ataque de SYN FLOOD (eu acho que é assim que se escreve) e bloqueava a porta 30900. sem desativar o ufw, eu usei este comando:

echo 1 > /proc/sys/net/ipv4/tcp_syncookies

Eita, veja só, agora você tirou o coelho da cartola, junto com o "Sampayu" que havia apontado antes a questão firewall. 

Muito bom, daqui a pouco irei testar a solução.

[druidaobelix]

echo 1 > /proc/sys/net/ipv4/tcp_syncookies
[...]A respeito da mudança de argumento dentro do arquivo /proc/sys/net/ipv4/tcp_syncookies: mudar o valor de 0 para 1 não apenas não compromete nada no sistema como é recomendável que se faça, pois na realidade aumenta a segurança do sistema. Isso porque a mudança no valor para 1 torna mais difícil (e reduz bastante o eventual impacto de) um ataque denominado "localhost SYN flood". Portanto, pode ativar isso sem medo de ser feliz. 

Dois centavos de contribuição para entender melhor a questão quanto a alteração do parâmetro syncookies de 0 para 1 e seu significado, numa bem elaborada, clara, simples e didática matéria do Morimoto.

Bloqueando ataques de SYN Flood

http://www.hardware.com.br/dicas/syncookies.html

[Sampayu]

echo 1 > /proc/sys/net/ipv4/tcp_syncookies
[...]A respeito da mudança de argumento dentro do arquivo /proc/sys/net/ipv4/tcp_syncookies: mudar o valor de 0 para 1 não apenas não compromete nada no sistema como é recomendável que se faça, pois na realidade aumenta a segurança do sistema. Isso porque a mudança no valor para 1 torna mais difícil (e reduz bastante o eventual impacto de) um ataque denominado "localhost SYN flood". Portanto, pode ativar isso sem medo de ser feliz. 

Dois centavos de contribuição para entender melhor a questão quanto a alteração do parâmetro syncookies de 0 para 1 e seu significado, numa bem elaborada, clara, simples e didática matéria do Morimoto.

Bloqueando ataques de SYN Flood

http://www.hardware.com.br/dicas/syncookies.html

Bacana. A explicação está mesmo bem didática.

[gr9942]

Fico muito feliz por ter contribuído com a solução do problema.
Muito Obrigado a todos que de alguma forma ajudaram também.
Fiquem em Paz e Boa Noite a todos.

[druidaobelix]

Minha proposta/sugestão é que todo mundo que esteja usando o Warsaw execute este supercomando

Código Selecionar Expandir

sudo iptables -P INPUT DROP ; sudo iptables -P FORWARD DROP ; sudo iptables-save | sudo tee /etc/iptables.conf ; sudo sed -i -e 's|exit 0||' "/etc/rc.local" ; echo iptables-restore \< /etc/iptables.conf | sudo tee -a /etc/rc.local ; echo ' ' | sudo tee -a /etc/rc.local ; echo \echo 1 \> /proc/sys/net/ipv4/tcp_syncookies | sudo tee -a /etc/rc.local ; echo ' ' | sudo tee -a /etc/rc.local ; echo exit 0 | sudo tee -a /etc/rc.local

O supercomando acima irá ativar e "fortalecer" o firewall do sistema, e ainda ativará o recurso de proteção "TCP SYN cookies" automaticamente, a cada inicialização do Linux. Isso porque o supercomando acima faz com que o netfilter por padrão ignore (DROP) os pedidos de entrada (INPUT) e de encaminhamento (FORWARD), sendo isso o que "fecha" as portas do seu sistema contra ataques. Além disso, o supercomando acima fará com que a cada login o código armazenado no arquivo tcp_syncookies (localizado em /proc/sys/net/ipv4/) seja alterado de 0 para 1. 

Muito bom, testei alterar o parâmetro tcp_syncookies com o UFW habilitado e funcionou, o que é um enorme avanço.

Alterando manualmente o arquivo o acesso BB funciona, notado que precisa ser root mesmo (sudo su), pois se "estranha" se quiser fazer usando o sudo.

A cada vez que reinicia a alteração se perde, então é o caso de torná-la permanente mesmo (ou não? ainda não me convenci disso).

Precisa ainda de alguns pequenos ajustes, não cheguei ainda a usar o "supercomando tcp_syncookies" proposto porque o arquivo **rc.local não existe no Ubuntu 16.10 e seguintes**, então não se aplicaria a essa situação.

[Sampayu]

Muito bom, testei alterar o parâmetro tcp_syncookies com o UFW habilitado e funcionou, o que é um enorme avanço.

Alterando manualmente o arquivo o acesso BB funciona, notado que precisa ser root mesmo (sudo su), pois se "estranha" se quiser fazer usando o sudo.

A cada vez que reinicia a alteração se perde, então é o caso de torná-la permanente mesmo (ou não? ainda não me convenci disso).

Precisa ainda de alguns pequenos ajustes, não cheguei ainda a usar o "supercomando tcp_syncookies" proposto porque o arquivo **rc.local não existe no Ubuntu 16.10 e seguintes**, então não se aplicaria a essa situação.

Para alterar o conteúdo do arquivo tcp_syncookies pode-se combinar os comandos sudo e tee, assim:

- Gravar 0 dentro do arquivo:

Código Selecionar Expandir

echo 0 |sudo tee /proc/sys/net/ipv4/tcp_syncookies
- Gravar 1 dentro do arquivo:

Código Selecionar Expandir

echo 1 |sudo tee /proc/sys/net/ipv4/tcp_syncookies

Quando o sistema é reiniciado, ele realmente perde a configuração. Eu testei e de fato o arquivo retorna para o padrão, que é zero. O valor só fica fixo se durante cada inicialização do sistema o valor do arquivo tcp_syncookies for alterado do padrão 0 para o valor 1.

Estou usando o XUbuntu 16.04. Não sabia que a partir da versão 16.10 o arquivo rc.local está ausente. Uma alternativa que conheço consiste em alterar diretamente a configuração do sysctl. O sysctl é um pequeno programa que envia parâmetros para o kernel em tempo de execução, ou seja, envia parâmetros para o kernel durante a execução do kernel. Como já deletei o LUbuntu 16.10 que estava na minha Virtual Box, vou instalar o XUbuntu 16.10 na Virtual Box e ver se o arquivo de configuração do systcl continua presente na versão 16.10. Caso esteja, publico aqui o método alternativo. De repente ele passa a ser o padrão, já que na versão 16.04 e anteriores esse arquivo de configuração também existe.

[gr9942]

Parece que a partir do Ubuntu 16.10, é usado o systemd na inicialização, e o rc.local é considerado um serviço, que por sinal é desligado por padrão.
Há maneiras de reativar o rc.local, um exemplo pode ser visto aqui:
http://www.cb-net.co.uk/2017/02/

Eu uso o 16.04, então não foi possível testar esse procedimento.
Espero ter ajudado de alguma forma.

Abraços.

[druidaobelix]

Estou usando o XUbuntu 16.04. Não sabia que a partir da versão 16.10 o arquivo rc.local está ausente. Uma alternativa que conheço consiste em alterar diretamente a configuração do sysctl. O sysctl é um pequeno programa que envia parâmetros para o kernel em tempo de execução, ou seja, envia parâmetros para o kernel durante a execução do kernel. Como já deletei o LUbuntu 16.10 que estava na minha Virtual Box, vou instalar o XUbuntu 16.10 na Virtual Box e ver se o arquivo de configuração do systcl continua presente na versão 16.10. Caso esteja, publico aqui o método alternativo. De repente ele passa a ser o padrão, já que na versão 16.04 e anteriores esse arquivo de configuração também existe.

Já havia usado aqui o sysctl no Ubuntu 16.10, que de fato é a ferramenta adequada para alterar parâmetros do kernel em runtime, funciona sem problemas, creio que seja melhor e mais simples ir por aí, apenas não tive tempo ainda de testar no Ubuntu padrão 16.04

Essencialmente é isso:

Código Selecionar Expandir

sudo sysctl -w net.ipv4.tcp_syncookies=1

Na verdade deveria ser possível configurar a partir do /etc/sysctl.conf, mas numa vista assim superficial não está funcionando (vi apenas num live-iso do 16.10), não deu certo, porém não tive tempo suficiente para aprofundar essa análise.

[druidaobelix]

Se quiser aprofundar um pouco a análise nesse tema, esse link que é mencionado no próprio /etc/sysctl.conf é muito bom:

Improving syncookies

https://lwn.net/Articles/277146/

Deriva daí a minha dificuldade momentânea em aceitar com adequado deixar o parâmetro permanentemente ligado em 1.

"Syncookies are discouraged these days. They disable too many valuable TCP features (window scaling, SACK) and even without them the kernel is usually strong enough to defend against syn floods and systems have much more memory than they used to be. So I don't think it makes much sense to add more code to it, sorry. "

Supondo o caso mais simples que é o uso do UFW, usado pela grande maioria dos usuários, sem ir diretamente no iptables, que no fundo só se justifica no caso de um servidor e não de um simples computador de um usuário comum, o fato é que o padrão Ubuntu é esse:

IFW desligado --> tcp_syncookies ligado em 1

IFW ligado    --> tcp_syncookies desligado em 0

O que estamos fazendo aqui é um workaround, um quebra galho, uma ajeitada, porque a anomalia é o warsaw (ou muito possivelmente o server do BB) estar sendo identificado como TCP SYN flood attacks, há um erro de origem nisso que precisa ser corrigido seja pelo Banco do Brasil ou pela Gas Tecnologia, mas enfim, não é algo que esteja imediatamente ao nosso alcance, restando-nos apenas informá-los disso e cobrar providências de solução real.

Isso posto, voltamos ao ponto, se não quero desfigurar minha instalação Ubuntu do que é o padrão dela (e que supostamente funciona melhor), deveria estar usando essa alteração de parâmetro apenas e tão somente para o acesso BB, retornando ao normal após o uso, daí que, no momento, estou inclinado apenas a esse uso, sem tornar permamente a alteração.

Em linhas gerais, como visão pessoal momentânea sujeita à críticas, creio existir o seguinte quadro, sempre considerado para um usuário comum (não server, não situações especiais):

1) Roteador externo com firewall ativado

Quem usa roteador externo com firewall devidamente ativado e o roteador regularmente configurado (login próprio+senha forte) simplesmente não precisa se preocupar com isso, deixe o IFW desativado, a chance de algum problema é o mínimo dos mínimos dos mínimoruns.

2) Usando IFW sem firewall externo de roteador/modem

Quando for usar o BB desbloqueie antes o tcp_syncookies fazendo:

sudo sysctl -w net.ipv4.tcp_syncookies=1

Após o uso do acesso BB retorne à situação anterior fazendo:

sudo sysctl -w net.ipv4.tcp_syncookies=0

Claro que se pode optar por tornar permanente a alteração no tcp_syncookies, também não parece existir um grande problema nisso numa instalação comum (não server) mas nesse caso deverá haver a consciência que se está operando fora do padrão regular do Ubuntu.