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

[druidaobelix]

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.

Muito bom link, de novo ajudou bastante, grato. 

Permite usar a estrutura normal do rc.local para executar o sysctl, mesmo no Ubuntu 16.10 ou superior

Nada obstante, se bem entendi, o Ubuntu 16.10 já vem municiado com o rc.local.service em:

/lib/systemd/system/rc.local.service

uma das cláusulas é essa:

[Unit]
Description=/etc/rc.local Compatibility
ConditionFileIsExecutable=/etc/rc.local
After=network.target

Suponho que a simples criação do arquivo /etc/rc.local tornando-o executável, como script que sempre foi, deveria funcionar.
Vou testar aqui pra ver o que dá.

[druidaobelix]

Confirmado, no Ubuntu 16.10 basta criar um /etc/rc.local como script executável idêntico ao que sempre foi que irá executar.

Torna a alteração permanente colocar nesse arquivo o parâmetro do kernel:

Código: [Selecionar]

/sbin/sysctl -w net.ipv4.tcp_syncookies=1
No teste usei dessa forma, informando o caminho completo, mas o fato é que funciona tornando a alteração permamente para quem queira mesmo deixá-la permanente.

[Sampayu]

Confirmado, no Ubuntu 16.10 basta criar um /etc/rc.local como script executável idêntico ao que sempre foi que irá executar.

Torna a alteração permanente colocar nesse arquivo o parâmetro do kernel:

Código: [Selecionar]

/sbin/sysctl -w net.ipv4.tcp_syncookies=1
No teste usei dessa forma, informando o caminho completo, mas o fato é que funciona tornando a alteração permamente para quem queira mesmo deixá-la permanente.

Agora estou com o XUbuntu 16.10 rodando numa máquina virtual. Editar o arquivo /etc/sysctl.conf funcionou no XUbuntu 16.10, mas não no 16.04: no 16.04 continua mesmo sendo necessário editar o arquivo rc.local

O comando sudo sysctl -w net.ipv4.tcp_syncookies=1 também não funcionou, no 16.10 (nem testei no 16.04, já que alterar o estado via sysctl não está surtindo efeito no comportamento do kernel, no caso do sistema versão 16.04). Mas se no 16.10 o usuário executar:

Código: [Selecionar]

sudo sed -i -e 's|#net.ipv4.tcp_syncookies|net.ipv4.tcp_syncookies|' "/etc/sysctl.conf" ; sudo sysctl -p
...funciona.

[druidaobelix]

Na verdade há um equívoco de raciocínio quando eu disse que deveria dar para configurar através do /etc/sysctl.conf, evidentemente que não dá e não poderia dar mesmo.

Se o parâmetro é do kernel, como de fato é, só se pode alterá-lo em runtime, que é uma alteração na memória ram do sistema, não no disco, pois aí a única forma de fazer é recompilando o kernel.

Parece evidente, mas na hora que fiz a afirmação não atinei com o raciocínio. 

[Sampayu]

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. "

Eu também dei uma pesquisada nos "sites gringos", em busca de opiniões a respeito da ativação ou não desse recurso, mas o que encontrei foram opiniões divergentes e muita controvérsia.

• De um lado, há os que defendem que a ativação desse recurso é boa, porque:

• Demanda pouco processamento (se comparado ao avanço dos processadores).
• Reduz o tempo de resposta (latência) dos sinais de rede SYN.
• Adiciona uma camada extra de proteção contra ataques.
• É ativado somente após o ataque iniciar e ocorrer um princípio de sobrecarga do serviço (vide o comentário no arquivo /etc/sysctl.d/10-network-security.conf).
• Desestimula novas tentativas de ataque (reincidência).

• De outro lado, há os que defendem que a ativação desse recurso é ruim, porque:

• Eleva a carga de trabalho do processador.
• Desabilita alguns recursos do protocolo TCP.
• Atualmente há um conjunto de novos recursos que possibilitam ao kernel defender-se muito bem de ataques, mesmo com o recurso contra "SYN Flood" desativado.
• O foco de ataques "SYN Flood" são servidores: é muitíssimo baixa a possibilidade de um computador doméstico vir a ser alvo de um ataque desses.
• A proteção contra "SYN Flood" não evita, por completo, que o ataque ocorra: apenas atenua seus efeitos.

No fim das contas, encontrei muito debate, mas nada conclusivo. Lá em https://lwn.net/Articles/277146/ mesmo há dois relatos mencionando que, na prática, observaram uma pequena elevação de processamento (de 60% para 70%) no computador, porém também observaram um ganho de desempenho, em termos de tempo de resposta dos sinais de rede (caiu de 1,5 segundos para algo entre 12 e 15 milissegundos). Ainda de acordo com o website, o resultado prático dos testes realizados atestou que esse recurso de proteção ainda tem seu valor, sendo essa a razão por que o suporte a esse recurso em IPv6 também está sendo desenvolvido.

Enfim: ao que me parece, a ativação do recurso contra "SYN Flood" no protocolo TCP pode ou ser "boa" ou ser "ruim", a depender do contexto. E o contexto engloba uma série de variáveis, como p.ex. qual é a capacidade de desempenho do hardware, qual é a finalidade de uso do computador, se o computador é doméstico ou um servidor, se há alguma particularidade que justifica o uso desse recurso etc.

Como meu computador possui capacidade de processamento suficiente para que a ativação desse recurso não seja perceptível (eu não observei perda nenhuma de desempenho) e eu preciso acessar minha conta corrente via computador, no meu contexto estou preferindo ativar o recurso de proteção. Como quem acessa este tópico provavelmente está no mesmo cenário que eu, ou pelo menos em um cenário bem parecido, acredito que o que propus lá no meu outro comentário será considerado uma solução "adequada" por uma parcela bastante considerável dos leitores. Espero que sim (porque deu trabalho pensar nos comandos e testá-los nos XUbuntu 16.04 e 16.10, rs  ).

...mas eu concordo que o Warsaw deveria estar melhor implementado mesmo, de modo a não "disparar" o bloqueio "antiflood" do firewall. O bloqueio por firewall só não ocorre quando o recurso contra ataque "SYN Flood" é ativado, justamente porque em tal caso o suposto "flood" acaba não ocorrendo. Se o Warsaw fosse melhor escrito, ele não daria "conflito" com o firewall do Linux, e daí o workaround apresentado aqui não seria necessário.

[druidaobelix]

Testei também no Ubuntu 16.04 padrão (=Unity), em versão 32-bit e 64-bit, com o IFW ativado, a solução de simplesmente acrescentar a linha no rc.local e igualmente ao Ubuntu 16.10 padrão, funcionou sem problemas.

Código: [Selecionar]

/sbin/sysctl -w net.ipv4.tcp_syncookies=1
Assim sendo, não há diferença de funcionamento entre o Ubuntu 16.04 e o 16.10,  padrão Unity, exceto que no caso desse último o arquivo /etc/rc.local é previamente inexistente e precisa ser criado, o que pode ser feito como uma cópia exata do que sempre foi.

Acho que, por enquanto, isso esgota o assunto no que diz respeito ao Ubuntu padrão propriamente dito (=Unity), restando verificar nos demais "sabores" (Kubuntu, Lubuntu, Ubuntu-Gnome, Ubuntu-Mate) , exceto o Xubuntu, também já testado, se o comportamento é realmente o mesmo.

[Sampayu]

Testei também no Ubuntu 16.04 padrão (=Unity), em versão 32-bit e 64-bit, com o IFW ativado, a solução de simplesmente acrescentar a linha no rc.local e igualmente ao Ubuntu 16.10 padrão, funcionou sem problemas.

Código: [Selecionar]

/sbin/sysctl -w net.ipv4.tcp_syncookies=1
Assim sendo, não há diferença de funcionamento entre o Ubuntu 16.04 e o 16.10,  padrão Unity, exceto que no caso desse último o arquivo /etc/rc.local é previamente inexistente e precisa ser criado, o que pode ser feito como uma cópia exata do que sempre foi.

Acho que, por enquanto, isso esgota o assunto no que diz respeito ao Ubuntu padrão propriamente dito (=Unity), restando verificar nos demais "sabores" (Kubuntu, Lubuntu, Ubuntu-Gnome, Ubuntu-Mate) , exceto o Xubuntu, também já testado, se o comportamento é realmente o mesmo.

Está ocorrendo algum "tilt" com o sysctl do XUbuntu 16.10: o comando sudo sysctl -w net.ipv4.tcp_syncookies=1 surte efeito, quando é executado, mas está sem persistência. Digo: após o reboot do sistema o valor volta a ser zero, ao invés de 1. Experimentei remover o sinal # do parâmetro net.ipv4.tcp_syncookies=1 presente nos arquivos /etc/sysctl.conf e /etc/sysctl.d/10-network-security.conf, mas não adianta: após reiniciar o sistema, o valor armazenado em /proc/sys/net/ipv4/tcp_syncookies continua sendo zero.

O jeito foi modificar o supercomando que publiquei lá no comentário para os que estiverem usando o *Ubuntu versão 16.10 ou posterior. Deste modo, o supercomando¹ criará o arquivo /etc/rc.local e executará o systemctl, para que o serviço rc-local seja reiniciado.

Infelizmente, só assim consegui obter persistência. Há algum problema com o sysctl ou com o systemd. Vi em alguns sites que, aparentemente, os dados de sysctl.conf estão sendo inicializados muito cedo (antes de os módulos dos serviços de rede serem ativados), daí o que a gente configura para o sysctl acaba não sendo executado. 

Mas é como você comentou mesmo: basta criar uma versão do /etc/rc.local no *Ubuntu 16.10. Ainda bem que essa opção está funcionando.² 

¹ Supercomando = comando composto por vários comandos.
² No Ubuntu 16.10 e XUbuntu 16.10. Nos outros "sabores" eu também não testei.

[druidaobelix]

Está ocorrendo algum "tilt" com o sysctl do XUbuntu 16.10: o comando sudo sysctl -w net.ipv4.tcp_syncookies=1 surte efeito, quando é executado, mas está sem persistência. Digo: após o reboot do sistema o valor volta a ser zero, ao invés de 1. [...]

Então, prezado "Sampayu",

Creio que não consegui ser suficientemente claro ao tentar explicar o que acho seja, sorry.

Esse comando (sysctl -w net.ipv4.tcp_syncookies=1 ) não vai armazenar **nunca**, sempre que reiniciar ele voltará a zero.
Essa informação está na compilação do kernel, se quiser deixar definitiva mesmo, só se compilar novamente o kernel.

Aquele parâmetro -p que usou em sysctl faz apenas um reload usando o /etc/sysctl como entrada, mas veja que tudo isso é apenas em runtime, apenas memória ram, deu reboot volta a prevalecer o que está no kernel.

Assim sendo, tem que setar o que quer a cada boot, logo, precisa executar em algum script realizado no boot, do qual o rc.local o é por excelência.

Nota:

Use

sysctl -a

para ver uma relação completa do que há no kernel

[Sampayu]

Está ocorrendo algum "tilt" com o sysctl do XUbuntu 16.10: o comando sudo sysctl -w net.ipv4.tcp_syncookies=1 surte efeito, quando é executado, mas está sem persistência. Digo: após o reboot do sistema o valor volta a ser zero, ao invés de 1. [...]

Então, prezado "Sampayu",

Creio que não consegui ser suficientemente claro ao tentar explicar o que acho seja, sorry.

Esse comando (sysctl -w net.ipv4.tcp_syncookies=1 ) não vai armazenar **nunca**, sempre que reiniciar ele voltará a zero.
Essa informação está na compilação do kernel, se quiser deixar definitiva mesmo, só se compilar novamente o kernel.

Aquele parâmetro -p que usou em sysctl faz apenas um reload usando o /etc/sysctl como entrada, mas veja que tudo isso é apenas em runtime, apenas memória ram, deu reboot volta a prevalecer o que está no kernel.

Assim sendo, tem que setar o que quer a cada boot, logo, precisa executar em algum script realizado no boot, do qual o rc.local o é por excelência.

Nota:

Use

sysctl -a

para ver uma relação completa do que há no kernel

Acho que eu é que andei "viajando na maionese" mesmo, rs: embora eu saiba que as alterações executadas pelo sysctl vigorem somente em tempo de execução, eu imaginei que o argumento -w enviado ao sysctl fazia com que essas alterações fossem armazenadas em algum arquivo de configuração externo (como por exemplo /etc/sysctl.conf), e que esse arquivo de configuração seria automaticamente inicializado a cada novo boot, graças a algum script ou daemon executado durante o boot.

Somente após perceber que isso não estava ocorrendo foi que resolvi recorrer novamente ao rc.local

[Sampayu]

Descobri qual é o problema com o *Ubuntu 16.10, que estava fazendo com que fosse obrigatório criar o arquivo /etc/rc.local: após a ativação do firewall UFW, o daemon do UFW passa a inicializar o script /etc/ufw/sysctl.conf a cada boot do Linux, e nesse arquivo de configuração há o parâmetro net/ipv4/tcp_syncookies com o argumento 0 (zero). Bastou eu alterar esse código para net/ipv4/tcp_syncookies=1 e reiniciar o daemon do UFW que a cada nova inicialização do Linux o conteúdo de /proc/sys/net/ipv4/tcp_syncookies agora é sempre 1. 

Vou ajustar lá os dois "supercomandos" que publiquei (tanto o para *Ubuntu 16.04 e anteriores quanto o para *Ubuntu 16.10 e posteriores), já que essa descoberta simplifica bastante as coisas: deixa de ser necessário criar o arquivo /etc/rc.local, tampouco editar um /etc/rc.local que já exista, tendo em vista que o daemon do UFW já ativará a proteção contra "SYN flood" a cada inicialização do Linux. 

EDIT: testei no XUbuntu 16.04 e também deu certo, portanto não é mais necessário haver dois "supercomandos" diferentes (um para os *Ubuntu versão 16.10 e posteriores, outro para os *Ubuntu versão 16.04 e anteriores). O daemon do UFW simplificou bastante as coisas e universalizou a solução. 

[druidaobelix]

Descobri qual é o problema com o *Ubuntu 16.10, que estava fazendo com que fosse obrigatório criar o arquivo /etc/rc.local: após a ativação do firewall UFW, [...]

Excelente, nada como a persistência na solução de um problema. 

Na verdade, embora se busque a praticidade e isso também seja bom, tudo isso não deixa de ser apenas o "enfeite do bolo", o acabamento final da obra, pois como já se disse, "todos os caminhos levam a Roma", porque o que é realmente importante foi você ter descoberto que a questão estava relacionada ao firewall e o colega "gr9942" brilhantamente ter apontado a solução indicando o parâmetro do arquivo tcp_syncookies, esses dois pontos, isto sim, são a essência da questão.

De toda forma, parabéns aos dois pela muito relevante contribuição ao tema. 

[Sampayu]

Descobri qual é o problema com o *Ubuntu 16.10, que estava fazendo com que fosse obrigatório criar o arquivo /etc/rc.local: após a ativação do firewall UFW, [...]

Excelente, nada como a persistência na solução de um problema. 

Na verdade, embora se busque a praticidade e isso também seja bom, tudo isso não deixa de ser apenas o "enfeite do bolo", o acabamento final da obra, pois como já se disse, "todos os caminhos levam a Roma", porque o que é realmente importante foi você ter descoberto que a questão estava relacionada ao firewall e o colega "gr9942" brilhantamente ter apontado a solução indicando o parâmetro do arquivo tcp_syncookies, esses dois pontos, isto sim, são a essência da questão.

De toda forma, parabéns aos dois pela muito relevante contribuição ao tema. 

Obrigado. 

[gwarah]

Olá pesso@l,

instalei o hdd do bb mas na verificação gerou esse resultado:

1) Na console:

Código: [Selecionar]

luis@jupiter:~$ hda_bb &
[1] 18039
luis@jupiter:~$ /usr/bin/hda_bb: linha 380: /tmp/HDA.tmp: Arquivo ou diretório não encontrado
Ubuntu
Ubuntu

DIAG_SUB_GUI_ROOT: false
Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.
Ubuntu
Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.


/usr/bin/hda_bb: linha 1245: 18045 Terminado               yad --form --undecorated --title="Segurança BB" --no-buttons --geometry="+0+0" --columns="5" --field=" ":LBL ' ' --field="!$LOCAL/IMG/MAIN/Install.png! Instalar!":BTN "bash -c 'ROOT_LOGIN true MAIN INST'" --field="      Instalar":LBL ' ' --field=" ":LBL ' ' --field="!$LOCAL/IMG/MAIN/Remove.png! Remover!":BTN "bash -c 'ROOT_LOGIN true MAIN REMO'" --field="    Remover":LBL ' ' --field=" ":LBL ' ' --field="!$LOCAL/IMG/MAIN/Diagnostico.png! Diagnostico!":BTN "bash -c 'ROOT_LOGIN true MAIN DIAG'" --field="  Diagnostico":LBL ' ' --field=" ":LBL ' ' --field="!$LOCAL/IMG/MAIN/Ajuda.png! Ajuda!":BTN "bash -c AJUDA_GUI" --field="        Ajuda":LBL ' ' --field="!$LOCAL/IMG/MAIN/$un_lock! Desbloquear!":BTN "bash -c 'ROOT_LOGIN true MAIN'" --field="!$LOCAL/IMG/MAIN/Exit.png! Sair!":BTN "bash -c 'SAIR_GUI Main'" --field="          Sair":LBL ' '
DIAGNOSTICO_GUI: false

Ubuntu
Ubuntu
Ubuntu
Ubuntu
Ubuntu
DIAG_SUB_GUI_ROOT: true
Connection closed by foreign host.
stat: impossível obter estado de '/usr/local/lib/warsaw/ld-linux-x86-64.so.2': Arquivo ou diretório não encontrado
stat: impossível obter estado de '/usr/local/lib/warsaw/ld-linux.so.2': Arquivo ou diretório não encontrado
Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.
Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.
Ubuntu
Ubuntu
Ubuntu
Connection closed by foreign host.
stat: impossível obter estado de '/usr/local/lib/warsaw/ld-linux-x86-64.so.2': Arquivo ou diretório não encontrado
stat: impossível obter estado de '/usr/local/lib/warsaw/ld-linux.so.2': Arquivo ou diretório não encontrado

Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.

1

2) Resultado da verificação:



Faltava permissão nas pastas mas mesmo depois de permissionados, nada acontecia. Pelas  mensagens acho que está faltando alguma coisa no warsaw. Mas funcionava antes da instalação do hda_bb.


Uma outra coisa que percebi quando tentei ver o estado do warsaw:

Código: [Selecionar]

● warsaw.service - LSB: Handle Warsaw
   Loaded: loaded (/etc/init.d/warsaw; bad; vendor preset: enabled)
   Active: active (running) since Dom 2017-03-26 15:38:33 BRT; 3min 22s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 1129 ExecStart=/etc/init.d/warsaw start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/warsaw.service
           └─1291 /usr/local/bin/warsaw/core

Mar 26 15:38:33 jupiter systemd[1]: Starting LSB: Handle Warsaw...
Mar 26 15:38:33 jupiter warsaw[1129]: Starting core
Mar 26 15:38:33 jupiter systemd[1]: Started LSB: Handle Warsaw.

Na  status do  mpinho aparece:

Código: [Selecionar]

Loaded: loaded (/etc/init.d/warsaw; generated; vendor preset: enabled)
generated ao invés de bad. Tentei reinstalar o warsaw mas não tive sucesso

[druidaobelix]

[...] Faltava permissão nas pastas mas mesmo depois de permissionados, nada acontecia. Pelas  mensagens acho que está faltando alguma coisa no warsaw. Mas funcionava antes da instalação do hda_bb.[...]
Tentei reinstalar o warsaw mas não tive sucesso

Então, "gwarah",

1) Qual é a versão do Ubuntu que está usando?

Código: [Selecionar]

lsb_release -rd
2) Qual o "sabor"?
É o Ubuntu padrão (=Unity) ou outro?

3) O tópico tem bastante informação de como fazer isso funcionar.

Em princípio use o script que está no post #12, item 5, ele desinstala e instala tudo de novo, geralmente dará certo e é bastante fácil e prático de fazer.

Depois atente para a circunstância de ter um não firewall ativado, notoriamente o IFW que é o firewall padrão do Ubuntu.

Código: [Selecionar]

sudo ufw status verbose
Se estiver desativado, tudo bem, sem problemas, entretanto, caso esteja habilitado e normalmente você use o firewall (mesmo que seja o iptables), então use esse comando:

sudo /sbin/sysctl -w net.ipv4.tcp_syncookies=1

E então veja se consegue o acesso.

Caso consiga, torne a modificação permamente usando o comando proposto no post #33 deste tópico.

[Sampayu]

Olá pesso@l,

instalei o hdd do bb mas na verificação gerou esse resultado:

Se o problema persistir, que tal limpar e desinstalar tudo? Depois é só instalar o Warsaw (apenas o Warsaw: o programa HDA_BB é desnecessário) e configurar o firewall, conforme explicado anteriormente.

Como fazer a remoção completa do Warsaw e do HDA_BB, desinstalar e "resetar" o firewall, reinstalar o Warsaw e o firewall, ativar o firewall fechando as portas de rede do seu computador (segurança) mas conceder acesso ao socket (websocket) de que o Warsaw necessita - tudo via terminal do shell

1. Execute o comando abaixo, para remover completamente o programa HDA_BB:

Código: [Selecionar]

sudo apt-get purge hda-bb -y
2. MANTENHA TODOS OS NAVEGADORES FECHADOS e então desinstale o Warsaw:¹

Código: [Selecionar]

sudo killall opera firefox chrome ; sudo apt-get purge warsaw -y ; sudo /usr/bin/warsaw_uninstall
3. Execute este supercomando para desinstalar o firewall (G)UFW e "resetar" o netfilter (firewall que fica "embutido" no kernel do Linux):¹

Código: [Selecionar]

sudo apt-get purge ufw gufw -y ; sudo iptables -F ; sudo iptables -X ; sudo iptables -P INPUT ACCEPT ; sudo iptables -P FORWARD ACCEPT ; sudo iptables -P OUTPUT ACCEPT ; sudo rm -r /etc/ufw
4. Execute este supercomando para desativar o arquivo rc.local e atualizar o sysctl:¹

Código: [Selecionar]

sudo mv /etc/rc.local /etc/rc.local.bak ; sudo sed -i -e 's|net.ipv4.tcp_syncookies=1|#net.ipv4.tcp_syncookies=1|' "/etc/sysctl.conf" ; sudo sed -i -e 's|net.ipv4.tcp_syncookies=1|#net.ipv4.tcp_syncookies=1|' "/etc/sysctl.d/10-network-security.conf" ; sudo sysctl -w net.ipv4.tcp_syncookies=0
5. Reinicie o computador:

Código: [Selecionar]

sudo telinit 6
6. Após o computador reiniciar, MANTENHA TODOS OS NAVEGADORES FECHADOS e então execute este supercomando para manualmente instalar o Warsaw via shell script (script do shell):

Código: [Selecionar]

sudo killall opera firefox chrome ; wget https://cloud.gastecnologia.com.br/bb/downloads/ws/warsaw_`getconf LONG_BIT`_installer.run -O /tmp/instalar.warsaw ; sudo chmod +x /tmp/instalar.warsaw ; sudo /tmp/instalar.warsaw
7. Quando a instalação terminar, reinicie novamente o computador:

Código: [Selecionar]

sudo telinit 6
8. Após o computador reiniciar, execute este supercomando para reinstalar o firewall (G)UFW, ativar a proteção contra ataques do tipo "SYN Flood" e então ativar o daemon (serviço) do (G)UFW:

Código: [Selecionar]

sudo apt-get install ufw gufw --reinstall -y ; sudo sed -i -e 's|syncookies=0|syncookies=1|' "/etc/ufw/sysctl.conf" ; sudo ufw enable
9. Acesse https://www2.bancobrasil.com.br/aapf/login.jsp para testar se o módulo está funcionando e sendo detectado. Caso o módulo não seja detectado, reinicie o computador e acesse https://www2.bancobrasil.com.br/aapf/login.jsp novamente. SE (E SOMENTE SE) o problema persistir, execute o supercomando abaixo e, após o computador reiniciar, tente novamente acessar https://www2.bancobrasil.com.br/aapf/login.jsp:

Código: [Selecionar]

sudo apt-get install libcurl4-openssl-dev libnss3-dev libdbus-1-dev yad libatk1.0-0 libc6 libcairo2 libcups2 libdbus-1-3 libexpat1 libfontconfig1 libfreetype6 libgcc1 libgconf-2-4 libgdk-pixbuf2.0-0 libglib2.0-0 libgtk2.0-0 libnspr4 libnspr4-0d libnss3 libpango-1.0-0 libpangocairo-1.0-0 libstdc++6 --reinstall -y ; sudo telinit 6
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.

10. Se mesmo após isso o Warsaw do seu sistema Linux continuar não sendo detectado e/ou executado na página do Banco do Brasil, execute este supercomando:

Código: [Selecionar]

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
...e, após o computador reiniciar, tente novamente acessar sua conta, no website do Banco do Brasil. Ainda não deu certo? Então...

11. MANTENHA TODOS OS NAVEGADORES FECHADOS e execute este supercomando para limpar os caches dos navegadores e (re)instalar os navegadores Google Chrome e Opera Browser:

Código: [Selecionar]

sudo killall opera firefox chrome ; sudo apt-get install gdebi --reinstall -y ; rm -r ~/.cache/google-chrome ~/.cache/opera ~/.cache/mozilla/firefox ; if [ `getconf LONG_BIT` == 64 ]; then wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb -O /tmp/chrome.deb ; sudo gdebi -n /tmp/chrome.deb ; fi; if [ `getconf LONG_BIT` == 64 ]; then wget http://ftp.opera.com/pub/opera/desktop/44.0.2510.1218/linux/opera-stable_44.0.2510.1218_amd64.deb -O /tmp/opera.deb; else wget http://ftp.opera.com/pub/opera/desktop/44.0.2510.1218/linux/opera-stable_44.0.2510.1218_i386.deb -O /tmp/opera.deb; fi ; sudo gdebi -n /tmp/opera.deb ; sudo apt-get update ; sudo apt-get check ; sudo apt-get dist-upgrade -y ; sudo apt-get autoremove -y ; sudo apt-get clean ; sudo telinit 6
COMANDO ALTERNATIVO

Caso queira desinstalar completamente um (ou mais de um) dos seus navegadores, este post explica como fazer isso com os navegadores Mozilla Firefox, Google Chrome e Opera Browser. O post também explica como reinstalar tais navegadores.

12. Após o computador reiniciar, execute o comando abaixo para abrir os navegadores Google Chrome² e Opera Browser na página de teste do módulo Warsaw (você também pode tentar usar o Mozilla Firefox³ para acessar sua conta):

Código: [Selecionar]

google-chrome https://www2.bancobrasil.com.br/aapf/login.jsp & opera https://www2.bancobrasil.com.br/aapf/login.jsp
IMPORTANTE: a página do Banco do Brasil requer o plugin Adobe Flash, para poder detectar e executar o Warsaw durante seu acesso à conta bancária, o que é feito por intermédio deste applet: https://www2.bancobrasil.com.br/aapf/includes/js/warsaw-websocket.swf que o Opera e o Chrome atualmente bloqueiam (e daí você vê aquela mensagem informando que o módulo de segurança não está instalado ou não foi detectado, embora ele esteja instalado). Caso você não possua o Flash instalado em seu sistema, instale-o com este comando, no terminal do shell:

Código: [Selecionar]

sudo apt-get install adobe-flashplugin -yCaso o comando acima não funcione, experimente executar este outro:

Código: [Selecionar]

sudo apt-get install flashplugin-installer -yApós isso, não deixe de ler as Notas de Rodapé para verificar como se ativa o plugin Flash nos navegadores. Cada navegador possui um método próprio de ativação do plugin Flash. A tendência é os navegadores dificultarem cada vez mais a vida do usuário, tornarão cada vez mais difícil conseguir fazer com que o navegador execute conteúdo Flash em websites, mas infelizmente os bancos retrógrados continuam insistindo em usar Flash nas suas páginas de acesso à conta bancária, e aí surge (mais) esse problema.

13. Se após isso o módulo for detectado mas você não conseguir efetuar login, pode ser que o certificado de segurança do Warsaw não tenha sido adicionado aos navegadores Chrome e Opera. Neste caso, execute este supercomando (ele fechará todos os navegadores, reinstalará o Warsaw e reiniciará o computador):

Código: [Selecionar]

sudo killall opera firefox chrome ; wget https://cloud.gastecnologia.com.br/bb/downloads/ws/warsaw_`getconf LONG_BIT`_installer.run -O /tmp/instalar.warsaw ; sleep 10 ; sudo chmod +x /tmp/instalar.warsaw ; sleep 10 ; sudo /tmp/instalar.warsaw ; sleep 10 ; sudo telinit 6
...e, após seu computador reiniciar, execute novamente o comando do item 12, para confirmar que o Google Chrome e o Opera Browser estão funcionando com o módulo Warsaw.

IMPORTANTE: caso você acesse as preferências/configurações do seu navegador, vá até a seção de certificados, acesse o item Autoridades e não encontre o certificado Warsaw Personal CA (que é o nome do certificado do Warsaw para navegadores web), leia este post para saber como instalar esse certificado manualmente.

14. Caso o Warsaw continue não funcionando e/ou então você esteja utilizando uma versão do *Ubuntu posterior à 16.04 (ou seja: 16.10, 17.04, 17.10 etc.) e o Warsaw continue não funcionando, execute este supercomando:

Código: [Selecionar]

sudo killall opera firefox chrome ; sudo /usr/bin/warsaw_uninstall ; sudo update-rc.d -f warsaw remove ; sudo rm /etc/init.d/warsaw /etc/xdg/autostart/warsaw.desktop /usr/bin/warsaw_uninstall ; sudo rm -r /usr/local/bin/warsaw /usr/local/etc/warsaw /usr/local/lib/warsaw /usr/share/doc/warsaw ; wget https://cloud.gastecnologia.com.br/bb/downloads/ws/linux/diagbb-1.0.`getconf LONG_BIT`.run -O /tmp/instalar.warsaw ; sleep 10 ; sudo chmod +x /tmp/instalar.warsaw ; sleep 10 ; sudo /tmp/instalar.warsaw ; sleep 10 ; sudo telinit 6
...e teste novamente o funcionamento do Warsaw, após o sistema reiniciar.

Resumo de tudo o que foi explicado neste post: para que o Warsaw funcione na página do Banco do Brasil, é necessário [1] instalar o Warsaw (isso já instala o certificado do Warsaw para os navegadores, e se por acaso não instalar siga as dicas publicadas aqui para instalar manualmente o certificado), [2] instalar o firewall com as portas TCP 30800 e 30900 desbloqueadas, [3] ativar a proteção do sistema contra ataques SYN Flood (em algumas versões do *Ubuntu essa proteção já pode estar ativada por padrão, mas o tutorial ativa a do firewall só por garantia), [4] instalar o plugin Adobe Flash no sistema e [5] configurar cada um dos seus navegadores para não impedir a execução do plugin Flash na página do banco.

NÃO DEIXE DE LER AS NOTAS DE RODAPÉ! ELAS CONTÊM INFORMAÇÕES COMPLEMENTARES IMPORTANTES!

Notas de rodapé:
¹ Ignore as mensagens de erro que eventualmente forem exibidas.
² Se após executar todos os procedimentos acima o Google Chrome não estiver funcionando com o Warsaw no website do BB, é bem provável que seja porque o Google Chrome está forçando o uso de HTML5 no website do banco, embora o Warsaw requeira Flash. Para resolver esse problema, inicie o Google Chrome, acesse o endereço chrome://settings/content/flash e certifique-se de que a opção Perguntar primeiro (recomendado) esteja ativada (no lugar da opção Impedir que sites executem Flash). Em seguida, acesse o endereço chrome://flags/#enable-ephemeral-flash-permission e marque essa opção como Disabled (Desabilitada), daí clique em RELAUNCH NOW ("REINICIAR AGORA") para que essa modificação seja salva e o navegador seja reiniciado com essa nova configuração já vigorando. Em seguida, acesse o endereço chrome://settings/content/siteDetails?site=https%3A%2F%2Fwww2.bancobrasil.com.br e marque como Permitir as seguintes opções: Javascript, Flash, Pop-ups, Sincronização em segundo plano, Downloads automáticos e Acesso a plug-in sem sandbox. Após isso, acesse novamente a página do BB. Se no canto superior direito (extremidade direita) da barra de endereços aparecer um aviso de Plug-in bloqueado, clique sobre o aviso e clique em Executar Flash desta vez. Somente assim os campos de acesso à sua conta corrente aparecerão. Se você clicar no botão de login à sua conta e o login demorar, repita o procedimento de clicar sobre o aviso e clicar em "Executar Flash desta vez". A tendência é os navegadores dificultarem cada vez mais a execução de Flash (até um ponto em que nenhum navegador executará mais o Flash). É torcer para que antes disso os desenvolvedores do website do BB e do famigerado Warsaw tornem o acesso ao banco independente do Flash...  E, se o problema persistir mesmo após você executar todos esses procedimentos com o Chrome, é possível que uma recente atualização do Google Chrome tenha eliminado o certificado de segurança do Warsaw, portanto reinstale o Warsaw (item 13), para que o instalador do Warsaw injete novamente o certificado de segurança dele no Google Chrome.
³ Para o plugin Flash funcionar no Mozilla Firefox, execute o Firefox, acesse o endereço about:addons, clique em Plugins, então clique em Shockwave Flash e, no item Preferências, desmarque a caixa Bloquear conteúdo Flash perigoso e malicioso e, por fim, modifique o valor do campo Perguntar para ativar para que passe a ser Sempre ativar.