📌 4 de Março, 2017

OpenVPN: Recomendações de Segurança

Informática · Linux · Privacidade

📌 4 de Março, 2017

OpenVPN: Recomendações de Segurança

Informática · Linux · Privacidade

Com todas as polémicas recentes em torno da segurança informática muitos power-users e administradores de sistemas decidiram criar os seus próprios VPNs para acederem à Internet de forma segura. Neste artigo passo algumas recomendações de segurança relacionadas com a configuração do OpenVPN.

AVISO: este artigo apresenta apenas recomendações e não poderei, em caso algum, ser responsabilizado por danos decorrentes da utilização da informação aqui apresentada.

1. Servidores Virtuais Privados (VPS) e Containers

  • Capacidades técnicas: pergunte-se se tem capacidade de instalar corretamente um sistema operativo, configurar um firewall, gerir interfaces de rede, configurar atualizações automáticas etc etc. Um VPS não deverá ser “instalado e esquecido” esta abordagem normalmente seguida por novatos resulta em software desatualizado, falhas de segurança e num VPN inseguro. Em caso de dúvida deverá procurar um VPN comercial;
  • Provedor de serviço: a empresa que presta o serviço tem uma política de privacidade transparente? Existem registos de violações à privacidade do cliente? Como lidam com pedidos das autoridades?
  • Imagens: muitos provedores fornecem imagens de sistemas operativos como Debian, Ubuntu, Red Hat etc prontas a usar. Estas imagens simplificam o processo de setup de um VPS no entanto poderão incluir ferramentas pre-instaladas que poderão comprometer a segurança;
  • Espaço partilhado: VPS ou Containers são sempre um espaço partilhado entre vários utilizadores. Existem registo de diversos malwares capazes de evadir a camada de virtualização de um VPS comprometido e passar para o servidor físico.

2. Cifras

Devemos limitar o número de cifras (tls-cipher) disponíveis ao mínimo absoluto. Caso todos os clientes a suportem devermos utilizar únicamente a cifra TLS-DHE-RSA-WITH-AES-256-GCM-SHA384. Devem-se evitar todas as cifras conhecidas como pouco seguras: DES, 3DES-EDE e RC4.

Caso o servidor e todos os clientes utilizem OpenVPN 2.3.3 ou superior são recomendadas as seguintes cifras TLSv1.2 DHE + RSA (da mais segura para a menos segura):

TLS-DHE-RSA-WITH-AES-256-GCM-SHA384
TLS-DHE-RSA-WITH-AES-256-CBC-SHA256
TLS-DHE-RSA-WITH-AES-128-GCM-SHA256
TLS-DHE-RSA-WITH-AES-128-CBC-SHA256

A primeira é a minha recomendação mesmo que os clientes incluam dispositivos móveis – qualquer CPU ARM moderno será capaz de lidar com esta cifra sem problemas.

Restantes configurações recomendadas:

tls-version-min 1.2
auth SHA512
cipher AES-256-CBC

Note-se que no parametro cipher o ideal seria um configuração como AES-512-CBC no entanto devido a diversas questões técnicas esta cifra não existe (ainda) oficialmente e apenas algumas versões do OpenVPN (como a incluída no DD-WRT) a suportam.

3. Gestão de Certificados e Chaves

O OpenVPN baseia-se num sistema PKI com certificados e chaves públicas e privadas que são utilizadas para a identificação, autenticação e comunicação entre os/dos clientes e o servidor. Deveremos tomar especial atenção a:

  • Geração: a PKI deverá ser criada num computador e não no próprio servidor do VPN. Apenas deverão ser transferidos os ficheiros estritamente necessários para o servidor, tipicamente: CA Cert (ca.crt), Server Cert (server.crt), Server Private Key (server.key), Diffie Hellman Secret (dh.pem) e TLS Auth (ta.key). É fundamental evitar enviar para o servidor a chave privada da CA (ca.key) porque é com ela é possível gerar novos clientes válidos;
  • Regra 1 = 1: cada dispositivo de cada utilizador deverá ter o seu certificado. Imaginemos que um dos utilizadores do VPN perde o telemóvel, poderemos facilmente revogar apenas esse certificado e emitir um novo sem prejudicar os restantes dispositivos do mesmos utilizador;
  • Armazenamento: todos os certificados gerados deverão ser armazenados de forma segura, recomendo uma unidade externa preferencialmente com algum mecanismo de encriptação e proteção físico como impressão digital ou menos seguro encriptação via software. Esta unidade deverá ser guardada num local seguro pois em caso de roubo será possível gerar novos clientes válidos;
  • Tamanho das chaves: as chaves assimétricas X.509 utilizadas pelo OpenVPN deverão ter um tamanho razoável – 2048 bits é o mínimo aceitável e 4096  é o máximo suportado pelo software. A European Union Agency for Network and Information Security no seu relatório intitulado “Algorithms, Key Sizes and Parameters Report” aconselha a utilização de chaves de 3072 bits em sistemas criados desde 2013. Isto pode ser definido no ficheiro vars da ferramenta EasyRSA através do parâmetro set_var EASYRSA_KEY_SIZE 3072;
  • Validade: a ferramenta EasyRSA define que os certificados emitidos terão uma validade de 10 anos. Este valor é razoável para a grande maioria dos VPNs, no entanto, reduzir este valor força-nos a emitir novos certificados periodicamente aumentando a segurança. Note-se que cada vez que criamos uma nova CA e certificado de servidor teremos também de criar novos certificados para os clientes. Isto pode ser definido no ficheiro vars através dos parâmetros EASYRSA_CA_EXPIREEASYRSA_CERT_EXPIREEASYRSA_CRL_DAYS;
  • Verificação de papeis: existem diversos ataques onde poderá ser utilizado um certificado “roubado” de um cliente para simular o servidor ou vice versa. Os clientes deverão incluir na sua configuração o parâmetro remote-cert-eku "TLS Web Server Authentication" enquanto o servidor o contrário: remote-cert-eku "TLS Web Client Authentication";
  • Verificação de sujeito: os clientes deverão verificar se o sujeito do certificado fornecedor pelo servidor é o correcto através do parâmetro verify-x509-name 'C=PT, ST=Lisbon, L=Lisbon, O=VPN, OU=VPN, CN=vpntest.server.dev, emailAddress=vpn@server.dev' subject (adaptar com a informação utilizada para gerar os certificados);

4. Outras Configurações

  • Tráfego entre clientes: (client-to-client) esta opção não impede os clientes de comunicarem entre si, apenas evita que os pacotes trocados cheguem à camada IP do servidor sendo redirecionados diretamente pelo OpenVPN. Em casos onde se pretende isolar / impedir a comunicação entre clientes deverá ser adicionada a seguinte regra ao iptables do servidor:  iptables -A FORWARD -i tun0 -o tun0 -j DROP (tun0 = interface do OpenVPN);
  • Número de clientes: (max-clients) clientes em simultâneo que o VPN suportará, manter este número num valor razoável poderá adicionar algumas segurança secundária;
  • Domínios, portos e IPs: utilizar um domínio para aceder ao VPN poderá facilitar as coisas no entanto se o servidor de DNS for comprometido os clientes poderão ser redirecionados para um servidor malicioso, ligação direta ao IP não têm este problema. Em relação às portas / portos a 443 apresenta-se como a mais versátil já que um cliente deverá ser capaz de se ligar ao VPN a partir de qualquer rede (mesma porta utilizada pelos sites protegidos por SSL) no entanto poderá expor o servidor de OpenVPN a ataques automatizados. Caso não existam problemas de acesso é recomendável uma porta alta por exemplo 4591;
  • Utilizador e grupo: o OpenVPN foi cuidadosamente desenhado para não precisar de ser executado como root após a sua incialização. Normalmente pode ser configurado através dos parâmetros user e group para correr como nobody e nogroup algo teoricamente suficiente. Deveremos reparar se não existe outro processo como o Apache a utilizar este utilizador e grupo porque se um for comprometido o outro também estará vulnerável. A solução mais segura é criar um utilizador e grupo específicos para o OpenVPN e desativar o login / shell para os mesmos;
  • Rotas e DNS: o servidor deverá tentar enviar aos clientes a informação das rotas e do DNS para evitar tráfego não protegido pelo VPN. Isto poderá ser feito com uma configuração semelhante a:
push "redirect-gateway def1"
push "dhcp-option DOMAIN vpntest.server.dev"
push "dhcp-option DNS 64.6.65.6"
push "dhcp-option DNS 208.67.220.220"

A primeira linha informa o cliente de que todo o tráfego deverá ser enviado através do VPN enquanto as duas últimas definem dois servidores de DNS públicos comuns.

5. Exemplo de Configuração (Servidor + Cliente)

Apresento agora um exemplo de configuração de um servidor de OpenVPN que inclui todas as recomendações anteriores e outros parâmetros necessários:

local xxx.xxx.xxx.xxx # IP do Servidor VPN
port 443
proto udp
dev tun
server yyy.yyy.yyy.0 255.255.255.0
user nobody
group nogroup
script-security 1
remote-cert-eku "TLS Web Client Authentication"

# Ciphers
cipher AES-256-CBC
tls-version-min 1.2
auth SHA512
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384

# Routes and DNS
push "redirect-gateway def1"
push "dhcp-option DOMAIN vpntest.server.dev"
push "dhcp-option DNS 64.6.65.6"
push "dhcp-option DNS 208.67.220.220"

# Connection Options
client-to-client
keepalive 10 120
comp-lzo
max-clients 10
persist-key
persist-tun

# Certificates
ca ca.crt
cert server.crt
key server.key
dh dh.pem
tls-auth ta.key 0

# Logging
verb 3
status /var/log/openvpn-status.log # Log das ligações ativas
log-append /var/log/openvpn.log

Agora um exemplo de uma configuração para cliente apropriada:

client
pull
dev tun
proto udp
remote xxx.xxx.xxx.xxx 443 udp # IP do Servidor VPN
user nobody
group nogroup
nobind
comp-lzo
verb 3
resolv-retry infinite
persist-key
persist-tun
mute-replay-warnings
redirect-gateway def1

verify-x509-name 'C=PT, ST=Lisbon, L=Lisbon, O=VPN, OU=VPN, CN=vpntest.server.dev, emailAddress=vpn@server.dev' subject

# Ciphers
tls-version-min 1.2
auth SHA512
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384
cipher AES-256-CBC

# Client Keys
<ca>
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----
</key>
<tls-auth>
-----BEGIN OpenVPN Static key V1-----
-----END OpenVPN Static key V1-----
</tls-auth>
key-direction 1

Espero que este artigo seja útil a todos os que já têm ou pretendem criar VPNs com o OpenVPN. Aqui foram resumidas muitas políticas de segurança recomendadas pela comunidade, instituições governamentais e algumas que resultam do puro entendimento detalhado do funcionamento do OpenVPN.