Decred através de VPNs e proxies
1. Introdução
É importante que haja várias formas de conexão e instalação testadas e documentadas para que o Decred possa ser usado no mundo todo, de preferência com liberdade e privacidade.
É possível criar túneis IPSec, SSH, TLS ou encapsular uma conexão em outro túnel. É preciso ainda considerar se é necessário também ocultar a própria existência do canal de comunicação.
A maior parte do que foi escrito aqui não está diretamente relacionada a um servidor dcrd hospedado em um provedor de nuvem com conexão VPN. Há muitas informações sobre VPN, proxies e firewalls que servem a qualquer usuário doméstico de Decred. Talvez um usuário comum não precisa ter todo o trabalho descrito aqui: pode usar o Decrediton no Tails. É provavel que essa solução mais simples atenda o requisito privacidade e evite a censura. Mas para o usuário que pretende fazer um uso mais avançado ou compartilhar um dcrd com um grupo, este artigo tem informações vitais para proteger a privacidade e a liberdade.
1.1. Objetivo
Mapear aplicativos e serviços considerados estáveis e seguros, com código-fonte aberto e analisados por dezenas de profissionais da área de segurança da informação. Apesar disso, nada impede que sejam descobertas ou divulgadas novas vulnerabilidades em aplicativos bem estabelecidos no mercado.
1.1.1. Criptografia forte
Apenas métodos criptográficos fortes devem ser usados, como AES-256, key exchange is done with 2048-bit RSA, e HMAC com SHA256 para message authentication.
Alguns mecanismos já estão há alguns anos no mercado como, por exemplo, VPN através de IPSec, com IKEv2 ou 2048-bit RSA para troca de chaves, e criptografia AES-256, AES-GCM, SHA2 ou P-256.
O OpenSSH, baseado no projeto SSH de 1995, foi criado em 1999 na versão SSHv1 e a versão SSHv2 foi lançada em 2000.
1.1.2. Forward Secrecy
Perfect Forward Secrecy significa que o tráfego criptografado não poderá ser capturado e decriptografado depois se uma chave criptográfica de uma sessão posterior for comprometida. A cada conexão é gerada uma nova chave criptográfica, então uma chave nunca é usada por mais de uma sessão.
1.2. Cenário proposto
O objetivo do censor pode ser impedir a comunicação ou usar técnicas de inspeção de pacotes (DPI, Deep Packet Inspection) para analisar o conteúdo da conexão, identificar atividades proibidas por ele e localizar o usuário. Esse cenário assume que o censor não tem nenhum controle ou influência sobre a infraestrutura ou a conexão com a Internet do dispositivo onde ficará instalado o dcrd.
Figura 1 - Um dcrd remoto, um censor e um túnel criptográfico conectando o cliente
Há duas vantagens claras em manter o dcrd em um provedor de serviços de nuvem fora do controle do censor:
a) O dcrd copia novas informações em média a cada 5 minutos (tempo do bloco) e usa consultas DNS para atualizar o arquivo peers.json com informações sobre os nodes. dcrwallet e Decrediton só precisarão trafegar informações para fazer consultas ou enviar transações, mantendo a conexão ativa por menos tempo e chamando menos atenção do censor.
b) É possível utilizar um servidor dcrd e dcrdata para um grupo de pessoas, o que tornará mais fácil a gestão do servidor e reduzirá o custo. Para reduzir as chances de erros que possam expor todos os usuários apenas métodos considerados seguros devem ser utilizados.
1.3. Anonimato
Anonimato significa não ser nomeado ou identificado. Isso não acontece, mesmo usando ferramentas de privacidade como Tor, Bitcoin ou VPN. Todo serviço tem alguma informação que ajuda a distinguir um usuário dos demais: pode ser o endereço IP, no caso da VPN e do Tor, ou o endereço de uma carteira, no caso do Bitcoin. Essa informação isolada não revela detalhes sobre o usuário mas pode ser correlacionada com outras e usada para identificar uma pessoa.
Há muitos provedores de VPN que vendem seu serviço alegando que podem deixar o usuário completamente anônimo. Isso não é verdade, até por causa do problemas dos trackers que são carregados nas páginas via Javascript. Anonimato completo através de um serviço de VPN é tecnicamente impossível porque apesar de o site que você acessa não saber o seu verdadeiro endereço IP, o provedor de VPN sempre saberá o seu verdadeiro endereço IP.
O anonimato na VPN não é uma garantia técnica, mas sim uma garantia legal fraca. Dependendo da lei do país onde está estabelecido o provedor de VPN, o provedor pode não ser obrigado a registrar o endereço IP, e assim, mesmo tendo acesso ao endereço IP, não é obrigado a registrar e entregar às autoridades.
1.4. Censura sofisticada
Se o seu provedor usa Deep Packet Inspection (DPI) é possível identificar e bloquear ou reduzir a velocidade da sua conexão. O provedor não terá como decriptar o tráfego e acessar o conteúdo, exceto se a sua conexão usa métodos criptográficos vulneráveis. Provedores de VPN sempre poderão ser bloqueados por provedores de Internet porque seus endereços IPs são conhecidos.
1.5. Confiança
A contratação de um provedor de VPN envolve a transferência de confiança do seu provedor de Internet para o de VPN. É o mesmo que dizer: não confio que o meu provedor de Internet não vá me espionar mas confio no provedor de VPN. O provedor de VPN terá acesso a todo o seu tráfeg, por isso sempre deve ser utilizada criptografia end-to-end (ponta-a-ponta). Assim, é importante escolher bem o provedor e ver o que ele fez para ganhar sua confiança. Provedores de VPN podem até mesmo funcionar como serviço de fachada para agências governamentais de espionagem.
No caso da contratação de um provedor de nuvem que hospedará o seu servidor VPN, a situação é um pouco mais complicada. Esse provedor, provavelmente gigante, precisa de muitos logs para manter sua operação e não deve ter feito nenhuma promessa de privacidade pois ele não está no ramo de soluções desse tipo.
1.6. DNS Leakage
Consultas DNS executadas fora do túnel podem expor ao censor o recurso que o usuário pretende acessar. Essa situação ocorre quando o cliente usa um servidor de DNS que não é acessível pelo túnel, seja o do seu provedor ou qualquer outro, fazendo com que seu tráfego DNS seja enviado por fora do túnel e exposto ao censor. Não apenas o censor terá o endereço IP que será acessado mas também o nome do domínio, o que pode indicar o tipo de recurso a ser acessado.
Essa vulnerabilidade pode estar presente tanto no uso de túneis através de proxy como de VPN e pode ser evitada através de configuração.
Figura 2 - Como ocorre vazamento de informações via consulta DNS
1.7. IPv6 Leakage
A vulnerabilidade ocorre porque os clientes de VPN manipulam apenas a tabela de roteamento IPv4, esquecendo da tabela de roteamento IPv6. Como nenhuma regra é adicionada para redirecionar o tráfego IPv6 ao túnel, ele acaba sendo enviado por fora da interface VPN.
Figura 3 - Como ocorre vazamento de informações via IPv6
2. Selecionando uma solução
Para manter o servidor seguro, atualizado e com o mínimo de serviços sendo executados é importante avaliar as soluções aqui apresentadas e escolher a que mais se adapta às suas necessidades.
- O Algo, apresentado na seção 3, configura o uso de VPN IPSec e túnel SSH
- A seção 4 traz outras opções, todas independentes umas das outras
- A seção 5 é sobre contratação de provedores de VPN
- A seção 6 apresenta um esquema que usa o Tor
- A seção 7 menciona o uso do Tails e trata da configuração do dcrwallet e do Decrediton como clientes em todos os cenários anteriores
É possível mesclar as soluções apresentadas e criar outras:
- Contratar um provedor de VPN (seção 5) e, por dentro da VPN, se conectar à rede do Tor (seção 6)
- Usar o Decrediton no Tails (seção 7), conectado a uma VPN criada com o Algo (seção 3)
Quanto mais dispositivos intermediários e camadas criptográficas forem usadas maior será a latência e o consumo de banda.
Para saber mais sobre como os componentes do Decred trabalham juntos, veja A estrutura do Decred.
Outras soluções
Há outras opções disponíveis, tanto para VPN como para proxy. Algumas usam mecanismos criptográficos insguros, outras são complicadas, não foram tão bem testadas ou analisadas, ou não possuem documentação extensa ou de fácil entendimento. Ainda assim é sempre bom ter um leque de opções em caso de incompatibilidade de aplicativos, plataformas, bibliotecas ou dificuldade de roteamento de tráfego.
Se você entende que essas não são as melhores soluções para o seu caso específico, avalie algumas outras opções como:
3. Algo VPN
Algo VPN is a set of Ansible scripts that simplify the setup of a personal IPSec VPN.
- Supports only IKEv2 with strong crypto: AES-GCM, SHA2, and P-256
- Sets up limited SSH users for tunneling traffic (optional)
- Based on current versions of Ubuntu and strongSwan
- Installs to DigitalOcean, Amazon EC2, Microsoft Azure, Google Compute Engine, or your own server
É possível instalar os mesmos pacotes de forma manual, sem o Algo.
O cenário de teste apresentado na seção 3 foi construído usando um Ubuntu 16.04 64-bit hospedado no DigitalOcean.
3.1. Instalação do Algo
The easiest way to get an Algo server running is to let it set up a new virtual machine in the cloud for you.
Faça a instalação do Algo como indicado no README.
Local deployment https://github.com/trailofbits/algo/blob/master/docs/deploy-to-ubuntu.md
Scripted deployment https://github.com/trailofbits/algo/blob/master/docs/deploy-from-ansible.md
3.2. VPN: IPSec via Algo
Figura 4 - Um túnel IPSec conecta o cliente em uma interface de rede virtual do servidor
Regras de firewall
A lista não exaustiva de regras sugeridas no artigo A estrutura do Decred assume que não há problemas em ter a porta do dcrd aberta para que outros servidores possam se conectar e buscar atualizações na blockchain. Esse não é o caso em um servidor que não deve divulgar seus serviços para que não se saiba o que fazem os usuários que nele se conectam.
Firewall IPv4
Para permitir conexões apenas vindo da interface da VPN substitua as regras pelo conjunto abaixo, que recebeu pequenas modificações.
$ sudo iptables -P INPUT DROP
$ sudo iptables -A INPUT -i lo -j ACCEPT
$ sudo iptables -A INPUT ! -i lo -s 127.0.0.0/8 -j DROP
$ sudo iptables -A INPUT -m state --state INVALID -j DROP
$ sudo iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT
$ sudo iptables -A INPUT -p tcp -m state --state NEW ! --syn -j DROP
$ sudo iptables -A INPUT -i $TUN -m multiport -p tcp --dports 9109,19109 -m comment --comment "dcrd from dcrwallet mainnet,testnet" -j ACCEPT
$ sudo iptables -A INPUT -i $TUN -m multiport -p tcp --dports 9110,19110 -m comment --comment "dcrwallet from dcrctl mainnet,testnet" -j ACCEPT
$ sudo iptables -A INPUT -p icmp --icmp-type echo-request -s $LOCALNET/24 -m comment --comment "icmp ping reply" -j ACCEPT
$ sudo iptables -A INPUT -m limit --limit 3/min -j LOG --log-prefix "iptables_INPUT_denied: " --log-level 4
$ sudo iptables -P FORWARD DROP
$ sudo iptables -P OUTPUT DROP
$ sudo iptables -A OUTPUT -o lo -j ACCEPT
$ sudo iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
$ sudo iptables -A OUTPUT -m multiport -p tcp --dports 80,443 -j ACCEPT
$ sudo iptables -A OUTPUT -m multiport -p tcp --dports 9108,19108 -m comment --comment "dcrd to dcrd mainnet,testnet" -j ACCEPT
$ sudo iptables -A OUTPUT -o $TUN -m multiport -p tcp --dports 9109,19109 -m comment --comment "dcrwallet/ctl to dcrd/wallet mainnet,testnet" -j ACCEPT
$ sudo iptables -A OUTPUT -o $TUN -m multiport -p tcp --dports 9110,19110 -m comment --comment "dcrctl to dcrwallet mainnet,testnet" -j ACCEPT
$ sudo iptables -A OUTPUT -o $TUN -p udp --dport 53 -m comment --comment "DNS Queries" -j ACCEPT
$ sudo iptables -A OUTPUT -o $TUN -p tcp --dport 53 -m comment --comment "DNS Extended Queries" -j ACCEPT
$ sudo iptables -A OUTPUT -p tcp --dport 11371 -m comment --comment "GPG HKP" -j ACCEPT
$ sudo iptables -A OUTPUT -p udp --dport 67 -m comment --comment "dhcp" -j ACCEPT
$ sudo iptables -A OUTPUT -p udp --dport 123 -m comment --comment "ntp" -j ACCEPT
$ sudo iptables -A OUTPUT -p icmp --icmp-type any -m comment --comment "icmp out" -j ACCEPT
$ sudo iptables -A OUTPUT -m limit --limit 3/min -j LOG --log-prefix "iptables_OUTPUT_denied: " --log-level 4
Foi removida a regra de entrada do dcrd e adiconada a interface de entrada nas regras do dcrwaller e dcrctl. Se for instalado o dcrdata também será necessário permitir tráfego nas portas TCP 80 e 443 apenas com origem na interface de VPN (-A INPUT -i $TUN -m multiport -p tcp --dports 80,443 -j ACCEPT).
Firewall IPv6
Considere adicionar regras de IPv6 que bloqueem todo o tráfego, se não for necessário falar IPv6. Em sistemas com ip6tables:
$ sudo ip6tables -P INPUT DROP
$ sudo ip6tables -P FORWARD DROP
$ sudo ip6tables -P OUTPUT DROP
$ sudo service iptables-persistent save
O último comando sobrescreverá os arquivos /etc/iptables/rules.v4 e /etc/iptables/rules.v6 com as regras atuais.
3.3. SSH tunneling via Algo
Use the example command below to start an SSH tunnel by replacing user and ip with your own. Once the tunnel is setup, you can configure a browser or other application to use 127.0.0.1:8080 as a SOCKS proxy to route traffic through the Algo server.
$ ssh -D 127.0.0.1:8080 -f -q -C -N $USERNAME@$DCRD_IP -i configs/ip_user.ssh.pem
Figura 5 - Um túnel SSH, configurado pelo Algo, atuando como proxy local para dcrwallet e Decrediton
4. Proxies e túneis
4.1. Túnel: SSH via OpenSSH
aaa
4.2. Túnel: SSH via SShuttle
https://github.com/sshuttle/sshuttle/
$ pip install sshuttle
Read carefully the requirements at http://sshuttle.readthedocs.io/en/stable/requirements.html.
$ sshuttle --dns -r $USERNAME@$DCRD_IP 0/0
5. Provedores de VPN
Uma opção para a conexão do cliente com o servidor dcrd, ou até mesmo para não usar um dcrd remoto e manter todos os componentes no mesmo dispositivo, é a contratação de um provedor de VPN.
Ainda que possa usar uma VPN para mascarar sua origem e encriptar o tráfego, seria necessário ter certeza de que o serviço de VPN não armazena seu endereço IP e os destinos acessados e consulta a DNS (no log policy). O site PrivacyTools tem uma lista de provedores de VPN localizados fora dos EUA, com no log policy (apesar de não haver nenhuma garantia), que aceitam Bitcoin e suportam OpenVPN. Dê preferência a provedores localizados em países fora do grupo Fourteen Eyes.
Figura 6 - Uso de um provedor de VPN para burlar o censor
Antes de contratar um provedor de VPN verifique se ele atende a alguns requisitos mínimos:
5.1. Kill switch
Mecanismo que bloqueia todas as conexões de rede caso a conexão com o servidor de VPN seja interrompida. Isso evita que a privacidade seja comprometida ao enviar pacotes para a Internet com o seu verdadeiro endereço IP.
5.2. Protocolos seguros
Provedores de VPN devem usar protocolos seguros como IPSec com IKEv2 e OpenVPN. Evite provedores que suportam apenas PPTP, L2TP/IPSec e outros protocolos que já foram comprometidos.
5.3. Proteção legal
Procure provedores localizados em países que tenham fortes leis de proteção à privacidade, fora da jurisdição de Estados Unidos e União Européia ou que não sejam obrigados por lei a manter log de atividades. Evite provedores baseados em países que formam o grupo Fourteen Eyes, que podem ser coagidos a entregar informações sobre seus usuários.
6. Rede Tor
Os componentes do Decred podem ser configurados para ser conectar via Tor proxy. Para saber mais detalhes, veja Decred através da rede Tor.
Figura 7 - Decred através da rede Tor
7. Instalação e configuração dos componentes
Para completar a instalação, leia o artigo Instalando o dcrd. Para conectar o dcrwallet ou o Decrediton ao dcrd remoto, leia Compartilhando o dcrd. Para instalar no dcrd remoto o explorador de blocos, veja dcrdata: executando seu próprio explorador de blocos. O dcrd e o dcrdata podem ficar acessíveis através da rede Tor como mostra o artigo Decred através da rede Tor. Se quiser camuflar o dcrd, veja como colocar o Decred atrás de Portknocking.
Para adicionar mais uma proteção instale o Decrediton no Tails em um flash drive com espaço criptografado para armazenamento persistente. Esse volume criptografado do Tails não poderá contar com a capacidade de negar que há ali um conteúdo criptografado, pois esse volume não será oculto.
Figura 8 - Um cenário com várias possibilidades de conexão ao dcrd
7.1. Decrediton
Para fazer o Decrediton usar o proxy, localize e abra o arquivo dcrwallet.conf de acordo com seu sistema operacional:
Linux: ~/.config/decrediton
macOS: ~/Library/Application Support/decrediton
Windows: C:\Users\$USERNAME\AppData\Local\Decrediton
e adicione a linha a seguir na seção [Application Options]:
proxy=127.0.0.1:8080
Firewall IPv6
Considere adicionar regras de IPv6 que bloqueem todo o tráfego, se não for necessário falar IPv6. Em sistemas com ip6tables:
$ sudo ip6tables -P INPUT DROP
$ sudo ip6tables -P FORWARD DROP
$ sudo ip6tables -P OUTPUT DROP
$ sudo service iptables-persistent save
7.2. dcrwallet
De acordo com os comentários dentro do arquivo sample-dcrwallet.conf, é possível configurar o dcrwallet para se conectar ao RPC server através de um proxy local na seção ‘RPC client settings’.
proxy=127.0.0.1:8080
Considere adicionar regras de IPv6 que bloqueem todo o tráfego, se não for necessário falar IPv6. Em sistemas com ip6tables:
$ sudo ip6tables -P INPUT DROP
$ sudo ip6tables -P FORWARD DROP
$ sudo ip6tables -P OUTPUT DROP
$ sudo service iptables-persistent save
7.3. Web browser
Para acessar o seu explorador de blocos ou o site da pool e acompanhar os tickets PoS será necessário configurar o browser para enviar os dados pelo túnel, caso contrário o censor pode perceber que o seu endereço IP se interessa por Decred.
Essa configuração é necessária se estiver usando um túnel SSH, TLS, SOCKS5 ou qualquer outro que não seja uma VPN que crie uma interface de rede pela qual todo o tráfego de rede será roteado.
Para configurar o browser: a) Acesse o menu geral, selecione “Preferências” b) Na página “Preferências” desça até o fim. Na seção “Network proxy” clique no botão “Settings” c) Com os devidos ajustes, faça a configuração como indicado na próxima figura
Figura 9 - Configuração de proxy de rede no Mozilla Firefox
7.4. dcrdata
Para configuração do dcrdata via HTTPS através do Tor, leia dcrdata: executando seu próprio explorador de blocos.
8. Testando a comunicação do túnel
Antes de acessar um site ou mesmo realizar alguma consulta sensível via DNS é recomendável que o usuário verifique o tipo de tráfego que sai da sua interface de rede.
Wireshark
O Wireshark é o analisador de protocolos de rede mais conhecido, um aplicativo que captura os pacotes enviados e recebidos pela interface de rede e fornece ferramentas para análise. É popularmente conhecido como “sniffer de rede”.
Após a instalação do Wireshark, teste se a solução funciona como esperado: a) Abra o Wireshark b) Inicie a captura de pacotes de rede, selecionando a interface física por onde passará o tráfego c) Faça a conexão com o servidor remoto (VPN ou proxy) d) Se configurou o proxy no browser, acesse algum site através de nome DNS e) Execute algumas atividades no servidor remoto, capture uma certa quantidade de tráfego entre o seu computador e o servidor f) Pare a captura g) Analise o tráfego capturado
Para uma solução de VPN todo o tráfego deve ter sido direcionado para o servidor remoto, incluindo consultas DNS. Não deve haver tráfego IPv6. Para uma solução de proxy todo o tráfego da ferramenta ou componente configurado para usar o túnel deve ter sido direcionado para o servidor remoto. Procure por consultas DNS e pacotes IPv6 e veja se alguma informação relevante foi enviada por fora do túnel.
9. Anonimato é possível?
“Não há solução mágica ou perfeita para um problema tão complexo.”
Não deixe de ler a página de alertas do Tails.
Mesmo durante o uso do Tails é necessário tomar alguns cuidados para evitar que ataques de correlação de tráfego ou intimações judiciais forcem terceiros a entregar informações que podem comprometer o usuário.
Um esquema mais próximo do anonimato depende de outros controles de segurança durante a sessão em que o usuário realiza as atividades objeto de censura:
- uso de um hardware confiável;
- sem BIOS modificada;
- rodando Tails;
- conectado a uma rede sem fio pública, sem câmeras de segurança ou com antena externa para conexão distante das câmeras;
- com criptografia ponta-a-ponta em tudo que acessa;
- sem acesso a sites que contenham login/conteúdo pessoal (e-mail, Facebook, Twitter);
- sem acesso a sites que usam trackers que podem expor o usuário (são muitos sites).
Veja a página de alertas do Tails para compreender o quão complexo é o problema do anonimato.
Figura 10 - Um esquema o mais próximo possível do anonimato, com ou sem o uso do dcrd remoto