FACULDADE SALESIANA DE VITÓRIA
PÓS-GRADUAÇÃO EM SEGURANÇA DE
REDES DE COMPUTADORES
ANDRÉ LUIZ PERCIANO FANELI
VANDERLEI CARLOS MARCHEZINI
OPENVPN: IMPLEMENTAÇÃO DE VPN ATRAVÉS DE SSL
EM AMBIENTE DE SOFTWARE LIVRE
VITÓRIA
2007
ANDRÉ LUIZ PERCIANO FANELI
VANDERLEI CARLOS MARCHEZINI
OPENVPN: IMPLEMENTAÇÃO DE VPN ATRAVÉS DE SSL
EM AMBIENTE DE SOFTWARE LIVRE
Monografia apresentada ao Curso de Pósgraduação em Segurança de Redes de
Computadores da Faculdade Salesiana de
Vitória, como requisito final para obtenção
do título de Especialista em Segurança de
Redes de Computadores.
Orientador: Prof. M. Sc. Ádrian Bonfá Drago
VITÓRIA
2007
Dados Internacionais de Catalogação-na-publicação (CIP)
(Biblioteca da Faculdade Salesiana de Vitória, Espírito Santo, Brasil)
F211o
Faneli, André Luiz Perciano, 1963; Marchezini, Vanderlei Carlos, 1959
Openvpn : implementação de VPN através de SSL em ambiente de
software livre / André Luiz Perciano Faneli, Vanderlei Carlos Marchezini.
– 2007.
133 f. : il.
Orientador: Ádrian Bonfá Drago.
Monografia (Pós-graduação em Segurança de Redes de
Computadores) – Faculdade Salesiana de Vitória.
1. Rede de Computadores – Segurança. 2. Rede Virtual Privada. 3.
OpenVPN. I. Marchezini, Vanderlei Carlos. II. Teixeira, Sérgio. III.
Faculdade Salesiana de Vitória. IV. Título.
CDU: 004.7
ANDRÉ LUIZ PERCIANO FANELI
VANDERLEI CARLOS MARCHEZINI
OPENVPN: IMPLEMENTAÇÃO DE VPN ATRAVÉS DE SSL
EM AMBIENTE DE SOFTWARE LIVRE
Monografia apresentada ao Curso de Pós-graduação em Segurança de Redes de
Computadores da Faculdade Salesiana de Vitória, como requisito final para obtenção do
título de Especialista em Segurança de Redes de Computadores.
Aprovada em 19 de junho de 2007.
COMISSÃO EXAMINADORA
_________________________________________
Prof. M. Sc. Adrian Bonfá Drago
Orientador
_________________________________________
Prof. M. Sc. Sérgio Teixeira
Faculdade Salesiana de Vitória
_________________________________________
Prof. D.Sc. Davidson Cury
Universidade Federal do Espírito Santo
AGRADECIMENTOS
Às famílias, pelo incentivo e paciência com que enfrentaram as inúmeras ausências dos
finais de semana. Ao orientador, Adrian Bonfá Drago, pela atenção, dedicação,
ensinamentos e paciência. Aos demais orientadores e professores do curso de pósgraduação, que colaboraram por meio de críticas e sugestões, contribuindo dessa forma
para a melhoria da qualidade deste trabalho.
RESUMO
Este trabalho objetiva examinar o conceito de VPN (Virtual Private Network) nos aspectos
de aplicabilidade, funcionalidade, segurança, custos e benefícios, valendo-se de algumas
ferramentas de software livre em ambiente Linux. Para tanto, escolheu-se a solução
OpenVPN, que tem como base o protocolo TLS/SSL. A idéia central dessa escolha foi
buscar uma alternativa qualitativamente capaz de equiparar-se às soluções de VPN baseadas
no protocolo IPSec, tecnologia onipresente no mercado e com ampla predominância na
literatura sobre o tema. O OpenVPN é um projeto open source, disponível para diversos
ambientes computacionais e sistemas operacionais, incluindo Linux e Windows, e se
beneficia da maturidade reconhecida do protocolo TLS/SSL, cuja evolução e fortalecimento
decorrem da forma exaustiva com que tem sido analisado à procura de falhas. Ao final, é
apresentada uma proposta de implementação de uma VPN através do OpenVPN num
cenário matriz-filiais e feita a apresentação dos resultados obtidos.
Palavras-chave: Redes de Computadores – Segurança, Rede Virtual Privada, OpenVPN.
ABSTRACT
This work wishes to evaluate the concept of VPN (Virtual Private Network) on applicability,
functionality, safety, costs and benefits, using some free software tools on Linux
environment.
Therefore, the chosen solution was OpenVPN, which is based on the
TLS/SSL protocol. The main idea on this alternative was to search for a capable way of
equaling the solutions of VPN based on the IPSec protocol, technology that is omnipresent
on the market with a wide prevalence on the related literature. The OpenVPN is an open
source project, available for several computational environments and operating systems,
including Linux and Windows, and benefits itself on the maturity recognized on the
TLS/SSL protocol, of wich’s evolution and strengthening come from the exhausting way
with wich has been analyzed in search of flaws.
In the end it is introduced an
implementation proposal of a VPN through the OpenVPN on a matrix-branch scenery and it
is done and presentation of the obtained results.
Keywords: Computer Networks – Security, Virtual Private Network, OpenVPN.
LISTA DE ILUSTRAÇÕES
Figura 1: Rede de computadores ................................................................................... 20
Figura 2: Fluxo normal de dados .................................................................................. 24
Figura 3: Interceptação.................................................................................................. 24
Figura 4: Interrupção ..................................................................................................... 24
Figura 5: Modificação ................................................................................................... 25
Figura 6: Fabricação ...................................................................................................... 25
Figura 7: TCP handshake.............................................................................................. 29
Figura 8: SYN flooding .................................................................................................. 30
Figura 9: Ataque man-in-the-middle............................................................................. 31
Figura 10: Ataque smurf................................................................................................ 33
Figura 11: O modelo de quatro camadas do TCP/IP .................................................... 34
Figura 12: Fluxo de dados entre as camadas da pilha TCP/IP ..................................... 35
Figura 13: Processo de handshake do TCP................................................................... 38
Figura 14: Redes com interligação via roteadores ........................................................ 41
Figura 15: Localização de endereços num frame Ethernet. .......................................... 43
Figura 16: Exemplo de um firewall ............................................................................. 46
Figura 17: Gateway VPN dentro de um firewall. ............................................................ 48
Figura 18: Gateway VPN paralelo ao firewall. .......................................................................................... 48
Figura 19: Gateway VPN atrás de um firewall ............................................................ 49
Figura 20: Processo de cifragem e decifragem ............................................................. 50
Figura 21: Processo de criptografia simétrica......................................................................................... 51
Figura 22: Criptografia simétrica. ................................................................................ 51
Figura 23: Processo de criptografia assimétrica........................................................... 55
Figura 24: Criptografia assimétrica .............................................................................. 56
Figura 25: Representação do algoritmo RSA............................................................... 58
Figura 26: Processamento da função hash.................................................................... 59
Figura 27: Processo de assinatura digital...................................................................... 62
Figura 28: Túnel virtual entre duas redes ..................................................................... 65
Figura 29: Topologia host-host..................................................................................... 69
Figura 30: Topologia host-rede .................................................................................... 70
Figura 31: Topologia rede-rede. ................................................................................... 71
Figura 32: Formato do pacote L2TP.............................................................................. 74
Figura 33: Modos do protocolo IPSec........................................................................... 78
Figura 34: Localização da camada de segurança TLS/SSL na pilha TCP/IP................ 79
Figura 35: Frame Ethernet detalhando os protocolos superiores.................................. 80
Figura 36: TLS/SSL – processo de handshake.............................................................. 82
Figura 37: Diagrama de conexões do laboratório ......................................................... 86
Figura 38: Menu de opções do OpenVPN para Windows .............................................116
LISTA DE QUADROS
Quadro 1: Portas padronizadas .............................................................................................. 37
Quadro 2: Comparação entre protocolos de VPN ................................................................. 84
Quadro 3: Características de uso e localização de chaves e certificados .............................. 98
LISTA DE ABREVIATURAS E SIGLAS
3DES – Triple Data Encryption Standard
ADSL – Asymmetric Digital Subscriber Line
AES – Advanced Encryption Standard
AH – Authentication Header
ANSI – American National Standards Institute
API – Application Programming Interface
ARP – Address Resolution Protocol
ATM – Asynchronous Transfer Mode
BSD – Berkeley Software Distribution
CA – Certificate Authority
CBC – Cipher Block Chaining
CEF – Caixa Econômica Federal
CFB – Cipher Feedback
CRL - Certificate Revogation List
DES – Data Encryption Standard
DHCP – Dynamic Host Configuration Protocol
DNS – Domain Name System
DoS – Denial of Service
ECB – Eletronic Codebook
ESP – Encapsulating Security Payload
FTP – File Transfer Protocol
GPL – General Public License
GRE – Generic Routing Encapsulation
HMAC – Hash Message Authentication Code
ICMP – Internet Control Message Protocol
IDC – International Data Corporation
IDEA – International Data Encryption Algorithm
IETF – Internet Engineering Task Force
IKE – Internet Key Exchange Protocol
IP – Internet Protocol
IPSec – Internet Protocol Secutity
IPv4 – Internet Protocol version 4
IPX – Interwork Packet Exchange
ISO – International Organization for Standardization
ISAKMP – Internet Security Association and Key Management Protocol
ISP – Internet Service Provider
ITU-T – International Telecommunication Union - Telecommunication Standard Sector
L2F – Layer Two Forwarding
L2TP – Layer Two Tunneling Protocol
LAN – Local Area Network
LPCD – Linha Privativa de Comunicação de Dados
LZO - Lempel-Ziv-Oberhumer
MAN – Metropolitan Area Network
MD-5 – Message Digest 5
MHz - Megahertz
MPPE – Microsoft Point-to-Point Encryption
MS-CHAP – Microsoft-Challenge Handshake Authentication Protocol
NAT – Network Address Translation
NetBEUI – NetBIOS Extended User Interface
NIST – National Institute of Standards and Technologies
NSA - National Security Agency
OSI – Open Systems Interconnection
PAM - Pluggable Authentication Modules
PKI – Public Key Infrastructure
POP3 – Post Office Protocol 3
PPP – Point-to-Point Protocol
PPTP – Point-to-Point Tunneling Protocol
RARP – Reverse Address Resolution Protocol
RC6 - Rivest Cipher 6 ou Ron's Code 6
RFC – Request For Comments
RIP – Routing Information Protocol
RSA – Rivest Shamir Adleman
SA – Security Association
SAD – Security Association Database
SERASA – Centralização dos Serviços dos Bancos S.A
SERPRO – Serviço Federal de Processamento de Dados
SHA – Secure Hash Algorithm (SHA-1, SHA-2, SHA-224, SHA-256, SHA-384, SHA-512)
SKEME - Secure Key Exchange Mechanism
SMTP – Simple Mail Transfer Protocol
SNMP – Simple Network Management Protocol
SPD – Security Policy Database
SPI – Security Parameters Index
SRF – Secretaria da Receita Federal
SSH - Secure Shell
SSL – Secure Sockets Layer
TAP - Terminal Access Point Interface
TCP – Transmission Control Protocol
TI – Tecnologia da Informação
TLS – Transport Layer Security
TTL – Time to Live
TUN – Tunneling Interface
UDP – User Datagram Protocol
URL – Uniform Resource Locator
VPN – Virtual Private Network
WAN – Wide Area Network
WEB – World Wide Web
Wi-Fi – Wireless Fidelity
WINS – Windows Internet Name Service
SUMÁRIO
1 INTRODUÇÃO ................................................................................. 15
1.1 Objetivo geral ....................................................................................... 16
1.2 Objetivo específico ............................................................................... 17
1.3 Metodologia de trabalho ........................................................................ 17
1.4 Organização do texto ............................................................................. 18
2 PRINCÍPIOS DE SEGURANÇA DA INFORMAÇÃO NAS REDES .......19
2.1 Redes de computadores..............................................................................20
2.2 Protocolos de comunicação ........................................................... 21
2.3 Fatores de segurança da informação na comunicação ..................... 21
2.4 Ameaças ...................................................................................... 23
2.4.1 Processo normal ................................................................. 24
2.4.2 Interceptação ..................................................................... 24
2.4.3 Interrupção ........................................................................ 24
2.4.4 Modificação ....................................................................... 25
2.4.5 Fabricação ......................................................................... 25
2.5 Principais ameaças e ataques às redes de computadores ................. 26
2.5.1 Vírus ................................................................................. 26
2.5.2 Verme (Worm) ................................................................... 26
2.5.3 Cavalo de Tróia (Trojan horse) .......................................... 26
2.5.4 Back door (Porta dos fundos) ............................................. 26
2.5.5 Bomba lógica (Logic bomb)................................................ 27
2.5.6 Port scanning (varredura de portas) .................................... 27
2.5.7 Estouro de buffer (buffer overflow)..................................... 27
2.5.8 Quebra de senha (password cracking)................................. 28
2.5.9 Engenharia social ............................................................... 28
2.5.10 Sniffing (monitoramento, “grampo”) ................................... 28
2.5.11 DoS – Denial of service (Interrupção de serviços) ............... 29
2.5.12 SYN flooding (Inundação de SYN) ...................................... 29
2.5.13 Ping da morte (Ping of death) ............................................. 30
2.5.14 Spoofs................................................................................ 30
2.5.14.1 IP spoofing ......................................................... 30
2.5.14.2 Sequence number spoofing .................................. 31
2.5.14.3 Man-in-the-middle (homem no meio) .................. 31
2.5.14.4 Redirecionamento............................................... 31
2.5.14.5 DNS spoofing ..................................................... 32
2.5.14.6 Envenenamento de DNS (DNS poisoning)........... 32
2.5.14.7 Smurf ................................................................. 32
3 A ARQUITETURA TCP/IP DE QUATRO CAMADAS ................................34
3.1 Camada de aplicação ..................................................................................36
3.2 Camada de transporte .................................................................................37
3.2.1 Portas .............................................................................................. 37
3.2.2 Sockets ............................................................................................ 37
3.2.3 TCP – Transmission Control Protocol ..........................................38
3.2.4 UDP – User Datagram Protocol ................................................... 39
3.3 Camada de Internet..................................................................................... 40
3.3.1 IP (Internet Protocol) .....................................................................40
3.4
3.3.2 ICMP (Internet Control Message Protocol) ..................................42
Camada de acesso à rede............................................................................43
4 MÉTODOS DE DEFESA......................................................................................... 45
4.1 Firewall ......................................................................................................45
4.2 Firewall e VPN .......................................................................................... 47
4.3 Criptografia ................................................................................................ 49
4.3.1 Criptografia simétrica.....................................................................50
4.3.1.1 Data Encryption Standard (DES) ...................................52
4.3.1.2 Triple Data Encryption Standard (3DES) ...................... 53
4.3.1.3 Advanced Encryption Standard (AES) ........................... 53
4.3.1.4 International Data Encryption Algorithm (IDEA) .........53
4.3.1.5 Blowfish/Twofish ............................................................. 54
4.3.2 Criptografia assimétrica .................................................................54
4.3.2.1 RSA (Rivest, Shamir e Adleman) ...................................57
4.3.2.2 Diffie-Hellman ................................................................ 58
4.3.3 Função hash.................................................................................... 59
4.3.3.1 Message Digest (MD-5)..................................................60
4.3.3.2 Secure Hash Algorithm 1 (SHA-1) .................................60
4.3.4 Assinatura digital............................................................................61
4.3.5 Certificado digital...........................................................................62
5 CONCEITOS SOBRE VPNS................................................................................... 64
5.1 Tunneling ........................................................................................................64
5.2 Autenticação nas extremidades......................................................................65
5.3 Vantagens das VPNs ......................................................................................65
5.3.1 Segurança ...........................................................................................65
5.3.2 Transparência .....................................................................................66
5.3.4 Custos .................................................................................................66
5.3.4 Flexibilidade.......................................................................................66
5.4 Desvantagens das VPNs.................................................................................66
5.5 Comparação com outras tecnologias de acesso remoto................................68
5.5.1 VPN x linhas dedicadas .....................................................................68
5.5.2 VPN x servidor de acesso remoto .....................................................68
5.6 Topologias.......................................................................................................69
5.6.1 Host-host.............................................................................................69
5.6.2 Host-gateway......................................................................................70
5.6.3 Gateway-Gateway..............................................................................70
5.7 Protocolos utilizados nas VPNs .....................................................................71
5.7.1 PPTP – Point to Point Tunneling Protocol.......................................72
5.7.2 L2F – Layer 2 Forwarding................................................................73
5.7.3 L2TP – Layer 2 Tunneling Protocol .................................................73
5.7.4 IPSec – Internet Protocol Security....................................................75
5.7.4.1 Negociação do nível de segurança.....................................76
5.7.4.2 Autenticação e integridade.................................................77
5.7.4.3 Confidencialidade...............................................................78
5.7.5 TLS/SSL – Transport Layer Security / Secure Sockets Layer .......79
5.8 Comparação entre protocolos de tunneling ................................................84
6 IMPLEMENTAÇÃO DE UMA VPN ATRAVÉS DO OPENVPN ...............85
6.1 Estudo de caso .............................................................................................85
6.1.1 Cenário .............................................................................................86
6.1.2 Instalação............................................................................................88
6.1.2.1 Decisão quanto ao modo de operação desejado (router ou
bridge) e do nível de segurança requerido ........................................88
6.1.2.2 Download dos módulos necessários para a plataforma
operacional, arquitetura de processador e nível de segurança
adotado ...........................................................................................89
6.1.2.3 Preparação do kernel dos gateways Linux ......................89
6.1.2.4 Instalação dos módulos baixados nos gateways..............90
6.1.2.5 Criação da infra-estrutura de geração e gerenciamento
de chaves de criptografia e outros elementos de segurança..............91
6.1.2.5.1 Geração da PKI.................................................92
6.1.2.5.2 Matriz ..............................................................95
6.1.2.5.3 Filiais e micro standalone (Windows) ..............97
6.1.2.5.4 Geração de parâmetros Diffie-Hellman............97
6.1.2.5.5 Resumo das características de utilização das
chaves e certificados gerados ...........................98
6.1.2.6 Preparação do arquivo de configuração da Matriz e
setup dos demais elementos necessários ao funcionamento do
OpenVPN ...........................................................................................99
6.1.2.7 Preparação dos arquivos de configuração das Filiais e
setup dos demais elementos necessários ao funcionamento do
OpenVPN ....................................................................................107
6.1.2.8 Instalação e configuração do OpenVPN no micro
standalone (ambiente Windows).................................................. 112
7
CONSIDERAÇÕES FINAIS E FUTUROS TRABALHOS..........................119
REFERÊNCIAS........................................................................................................... 123
ANEXOS .........................................................................................................................125
ANEXO I - O algoritmo Diffie-Hellman..........................................................125
APÊNDICES........................................................................................................................127
APÊNDICE A - Comparativos entre OpenVPN e VPNs IPSec ......................127
APÊNDICE B - Características do OpenVPN .................................................128
15
1 INTRODUÇÃO
Nos últimos anos têm ocorrido grandes mudanças na área de tecnologia da informação,
abrangendo tanto o hardware, o software e a infra-estrutura de comunicações, como também
as formas de distribuição de conteúdos através da Internet.
Inicialmente as redes locais de computadores eram utilizadas basicamente para o
compartilhamento de seus recursos e aplicações, sem muita preocupação com aspectos de
segurança. As razões para isso eram diversas: a abrangência física da rede era limitada, o
número de usuários era pequeno, as aplicações eram menos críticas no quesito
disponibilidade, etc.
Com o advento da internet comercial e com a.crescente necessidade de comunicação entre as
redes locais, incluindo o acesso a sistemas remotos, tornou-se necessária a adoção de uma
política de segurança que garantisse o funcionamento desse conjunto de forma segura e
confiável. Vários métodos foram desenvolvidos com este objetivo, entre eles a VPN (Virtual
Private Network - Rede Privada Virtual.).
Antes do surgimento do conceito de VPN, as comunicações entre as várias localidades de uma
empresa eram feitas através de serviços de frame relay, linhas privadas, servidores de acesso
remoto e modems. Apesar de serem seguras e apresentarem grande disponibilidade, essas
tecnologias tinham um custo elevado e pouca escalabilidade.
A cada nova filial a ser
conectada à rede da empresa, entre outras situações possíveis, uma nova conexão dedicada
deveria ser adicionada.
A tecnologia utilizada pela VPN consiste em criar "túneis virtuais" de comunicação entre as
redes que se deseja interligar, fazendo com que os dados trafeguem por eles de forma
criptografada. A criptografia é imprescindível, uma vez que o meio físico de interligação, por
questões de custo e abrangência geográfica, é a própria Internet.
Como benefício adicional, a VPN permite expandir a quantidade de computadores que podem
ter acesso a essa rede, sem investimentos em infra-estrutura extra. Permite também o suporte a
usuários móveis, sem a utilização de modems ou servidores de acesso remoto, ajudando a
16
aumentar a flexibilidade e diminuir os gastos com equipamentos extras.(SCRIMGER et al,
2002).
1.1 Objetivo geral
Este trabalho propõe-se a demonstrar a funcionalidade e a segurança da tecnologia VPN, em
ambiente Linux, utilizando a solução de software livre OpenVPN, Para isso, será utilizado um
cenário de integração matriz-filial com links de comunicação ADSL.
A configuração de uma VPN requer inicialmente a escolha do sistema operacional dos
gateways e a ferramenta que será usada para implementar os protocolos adotados. Existem
várias ferramentas disponíveis no mercado, com preços variados ou totalmente gratuitas. Este
estudo preocupou-se com três fatores básicos: segurança, usabilidade e baixo custo de
implementação. Por isso, foi utilizado o Linux, sistema operacional bastante flexível, podendo
ser configurado com o mínimo de opções necessárias, de forma a garantir maior segurança da
rede. Além disso, por ser de livre distribuição e estar disponível gratuitamente através da
Internet, reduz drasticamente os gastos com licenças, o que se reflete no custo total de
propriedade.
A distribuição escolhida foi a Fedora, derivada do Red Hat, pois além de ser largamente
utilizada em servidores do mundo inteiro, sendo reconhecida por sua estabilidade, foi a
utilizada nos exercícios de laboratório do curso de pós-graduação ao qual se relaciona este
trabalho, o que garante bastante familiaridade com suas particularidades.
Em relação à solução de VPN, foi observado inicialmente uma predominância quase absoluta
de soluções baseadas no protocolo IPSec. Percebeu-se um market share1, entre soluções
proprietárias e livres, em torno de 60% (RENDON, 2004). Na literatura sobre VPNs foi
observada a mesma predominância. Analisadas as razões, constatou-se que requisitos como
robustez, segurança, aderência a padrões de mercado, variedade de recursos, entre outros,
justificavam tal posição. No mundo do software livre o IPSec estava representado pelo
OpenS/Wan (derivado do antigo FreeS/Wan), tendo sido a solução de VPN utilizada nos
exercícios de laboratório do curso de pós-graduação citado. A partir dessas observações, e da
1
Participação de mercado.
17
rejeição à idéia de produzir apenas mais um trabalho sobre o tema, foi levantado o seguinte
questionamento: EXISTE OUTRO PROTOCOLO CAPAZ DE FAZER FRENTE AO IPSEC
EM RELAÇÃO ÀS CARACTERÍSTICAS CITADAS, COM DISPONIBILIDADE DE
SOLUÇÕES OPEN SOURCE? A resposta foi SIM, obtida através de pesquisas na Internet,
quando travou-se contato com o OpenVPN, solução baseada no protocolo TLS/SSL. Pelas
características básicas exigidas (as mesmas citadas antes para as soluções IPSec), aliadas a
facilidade de configuração, disponibilidade como freeware para vários sistemas operacionais,
incluindo o Microsoft Windows e, principalmente e por conviver de forma amigável com
redes baseadas em NAT e IP dinâmico, a ferramenta adotada acabou sendo o OpenVPN.
Como é comum em se tratando de softwares open source e completamente gratuitos (Linux e
OpenVPN), as orientações para instalação e configuração foram obtidas principalmente da
Internet, através de material disponível on-line.
1.2 Objetivo específico
Sedimentar e ampliar os conhecimentos adquiridos no curso pós-graduação em segurança de
redes com Linux, ministrado pela FACULDADE SALESIANA no período de 2004 a 2006, e
que se relacionam com o projeto proposto: segurança de redes, métodos de criptografia,
criptografia de chave pública, geração e utilização de certificados digitais, protocolos de
segurança, conceitos de firewall, conceitos de VPN, entre outros.
1.3 Metodologia de trabalho
Após tomada a decisão sobre o tema VPN e escolhida a ferramenta OpenVPN, o trabalho
voltou-se para a construção de um estudo de caso envolvendo um cenário de interligação
matriz-filial, com suporte adicional a micros isolados acessando a matriz.
Procurou-se
conceituar os aspectos relevantes de implementação, o que exigiu algumas escolhas entre as
alternativas suportadas.
Foram então aferidos os aspectos escolhidos para análise de
resultados: flexibilidade de uso, segurança e comportamento nas condições adversas adotadas
(links com IP dinâmico em todas as pontas). Ao longo do trabalho, foram conceituados os
18
diversos elementos utilizados no projeto: redes, protocolos de rede, TCP/IP, ataques comuns
na Internet, segurança na Internet, protocolos de segurança, etc.
1.4Organização do texto
Este capítulo trata da introdução do trabalho, dos seus objetivos, da metodologia adotada e
resume o conteúdo dos diversos capítulos.
O capítulo 2 aborda os princípios de comunicação nas redes de computadores, bem como
questões de segurança, conceituando os fatores de segurança e descrevendo os tipos de ataque
mais comuns.
O capítulo 3 explica o modelo de quatro camadas do TCP/IP, expondo de forma resumida
cada uma delas. Os conceitos abordados neste capítulo são fundamentais para o entendimento
do funcionamento da VPN, e de algumas decisões de implementação adotadas.
O capítulo 4 contém informações relevantes a respeito dos métodos de defesa adotados nas
VPNs, sendo abordados temas como criptografia, protocolos de cifragem, protocolos
para troca de chaves, mecanismos de hashing, assinaturas e certificados digitais, entre
outros.
O capítulo 5 trata exclusivamente dos conceitos concernentes as VPNs, sendo observadas as
suas principais características, seus elementos, as topologias e as vantagens e desvantagens do
seu uso em comparação com outras tecnologias. Também aborda e compara alguns dos
principais protocolos usados no estabelecimento de VPN´s.
O capítulo 6 mostra em detalhes como uma VPN experimental utilizando o OpenVPN foi
implementada, descrevendo o ambiente de testes e os aspectos relevantes de sua configuração,
além dos resultados obtidos.
Por fim, no capítulo 7, vêm as considerações finais e sugestões para trabalhos futuros
relacionados ao tema.
19
2 PRINCÍPIOS DE SEGURANÇA DA INFORMAÇÃO NAS REDES
Este capítulo trata dos princípios da segurança que se aplicam às atividades da área de
tecnologia da informação, através dos quais se busca, utilizando ferramentas adequadas de
hardware e de software, evitar os riscos de vazamento de dados, uso indevido ou roubo de
informações, interceptação de senhas, indisponibilização de serviços, ou qualquer outro tipo de
ameaça que possa causar prejuízo e descontinuidade de serviços para as organizações.
As redes de computadores surgiram como resposta à necessidade da troca de informações,
permitindo o acesso a dados localizados fisicamente a distâncias consideráveis.
Com as sucessivas reduções no custo dos insumos de informática observadas nos últimos anos,
é comum que uma empresa possua uma ou várias filiais com suas próprias redes de
computadores. Em geral, porém, elas não têm qualquer ligação entre si, fato que se deve
principalmente ao fator custo. Este, por sua vez, está relacionado, em alguns casos, à grande
distância geográfica existente entre elas. Apesar disso, a troca de informações, boa parte das
quais sigilosas, é essencial. Com o objetivo de dar suporte a essa necessidade, diversos
métodos foram desenvolvidos para interligar essas redes de forma segura.
Atualmente, a Internet é o meio público mais utilizado para a troca de informações entre
organizações ou entre diferentes localidades de uma mesma empresa. A VPN constitui uma
das principais formas de interligação dessas redes, sendo comum a utilização de meios
públicos de transmissão de dados, dentre eles a Internet . A principal característica da VPN é a
criação de “túneis virtuais” de comunicação entre as redes, de tal forma que os dados
trafeguem embaralhados ou criptografados.
De acordo com Cyclades “A principal motivação para a implementação de VPNs é financeira
[...]”. Tal percepção tem despertado um interesse crescente de empresas com diversas filiais
que necessitam de uma forma econômica de comunicação, a adotarem esta tecnologia.
(CYCLADES, 2000)
Outra característica que as VPNs possuem é a escalabilidade. Uma vez implantado um site de
acesso (matriz ou filial), pode-se adicionar novos computadores à rede local, com pleno
acesso aos demais sites que fazem parte da VPN, sem investir em infra-estrutura extra.
20
O suporte a usuários móveis também é garantido pela tecnologia, que dispen s a a
m anut enção de i números modems, linhas telefônicas e servidores de acesso remoto.
A correta utilização das ferramentas de VPN, combinada com outras ferramentas de
segurança e com medidas de controle adequadas, proporciona um ambiente seguro e
organizado e concede benefícios diversos: aumento de produtividade, funcionamento
contínuo e sem interrupção das aplicações e ambiente seguro para as informações da
empresa.
2.1 Redes de computadores
Para Tanenbaum, “uma rede de computadores é um conjunto de computadores autônomos
interconectados, trocando informações entre si, através de fios de cobre, fibras ópticas, links
de rádio, microondas, satélites de comunicação, entre outros”, a Figura 1, composta por cinco
computadores, uma impressora e um hub2, demonstra um exemplo de rede de computadores.
(TANENBAUM, 1997)
Figura 1 – Rede de computadores
A tecnologia de interligação de computadores e periféricos em redes foi criada objetivando
inicialmente compartilhar recursos entre os seus usuários, tais como aplicações, equipamentos
2
Dispositivo de baixo custo, responsável por concentrar as conexões dos equipamentos de uma rede local,
repetindo os sinais recebidos para todas as suas portas. Assim, sua forma de trabalho é mais simples se
comparada à de um switch ou de um roteador.
21
e dados.
Tal compartilhamento deveria se dar de forma transparente, independendo da
localização física dos usuários ou dos próprios recursos.
Três itens foram fundamentais para o desenvolvimento das redes: a confiabilidade (duas ou
mais fontes alternativas de fornecimento do mesmo dado), a escalabilidade (possibilidade de
aumentar os recursos gradualmente, à medida que isso se mostra necessário) e a economia de
custos (troca de caríssimos computadores de grande porte – mainframes – por um maior
número de computadores pessoais de preço accessível).
Um exemplo de rede mundialmente difundida é a Internet, que possui milhões de
computadores interconectados trocando as mais diversas informações, tais como email,
arquivos, páginas web pessoais e corporativas, blogs, vídeos, etc...
2.2 Protocolos de comunicação
A família de protocolos TCP/IP, por se constituir no protocolo básico da Internet desde a sua
criação, é amplamente utilizado para a comunicação tanto na rede local quanto entre redes.
Por razões históricas, o projeto do TCP/IP não deu ênfase às questões de segurança. Trata-se,
portanto, de um protocolo muito inseguro. As aplicações que demandam algum nível de
segurança devem agregar novas funcionalidades ao protocolo original. Isso pode ser feito
adicionando novos cabeçalhos ou novas camadas, o que, em ambos os casos, significa
introduzir um novo protocolo. Dada sua importância, no capítulo seguinte é mostrado em
detalhes o TCP/IP, com todos os seus principais protocolos e conceitos associados.
2.3 Fatores de segurança da informação na comunicação
Dado que o TCP/IP por si só não provê mecanismos para uma comunicação segura e
confiável entre dois nós de rede, foram desenvolvidas ao longo dos anos ferramentas que
buscam fechar essa lacuna. Essas ferramentas serão mais detalhadas no capítulo 4.
Além dos problemas intrínsecos do TCP/IP, outros fatores de risco existem, situando-se no
22
âmbito do sistema operacional, dos protocolos e dos aplicativos: falhas de programação que se
traduzem em vulnerabilidades exploráveis por atacantes. As principais origens das
vulnerabilidades são:
-
Deficiências de projeto: provocam brechas de segurança no hardware ou no software;
-
Deficiências de implementação: instalação/configuração incorreta, por inexperiência, falta de
treinamento ou desleixo;
-
Deficiências de gerenciamento: procedimentos inadequados, verificações e monitoramentos
insuficientes.
Exemplos de situações que podem ter como conseqüência o surgimento de vulnerabilidades:
-
Software: limites mal definidos, bugs no projeto ou na programação, algoritmos deficientes em
função de situações não previstas;
-
Instalação física: má proteção física de equipamentos e de mídias contendo dados;
-
Mídia: roubo, perda, danificação, desgaste não controlado de discos, fitas etc...
-
Transmissão: interceptação de sinal, monitoramento, grampo;
-
Humana: incompetência técnica, desleixo, preguiça, ganância, revolta, e outras.
Assim, considerando que o meio de comunicação e os dispositivos que possibilitam o acesso a
ele são vulneráveis, as entidades envolvidas na troca de informações pela rede devem garantir
a segurança e o sigilo, além de estar preparadas para se defender de atacantes que conhecem e
exploraram tais vulnerabilidades.
Quando se fala em Internet, essa preocupação torna-se ainda maior. Com sua popularização
crescente nas empresas, o risco das informações serem acessadas ou alteradas é grande, pois,
em tese, qualquer pessoa conectada à rede pode vir a tomar posse delas, caso não estejam bem
protegidas.
Segundo Margi, as principais funções de segurança são: (MARGI, 2000)
-
Autenticidade: Procura certificar-se que a pessoa com quem se está trocando
informações sigilosas é quem realmente deveria ser. A verificação de autenticidade é
necessária após qualquer processo de identificação, seja de usuário para sistema, de
sistema para usuário ou de sistema para sistema;
23
-
Confidencialidade: Consiste em proteger a informação contra leitura ou cópia por alguém
que não tenha sido explicitamente autorizado pelo seu proprietário. Isso é feito geralmente
através do uso de criptografia;
-
Integridade: D e v e a ssegurar que os dados não serão alterados durante s u a
transmissão;
-
Controle de acesso: Limita o acesso e a utilização de recursos apenas a pessoas
autorizadas. Acessos desconhecidos ou feitos por elementos não autorizados colocam a
necessidade de uma verificação em todos os recursos envolvidos em busca de possíveis
danos que possam ter sido causados ao sistema, mesmo que nenhuma evidência disso tenha
sido percebida;
-
Disponibilidade: Consiste na proteção dos serviços prestados pelo sistema de forma que
eles não sejam degradados ou tornem-se indisponíveis sem autorização. Deve manter os
recursos disponíveis, mesmo em caso de ataques;
-
Não-repúdio: Impede que uma entidade (computador, pessoa, etc.) envolvida em uma
transação de transmissão ou de recepção de dados, negue a sua participação nela;
-
Auditoria: Consiste na capacidade de verificação das atividades do sistema e
determinação do que foi feito, quando, por quem e o que foi afetado. Aplica-se não apenas
à verificação das atividades de usuários não autorizados, mas também de usuários
autorizados, que podem cometer erros ou executar ações maliciosas no sistema.
2.4 Ameaças
Para tornar uma rede mais segura e confiável, deve-se estar atento às principais ameaças que
podem comprometer a integridade das informações nela existentes. Ao contrário do que se
pensa, nem sempre o inimigo está fora da rede, como um hacker3 ou cracker 4, mas
event ualm ente dentro dela, como por exemplo um funcionário mal intencionado, que
geralmente possui livre acesso aos recursos disponíveis.
As ameaças são classificadas em dois tipos: passivas e ativas. Uma ameaça é dita passiva
quando o sistema continua sua operação sem a percepção de ter um invasor na rede e,
geralmente, tem como conseqüência o roubo de informações. Uma ameaça ativa ocorre
quando o invasor prejudica o sistema, atingindo os dados ou degradando os serviços.
(BATISTA, 2002)
3
4
Indivíduo hábil em enganar os mecanismos de segurança de sistemas de computação.
O mesmo que hacker, mas com o intuito de roubar, alterar ou apagar as informações da rede invadida.
24
Os principais tipos de ataques, descritos por Margi, são mostrados a seguir de forma
esquemática. (MARGI, 2000)
2.4.1 Processo Normal
A Figura 2 ilustra um processo normal para efeito de comparação.
Figura 2 – Fluxo normal de dados
2.4.2 Interceptação
Ataca a confidencialidade. É um ataque passivo, conforme a Figura 3.
Figura 3 – Interceptação
2.4.3 Interrupção
Ataca a disponibilidade. É um ataque ativo como demonstrado na Figura 4 a seguir.
Figura 4 – Interrupção
25
2.4.4 Modificação
Ataca a integridade. É um ataque ativo, conforme a Figura 5.
Figura 5 - Modificação
2.4.5 Fabricação
Ataca a autenticidade. O invasor se faz passar por uma origem conhecida do destino e simula
uma comunicação falsa. É um ataque ativo como ilustrado na Figura 6.
Figura 6 – Fabricação
26
2.5 Principais ameaças e ataques às redes de computadores
A World Wide Web (Web) foi projetada sem muita, ou quase nenhuma, preocupação, com
segurança. O objetivo principal era disponibilizar informações de uma forma mais amigável
que os recursos disponíveis na época. Com o rápido crescimento da Web e com a
diversificação de sua utilização, a segurança se tornou um ponto de importância crucial.
2.5.1 Vírus
É um programa ou fragmento de código, incapaz de funcionar de forma autônoma, requerendo
por isso um programa hospedeiro, ao qual se anexa. Uma vez instalado num sistema, entra em
operação quando o programa infectado é executado. Utiliza uma técnica de autopropagação,
sendo capaz de infectar outros programas presentes no mesmo sistema ou alcançar outros
sistemas através de emails com anexos infectados.
2.5.2 Verme (Worm)
Em geral, é um programa independente (autônomo), característica que o diferencia dos vírus.
Sua concepção faz com que se propague procurando outros sistemas através das conexões de
redes acessíveis ao sistema infectado. Atualmente existem programas de intrusão que reúnem
características de vírus e worms.
2.5.3 Cavalo de Tróia (Trojan horse)
Programa que se apresenta com tendo uma determinada finalidade, que realmente tem, mas,
adicionalmente e de forma secreta, possui uma segunda função cujo objetivo é abrir o
computador para invasões, acessos remotos ou roubo de informações (senhas, por exemplo).
2.5.4 Back door (Porta dos fundos)
Função não documentada de um programa de conexão ou autenticação, criada secretamente
por quem o projetou ou programou. Em geral, objetiva permitir ou facilitar o acesso a um
27
sistema, ou ainda permitir o acesso privilegiado a alguém. É comum que um hacker, após
invadir um sistema, instale uma back door que lhe permita retornar futuramente caso o usuário
ou administrador do sistema invadido descubra que sua segurança foi violada. Pode estar na
forma de um programa executável, de um script (muito comum no mundo Unix) ou de
elementos do sistema (exemplo: uma conta de usuário com nome comum, mas com
privilégios de administrador). Essas várias formas da back door a diferenciam dos trojans,
que são sempre arquivos executáveis.
2.5.5 Bomba lógica (Logic Bomb)
Programa ou seção de um programa projetado para executar alguma atividade ilegal
relacionada com intrusão, mas com a característica particular de ser ativado por determinada
condição lógica.
2.5.6 Port scanning (Varredura de portas5)
Técnica de reconhecimento bastante utilizada por hackers. Consiste num programa que
procura descobrir as portas associadas aos daemons em execução no sistema que se deseja
invadir. De posse dessas informações, o hacker pode planejar o ataque utilizando alguma
vulnerabilidade daquele daemon.
2.5.7 Estouro de buffer (Buffer overflow)
Consiste em enviar para um programa que espera a digitação de um dado qualquer uma
informação que excede o tamanho previsto, ou que seja inconsistente com o padrão de
armazenamento requerido para aquele dado. Isso só é possível em programas que não tratam
ou tratam de forma inadequada a consistência dos dados de entrada. A conseqüência é a
desestruturação do código em execução, permitindo que código estranho seja introduzido e
executado. Esse “código estranho” pode fazer parte da entrada de dados não consistida. Outra
5
Porta (port) é representada por um número situado entre 1 e 65535 cuja função é identificar a aplicação à qual o
processo de comunicação se refere (vide capítulo 3 – item 3.2.1)
28
possibilidade é que esses dados entrados de forma maliciosa forneçam uma chamada para a
execução de um programa já presente no sistema ou localizados remotamente. Nas formas
mais comuns de buffer overflow, cujas vítimas são servidores web ou ftp, o atacante submete
uma URL6 muito grande (acima de 150 caracteres) que faz com que os servidores parem de
responder.
2.5.8 Quebra de senha (Password cracking)
Também conhecido como ataque de força bruta. Ocorre quando se tenta várias possibilidades
de senha para ver se uma delas coincide. É comum o uso de “dicionário” de
palavras/expressões comuns para balizar as tentativas. Existem muitos programas quebrasenha disponíveis para a maioria dos sistemas operacionais e de rede.
2.5.9 Engenharia social
Utiliza métodos não-técnicos para obter acesso a um sistema, em geral através de processos de
persuasão, que levam alguém a revelar informação sigilosa. Exemplo típico: ligar para alguém
pertencente ou com acesso aos sistemas de uma empresa, identificando-se de forma
convincente como um elemento pertencente à área de suporte técnico, e inventar uma história
para solicitar a senha de acesso da vítima.
2.5.10 Sniffing (Monitoramento, “grampo”)
Consiste no monitoramento dos pacotes transitando na rede. É um processo passivo. Muitas
vezes são usadas ferramentas de fabricantes ou comerciais, criadas com propósitos legítimos
(gerenciamento e manutenção). As informações obtidas são endereços IP, senhas, usernames,
etc. Baseia-se no fato de que algumas aplicações (telnet, por exemplo) não criptografam as
senhas digitadas pelo usuário, fazendo com que trafeguem livremente até o servidor.
6
Uniform Resource Locator – Define o protocolo de acesso e o endereço de uma informação na Internet, sendo
utilizada nas aplicações, incluindo os web browsers, para fins de endereçamento.
29
2.5.11 DoS - Denial of Service (Interrupção de Serviço)
Ação que interrompe um serviço ou impede totalmente seu uso por usuários/entidades
legítimos. O objetivo principal é “tirar do ar” (indisponibilizar) um serviço, apenas para
causar transtorno/prejuízo, ou para eliminar uma proteção que assim permitiria ao hacker
utilizar outras formas de acesso não autorizadas.
Os tipos de ataques DoS mais comuns são:
-
Consumo da banda de rede: o atacante possui banda maior que a da rede alvo ou vários
atacantes atuam simultaneamente para provocar a sobrecarga;
-
Consumo de recursos de sistema: visa criar situações de abuso ou sobrecarga que
ultrapassem o limite de determinado recurso (buffer, HD...);
-
Adulteração de rotas/DNS: ao invés de desativar um serviço, impede o acesso ao serviço
legítimo (DNS Poisoning, já visto anteriormente).
A exploração de falhas conhecidas do ambiente ou do software que têm como conseqüência a
interrupção de determinado serviço.
2.5.12 SYN Flooding (Inundação de SYN7)
Ataca o handshake de 3-vias (3-way handshake) do estabelecimento de conexão TCP. O
cliente envia uma sequüência SYN; o servidor o reconhece e responde com um SYN-ACK; o
cliente reconhece a resposta enviando ACK8 e inicia a transferência de dados. A Figura 7
mostra o processo normal de estabelecimento de uma conexão TCP.
Figura 7 – TCP Handshake
7
SYN (Synchronize sequence number) – pacote enviado por um dispositivo de rede ao seu destinarário para
indicar que deseja iniciar uma conexão TCP.
8
ACK (Aknowledgement packet) – pacote de confirmação que o destino envia à origem para sinalizar que
recebeu corretamente os dados enviados através de uma rede.
30
O ataque consiste em enviar SYNs e não responder aos SYN-ACK, deixando em aberto os
processos de estabelecimento de conexão até ocupar todos os buffers de conexão do servidor.
Com isso, outros clientes não conseguem iniciar conexões legítimas e o ataque pode derrubar
o sistema operacional se a situação consumir toda a memória livre do servidor. A Figura 8
mostra esse processo.
Figura 8 – SYN Flooding
2.5.13 Ping da Morte (Ping of Death)
O ping é um comando do TCP/IP que envia um pacote IP para um endereço, para testar se ele
existe e está “vivo”. Um sistema vulnerável não trata adequadamente pacotes ICMP (pacote
de controle da camada IP) maiores do que o normal. O ataque é feito enviando uma seqüência
de pings com tamanho máximo (muito maior que o comum), que sobrecarregam o sistema
atacado. Portanto, trata-se de um tipo de ataque que explora uma vulnerabilidade.
2.5.14 Spoofs
São ataques baseados na falsificação ou disfarce da identidade do atacante. Existem vários
ataques desse tipo desse tipo, sendo os principais mostrados a seguir.
2.5.14.1 IP Spoofing
Conforme será detalhado no capítulo 3, todo dispositivo em rede TCP/IP tem um endereço IP
único, que é sua identificação (ex: 141.31.48.18). A técnica consiste em atribuir à máquina
31
invasora um IP que possa ser aceito pelos sistemas de validação (roteador, firewall) da rede
na qual se situa o servidor alvo do ataque.
2.5.14.2 Sequence Number Spoofing
Também conforme será detalhado no capítulo 3, conexões de rede TCP/IP usam números de
seqüência, incluídos nas transmissões e incrementados por transação. Se o algoritmo de
geração de números é previsível, um hacker pode monitorar a conexão, gravar a troca de
números de seqüência e prever os próximos para se inserir na conexão.
2.5.14.3 Man-In-the-middle (Homem no meio)
Consiste numa técnica em que o invasor se interpõe entre dois computadores que se
comunicam. O tráfego entre os dois computadores é interceptado, de forma imperceptível
para ambos. O invasor então altera os dados transmitidos de forma a atingir seus objetivos. É
um ataque difícil de ser implementado por exigir do invasor grande conhecimento de
programação e das características das redes nas quais se inserem os computadores alvo. A
Figura 9 a seguir ilustra como isso acontece.
Figura 9 – Ataque man-in-the-middle
2.5.14.4 Redirecionamento
Consiste em inserir links para destinos falsos. O usuário pensa que está se comunicando com
determinada entidade, quando na verdade foi redirecionado para outro servidor que se
32
comporta aparentemente como o original. O exemplo mais corriqueiro desse tipo de ataque é
aquele em que os usuários de home banking são direcionados para uma página falsa que
emula o layout e forma de interação da página original. Com isso, o invasor consegue capturar
a senha e outros dados do usuário.
2.5.14.5 DNS spoofing
Consiste em alterar o endereço IP associado a determinado hostname9, no servidor DNS do
domínio daquele hostname. Exemplo: quando alguém fizer um acesso ao host identificado
pelo hostname www.bancodobrasil.com.br, a consulta ao servidor DNS do domínio
bancodobrasil.com.br retornará um IP que não corresponde ao IP do site do Banco do Brasil,
mas a outro site previamente preparado para isso. Tal ataque requer a invasão do servidor
DNS do domínio do servidor alvo.
2.5.14.6 Envenenamento de DNS (DNS Poisoning)
Baseia-se no fato de que as consultas mais freqüentes feitas a um servidor DNS são
armazenadas em cache para facilitar futuras consultas (da próxima vez, não será mais
necessário um acesso físico para obter a resposta, uma vez que ela já se encontra disponível).
O ataque consiste em alterar o IP da máquina alvo no cache DNS, de forma a se obter uma
resposta que direciona o acesso para uma máquina previamente preparada, tal como ocorre no
DNS spoofing.
2.5.14.7 Smurf
O atacante envia uma mensagem ICMP do tipo ECHO REQUEST fazendo spoofing do
endereço de origem (substituindo-o pelo endereço IP da máquina alvo do ataque) e solicitando
uma resposta (ICMP ECHO REPLY) a todas as máquinas da rede escolhida para desferir o
ataque. A rede inteira responde para a máquina alvo real enviando o ECHO REPLY, o que
sobrecarrega a rede e o sistema alvo. A Figura 10 ilustra o que ocorre.
9
Hostname - Nome que identifica um computador ou outro recurso na rede.
33
Figura 10 – Ataque Smurf
34
3 A ARQUITETURA TCP/IP DE QUATRO CAMADAS
O TCP/IP é um conjunto de protocolos de interconexão de sistemas que utiliza uma
arquitetura de quatro camadas. Cada camada desse modelo consiste de um conjunto de
protocolos que são referenciados como “conjunto de protocolos TCP/IP” (TCP/IP protocol
suíte). As quatro camadas são: acesso à rede, internet, transporte e aplicação.
A Figura 11 mostra a disposição das quatro camadas, sendo suas posições relativas importante
porque definem o interfaceamento entre elas e delas com as aplicações de rede e com a rede
física.
Figura 11 – O modelo de quatro camadas do TCP/IP
Cabe observar que não existe uma correspondência exata em termos de agrupamento das sete
camadas do modelo OSI nas quatro camadas da arquitetura TCP/IP. Por exemplo, a camada 3
do modelo OSI (rede) corresponde à camada 2 do TCP/IP (internet), enquanto a camada de
transporte e parte da camada de sessão do modelo OSI correspondem à camada de transporte
do TCP/IP.
35
O funcionamento do modelo de camadas baseia-se na adição de cabeçalhos aos dados
transmitidos pela aplicação, em cada camada, e, no lado receptor, pela sua extração à medida
em que ocorre o processamento nas respectivas camadas. Os dados contidos nos cabeçalhos
contêm informações importantes para o transporte físico e para o processamento. No lado
emissor, cada camada, começando pela de aplicação, insere o seu cabeçalho, e trata a
mensagem recebida da camada superior como se fossem apenas dados. Assim, a mensagem
vai ganhando novos cabeçalhos de controle à medida em “desce” pela pilha TCP/IP, até ser
transmitida pelo meio físico.
No lado receptor, os cabeçalhos vão sendo retirados e
processados por cada camada, na medida em que “sobem” pela pilha. Quando a mensagem
chega à aplicação de destino, está livre de cabeçalhos de controle e corresponde exatamente à
informação transmitida pelo emissor.
A Figura 12 ilustra o fluxo de dados pela pilha TCP/IP entre dois hosts (A e B) com um
roteador entre eles.
Figura 12 – Fluxo de dados entre as camadas da pilha TCP/IP
36
3.1 Camada de aplicação
Funciona como uma interface de ligação entre os processos de comunicação de rede e as
aplicações utilizadas pelo usuário. Não se deve confundir a camada de aplicação com as
aplicações do usuário propriamente ditas.
Por exemplo, o protocolo SMTP situa-se na
camada de aplicação, mas um usuário não o utiliza diretamente. Ao invés disso, faz uso de
um programa cliente de correio eletrônico, que por sua vez utiliza o protocolo SMTP para
enviar emails. Cabe observar também que elementos da camada de aplicação podem estar
implementados no próprio sistema operacional, e não necessariamente em ferramentas de
terceiros.
É de vital importância perceber que as aplicações de rede normalmente requerem dois
programas separados: um módulo servidor (server) e um módulo cliente (client). O módulo
servidor geralmente é executado em background e é iniciado quase sempre junto com o
sistema operacional, sendo referenciado pelo termo “daemon”. Do outro lado do link de rede,
um usuário executa o módulo cliente.
Nesta camada, os hosts são referenciados (endereçados) por um nome, conhecido como
hostname.
Em aplicações voltadas para a Internet, utiliza-se uma hierarquia de nomes
baseada em domínios e sub-domínios. Exemplo de um hostname completamente identificado
(fully qualified hostname) seria: ftp.milmicroscorp.com.br, cuja interpretação seria: o host
“ftp” pertence à organização “milmicroscorp”, que situa-se no sub-domínio “com” e no
domínio “br”. Em outras palavras, identifica o servidor de ftp da empresa milmicroscorp, que
pertence ao mundo das empresas comerciais (.com) e situa-se no Brasil (.br). Esse host ftp
possui um endereço IP, que está associado ao seu hostname. Essa associação é mantida por
um sistema de abrangência global chamado DNS (Domain Name Service).
Exemplos de protocolo: File Tranfer Protocol (FTP), Telnet, Simple Network Management
Protocol (SNMP).
37
3.2 Camada de Transporte
Fornece serviços de entrega fim-a-fim, entre servidor e cliente. Entre suas principais funções
pode-se citar a organização das mensagens recebidas das camadas mais altas em segmentos de
tamanho menor, o controle de erros e o controle de fluxo fim-a-fim. Os protocolos dessa
camada são o UDP e o TCP.
3.2.1 Portas
Um conceito importante do mundo TCP/IP é o número de porta (port number) ou
simplesmente porta. A cada aplicação de rede rodando num determinado computador (host) é
associada uma única porta. Essa associação ocorre na camada de transporte. De forma
simplificada, a porta pode ser vista como o endereço da aplicação dentro do host.
O
cabeçalho dessa camada especifica sempre uma porta de origem e uma porta de destino. Se,
por exemplo, um host deseja estabelecer uma sessão telnet com outro host, ele definirá a porta
de destino como 23 (porta padrão da aplicação telnet) e a de origem como um número acima
de 1.023 (as portas abaixo de 1.024 são reservadas para serviços padronizados). Os números
de porta podem ir até 65.535. Assim existem 65.535 portas TCP e 65.535 portas UDP.
Algumas portas padronizadas são mostradas no Quadro 1.
Serviço
FTP
DNS
SMTP
POP3
SNMP
Descrição
File Transfer Protocol
Domain Name Service
Simple Mail Transfer Protocol
Post Office Protocol
Simple Network Management Protocol
Porta
21
53
25
110
161
Protocolo
TCP
UDP
TCP
TCP
UDP
Quadro 1 – Portas padronizadas
3.2.2 Sockets
Outro conceito importantíssimo é o de soquete (socket). Os sockets são a base para o
estabelecimento da comunicação numa rede TCP/IP. Cada conexão possui um socket
associado, que é composto de três informações: 1º) os endereços IP de origem e destino; 2º)
As portas de origem e destino e 3º) protocolo de transporte utilizado. Exemplo de um socket
38
seria: IP de origem 201.23.234.5, IP de destino 201.39.124.35, porta de origem 2.345, porta
de destino 22, protocolo de transporte TCP. O socket é único para cada conexão.
3.2.3 TCP – Transmission Control Protocol
É um protocolo orientado a conexão (connection-oriented protocol). A comunicação que um
protocolo desse tipo oferece é dita segura com entrega garantida (reliable data delivery).
Nela, os dados são formatados em pacotes (packets) que são seqüenciados e submetidos a um
processo de confirmação de recebimento (acknowledgement), estabelecendo um circuito
virtual de comunicação entre o servidor e o cliente. Caso o emissor do pacote não receba uma
mensagem de confirmação de recebimento (ACK), ocorrerá uma retransmissão. A segurança
da comunicação é garantida por esse mecanismo.
Por questões de desempenho (diminuição do overhead10), não se utiliza acknowledgements
para cada pacote transmitido.
Ao invés disso, os pacotes são agrupados e os
acknowledgements ocorrem por grupo, e não para pacotes individuais.
Esse conceito é
conhecido como “windowing”. Os algoritmos que implementam essa técnica dentro do TCP
são bastante sofisticados e não cabe descrevê-los aqui.
Antes que dados possam ser transmitidos, deve ser estabelecida uma conexão TCP, e o
processo que faz isso recebe o nome de “three-way handshake”. Uma descrição bem resumida
desse processo é ilustrado na Figura 13.
Figura 13 – Processo de handshake do TCP
10
Overhead diz respeito a utilização excessiva de um recurso computacional (processamento, memória, espaço
em disco, largura de banda, etc), provocando uma queda perceptível no desempenho do sistema afetado.
39
Passo 1 - O host que deseja iniciar a comunicação transmite um pacote SYN (Synchronize
Sequence Numbers) para o outro host com o objetivo de informar que uma nova conexão está
sendo requisitada e para estabelecer que número será usado como ponto de partida para
numeração seqüencial das mensagens transmitidas. Esses números seqüenciais são utilizados
pelo protocolo para garantir que os pacotes recebidos serão processados na ordem correta.
Passo 2 - Para que o processo possa prosseguir, o host receptor deve confirmar o
recebimento do pacote SYN e definir o número seqüencial que será usado para o envio de
dados. Isso se dá pelo envio de um pacote SYN, ACK de volta para o host emissor.
Passo 3 - Finalmente, o host emissor envia um pacote ACK para informar ao host receptor
que recebeu sua confirmação do pedido de conexão, e junto com ele envia os primeiros dados.
A partir daí, a comunicação continua com o envio e recepção efetivo de dados.
A comunicação prossegue até que todos os dados tenham sido enviados. Ocorre então um
processo de desconexão semelhante ao de conexão, também em três fases, com o pacote FIN
substituindo o pacote SYN.
Exemplos de aplicações que utilizam TCP são: Telnet, FTP e SMTP.
3.2.4 UDP – User Datagram Protocol
Fornece serviços de entrega sem conexão (connectionless) e sem garantia de sucesso. Ele
transmite os dados pela rede especificando um endereço de destino e assume que eles
chegarão lá. A rede se esforçará para manter os dados intactos e na ordem correta, mas se
existem múltiplos caminhos entre o emissor e o receptor, os pacotes poderão chegar fora de
ordem. Também podem ocorrer perdas ou adulteração dos dados à medida que eles viajam
pela rede. Não há meios de saber se uma mensagem chegou ao seu destino, ou se chegou na
ordem correta. O UDP não se preocupa com essas possibilidades, assumindo que devem
existir mecanismos na camada de aplicação capazes de cuidar desses problemas e de outros.
Tal como o TCP, o UDP também utiliza portas para identificar as aplicações. Uma diferença
importante entre os dois protocolos é que o UDP permite o uso de broadcast de pacotes
(envio de um pacote para todos os hosts de uma rede), ao passo que o TCP não.
40
A decisão sobre usar TCP ou UDP é uma tarefa do desenvolvedor da aplicação de rede. O
TCP, a princípio, parece ser uma melhor escolha, já que ele garante a entrega dos dados.
Entretanto, o overhead decorrente da necessidade de acknowledgements pode tornar a
implementação de certos sistemas impossível. Assim, por ser mais rápido, o UDP pode ser
uma opção melhor para esses sistemas. Exemplos de aplicações que usam UDP são: DNS,
SNMP e OpenVPN.
3.3 Camada de Internet
A principal função dessa camada é rotear pacotes entre diferentes hosts, o que é feito através
de um esquema de endereçamento fornecido pelo protocolo IP (Internet Protocol). Este é o
protocolo principal da camada de internet (equivalente à camada de rede do modelo OSI).
Além do IP, mais um protocolo dessa camada será brevemente descritos: o ICMP (Internet
Control Message Protocol).
3.3.1 IP (Internet Protocol)
O protocolo IP é um protocolo não orientado a conexão e incapaz de garantir a entrega de
pacotes na rede. Se serviços orientados a conexão forem necessários, eles deverão estar
implementados na camada de transporte ou de aplicação. Suas principais funções são:
endereçamento de pacotes entre hosts, roteamento de pacotes entre redes, fragmentação e
remontagem de mensagens e movimentação de dados entre a camada de transporte e a camada
de acesso à rede.
O cabeçalho IP contém muitos campos, sendo os principais o endereço de origem, o endereço
de destino e o TTL (time to live).
41
Para ilustrar o processo de envio de pacotes entre dois hosts, pode-se utilizar como exemplo a
Figura 14 a seguir. Primeiro, PC111 deseja enviar um pacote para PC2. Em seguida, para
PC3. Interessa aqui analisar a diferença entre as duas situações.
Figura 14 – Redes com interligação via roteadores
No primeiro caso (de PC1 para PC2) o exame do endereço de destino do pacote mostra que
PC2 está na mesma rede que PC1 (Rede A). Neste caso, o pacote é enviado diretamente para
PC2.
No segundo caso (de PC1 para PC3), o protocolo IP implementado em PC1, ao analisar o
endereço de destino do pacote, percebe que PC3 não está em sua própria rede (Rede A). O
pacote é então encaminhado para o gateway padrão (default gateway), que nesse caso é o
roteador 2. O roteador 2, por sua vez, também analisando o endereço de destino e sua tabela
de roteamento encaminha o pacote para o roteador 1. O roteador 1 finalmente faz a entrega do
pacote ao seu destino, já que tem uma de suas portas conectadas à Rede C, onde está o PC3.
A definição de gateway padrão ou default gateway é: endereço IP para qual deve ser
encaminhado um pacote cujo endereço de destino não faz parte da própria rede do host
emissor.
11
PC - Personal computer ou computador pessoal. Refere-se a um microcomputador utilizado de forma isolada
(standalone) ou em rede, caso em que é chamado também de estação de trabalho.
42
Conforme pode ser percebido, a função do roteador é encaminhar pacotes de uma rede para
outra. Dito de outra forma, rotear pacotes entre redes físicas diferentes.
O campo TTL do pacote IP é usado para garantir que um pacote não se perca em loops de
roteamento, isto é, fique circulando entre os roteadores da rede eternamente, nunca
alcançando seu destino. A regra que garante isso é que cada vez que um pacote atravessa um
roteador, seu campo TTL é reduzido de uma unidade. Quando esse valor chega a zero, o
pacote é descartado pelo roteador. O valor inicial do campo TTL depende do protocolo de
roteamento utilizado. No caso do RIP (Routing Internet Protocol), esse valor é 15.
Foge aos propósitos deste trabalho um detalhamento maior do esquema de endereçamento IP.
Basta saber que um endereço IP é formado por 32 bits, divididos em quatro partes de 8 bits
cada, sendo cada parte representada por um número decimal na faixa de 0 a 255. Na notação
mais comum, os quatro números são separados por um ponto. Exemplo: 200.276.0.34.
3.3.2 ICMP (Internet Control Message Protocol)
O protocolo ICMP permite que roteadores e hosts enviem mensagens de erro e de controle
entre si. Executa quatro funções principais: 1) Controle de fluxo (flow control) – Quando o
receptor da mensagem está muito ocupado para processar os pacotes que chegam, ele envia
uma “source quench message” para o emissor solicitando uma interrupção temporária do
envio de dados. 2) Alerta de destino inalcançável (unreachable destination) – Enviado
quando é detectado que um endereço IP de destino não é alcançável, ou porque o IP não
corresponde a uma máquina existente na rede, ou devido a uma falha no link de comunicação.
3) Redirecionamento de rota (redirecting routes) – Solicita á máquina emissora que utilize um
outro gateway. Exemplo: um roteador sabe, a partir de sua tabela de rotas, que um pacote
pode alcançar seu destino mais rapidamente através de uma outra rota que não passa por ele.
4) Verificação de host remoto (checking remote hosts) – Através de “ICMP echo messages”
uma máquina pode checar se existe conexão física entre ela e outra através da rede. Para isso,
envia um pacote “ICMP echo request” (conhecido como ping). O destinatário se for
alcançado, responde com um “ICMP echo reply”.
43
3.4 Camada de Acesso à Rede (Network Access)
A camada de acesso à rede relaciona a camada de internet com o harware que efetivamente
efetua o transporte físico dos dados (infra-estrutura composta por cabos, conectores, switches,
etc). É a camada mais baixa da pilha TCP/IP (diferentemente do modelo OSI , nela não foi
definida camada física). O ponto chave a ser entendido aqui é que endereços de rede (IP) não
fazem sentido para essa camada. Os endereços utilizados endereçam os dispositivos
fisicamente e têm significado apenas dentro do segmento de rede no qual o pacote foi
transmitido. Em outras palavras, os endereços da camada de acesso à rede não atravessam
roteadores.
Outro ponto importante é que, diferentemente das camadas superiores, essa
camada precisa conhecer detalhes da infra-estrutura física da rede, a fim de que possa preparar
corretamente os dados para transmissão, o que inclui a utilização de protocolos que definem
as características elétricas e mecânicas da transmissão.
Ainda em relação aos endereços utilizados nessa camada, eles recebem vários nomes que
dependem da tecnologia utilizada: MAC address, para redes locais ethernet ou token-ring, e
hardware address ou physical address para outras tecnologias. O MAC address tem o
tamanho de 6 bytes, e vem gravado de fábrica nas ROMs das interfaces de rede (placas de
rede, portas de switches, portas LAN de roteadores, etc). O exemplo abaixo mostra a notação
mais utilizada para representar esses endereços:
08:CA:00:31:56:AE (seis números hexadecimais de dois dígitos cada)
A figura abaixo ilustra, de forma simplificada, os vários endereços presentes num pacote
ethernet, situando as camadas responsáveis pela adição dos mesmos como parte de seus
respectivos cabeçalhos.
Figura 15 – Localização de endereços num frame Ethernet
44
Uma observação importante diz respeito ao que ocorre com os endereços da camada de acesso
à rede quando o endereço IP de destino localiza-se fora da rede do dispositivo emissor.
Conforme visto anteriormente, os endereços dessa camada não atravessam roteadores, só
sendo reconhecidos na própria rede do emissor. Nesse caso, o roteador alterará os MAC
address de origem e destino, substituindo-os pelo MAC address da sua porta de saída, e pelo
MAC address do destinatário. Portanto, à medida que o pacote “viaja” pela Internet, os
endereços físicos da camada de acesso à rede vão mudando. Os IPs de origem e destino, no
entanto, permanecem inalterados.
45
4 MÉTODOS DE DEFESA
Foi visto no capítulo 3 que as redes conectadas à Internet estão sujeitas a uma gama de
ataques que exploram a diversidade de elementos que compõem o ambiente de TI12 da
empresa: o hardware composto por roteadores, switches, servidores, links de comunicação,
etc; o software, desde os aplicativos voltados para o usuário final, até o sistema operacional e
os protocolos de rede e de segurança; e por fim, os fatores relacionados ao elemento humano:
procedimentos, normas de segurança, regras de acesso, segurança física, etc...
Do ponto de vista tecnológico, de acordo com Scrimger et al “Há dois aspectos da segurança
de uma rede – proteger o acesso aos dados e proteger a transmissão dos dados”. Dessa
forma, a base da segurança de uma VPN está na autenticação entre as partes que se comunicam e
na criptografia das informações que trafegam entre elas. (SCRIMGER et al, 2002)
Além desses dois aspectos, que o software de VPN deve ser capaz de suprir, existem
outros métodos de defesas disponíveis para os mais variados tipos de ataque, que passam
por outras tecnologias que devem atuar de forma complementar. Dada a extensão do assunto,
este trabalho irá limitar-se a explicar de forma simplificada aquelas que são úteis à
implementação de uma VPN.
4.1 Firewall
É uma combinação de hardware e software que tem por objetivo controlar o fluxo de
informações entre as redes privadas e a Internet, comportando-se como uma barreira entre
as duas redes capaz de impedir os acessos não autorizados, conforme mostra a Figura 16 a
seguir.
12
Tecnologia da Informação – Diz respeito ao conjunto de todas as atividades e soluções providas por recursos
de computação.
46
Figura 16 – Exemplo de um Firewall.
Fonte: Adaptadade Scrimger (SCRIMGER et al, 2002)
Uma das possíveis classificações para os firewalls define três tipos: filtros de pacotes,
inspeção de pacotes com tratamento do estado das conexões e aplicativos de firewalls e de
proxy 13 .
O filtro de pacotes é o tipo mais comum de firewall e tem como objetivo permitir ou negar a
entrada de um determinado pacote em uma rede, levando em consideração apenas o
endereço IP e/ ou a porta de origem e de destino. Por atuar apenas sobre as informações
existentes no cabeçalho do pacote IP, não se interessando pelo conteúdo do pacote em si, é
mais barato e rápido que os outros tipos de firewall. Essas seriam as suas vantagens.
Entretanto, por fazer uma filtragem apenas superficial, apresenta a desvantagem de ser mais
inseguro e menos flexível.
O firewall por inspeção de pacotes com tratamento do estado das conexões, além de
desempenhar as funções do filtro de pacotes, é capaz de checar e armazenar o estado de cada
conexão, e tomar decisões com base nele. Apenas as conexões válidas que cumprem as
condições estabelecidas pelo firewall, têm acesso à rede. Essa característica relativa ao
estado das conexões torna-o bastante flexível e poderoso, além de simplifica o projeto das
regras de acesso.
13
Proxy é um servidor que oferece serviços de rede que permitem que computadores clientes façam acessos a
outros servidores de forma indireta, atuando assim como um procurador ou intermediário.
47
Os aplicativos de firewall e de proxy são os mais complexos, pois verificam todos os dados
que passam por eles, podendo bloquear pacotes com base em critérios associados ao seu
conteúdo.
Possuem como vantagens oferecer a maior segurança, além de apresentar a
habilidade de autenticar as atividades dos usuários. P or s erem mais complexos, s ão
também mais lentos e mais caros que os outros dois tipos. São conhecidos também pela
denominação “filtro de conteúdo”.
4.2 Firewall e VPN
Uma VPN permite interligar duas ou mais redes de computadores, provendo um
mecanismo seguro de comunicação, conforme será abordado no capítulo seguinte. Constituise numa ferramenta muito útil para proteger os dados de empresas que necessitam
interconectar suas redes espalhadas geograficamente. Entretanto, ela não é capaz de sozinha
dar conta de todos os aspectos de segurança de uma rede. É imprescindível a utilização de um
firewall, que deve atuar em conjunto com o gateway 14 VPN. Aqui surge uma questão: qual a
localização correta do gateway VPN em relação ao firewall?
Pode-se afirmar que é
necessário um planejamento cuidadoso antes de escolher a melhor das três opções
existentes: gateway VPN e firewall na mesma máquina, em máquinas separadas e em paralelo
ou em máquinas separadas com o gateway VPN atrás do firewall.
O gateway VPN dentro de um firewall, ou seja, ambos no mesmo servidor, parece ser a opção
mais natural, uma vez que toda a segurança da rede é feita em apenas um computador,
conforme ilustra a Figura 17 a seguir. Entretanto, para que isso seja viável, o firewall
deve ser extremamente seguro, uma vez que qualquer configuração imprópria e m s u a s
regras a b r e e s p a ç o p a r a que o tráfego vindo da Internet penetre na rede utilizando
endereços de VPN, sem ser percebido.
14
Gateway é uma máquina intermediária geralmente destinada a interligar redes e com capacidade de traduzir
os protocolos entre elas. O proxies, os firewalls e os “servidores” de VPN atuam como gateways.
48
Figura 17: Gateway VPN dentro de um firewall.
Fonte: Adaptada de Koleniskov e Hatch (KOLENISKOV e HATCH, 2002)
A opção de gateway VPN e m paralelo c o m o firewall, separa o tráfego da VPN do tráfego
da Internet em dois ou mais computadores, c o n f o r m e m o s t r a d o n a F i g u r a 1 8 . Uma
das vantagens da separação é que, devido ao fluxo das informações transmitidas a VPN não
passar pelo firewall, nenhuma configuração extra é necessária no f i r e w a l l para permitir a
passagem de pacotes VPN. P o r o u t r o l a d o, o gateway VPN torna-se vulnerável a ataques
externos.
Figura 18: Gateway VPN paralelo ao firewall.
Fonte: Adaptadaa de Koleniskov e Hatch (KOLENISKOV e HATCH, 2002)
49
A terceira opção, gateway VPN atrás de um firewall, força todo o tráfego vindo da Internet a
passar primeiramente pelo firewall, conforme a Figura 19. Isso deixa a rede mais segura.
Em conseqüência, deve-se configurar regras no firewall para redirecionar o tráfego de VPN
vindo da Internet para o gateway VPN. Esta topologia possui como desvantagem uma perda
de performance pelo fato de todo o conteúdo da VPN passar antes pelo firewall.
Figura 19: Gateway VPN atrás de um firewall.
Fonte: Adaptada de Koleniskov e Hatch (KOLENISKOV e HATCH, 2002)
4.3 Criptografia
A palavra criptografia vem do grego, onde Kryptos s i gni fi c a “ escondido, oculto” e
Grafia significa “escrita”. Pode ser definida como a arte ou ciência de garantir a segurança
de mensagens, de forma que apenas pessoas autorizadas a leiam.
Seu uso vem dos
primórdios da civilização. O imperador romano Júlio César utilizava uma técnica de gravar
uma mensagem na cabeça raspada de um escravo para, após o crescimento do cabelo, enviálo como mensageiro. No local de destino, a cabeça do escravo era novamente raspada, de
forma que a mensagem pudesse ser lida. O detalhe aqui é que apenas o destinatário da
mensagem conhecia o “segredo” do processo (cabeça contendo mensagem sob os cabelos).
Há também inúmeros registros de uso da ciência da criptologia na área militar, durante a
primeira e segunda guerras mundiais. A título de ilustração, através de uma técnica que
substitui cada letra de um texto pela terceira letra subseqüente do alfabeto, a seqüência
ANDRÉ E VANDERLEI seria criptografada como DQGUH H YDQGHUOHL. O crédito
desta técnica também pertence ao imperador romano Júlio César, q u e há mais de 2000
50
anos, inventou o método de criptografia por substituição. Como se pode perceber, trata-se
de uma técnica é extremamente simples, mas o importante aqui é o segredo ou chave de
criptografia e como fazer com que os dois lados saibam como utilizá-la (SARLO, 2003).
A criptografia garante confidencialidade, autenticidade, integridade e não-repúdio
(SCHNEIER, 1996).
Uma breve descrição do processo de criptografia s eri a: um emissor gera a mensagem
original, chamada de “texto plano” e, utilizando uma chave e um algoritmo de cifragem, gera
um “texto cifrado”, incompreensível para quem não está autorizado a lê-lo. Chagando ao
receptor, este “texto cifrado” passa pelo processo inverso, chamado decifragem, o que resulta
no “texto plano” original. O processo está ilustrado na Figura 20 abaixo.
Figura 20: Processo de cifragem e decifragem.
Fonte: Adaptadaa de Brocardo (BROCARDO, 2001)
Uma chave é uma seqüênci a de bits e quanto maior for esta s eqüênci a, maior será a
segurança resultante. Dependendo do tipo de chave utilizada, a criptografia classifica-se em
dois tipos: criptografia simétrica e criptografia assimétrica.
4.3.1 Criptografia simétrica
A criptografia simétrica utiliza uma única chave. A mesma chave utilizada para a cifragem
será usada para a decifragem. Como vantagem comparativa em relação ao processo
assimétrico, pode-se citar o melhor desempenho. Por outro lado, a vulnerabilidade a ataques
do tipo força bruta ou quebra de senha (password cracking) é maior.
51
O processo, de acordo com a Figura 21 abaixo, é o seguinte: a chave simétrica é previamente
trocada entre o emissor e o receptor por um canal de comunicação seguro. Utilizando essa
chave, ocorre o processo de cifragem no lado emissor, quando o “texto plano” é convertido
em “texto cifrado”. O “texto cifrado” é enviado. No lado receptor, utilizando a mesma chave,
é feita a decifragem, que retorna o “texto cifrado” a “texto plano”.
Figura 21: Processo de criptografia simétrica.
Fonte: Adaptadaa de Brocardo (BROCARDO, 2001)
As desvantagens deste processo devem-se ao fato de que como apenas uma chave é utilizada
para cada par de entidades que se comunicam, o sigilo exigido deve ser extremamente rígido.
Se o número de entidades que necessitam comunicar-se de forma segura for muito grande,
serão necessárias inúmeras chaves, o que dificultará ainda mais seu processo de
gerenciamento. Na Figura 22 é mostrado novamente o processo de criptografia simétrica,
reforçando alguns dos elementos envolvidos.
Figura 22: Criptografia simétrica.
Fonte: Carmo (CARMO, 2005)
52
Conforme se pode observar na figura, um elemento importante do processo é o algoritmo de
criptografia utilizado.
Os algoritmos simétricos modernos são baseados em cifras de blocos. Isso significa que
durante o seu processamento, o objeto a ser criptografado é dividido em blocos, em geral
com tamanhos de 64 ou 128 bits. Existem vários modos de operação sobre os blocos, cada
um deles apresentando vantagens sob determinado aspecto. Alguns atuam sobre os blocos
tomando-os de forma independente uns dos outros, outros executam operações lógicas entre
o bloco que está sendo processado e seu antecessor, e assim por diante. Os modos mais
comuns são: CBC (Cipher Block Chaining), ECB (Electronic Codebook), CFB (Cipher
Feedback) e OFB (Output Feedback). Cada algoritmo possibilita escolher entre alguns
desses vários modos.
A seguir serão descritos brevemente alguns algoritmos simétricos com as principais
características das chaves envolvidas.
4.3.1.1 Data Encryption Standard (DES)
É um dos algoritmos de criptografia simétrica mais antigos e difundidos, tendo se
desenvolvido a partir de um projeto da IBM de 1974. Em 1977 foi adotado como p a d r ã o
pelo ANSI (American National Standards Institute) para aplicações não sensíveis.
Utiliza chaves c om comprimento de 56 bits. Na verdade, a chave tem 64 bits, mas apenas 56
são utilizados para cifragem (o restante é utilizado para funções de controle). Opera sobre
blocos de 64 bits. Um problema com o DES é que os critérios de projeto não foram totalmente
revelados pelos desenvolvedores, o que causou, durante anos, desconfiança de que o
algoritmo contivesse armadilhas secretas que permitiriam à comunidade de informação acesso
às mensagens cifradas dos usuários.
O DES é considerado vulnerável desde meados dos anos 90, tendo sua chave sido quebrada
1997, em um desafio lançado na Internet, e novamente em 1998, em apenas dois dias de
processamento. A explicação é que em função dos avanços obtidos na capacidade de
processamento dos computadores nos anos recentes, a chave de 56 bits tornou-se pequena
demais.
53
4.3.1.2 Triple Data Encryption Standard (3DES)
O 3DES foi uma tentativa de fortalecer DES. A idéia foi efetuar a cifragem múltiplas vezes
utilizando chaves diferentes. Pode ser usado com duas ou três chaves, o que equivale a um
comprimento efetivo de chave de 112 ou 168 bits, respectivamente. Quando utilizadas três
chaves, os dados são cifrados com a primeira chave, decifrados com a segunda chave, o que
não retorna o texto original, e então novamente cifrados, agora com a terceira chave. Isto faz
com que o 3DES seja seguro, mas lento demais para um algoritmo que tinha a pretensão de se
tornar um padrão de mercado. Ainda assim, é bastante utilizado.
4.3.1.3 Adanced Encryption Standard (AES)
O DES e sua variante 3DES foi a cifra padrão oficial dos Estados Unidos entre 1976 e 2001,
quando foi substituído pelo AES. A história do AES começa em 1977, quando o NIST
(National Institute of Standard and Technology) iniciou um projeto que visava promover um
substituto para o DES como algoritmo de criptografia padrão. Criou então um concurso para
escolha do novo algoritmo. Os finalistas foram os algoritmos: Serpent, Mars, RC6, Twofish e
Rinjdael, em 2 de dezembro de 2001 foi anunci ado o vencedor: o algoritmo Rijndael,
c r i a d o p e l o s belgas Joan Daemen e Vicent Rijmen.
Esta nova geração de algoritmos criptográficos agrega fatores que combinam segurança,
desempenho, eficiência, facilidade de implementação e flexibilidade em diversas plataformas de
hardware e software (SARLO, 2003).
O AES utiliza chaves de 128, 192 ou 256 bits e opera sobre blocos de 128 bits, tendo uma
expectativa de vida entre 20 e 30 anos. Até o momento não existem ataques bem sucedidos a
este protocolo.
4.3.1.4 International Data Encryption Algorithm (IDEA)
O protocolo IDEA foi criado em 1991 por James Massey e Xuejia Lai, sendo patenteado pela
empresa suíça Ascom Systec. Sua chave tem comprimento de 128 bits. O algoritmo segue as
54
mesmas linhas gerais do DES. Mas na maioria dos microprocessadores, uma implementação
por software do IDEA é mais rápida do que uma implementação por software do DES. O
IDEA é utilizado principalmente no mercado financeiro e no PGP, programa mais
disseminado no mundo para criptografia de email pessoal.
4.3.1.5 Blowfish/Twofish
O Blowfish é um algoritmo desenvolvido por Bruce Schneier. Oferece a escolhe entre maior
segurança ou desempenho através de chaves de tamanho variável. As chaves podem ter de 32
a 448 bits, em incrementos de 128. O tamanho do bloco é de 64 bits.
Mais recentemente, o Blowfish foi aperfeiçoado, dando origem ao Twofish, que atualmente é
concorrente do AES (Conforme visto no item 4.3.1.3 acima, o twofish foi finalista do
concurso para escolha do AES).
Utiliza chave de comprimento variável até o limite de 256 bits, tamanho considerado eficiente
para execução até mesmo em softwares que rodam em pequenos processadores tais como
aqueles embutidos em smart cards ou tokens. O algoritmo é processado em blocos de dados
de 128 bits. É um algoritmo não patenteado, de uso livre e gratuito.
Não existem ataques bem sucedidos a nenhum desses dois algoritmos.
Uma vez estudados os algoritmos simétricos, cabem duas observações.
Primeiro, a
criptografia simétrica não resolve um problema básico: o estabelecimento seguro da chave
secreta entre as duas partes que se comunicam. Segundo: nos sistemas desse tipo, as partes
são incapazes de demonstrar a autoria de uma mensagem a uma terceira parte. Não existe um
mecanismo equivalente a assinaturas para suprir essa deficiência. A criptografia de chave
pública tem resposta a esses dois problemas.
4.3.2 Criptografia assimétrica
A criptografia assimétrica, em contraposição à simétrica estudada no item 4.3.1, faz uso de duas
chaves distintas, matematicamente relacionadas, uma privada e outra pública. Pode-se utilizar
55
qualquer uma das chaves para cifrar a mensagem. Entretanto, somente a chave inversa associada
pode ser utilizada para decifrá-la. Exemplo, se um emissor utiliza a chave pública do receptor
para cifrar a mensagem, o receptor deve utilizar a sua chave privada para decifrá-la, conforme a
Figura 23. Dessa forma, garante-se autenticidade e confidencialidade.
Figura 23: Processo de criptografia assimétrica.
Fonte: Adaptada de Brocardo (BROCARDO, 2001)
Contudo, se o emissor utilizar sua chave privada para cifrar a mensagem, qualquer pessoa que
conheça sua chave pública poderá decifrá-la, uma vez que a chave pública é de livre
divulgação. Neste caso, estará garantida apenas a autenticidade da mensagem, já que
todos que a decifraram terão certeza absoluta que foi cifrada por quem detinha a chave privada
correspondente à chave pública que utilizaram.
Basicamente o processo ocorre como se a chave é fosse dividida em duas partes: uma
privativa e secreta que não pode ser divulgada para ninguém, e outra pública e aberta, que
pode
ser
entregues
a
qualquer pessoa c o m
a
qual
se
deseje
efetuar
t r a n s a ç õ e s q u e e n v o l v a m c o n f i d e n c i a l i d a d e o u a u t e n t i c i d a d e . Para que o
processo seja bi-direcional, garantindo as duas funções nos dois sentidos, é necessário que as
duas partes envolvidas tenham seu par de chaves e divulguem à outra parte a sua chave pública.
Conforme se pode deduzir das explicações acima, nos sistemas de chave pública o “dono” do
par de chaves usadas numa comunicação tem controle da situação. O nome assimétrico vem do
fato de se usaram chaves distintas no mesmo processo de cifragem e decifragem.
Para que um sistema de chave pública seja efetivo, é necessário que duas premissas sejam
atendidas: 1ª) a função de ciframento seja difícil de inverter; 2ª) seja muito difícil descobrir a
chave privada, apesar do conhecimento da chave pública.
56
Sistemas assimétricos poderiam substituir completamente sistemas simétricos, exceto por dois
aspectos importantes: performance e segurança na obtenção da chave pública. Os algoritmos de
chave pública são extremamente mais lentos que os de chave simétrica. Em relação à chave
pública, é necessário que se tenha absoluta certeza de que ela de fato pertence a uma
determinada entidade ou pessoa.
Na prática, sistemas de chave pública são usados apenas para estabelecer uma chave secreta de
um sistema simétrico, num processo que se dá a cada sessão de comunicação. Essa chave secreta
é denominada chave de sessão. Após o encerramento da sessão, a chave deixa de existir. Desta
forma, uma sessão de comunicação fica dividida em duas fases: a primeira utiliza um algoritmo
assimétrico para gerar e distribuir uma chave secreta. Esse processo se dá com confidencialidade
e autenticidade. Uma vez que os dois lados estejam de posse dessa chave, ocorre um
chaveamento para um algoritmo simétrico de criptografia e vem então a segunda fase: uso da
mesma chave secreta pelos dois lados para troca de dados.
Procura-se com isso combinar a flexibilidade dos sistemas assimétricos com a eficiência dos
sistemas simétricos.
A Figura 24 mostra o processo de cifragem e decifragem via uso da criptografia assimétrica.
.
Figura 24: Criptografia assimétrica.
Fonte: Carmo (CARMO, 2005)
A seguir serão estudados dois algoritmos de chave pública: RSA e Diffie-Hellman.
57
4.3.2.1 RSA (Rivest, Shamir e Adleman)
O RSA utiliza chaves de 512, 768, 1024 ou 2048 bits. Este algoritmo é ut i l i z ad o p el a
maioria das aplicações de criptografia assimétrica em uso atualmente.
RSA vem dos sobrenomes de seus inventores, Ron Rivest, Adi Shamir e Leonard Adleman,
tendo sido criado em 1997, nos EUA. Atualmente, é o algoritmo de chave pública mais
utilizado no mundo todo, além de ser uma das mais poderosas formas de criptografia de
chave pública conhecidas até o momento.
Matematicamente, o RSA baseia-se no fato de que é fácil multiplicar dois números primos
para obter um terceiro número, mas muito difícil executar o caminho inverso, isto é, fatorar
esse terceiro número para recuperar os dois primos que deram origem a ele. Por exemplo, os
fatores primos de 3.337 são 47 e 71. Gerar a chave pública envolve multiplicar dois primos
grandes (isso é fácil e qualquer um pode fazer). Obter a chave privada a partir da chave
pública envolve fatorar um número grande. Se o número for grande o suficiente e bem
escolhido, ninguém conseguirá fazer isto em um espaço de tempo razoável. Assim, a
segurança do RSA baseia-se na dificuldade de fatoração de números grandes.
Em 1999, uma chave RSA de 512 bits foi quebrada pelo Instituto Nacional de Pesquisa da
Holanda. Esta tarefa contou com a participação de cientistas de mais seis países e levou cerca
de sete meses, tendo sido utilizadas 300 estações de trabalho no processo. A primeira vista
pode não parecer, mas é preocupante que cerca de 95% dos sites de comércio eletrônico
utilizem chaves RSA de 512 bits.
Este algoritmo não faz a geração de senhas, mas usa as chaves geradas previamente por uma
infra-estrutura de chaves publicas (PKI – Public Key Infrastructure), cifrando e
d e c i f r a n d o com o par de chaves de cada usuário, conforme ilustrado na próxima Figura
25.
58
Figura 25 - Representação do algoritmo RSA
As chaves públicas podem ficar disponíveis na Internet, administradas por órgãos
certificadores ou por uma CA (Certificate Authority), ou ficar em um servidor interno à
rede local para uso exclusivo da empresa (SARLO, 2003).
4.3.2.2 Diffie-Hellman
Sua matemática difere da utilizada no RSA, mas também envolve a manipulação de grandes
quantidades numéricas. Sua segurança advém de uma questão matemática denominado
problema do logaritmo discreto.
Os princípios básicos da tecnologia de chave pública foram propostos em meados da década
de 70 por Whitfield Diffie e Martin Hellman no artigo “New directions in Cryptography”, que
tornou-se um marco na história da criptografia moderna.
O algoritmo Diffie-Hellman constitui um método que permite estabelecer uma chave secreta
usando um canal inseguro para isso. Diferentemente do algoritmo RSA, ele não possibilita
cifragem, decifragem ou assinatura digital.
A obtenção de uma chave secreta compartilhada se dá por método puramente matemático, sem
os processos de cifragem e decifragem utilizando chaves públicas e privadas que ocorrem no
algoritmo RSA. A descrição completa do método encontra-se no Anexo 1.
59
4.3.3 Função hash
Consiste em um algoritmo que mapeia uma entrada de tamanho variável para uma saída de
tamanho fixo. Dada uma mensagem original, a função hash tem como objetivo produzir um
número, conhecido como resumo, que representa de forma única esta mensagem. Uma
propriedade desta função diz que o caminho inverso deverá ser computacionalmente inviável,
isto é, não deverá ser possível obter a mensagem original a partir do seu resumo. Também é
verdade que pequenas alterações na mensagem original (um bit que seja) produzirá um resumo
completamente diferente.
A idéia de uso das funções hash é que elas funcionem como um mecanismo de garantia de
integridade nas transmissões de mensagens pela Internet. Na origem, calcula-se o resumo da
mensagem. A mensagem, juntamente com o resumo, é transmitida. No destino, a partir da
mensagem recebida, calcula-se novamente o resumo, utilizando o mesmo algoritmo hash.
Compara-se o resumo calculado com o recebido. Se forem iguais, conclui-se que a mensagem
recebida corresponde àquela que foi transmitida. Tem-se então garantia de integridade.
A Figura 26 abaixo mostra o funcionamento de um algoritmo hash puro, sem criptografia
associada.
Figura 26: Processamento da função hash.
Fonte: Adaptada de Carmo (CARMO, 2005)
Os dois principais algoritmos de hash utilizados atualmente são: MD-5 e o SHA-1.
60
4.3.3.1 Message Digest (MD-5)
Criada por Ron Rivest, um dos criadores do algoritmo RSA. Produz um valor hash de 128 bits
para qualquer mensagem de entrada de tamanho arbitrário. Foi inicialmente proposto em 1991,
após alguns ataques terem sido descobertos contra a função de hashing criada anteriormente
por Rivest: a MD4. O algoritmo foi projetado para ser rápido, simples e seguro. Entretanto, o
fato dele produzir um resumo de apenas 128 bits causa preocupação a alguns especialistas em
criptoanálise.
4.3.3.2 Secure Hash Algorithm 1 (SHA-1)
Foi criada pela NSA (National Security Agency), em 1995. Gera um valor hash de 160 bits,
também a partir de um tamanho arbitrário de mensagem. O funcionamento interno do SHA-1
é baseado no MD-4, com melhorias na parte de segurança. Atualmente, não se conhece
nenhum ataque de criptoanálise contra o SHA-1. Ataques da força bruta são impraticáveis,
devido ao seu valor hash de 160 bits.
A principal diferença entre os dois é que o primeiro é mais rápido por retornar um resumo de
ap en as 128 bits, enquanto que o segundo retorna um número de 160 bits, sendo, por isso,
mais seguro.
O SHA-1 já tem seus sucessores, capazes de retornar resumos maiores. São os protocolos
SHA-224, SHA-256, SHA-384 e SHA-512, conhecidos coletivamente pela denominação
SHA-2.
Outro ponto a frisar é que os algoritmos de hash são normalmente utilizados em conjunto com
algoritmos criptográficos. Assim, a transmissão do texto junto com seu resumo, de forma não
criptografada, como já mostrado na Figura 26, teve intenção apenas didática, buscando não
misturar a função hash com outras técnicas, o que tornaria a figura confusa.
61
4.3.4 Assinatura Digital
É uma tecnologia que permite autenticar o conteúdo de uma mensagem, garantido sua
integridade e a autenticidade de sua origem. Utiliza criptografia assimétrica associada a
funções de hash.
Autenticar, na definição de Albuquerque (2001) é “[...] confirmar a identidade de uma
entidade com o objetivo de se garantir que a entidade é quem ela diz ser”.
(ALBUQUERQUE, 2001)
As técnicas mais comuns de autenticação fazem uso de informações sigilosas (como senhas),
meios físicos como cartões magnéticos (smart cards ou tokens), verificação de informações
biométricas (como impressões digitais) ou uma combinação delas. Um exemplo desta
combinação está no cartão de crédito, onde, além do cartão físico, é exigida também uma
senha para efetuar a transação.
A assinatura digital faz uso da criptografia assimétrica, pois utiliza um par de chaves, uma
privada e outra pública. A chave privada serve para assinar o documento, enquanto a pública
é usada para verificar a assinatura. Conforme explicado no item 4.3.3, o processo de geração
da assinatura utiliza uma função hash para obtenção do resumo do documento, que, em
seguida, é cifrado, juntamente como o documento a ser assinado, com a chave privada do
emissor. Os dois itens são então enviados ao receptor. O receptor utilizará a chave pública do
emissor para decifrar a mensagem e o resumo recebidos, e a mesma função hash para
recalcular o resumo a partir do documento, comparando-o com o resumo recebido. Se houver
igualdade no conteúdo dos dois resumos, a integridade do documento estará garantida. A
autenticidade também, pois o fato de conseguir decifrar os textos com a chave pública do
emissor garante que a cifragem só poderia ter sido feita por ele. Não há sigilo neste processo,
uma vez que outras entidades ou pessoas além do receptor podem ter conhecimento da chave
pública do emissor. A próxima Figura 27 ilustra o processo descrito.
62
Figura 27: Processo de assinatura digital.
Fonte: Adaptadaa de Brocardo (BROCARDO, 2001)
4.3.5 Certificado digital
O certificado digital é um arquivo assinado eletronicamente por uma entidade confiável,
denominada
“Autoridade
Cerificadora”
ou
CA
(Certificate
Authority).
Representa um documento digital e contêm informações de identificação do seu proprietário
tais como nome, email, chave pública e validade da chave pública, além do nome e assinatura
da CA que o emitiu, do número de série do certificado, entre outros dados. Um certificado
tem co m o fi nal idade prover aut enti cação, int egridade, confi denci al idad e e
i rret rat abili dade, ao associar uma chave pública a uma pessoa ou entidade. Constitui
também um mecanismo para a divulgação da chave pública.
Qualquer entidade que conheça a chave pública da CA pode examinar o conteúdo dos
certificados assinados por ela e confirmar assim a sua autenticidade, uma vez que a CA
assina os certificados utilizando sua chave privada.
A recomendação mais aceita e utilizada para a produção de certificados digitais é a X.509 v3,
formulada pela Internacional Telecommunication Union – Telecommunication Standard
Sector (ITU-T). Portanto o padrão X.509 é aceito como base para a estruturação da Public
Key Infrastructure (PKI), ou Infra-estrutura de chaves públicas, ambiente onde são definidos
os formatos de dados e procedimentos relativos à distribuição de chaves públicas usando
certificados assinados digitalmente. Formalmente trata-se de um conjunto composto por
hardware, software, pessoas, políticas e procedimentos necessários para criar, gerenciar,
armazenar, distribuir e revogar certificados baseados em criptografia de chave pública.
63
Para ilustrar como são estruturadas as PKIs, em 24 de Agosto de 2001, foi editada no Brasil a
medida provisória nº 2.200-2 pela qual foi instituída a ICP-Brasil (Infra-estrutura de Chaves
Públicas Brasileira), órgão vinculado à Presidência da República que resumidamente objetiva
prover um conjunto de técnicas, práticas e procedimentos, a serem implementados pelas
organizações governamentais brasileiras (SERPRO, CEF, SRF e outras) e privadas
(SERASA, CertiSign, etc)
com o objetivo de estabelecer os fundamentos técnicos e
metodológicos de um sistema de certificação digital baseado em chaves públicas.
Este capítulo introduziu os conceitos básicos de segurança, mostrando as principais ameaças,
os tipos mais comuns de ataques e os mecanismos de defesa comumente utilizados,
compostos por firewalls, criptografia, assinaturas e certificados digitais. Todos são
importantes para um entendimento satisfatório das VPNs.
O próximo capítulo abordará os principais conceitos sobre VPNs, explicando cada uma de
suas características e citando alguns dos protocolos utilizados, com ênfase no TLS/SSL,
protocolo principal do OpenVPN.
64
5 CONCEITOS SOBRE VPNS
VPNs são redes de computadores que estão separadas fisicamente e, que através de um meio
público de comunicação – geralmente a Internet – comunicam-se de forma segura, por meio do
uso de criptografia.
As VPNs possuem seus próprios protocolos de comunicação que atuam em conjunto com
o TCP/IP, fazendo com que um túnel virtual seja estabelecido e os dados trafeguem por
ele criptografados.
Dentre eles, podemos destacar o Point-to-Point Tunneling Protocol
(PPTP), o Layer Two Tunneling Protocol (L2TP), IPSec (Secure IP) e o Transport Layer
Security / Secure Sockets Layer (TLS/SSL), que serão abordados no próximo capítulo.
Alguns dos dispositivos que implementam uma VPN são: roteadores15, módulos específicos de
VPN implementados em hardware e softwares de VPN instalados em servidores de uso geral,
conhecidos como gateways de VPN.
5.1 Tunneling
Uma VPN tem como principal elemento a criação de um túnel virtual encriptado, técnica
conhecida como tunneling ou, numa tradução um tanto estranha, tunelamento.
As informações transmitidas entre as redes que compõem uma VPN trafegam de forma
cifrada, dando a idéia da existência de um túnel virtual no qual os dados perecem
ininteligíveis para quem não faz parte dele.
Dessa forma, se alguma informação for
capturada, será quase impossível entendê-la, a menos que se descubra a chave de criptografia
utilizada, como mostra a próxima Figura 28.
15
Roteadores ou routers são dispositivos capazes de interligar redes com diferentes padrões de endereçamento
na camada de Internet (rede).
65
Figura 28: Túnel virtual entre duas redes.
Fonte: Adaptadaa de Cyclades (CYCLADES, 2000)
A técnica de tunneling consiste em encapsular um pacote de dados de um certo protocolo em
um pacote de outro protocolo. Numa extremidade do túnel os dados são encapsulados, a
seguir transmitidos, e, na extremidade oposta, desencapsulados. Para as estações das duas
redes, o processo é transparente. Apenas os gateways VPN têm conhecimento do que ocorre,
e todos os protocolos utilizados (troca de chave de sessão, criptografia, hashing, etc) são
implementados neles.
5.2 Autenticação das extremidades
As mensagens devem ser autenticadas como meio de garantir que vieram de usuários
válidos. Isso deve ocorrer em ambas as extremidades do túnel e é feito utilizando protocolos
de autenticação associados a algoritmos de hash.
5.3 Vantagens das VPNs
Entre os principais benefícios que as VPNs proporcionam estão aqueles relacionados a custo,
transparência, flexibilidade e segurança.
5.3.1 Segurança
Uma VPN fornece funções vitais de segurança, como autenticidade, confidencialidade,
integridade e controle de acesso. Os riscos de ataques externos ficam minimizados (IP
Spoofing e man-in-the-middle, por exemplo, já estudados no capítulo 3).
66
5.3.2 Transparência
A transparência consi st e
em
dot ar
a
VP N
de
m ecanis mos
que
to rn em
des necess ário que usuários, aplicações e computadores precisem conhecer a localização
física dos recursos que estão sendo utilizados na rede, permitindo que sejam acessados de
locais remotos como se estivessem presentes localmente. Tal característica facilita o
gerenciamento, diminui a necessidade de treinamento para os administradores e elimina a
necessidade de treinar os usuários.
5.3.3 Custos
A redução de custos é uma das maiores vantagens de se implementar uma VPN, pois
p o d e s e r f e i t a utilizando conexões locais de Internet, d i s p e ns an d o, por exemplo, a
co ntrat ação de linhas de comunicação dedicadas (LPCDs - linhas privativas de
comunicações de dados) ou a ut iliz ação de servidores para acesso remoto, que são
relativamente mais caros de se manter em comparação com uma VPN.
5.3.4 Flexibilidade
As VPNs apresentam-se bastante flexíveis em relação a aspectos como escalabilidade,
absorção de novas tecnologias, utilização de novos protocolos, etc. Como exemplo podemos
citar a inserção de uma nova filial à rede de uma empresa. No lado da matriz, basta alterar a
configuração do gateway VPN para autenticar a nova rede e, se necessário, efetuar um
upgrade no link de Internet. No caso de novos protocolos, como são implementados nos
gateways VPN, basta que sejam instalados e configurados nessas máquinas.
5.4 Desvantagens das VPNs
Em contraposição a todas as vantagens citadas anteriormente, as VPNs, de forma geral, são
complexas, demandam grande tempo de implantação, exigem um bom planejamento préimplantação, apresentam certa dificuldade na localização de defeitos, e s t a b e l e c e m u m a
67
relação de confiança entre as redes interconectadas, podem apresentar deficiências de
desempenho e dependem da disponibilidade da Internet.
Os problemas de planejamento dizem respeito principalmente à gerência das chaves e é
particularmente importante que se tenha um bom conhecimento de como as redes que se
pretende interligar estão funcionando, assim como d e suas configurações, pois qualquer
imperfeição pode resultar em mais tempo gasto em sua correção.
Em razão dos dados trafegarem de forma cifrada em uma VPN, a localização de defeitos,
como a falta de sincronismo entre as chaves, falhas nos processos de autenticação, excesso de
pacotes perdidos e a sobrecarga dos gateways VPN pode constituir um grande problema.
A relação de confiança entre as redes que a VPN interliga é de fundamental importância para o
bom funcionamento do conjunto, e deve ser muito bem planejada, pois os recursos
compartilhados por uma das redes ficarão acessíveis às outras. P or i s s o , se uma das redes
não possuir uma segurança adequada, ela está vulnerável a ataques externos e,
conseqüentemente, toda a VPN também estará.
A segurança da VPN é equivalente à
segurança de sua rede mais vulnerável.
Pelo fato das VPNs serem dependentes da Internet para conectar suas redes, o que representa o
principal fator de baixo custo dessa tecnologia, é necessário que ela esteja sempre disponível,
o que nem sempre é possível, devido às falhas existentes nos provedores de serviços de
Internet.
Em aplicações onde o tempo de transmissão é crítico, o uso de VPNs deve ser analisado com
cuidado. Os problemas de desempenho e atrasos na transmissão, sobre os quais a empresa não
tem nenhum tipo de gerência ou controle, podem comprometer a qualidade desejada nos
serviços corporativos.
68
5.5 Comparação com outras tecnologias de acesso remoto
Uma forma de analisar a validade de se utilizar a tecnologia VPN é compará-la diretamente
com outras tecnologias que têm a mesma finalidade: as linhas dedicadas e os servidores de
acesso remoto.
5.5.1 VPN x Linhas Dedicadas
Quando se fala em conexão de redes a longa distância para a troca e a atualização diária de
informações entre banco de dados, pensa-se primeiramente e m l i n k s dedicados. Um dos
benefícios dessa abordagem está na disponibilidade da conexão, pois nesse caso os
equipamentos que permitem a comunicação são controlados pela própria empresa.
No
entanto, os custos de implantação de linhas dedicadas poderão inviabilizar seu uso. Utilizar
uma solução de VPN certamente reduzirá esse custo.
5.5.2 VPN x Servidor de Acesso Remoto
Nos tempos atuais, existe uma tendência no mundo empresarial de flexibilizar o trabalho dos
seus funcionários, tanto em termos de horário quanto da possibilidade de exercerem suas
funções em suas próprias residências, principalmente quando há grande distância entre a
empresa e as residências, ou em grandes centros urbanos em que se perde boa parte do dia no
trânsito. Outra situação de trabalho a distância ocorre nas viagens de negócio.
Existem duas opções tradicionais que buscam solucionar as questões colocadas acima: abrir os
recursos da rede interna da empresa para a Internet ou manter um pool de modems em
quantidade suficiente para permitir o acesso remoto dos usuários.
A primeira opção causa enormes riscos à segurança, pois se por uma situação qualquer os
recursos da rede ficarem comprometidos, informações confidenciais da empresa também
ficarão.
O mesmo ocorrerá com os servidores. Tudo isso poderá gerar grandes perdas
financeiras, tanto pelo roubo de informações quanto por uma eventual indisponibilidade de
serviços da rede invadida.
69
A outra opção eleva bastante os custos, pois são necessários servidores dedicados, placas
multiseriais de boa qualidade, linhas telefônicas exclusivas, ligações interurbanas se o
funcionário estiver em outra cidade.
5.6 Topologias
As VPNs admitem três layouts básicos de integração: host-host, host-gateway e gatewaygateway.
5.6.1 Host-host
Neste trabalho, podemos definir host como sendo um computador que possui acesso à Internet.
Esta topologia permite comunicar dois hosts separados fisicamente, fornecendo a segurança
necessária para a troca de informações via Internet. Estes hosts podem ou não fazer parte de
uma rede. A Figura 29 abaixo mostra dois hosts pertencentes a duas filiais de uma mesma
empresa, sincronizando suas informações. Deve fi car cl ar o que, n este caso, o objetivo
não era interligar as redes inteiras, o que exigiria um esforço maior e desnecessário, além de
acarretar custos extras.
Figura 29: Topologia host-host.
Fonte: Carmo (CARMO, 2005)
70
5.6.2 Host-Gateway
Também chamada de acesso remoto VPN, esta topologia permite a conexão de um host
móvel a uma determinada rede através da Internet. Para isso, basta ao usuário ter um
software para conexões remotas VPN instalado neste host. Esta opção é bastante utilizada
por funcionários que viajam constantemente ou passam bom tempo fora da empresa e
precisam manter de alguma forma o contato.
Nesta topologia, também chamada de client-to-gateway, a VPN é usada para criar um túnel
entre uma máquina standalone e a rede da empresa. Exemplo: funcionário em viagem usa
seu notebook em um hotspot (acesso wireless) de aeroporto e acessa a rede da empresa para
fazer o upload dos pedidos vendidos até aquele momento. Nestas situações, é sempre o
cliente que inicia a conexão com o gateway VPN. (NAKAMURA, 2002), (SARLO, 2003)
A Figura 30 a seguir ilustra esse caso.
Figura 30 - Topologia host-rede.
Fonte: Adaptada de Kolesnikov e Hatch (KOLENISKOV e HATCH, 2002)
5.6.3 Gateway-gateway
Nesta configuração existe um gateway VPN nas extremidades de duas ou mais redes,
conforme mostrado na próxima Figura 31 Esta topologia é indicada para interligar redes de
71
uma mesma empresa geograficamente distante entre si. Pode ser utilizada também para
compartilhar recursos específicos entre parceiros de negócios, como fornecedores, principais
consumidores e outras companhias.
Neste tipo de VPN o recurso de transparência visto
anteriormente se reveste de especial importância.
Figura 31 - Topologia rede-rede
Fonte: Carmo (CARMO, 2005)
5.7 Protocolos usados nas VPNs
Esta seção apresenta os principais protocolos utilizados nas VPNs. Para manter a sintonia com
os objetivos desse trabalho, eles serão vistos de forma breve, com ênfase um pouco maior para
TLS/SSL.
Tomando por referência o modelo OSI, o tunneling pode ocorrer na camada 2 (enlace) ou na
camada 3 (rede). Conforme visto no capítulo 3, na pilha TCP/IP corresponderiam às camadas
de acesso à rede e internet, respectivamente.
referência baseada no modelo OSI.
Neste capítulo será utilizada a primeira
72
Os protocolos de camada 2 são o PPTP, o L2F e o L2TP. O objetivo do tunneling de camada
2 é transportar protocolos de camada 3 tais como AppleTalk, IP e IPX na Internet. Até
mesmos protocolos não roteáveis podem ser encapsulados dessa forma (por exemplo, o
Netbeui, da Microsoft) e transportados. Para conseguir isto, seus projetistas se basearam no
protocolo de camada 2 PPP (Point to Point Protocol), que foi concebido originalmente para
transportar diferentes protocolos de nível 3 em canais seriais. Na estratégia adotada os
pacotes de camada 3 são encapsulados em pacotes PPP, que por sua vez são re-encapsulados
em pacotes IP, o que possibilita seu transporte via Internet. O OpenVPN, objeto de estudo
deste trabalho, também implementa túneis de camada 2 quando instalado no modo bridge
usando a interface virtual TAP.
Como protocolo de camada 3 pode-se citar o IPsec. Seu funcionamento baseia-se no
encapsulamento de IP sobre IP.
Isso é feito tomando os pacotes IP que devem ser
transmitidos e aplicando a eles as funções de segurança estudadas no capítulo 4, com objetivo
de prover privacidade, autenticação e integridade. A seguir, esses pacotes, já protegidos, são
encapsulados em outros pacotes IP para transmissão pela Internet. O IPsec engloba também
funções de gerenciamento de chaves. O transporte de outros protocolos de camada 3, como
IPX e Appletalk, pode ser realizado dentro do IPSec através do encapsulamento de protocolos
de nível 3.
Além do IPSec, o OpenVPN instalado no modo router através da interface virtual TUN
também implementa túneis de camada 3.
Na seqüência serão vistas algumas características dos protocolos citados.
5.7.1 PPTP – Point to Point Tunneling Protocol
Foi desenvolvido pelo Fórum PPTP - consórcio formado pelas empresas US Robotics,
Microsoft, 3Com, Ascend e ECI Telematic. Sua implementação mais conhecida é a da
Microsoft, utilizada em sistemas Windows.
Utiliza os mesmos mecanismos de autenticação do PPP para fazer as conexões através da
73
Internet. As funções de encapsulamento são feitas através do protocolo GRE (Generic
Routing Encapsulation).
No PPTP a autenticação é feita através do MS-CHAP (Microsoft - Challenge Handshake
Authentication Protocol) e a criptografia por meio do MPPE (Microsoft Point to Point
Encryption), que utiliza chaves de 40, 56 ou 128 bits.
Apresenta as vantagens já citadas de um protocolo de tunneling de camada 2, mas seu ponto
mais fraco relaciona-se a segurança. Sem entrar em detalhes de funcionamento, pode-se citar:
a negociação do túnel não é protegida; as chaves de criptografia são geradas utilizando a
senha do usuário como base (se esta senha for fraca, a chave também será) e o processo de
autenticação é feito após a negociação do túnel.
5.7.2 L2F – Layer 2 Forwarding
Foi um dos protocolos pioneiros para VPNs. De forma semelhante ao PPTP, o L2F foi
concebido para ser um protocolo de tunneling entre usuários remotos e redes locais.
Diferentemente do PPTP, no entanto, o L2F não depende do protocolo IP, sendo, por isso,
capaz de trabalhar diretamente com outros protocolos como Frame Relay ou ATM.
A autenticação de usuários remotos utiliza conexões PPP, mas provê também suporte para
TACACS+ e RADIUS, o que possibilita uma autenticação desde o inicio da conexão. Na
verdade, esse processo de autenticação é feito em dois níveis: primeiro, no momento em que a
conexão é solicitada pelo usuário ao provedor de acesso à Internet; depois, quando o túnel se
estabelece, o gateway VPN da rede também exigirá autenticação.
Uma grande vantagem desse protocolo é que os túneis podem suportar mais de uma conexão,
o que não é possível no protocolo PPTP. Outro ponto já citado: por ser um protocolo de
camada 2, o L2F permite encapsular diferentes protocolos de camada 3: IP, IPX, NetBEUI,
etc. Atualmente, está praticamente em desuso.
5.7.3 L2TP – Layer 2 Tunneling Protocol
Foi criado pela Cisco Systems e, mais tarde, homologado pela IETF (Internet Engineering
Task Force) como protocolo padrão.
Seu projeto foi desenvolvido a partir do L2F com o
74
objetivo de resolver alguns problemas do PPTP, sendo por isso considerado o seu
herdeiro. Algumas características, como a utilização do PPP para fornecer o acesso remoto e
a capacidade de encapsular protocolos como NetBEUI e IPX, foram mantidas do PPTP e do
L2F. Pode funcionar com IP, Frame Relay, ATM e X.25.
Uma diferença importante em relação a seu predecessor PPTP relaciona-se à forma de
autenticação, que é feita em dois níveis, como no L2F. No primeiro, o usuário é autenticado
pelo provedor de acesso à Internet antes do túnel ser instalado e, no segundo, quando a
conexão é estabelecida entre os gateways VPN. Outro ponto positivo: no L2TP os dados são
criptografados antes da conexão ser estabelecida.
Por se tratar de um protocolo padrão, é permitido a qualquer fabricante criar produtos que o
utilizem. Para os usuários, significa liberdade de escolha pela não dependência de produtos
fornecidos por uma única empresa.
O L2TP utiliza o protocolo UDP para manter o túnel através da porta 1701. Uma vez que o
protocolo UDP não garante a entrega dos pacotes, normalmente é usado com o IPSec.
O
formato do pacote L2TP é ilustrado pela Figura 32.
Figura 32: Formado do pacote L2TP.
Como no protocolo PPTP, o protocolo L2TP também possui alguns níveis de tunneling, sendo
eles:
Encapsulamento L2TP - O pacote é encapsulado, recebendo um cabeçalho PPP, em seguida
um cabeçalho L2TP;
Encapsulamento UDP - O pacote L2TP é encapsulado pelo protocolo UDP, e enviado à
porta 1701;
Encapsulamento IPSec – Nesta fase o pacote ganha segurança. Os dados são criptografados
e autenticados;
75
Encapsulamento IP - Aqui o pacote ganha um cabeçalho com informações referentes ao
destino e à origem;
Encapsulamento de camada de transporte – Por último, o pacote recebe um cabeçalho que
representa os padrões utilizados pela rede na camada de transporte.
Apesar de ser um protocolo atual, o L2TP não possui um mecanismo eficiente de
encapsulamento. Para realizar esta tarefa, ele necessita do protocolo IPSec, de forma que em
conjunto possam garantir a segurança da VPN.
5.7.4 IPSec – Internet Protocol Security
O IPSec foi desenvolvido pela IETF (Internet Engineering Task Force) para ser o protocolo
padrão de endereçamento da próxima versão do IP (IPv6) que está em fase de testes em
diversas instituições no mundo inteiro. Foi adaptado ao IPv4 atualmente em uso, tornando-se
assim uma das opções mais robustas para implementar VPNs. Seus serviços podem ser
utilizados para quaisquer protocolos das camadas superiores como TCP, UDP, etc...
Segundo Kolesnikov e Hatch, IPSec é "[...] um conjunto de protocolos desenvolvidos para
proteger o tráfego dos pacotes IP". (KOLESNIKOV e HATCH, 2002)
O IPSec foi projetado para suportar múltiplos protocolos de criptografia, dando aos projetistas
da VPN a possibilidade de escolha do nível de segurança desejado.
Os requisitos de segurança podem ser divididos em três grupos:
- Negociação do nível de segurança;
- Autenticação e Integridade;
- Confidencialidade.
Os dois últimos são independentes entre si, podendo ser utilizados de forma conjunta ou
isoladamente, de acordo com as necessidades colocadas pelo projeto.
76
Para implementar estas características, o IPSec é composto de três mecanismos adicionais:
- AH - Autentication Header;
- ESP - Encapsulation Security Payload;
- ISAKMP - Internet Security Association and Key Management Protocol.
Esses mecanismos serão mostrados a seguir, situando-os em relação aos requisitos de
segurança citados acima.
5.7.4.1 Negociação do nível de segurança
O protocolo ISAKMP combina conceitos de autenticação, gerenciamento de chaves e outros
itens de segurança necessários à comunicação através da Internet. O ISAKMP possibilita que
duas máquinas negociem os métodos de autenticação e segurança dos dados, executem a
autenticação mútua e gerem a chave de sessão que permitirá criptografar os dados.
Além da geração da chave de sessão, o ISAKMP define os procedimentos e os formatos de
pacotes necessários para estabelecer, negociar, modificar e excluir as SAs (Security
Associations ou Associações de Segurança). SAs constituem um dos conceitos fundamentais
do IPSec, podendo ser definidas como conexões que viabilizam o tráfego de serviços seguros.
As SAs ficam armazenadas num banco de dados denominado SAD (Security Association
Dtabase). As SAs contêm todas as informações necessárias para execução dos diversos
serviços de segurança, que é garantida pela utilização dos protocolos AH, ESP ou dos dois em
conjunto. Quando utilizados AH e ESP simultaneamente, mais de uma SA deve ser utilizada.
Uma SA é definida de modo único por três parâmetros: o SPI (Security Parameter Index), o
endereço IP de destino e o identificador do protocolo de segurança (AH ou ESP). O SPI é um
número que identifica uma SA, sendo criado durante a negociação que antecede o
estabelecimento da SA. Todos os serviços pertencentes a uma SA devem conhecer o SPI
correspondente e utilizá-lo durante a comunicação.
Além do SAD, existe uma outra database importante denominado SPD (Security Policy
Database), responsável pela ação mais importante a ser feita sobre o pacote, que consiste em
determinar se o mesmo será descartado, seguirá apenas em frente ou seguirá adiante
aplicando-se o protocolo IPSec.
77
O ISAKMP pretende dar suporte para protocolos de segurança em todas as camadas da pilha
TCP/IP. Centralizando o gerenciamento das SAs, o ISAKMP minimiza as redundâncias
funcionais dentro de cada protocolo de segurança e possibilita uma redução do tempo gasto
durante as conexões efetuando a negociação da pilha completa de serviços de uma só vez.
Outra questão importante diz respeito ao gerenciamento de chaves. Em redes pequenas, com
poucos computadores, pode-se configurar as SAs e os SPDs manualmente. Entretanto, se a
rede for grande, a configuração manual torna-se inviável. O recomendado então é configurálos automaticamente, o que significa usar o gerenciamento de chaves automático. Dentre os
protocolos que implementam de forma satisfatória este gerenciamento, o principal deles é o
Internet Key Exchange Protocol (IKE), que combina os protocolos ISAKMP, SKEME e
Oakley Key Determination Protocol. O IKE negocia automaticamente as SAs, permitindo
maior proteção contra ataques.
5.7.4.2 Autenticação e integridade
Conforme visto no capítulo 2, a autenticação garante a identidade do emissor, enquanto a
integridade significa que os dados transmitidos chegam ao seu destino sem alterações,
eliminando a possibilidade modificações não percebidas no caminho entre emissor e receptor.
O AH é um mecanismo que fornece garantia de integridade e autenticação dos datagramas IP.
A segurança é garantida pela inclusão de informações para autenticação no pacote. Essas
informações são obtidas por meio de um algoritmo aplicado sobre o conteúdo dos campos do
datagrama IP, excluindo-se aqueles passíveis de mudanças durante o processo de transmissão.
Esses campos abrangem não só o cabeçalho IP como todos os outros cabeçalhos e os dados da
aplicação propriamente ditos. O campo time-to-live (TTL) do IPv4 não é utilizado, pois,
conforme visto no capítulo 3, sofre mudanças ao longo da transferência.
Para algumas aplicações, o uso de autenticação pode ser suficiente, não sendo necessária a
confidencialidade. Neste caso, o protocolo AH pode ser utilizado sozinho, sem necessidade
do ESP.
78
5.7.4.3 Confidencialidade
Recapitulando o conceito, explicado no capítulo 2, confidencialidade é uma propriedade da
comunicação que garante que apenas usuários autorizados possam entender o conteúdo
transportado. Na hipótese de usuários não autorizados, via captura de pacotes, conseguirem
acesso aos dados, eles não serão entendidos pelo fato de terem sido criptografados na origem.
O serviço que garante a confidencialidade no IPSec é o ESP. O ESP também provê a
autenticação da origem dos dados e a integridade da conexão. A confidencialidade independe
dos demais serviços e pode ser implementada nos dois modos de utilização do IPSec transporte e túnel. No primeiro modo, o pacote da camada de transporte é encapsulado dentro
do ESP. No segundo, o datagrama IP é encapsulado inteiro dentro do cabeçalho do ESP.
A Figura 33 mostra os pacotes nos dois modos de utilização.
Figura 33 – Modos do protocolo IPSec
Mais informações sobre o IPSec podem ser encontradas nas RFCs 2401 (S.Kent; R.Atkison,
1998) e 2411 (R.Thayer; N. Doraswamy; R. Glenn, 1998), disponíveis em <http://www.ietf.
org/rfc/ rfc2401.txt e http://www.faqs.org/rfcs/>.
79
5.7.5 TLS/SSL – Transport Layer Security / Secure Sockets Layer
O protocolo TLS é uma versão atualizada do SSL versão 3, originalmente criado pela
Netscape. Os dois protocolos são bastante semelhantes, embora não possam interoperar
diretamente entre si. O TLS/SSL fornece um serviço de comunicação segura entre cliente e
servidor, permitindo autenticação mútua e garantindo a integridade dos dados pelo uso de
assinaturas digitais e privacidade pelo uso de criptografia. Ele é implementado como uma
camada adicional entre o TCP/IP e os protocolos de nível superior tais como HTTP, SMTP,
etc. Sua implementação em web browsers é a mais conhecida dos usuários da Internet,
oferecendo autenticação e encriptação baseada em sessão.
Um dos pontos fortes do TLS/SSL é que ele atua diretamente no topo dos sockets TCP/IP e se
relaciona com eles de forma muito mais fácil que os protocolos das camadas superiores.
Como resultado, torna-se muito mais fácil construir aplicações de rede utilizando o TLS que
programando diretamente sobre sockets.
O termo sockets refere-se ao método utilizado para troca de dados entre os módulos cliente e
servidor de uma aplicação de rede ou entre camadas de programas em um mesmo
computador.
O TLS/SSL é implementado de modo a atuar como uma subcamada da camada aplicação,
posicionada entre ela e a camada de transporte, conforme mostra a Figura 34.
Figura 34 – Localização da camada de segurança TLS/SSL na pilha TCP/IP
80
Já a estrutura do quadro transmitido pode ser observada na Figura 35.
Figura 35 – Frame Ethernet detalhando os protocolos superiores
Diferentemente do IPSec, visto na sessão anterior, que fornece segurança a todos os
datagramas IP, o TLS/SSL é implementado na própria aplicação (ex.: browsers Internet
Explorer ou Mozilla), sendo portanto uma porção do seu código. Isto possibilita à aplicação
determinar que dados deverão ser protegidos, o que representa uma vantagem em relação ao
IPSec, pois elimina o overhead resultante da proteção desnecessária de certos dados.
O protocolo foi projetado de modo a suportar diversos algoritmos de criptografia e assinatura
digital, permitindo a seleção dos mais convenientes para cada situação, assim como a
incorporação de novos algoritmos, à medida que forem surgindo. A escolha desses protocolos
é negociada entre o cliente e o servidor durante o estabelecimento de uma sessão.
O protocolo TLS começa com um ‘handshake’, no qual cliente e servidor tentam chegar a um
acordo sobre que cipher suíte (grupo de algoritmos criptográficos) eles irão utilizar para
autenticação e criptografia de sessão. Uma vez feita essa negociação, cliente e servidor
poderão se autenticar mutuamente e gerar uma premaster secret, que será usada como base
para a construção da chave de sessão propriamente dita. A chave de sessão será utilizada
então para encriptar e decriptar todo o tráfego entre cliente e servidor, sendo válida apenas
enquanto durar aquela sessão. O truque desse processo é que cliente e servidor estabelecem
uma chave secreta para troca de informações sem nunca precisar enviar um texto aberto
(plaintext) pela rede, o que garante a confidencialidade da comunicação.
Para facilitar o entendimento desse processo, segue abaixo o diálogo entre cliente e servidor
durante a fase de handshake, traduzido para linguagem comum:
81
Cliente: Hello, aqui está a lista de cifradores (cipher suíte) que eu posso usar.
Servidor: Hello, aqui está o cifrador (cipher suíte) que eu escolhi a partir da sua lista. E aqui
está também um certificado X.509v3 que contem minha chave pública RSA.
Cliente: [Vasculha o certificado e verifica se ele está assinado por uma autoridade
certificadora conhecida e confiável. Gera também uma premaster secret e a partir dela a chave
de sessão].
Servidor: OK, obrigado. Aqui está a premaster secret, encriptada com sua chave pública. A
próxima coisa que eu disser para você estará encriptada com a chave de sessão.
Cliente: [Encriptado] Eu já terminei o handshake.
Servidor: [Decripta a premaster secret enviada pelo cliente usando sua chave privada e então
gera a chave de sessão.]. A próxima coisa que eu disser para você também estará encriptada
com a chave de sessão.
Servidor: [Encriptado] Eu também já terminei o handshake.
No processo acima, o cliente envia a premaster secret encriptada com a chave pública do
servidor. O servidor pode ser então considerado autenticado, porque só sua chave privada
pode ser utilizada para decriptar a premaster secret enviada pelo cliente. Mesmo que o
servidor já tenha enviado seu certificado para o cliente, ele só prova que tem a chave privada
correspondente à chave pública existente no certificado (e assim confirma sua identidade) no
momento em que consegue decriptar a premaster secret enviada pelo cliente. Partindo da
mesma premaster secret, cliente e servidor, independentemente um do outro, geram a mesma
chave de sessão.
TLS também suporta o protocolo de troca de chaves Diffie-Hellman. O processo de troca de
chaves com ele é ligeiramente diferente do utilizado no exemplo acima, baseado no algoritmo
RSA. Mas o resultado final é que ambos os lados terão a mesma a mesma chave de sessão.
82
Variações em relação ao exposto são possíveis. Em sistemas que implementam autenticação
bidirecional, por exemplo, o servidor pode solicitar ao cliente que envie seu certificado. Mas
a idéia central é a mesma: autenticação, negociação de protocolos que ambos os lados
suportem e troca segura da chave de sessão.
O processo de handshake entre o cliente e o servidor visto acima utiliza três protocolos:
- SSL Handshake Protocol - Promove o estabelecimento da sessão entre cliente e servidor;
- SSL Change Cipher Spec Protocol - Estabelece o mecanismo de criptografia a ser utilizado
na sessão;
- SSL Alert Protocol - Composto por eventuais mensagens de erro entre cliente e servidor.
A Figura 36 abaixo mostra o processo de handshake com mais detalhes, situando nas
mensagens os protocolos acima.
Figura 36 – TLS/SSL – processo de handshake
Uma vez estabelecida a conexão, cliente e servidor podem trocar dados de forma segura. Cada
registro de dados é individualmente encapsulado em um SSL Record Protocol e um valor hash
83
é calculado, com objetivo de garantir a integridade dos dados. Caso os dados sofram
alterações durante a transmissão, um valor hash inválido será gerado no destino,
possibilitando a identificação do problema.
Para encerrar a conexão, uma das partes envia uma mensagem comunicando o fato (Close
Notify).
O TLS/SSL suporta também o restabelecimento de conexão. Caso o cliente queira estabelecer
outra sessão com o servidor, ele pode dar continuidade a uma sessão anterior fornecendo seu
identificador de sessão em sua mensagem Hello. Isto faz com que protocolo de handshake
seja executado de forma reduzida, de modo que os parâmetros de segurança e a chave de
sessão estabelecida anteriormente sejam reutilizados. Reduz-se assim o overhead com o
estabelecimento de sessões, visto que o tráfego de dados via web browser é tipicamente
caracterizado por várias sessões, simultâneas ou consecutivas, entre um cliente e um servidor.
84
5.8 Comparação entre protocolos de tunneling
O Quadro 2 abaixo mostra a potencialidade de cada protocolo de VPN.
Propriedades
Autenticação
de
Usuário
Autenticação
de
Computadores
Suporte a
NAT
Suporte a
MultiProtocolo
Atribuição
Dinâmica de
Endereço IP
Encriptação
Uso de PKI
Autenticação
de
Pacotes
Descrição
PPTP
Consegue autenticar os
usuários que queiram
estabelecer uma conexão.
SIM
SIM
SIM
Autentica computadores
envolvidos na conexão.
SIM
SIM
SIM
SIM
SIM
SIM
SIM
NÃO
NÃO
SIM
SIM
SIM
SIM
Implementação em
andamento.
SIM
Passa por meio de um
NAT para esconder os
pontos finais da conexão.
Define um método padrão
para o tráfego IP e não IP
Define uma negociação
de endereçamento IP
entre o servidor VPN e
seus clientes. Isso elimina
configurações manuais do
protocolo IP.
Pode criptografar o tráfego corrente.
Usa infra-estrutura de
chave pública para imple
mentar a criptografia e a
autenticação.
Provê um método de
autenticação que garante
que os pacotes não foram
alterados durante a
transmissão.
L2F
L2TP/IPSec
IPSec
Implementação em
andamento.
TLS/SSL
SIM
Implementação em
andamento.
SIM
SIM
SIM
SIM
SIM
SIM
SIM
SIM
SIM
SIM
SIM
SIM
SIM
NÃO
NÃO
SIM
SIM
SIM
Quadro 2: Comparação entre protocolos de VPN
SIM
85
6 IMPLEMENTAÇÃO DE UMA VPN ATRAVÉS DO OPENVPN
A configuração de uma VPN requer a escolha do sistema operacional dos gateways e da
ferramenta que será usada para implementar os protocolos adotados. Existem várias
ferramentas disponíveis no mercado, com preços variados ou totalmente gratuitas.
Este trabalho preocupou-se com três fatores básicos: segurança, usabilidade e baixo custo de
implementação. Por isso, foi utilizado o Linux, sistema operacional bastante flexível, podendo
ser configurado com o mínimo de opções possíveis, de forma a garantir maior segurança da
rede. Além disso, por ser de livre distribuição e estar disponível gratuitamente pela Internet,
reduz drasticamente os gastos com licenças e custo total de propriedade.
A distribuição escolhida foi a Fedora, derivada do Red Hat, pois além de ser largamente
utilizada em servidores do mundo inteiro, sendo reconhecida por sua estabilidade, foi a
utilizada nos exercícios de laboratório do curso de pós-graduação, o que garante bastante
familiaridade com suas particularidades.
Dentre as ferramentas gratuitas de VPN consideradas nas pesquisas efetuadas, duas se
destacaram por sua robustez, por seguir padrões de mercado e por sua variedade de recursos:
o OpenS/Wan, sucessor do FreeS/Wan, que implementa o protocolo IPSec, e o OpenVPN,
baseado no protocolo TLS/SSL. A ferramenta adotada acabou sendo o OpenVPN, pela sua
facilidade de configuração, disponibilidade como freeware para vários sistemas operacionais,
incluindo Microsoft Windows e, principalmente, por conviver bem com redes baseadas em
NAT e IP dinâmico, que são realidade incontestável no mundo de hoje. O APÊNDICE A
mostra um breve comparativo entre essas duas ferramentas de VPN, mostrando os prós e
contras de cada uma.
Por tratar-se de softwares open source e completamente gratuitos (Linux e OpenVPN), as
orientações para instalação e configuração foram obtidas principalmente da Internet, através
de material disponível on-line.
6.1 Estudo de caso
A seguir será mostrado como a VPN experimental foi implementada, descrevendo o ambiente
86
de testes e os aspectos relevantes de sua configuração, bem como os resultados obtidos.
6.1.1 Cenário
Com base na Figura 37, os testes foram conduzidos simulando-se três redes distintas de uma
mesma empresa, cujas denominações adotadas foram “matriz”, “filial1” e “filial2”, onde cada
uma delas possui um gateway VPN e um host. Um quarto elemento foi considerado: um
equipamento standalone (não ligado a uma rede e, portanto, sem um gateway de Internet para
implementar o túnel VPN) com necessidade de acesso à rede Matriz, rodando o sistema
operacional Microsoft Windows e o software OpenVPN para Windows. Para esse micro foi
adotada a denominação Windows. Foram utilizados links ADSL (Velox da Telemar) para a
conexão das três redes e do computador Windows à Internet. Todos os modems ADSL estão
configurados no modo router.
Figura 37 – Diagrama de conexões do laboratório
87
Os gateways foram configurados com duas placas de rede, sendo uma voltada para a rede
interna da empresa e a outra para a Internet. Os hosts, por sua vez, possuem apenas uma placa
de rede e funcionam em ambientes Windows (escolhemos Windows por ser mais comum, mas
poderia ser um desktop Linux ou um MacIntosh, já que o OpenVPN roda também nessas
plataformas). Da mesma forma, o computador Windows citado possui uma única placa de
rede que possibilita sua conexão a VPN através de link ADSL (alternativamente, poderia ser
uma linha discada com acesso à Internet através de um ISP – Internet Service Provider ou
uma conexão a cabo através de um cable modem, entre outras opções). Os três gateways
Linux desempenham também o papel de firewall das respectivas redes.
O acesso à matriz se dará através do identificador labvpn-matriz.dyndns.org, que estará
dinamicamente associado ao IP do seu link ADSL. Os IPs das filiais não precisam ser
conhecidos nem mapeados dinamicamente, já que elas não se acessam mutuamente.
Os IPs utilizados são:
Modems ADSL – IP porta LAN: 192.168.254.254
Matriz –IP da interface Internet (eth0):
IP da interface local
(eth1):
IP da interface de host-m
:
192.168.254.1
192.168.0.250
192.168.0.1
Filial 1 –IP da interface Internet (eth0):
IP da interface local
(eth1):
IP da interface de host-f1
:
192.168.254.1
192.168.1.250
192.168.1.1
Filial 2 –IP da interface Internet (eth0):
IP da interface local
(eth1):
IP da interface de host-f2
:
192.168.254.1
192.168.2.250
192.168.2.1
Windows - IP da interface local
192.168.254.250
:
88
6.1.2 Instalação
Definido o ambiente de trabalho, será visto a seguir os procedimentos para instalação do
OpenVPN, que requer a execução dos seguintes passos:
-
Decisão quanto ao modo de operação desejado (router ou bridge) e do nível de
segurança requerido;
-
Download dos módulos necessários para a plataforma operacional, arquitetura de
processador e nível de segurança adotado;
-
Preparação do kernel dos gateways Linux;
-
Instalação dos módulos baixados nos gateways;
-
Criação da infra-estrutura de geração e gerenciamento de chaves de criptografia e
outros elementos de segurança;
-
Preparação do arquivo de configuração da Matriz e setup dos demais elementos
necessários ao funcionamento do OpenVPN;
-
Preparação dos arquivos de configuração das Filiais e setup dos demais elementos
necessários ao funcionamento do OpenVPN;
-
Instalação e configuração do OpenVPN no micro standalone (ambiente Windows).
6.1.2.1 Decisão quanto ao modo de operação desejado (router ou bridge) e do nível de
segurança requerido.
O OpenVPN admite dois modos de funcionamento:
Router
ou Brigde.
No cenário
estabelecido neste trabalho, será usado o modo Router. O modo Bridge seria obrigatório se:
-
A VPN tivesse necessidade de suportar protocolos não-IP, tais como IPX, por
exemplo;
89
-
Fosse necessário dar suporte a aplicações baseadas em broadcasts de rede, tais
como LAN games.
-
Fosse necessário permitir browsing, através da VPN, de recursos compartilhados
pelas estações Windows, sem o suporte de um servidor SAMBA ou WINS.
Em relação ao nível de segurança da VPN, serão utilizados todos os recursos suportados pela
solução, o que engloba autenticação baseada em certificados, encriptação de chave pública e
distribuição dinâmica de chaves.
6.1.2.2 Download dos módulos necessários para a plataforma operacional, arquitetura de
processador e nível de segurança adotado.
Conforme já visto, o OpenVPN roda em várias plataformas operacionais e suporta uma
variedade de arquiteturas de
processador.
Este trabalho foi desenvolvido em Linux
(distribuição Fedora) rodando em plataforma Intel x86. Assim, os downloads necessários são:
-
Fonte do OpenVPN: openvpn-2.0.9.tar.gz
Link para download: http://openvpn.net/download.html
Biblioteca LZO
: lzo-2.02.tar.gz
Link para download: http://www.oberhumer.com/opensource/lzo/download/
A biblioteca LZO provê funções de compressão em tempo real dos dados que trafegam no
túnel VPN, permitindo otimizar a utilização do link.
A biblioteca OpenSSL já está incluída na distribuição Linux Fedora.
Obs: Não foi considerado aqui o módulo para ambiente Windows necessário para instalar o
OpenVPN no micro standalone [vide item 8 - Instalação e configuração do OpenVPN no
micro standalone (ambiente Windows)].
6.1.2.3 Preparação do kernel dos gateways Linux.
Do ponto de vista do kernel do Linux, o único pré-requisito para instalação do OpenVPN é
que o suporte aos drivers TUN e/ou TAP esteja disponível. Isso é necessário para permitir
que programas rodando no espaço do usuário, que é o caso do OpenVPN, conforme mostrado
90
no APÊNDICE B deste trabalho, possam controlar dispositivos virtuais IP ponto-a-ponto
(virtual point-to-point IP devices ) ou dispositivos virtuais Ethernet (virtual Ethernet devices).
O driver virtual TUN é utilizado no modo de operação “router” do OpenVPN, também
chamado de modo túnel. O driver TAP apenas no modo “bridge”. No cenário adotado, será
considerado o driver TUN (interface tun0 no Linux).
No caso da distribuição Fedora, adotada no cenário de implementação descrito anteriormente,
os drivers TUN/TAP já estão presentes no kernel. Em outras distribuições em que isso não
ocorra, o kernel deverá ser recompilado.
6.1.2.4 Instalação dos módulos baixados nos gateways
Antes de descrever o processo de instalação do OpenVPN a partir do fonte baixado
anteriormente, tarefa extremamente simples, cabe estabelecer que a instalação do Fedora deve
ser a mais simples possível, partindo da regra básica de segurança que diz que todo software
contém falhas de programação e que estas falhas podem se traduzir em vulnerabilidades, e
que, portanto, quanto menos software, menos riscos. Assim, não se deve utilizar interface
gráfica e módulos desnecessários. O firewall utilizado neste trabalho já está contido no kernel
(Netfilter/Iptables).
Os passos para instalação podem ser descritos pela execução dos seguintes comandos, em
sessão com privilégio de root:
1ª parte – Instalar a biblioteca de compactação LZO
cd /root
tar –xzvf lzo-2.02.tar.gz
cd lzo-2.02
./configure
make
make install
91
2ª parte – Instalar o OpenVPN
cd /root
tar –xvzf openvpn-2.0.9.tar.gz
cd /openvpn-2.09
./configure
make
make install
A instalação cria o diretório /etc/openvpn, com todos os subdiretórios necessários ao
funcionamento do software.
6.1.2.5 Criação da infra-estrutura de geração e gerenciamento de chaves de criptografia e
outros elementos de segurança.
O OpenVPN, em sua implementação mais segura, suporta autenticação bi-direcional baseada
em certificados, o que significa que o cliente (Filial ou micro standalone) deve autenticar o
certificado do servidor, e o servidor (Matriz) deve autenticar o certificado do cliente, antes
que se estabeleça uma relação de confiança mútua que permita a criação do túnel VPN. Para
tornar tal processo possível, torna-se necessário construir uma PKI – Public Key
Infrastructure, que consiste em:
-
Um certificado individual (que contêm uma chave pública) e uma chave privada
para o servidor e para cada cliente;
-
Um certificado mestre da autoridade certificadora (CA) e uma chave privada
mestre que será utilizada para assinar cada certificado emitido para o servidor e
para cada cliente;
Servidor e cliente deverão se autenticar mutuamente primeiramente verificando se o
certificado apresentado pela outra parte está assinado pela autoridade certificadora mestre
(CA) e em seguida checando as informações existentes no cabeçalho (header) do mesmo
(common name, que identifica a entidade proprietária do certificado e o “type” do certificado
– servidor ou cliente).
Este modelo de segurança apresenta algumas características importantes sob a perspectiva da
VPN:
92
-
O servidor necessita apenas de seu próprio certificado e chave privada. Ele não
precisa conhecer os certificados individuais de cada cliente que possa vir a
conectar-se a ele;
-
O servidor somente aceita clientes cujos certificados tenham sido assinados pela
autoridade certificadora mestre (CA). E, pelo fato do servidor poder efetuar essa
verificação de assinatura sem necessidade de acesso à chave privada mestre da CA,
é possível que essa chave (o elemento mais sensível e importante de toda a PKI)
fique armazenada numa máquina completamente diferente, inclusive sem nenhuma
conexão de rede, o que garantiria maior segurança;
-
Se uma chave privada tornar-se comprometida por alguma razão, ela pode ser
desabilitada adicionando-se seu certificado a uma CRL (certificate revogation list).
A CRL possibilita que certificados comprometidos sejam seletivamente rejeitados
sem necessidade de reconstruir a PKI inteira. A CRL deve ter uma cópia no
servidor, para que a checagem possa ser feita;
-
O servidor pode considerar direitos de acesso específicos dos clientes com base em
campos embutidos em seus certificados (Common Name, por exemplo).
Apresentado o overview acima, pode-se agora gerar a PKI no próprio servidor (Matriz), tendo
em mente que num ambiente de produção ela deveria ficar num equipamento isolado de rede
por motivos de segurança.
Uma vez que já foi instalado o OpenVPN no passo anterior, existem duas opções para
construir uma PKI. A primeira seria trabalhar diretamente com as diretivas da biblioteca
OpenSSL, disponível no Linux, e que é quem dá suporte efetivo à criação e gerenciamento da
PKI. A segunda é utilizar a interface disponibilizada pelo OpenVPN para simplificar as
diretivas do OpenSSL. Será utilizada esta última opção.
6.1.2.5.1 Geração da PKI
A instalação a partir do arquivo.tar.gz utilizada anteriormente cria um diretório easy-rsa em
/root/openvpn-2.09. Para facilitar o gerenciamento da VPN, deve-se mover esse diretório
para /etc/openvpn.
cp –Rv /root/openvpn-2.09/easy-rsa /etc/openvpn/
cd /etc/openvpn/easy-rsa
93
Deve-se em seguida editar o arquivo ‘vars’, existente neste diretório alterando as seguintes
linhas (os números no início de cada linha não fazem parte do arquivo) para os valores
mostrados:
01
02
03
04
05
06
07
08
09
10
11
export EASY_RSA="/etc/openvpn/easy-rsa"
export KEY_CONFIG="$EASY_RSA/openssl.cnf"
export KEY_DIR="$EASY_RSA/keys"
export KEY_SIZE=1024
export CA_EXPIRE=365
export KEY_EXPIRE=365
export KEY_COUNTRY="BR"
export KEY_PROVINCE="ES"
export KEY_CITY="Vitoria"
export KEY_ORG="labvpn"
export KEY_EMAIL="[email protected]"
Este arquivo é um script que contém parâmetros que serão utilizados pelo OpenVPN para seu
próprio controle e para geração dos certificados. Segue uma breve explicação sobre cada uma
das linhas acima:
Linha 01:
Linha 02:
Linha 03:
Linha 04:
Linha 05:
Linha 06:
Linha 07:
Linha 08:
Linha 09:
Linha 10:
Linha 11:
Diretório onde será construída a estrutura PKI
Arquivo de configuração do OpenSSL que será alimentado pelos parâmetros
informados neste arquivo e por outros complementares obtidos em tempo de
execução dos comandos de geração dos certificados.
Diretório onde serão colocados os certificados criados.
Tamanho das chaves geradas em bits.
Número de dias em que a chave privada da CA irá expirar.
Número de dias em que os certificados irão expirar.
Campo COUNTRY do certificado.
Campo PROVINCE do certificado.
Campo CITY do certificado.
Campo ORGANIZATION do certificado.
Campo EMAIL do certificado.
Feita essa parte, pode-se partir para a inicialização da PKI executando os seguintes
comandos/scripts:
./vars
./clean-all
./build-ca
O primeiro script já foi visto. O segundo inicializa os arquivos necessários para começar a
geração da PKI do zero. O terceiro irá gerar o certificado mestre da CA e a chave mestre
privada da CA.
94
A execução de ‘build-ca’ invocará interativamente o comando openssl, cujos resultados estão
reproduzidos abaixo:
Generating a 1024 bit RSA private key
............++++++
...........++++++
writing new private key to 'ca.key'
----You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
----Country Name (2 letter code) [BR]:
State or Province Name (full name) [ES]:
Locality Name (eg, city) [Vitória]:
Organization Name (eg, company) labvpn}:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:CA
Email Address [[email protected]]:
Deve-se observar na seqüência interativa acima que os valores default de alguns campos são
aqueles informados no arquivo ‘vars’. O campo Organizational Unit Name é opcional e foi
deixado em branco e o campo Common Name foi preenchido com a seqüência “CA”. Este
último campo não existe em vars e deve ser informado explicitamente, pois deve ser único
para cada par certificado/chave privada gerada.
Os arquivos resultantes do script acima são:
ca.crt ca.key index.txt serial.txt -
Certificado mestre da CA.
Chave privada mestre da CA.
Campo de controle
Campo de controle
Com isso, a PKI foi inicializada e os arquivos mestre da CA criados. Pode-se agora partir
para a criação dos certificados/chaves privadas para a matriz, as filiais e o micro standalone
(Windows).
95
6.1.2.5.2 Matriz
./build-key-server
Como no passo anterior, os parâmetros default devem ser aceitos e em Common Name deve
ser informado “matriz”. Duas outras perguntas devem ser respondidas positivamente: "Sign
the certificate? [y/n]" e "1 out of 1 certificate requests certified, commit? [y/n]". A primeira
estabelece que o certificado deve ser assinado pela CA e a segunda confirma que o conjunto
certificado/chave privada gerados deve ser criado.
Os arquivos resultantes do script acima que nos interessam são:
matriz.crt
matriz.key
- Certificado da matriz assinado
- Chave privada da matriz
Abaixo, uma reprodução do certificado da matriz.
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=BR, ST=ES, L=Vitoria, O=labvpn, OU=, CN=CA /[email protected]
Validity
Not Before: Out 17 20:29:25 2006 GMT
Not After : Out 16 20:29:25 2007 GMT
Subject: C=BR, ST=ES, L=Vitoria, O=labvpn, OU=, CN=matriz
/[email protected]
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:9c:35:d9:4c:15:66:ec:3d:6d:7f:84:9b:e7:97:
8c:3f:9d:0d:ad:06:45:7d:9b:0b:6d:75:4f:71:89:
0e:85:e6:34:29:26:a0:8f:13:3e:6e:f3:1a:fb:8a:
9b:68:1f:d1:f7:5c:80:19:ba:5a:97:68:98:7f:c4:
80:d3:b2:1a:cb:a8:bc:0f:2e:4f:51:2c:1a:df:7b:
22:57:2d:94:a7:3a:a6:61:68:7c:26:63:2a:e0:07:
b1:4f:82:27:79:ca:a3:bf:e1:e6:48:71:50:bd:2a:
df:d5:20:b0:6d:24:82:af:1a:27:9c:eb:5b:9a:8e:
ef:45:1f:5c:a2:a2:0b:2e:63
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Cert Type:
SSL Server
Netscape Comment:
OpenSSL Generated Server Certificate
96
X509v3 Subject Key Identifier:
00:1C:82:7F:CF:AA:95:37:95:C5:57:32:37:A1:EA:01:6F:A2:FE:BE
X509v3 Authority Key Identifier:
keyid:2E:3F:B3:2E:6E:17:12:48:A1:00:C1:93:75:75:CF:99:2C:8F:48:F2
DirName:/C=BR/ST=ES/L=Vitoria/O=labvpn/OU=/CN=CA/
[email protected]
serial:00
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Key Usage:
Digital Signature, Key Encipherment
Signature Algorithm: md5WithRSAEncryption
8a:e2:91:51:b1:ba:8e:fe:de:93:49:98:63:a0:27:62:5b:f5:
0c:bf:0b:bb:5b:45:7e:0e:1f:2f:9d:08:52:b0:3d:b6:60:84:
2e:fe:45:65:d4:4d:52:6e:2c:ae:15:e5:4d:c7:00:0b:08:37:
14:d9:a5:ff:0d:69:17:92:5a:c3:69:a1:ad:0e:cd:0d:21:eb:
71:1a:a6:a7:f5:18:db:e4:58:6a:b4:77:3b:2f:c7:6b:e2:00:
ef:5d:87:02:9b:40:74:45:4d:7e:02:13:15:c2:9f:c9:c1:51:
5f:65:86:ff:5b:8f:c1:99:8b:2b:17:5e:ad:3f:60:8b:26:9f:
44:2e
-----BEGIN CERTIFICATE----MIID/TCCA2agAwIBAgIBATANBgkqhkiG9w0BAQQFADCBljELMAkGA1UEBhMCQlIx
CzAJBgNVBAgTAkVTMRAwDgYDVQQHEwdWaXRvcmlhMRMwEQYDVQQKEwpIZWxwY2Vu
dGVyMQswCQYDVQQLEwJIQzEWMBQGA1UEAxMNSGVscGNlbnRlciBDQTEuMCwGCSqG
SIb3DQEJARYfdmFuZGVybGVpQGhlbHBjZW50ZXItdml4LmNvbS5icjAeFw0wNjA3
MTcyMDI5MjVaFw0xNjA3MTQyMDI5MjVaMIGPMQswCQYDVQQGEwJCUjELMAkGA1UE
CBMCRVMxEDAOBgNVBAcTB1ZpdG9yaWExEzARBgNVBAoTCkhlbHBjZW50ZXIxCzAJ
BgNVBAsTAkhDMQ8wDQYDVQQDEwZtYXRyaXoxLjAsBgkqhkiG9w0BCQEWH3ZhbmRl
cmxlaUBoZWxwY2VudGVyLXZpeC5jb20uYnIwgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBAJw12UwVZuw9bX+Em+eXjD+dDa0GRX2bC211T3GJDoXmNCkmoI8TPm7z
GvuKm2gf0fdcgBm6WpdomH/EgNOyGsuovA8uT1EsGt97IlctlKc6pmFofCZjKuAH
sU+CJ3nKo7/h5khxUL0q39UgsG0kgq8aJ5zrW5qO70UfXKKiCy5jAgMBAAGjggFe
MIIBWjAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIGQDAzBglghkgBhvhCAQ0E
JhYkT3BlblNTTCBHZW5lcmF0ZWQgU2VydmVyIENlcnRpZmljYXRlMB0GA1UdDgQW
BBQAHIJ/z6qVN5XFVzI3oeoBb6L+vjCBwwYDVR0jBIG7MIG4gBQuP7MubhcSSKEA
wZN1dc+ZLI9I8qGBnKSBmTCBljELMAkGA1UEBhMCQlIxCzAJBgNVBAgTAkVTMRAw
DgYDVQQHEwdWaXRvcmlhMRMwEQYDVQQKEwpIZWxwY2VudGVyMQswCQYDVQQLEwJI
QzEWMBQGA1UEAxMNSGVscGNlbnRlciBDQTEuMCwGCSqGSIb3DQEJARYfdmFuZGVy
bGVpQGhlbHBjZW50ZXItdml4LmNvbS5icoIBADATBgNVHSUEDDAKBggrBgEFBQcD
ATALBgNVHQ8EBAMCBaAwDQYJKoZIhvcNAQEEBQADgYEAiuKRUbG6jv7ek0mYY6An
Ylv1DL8Lu1tFfg4fL50IUrA9tmCELv5FZdRNUm4srhXlTccACwg3FNml/w1pF5Ja
w2mhrQ7NDSHrcRqmp/UY2+RYarR3Oy/Ha+IA712HAptAdEVNfgITFcKfycFRX2WG
/1uPwZmLKxderT9giyafRC4=
-----END CERTIFICATE-----
Além do nível de segurança garantido pelo protocolo SSL/TLS, o OpenVPN possui um
recurso que torna possível criar uma de espécie de firewall interno ao daemon para ajudar no
bloqueio de ataques DoS e de inundação (flooding) de pacotes UDP. Esse recurso utiliza-se
de uma chave estática que deve ser gerada através do comando:
openvpn --genkey --secret ta.key
97
Essa chave deve ser copiada para o servidor e para os clientes da VPN. Sua ativação deve ser
feita através da diretiva tls-auth nos arquivos de configuração do OpenVPN (vide arquivos de
configuração nos tópicos seguintes).
6.1.2.5.3 Filiais e micro standalone (Windows)
./build-key filial1
./build-key filial2
./build-key Windows
De forma análoga à da matriz, os Common Names são filial1, filial2 e Windows,
espectivamente.
6.1.2.5.4 Geração de parâmetros Diffie-Hellman
./build-dh
O arquivo gerado é o ‘dh1024.pem’.
Conforme visto no capítulo 2, o algoritmo Diffie-Hellman foi o primeiro algoritmo de chave
pública descoberto, em 1976. Ele é usado até hoje para a distribuição de chaves, mas não é
capaz de cifrar ou decifrar mensagens. Seu objetivo é permitir a troca de chaves entre duas
entidades remotas através de um meio de comunicação não seguro. Matematicamente, baseiase na aplicação de funções unidirecionais. Deve-se observar que o Algoritmo Diffie-Hellman
é usado somente para a troca segura de chaves. Uma vez feita a troca, a comunicação passa a
utilizar a criptografia tradicional baseada em chaves simétricas.
98
6.1.2.5.5 Resumo das características de utilização das chaves e certificados gerados
Resumidamente, os pares certificado/chave privada e o arquivo de parâmetros DiffieHellman têm as seguintes características de utilização conforme ilustrado no Quadro 3.
Arquivo
Secreto
Necessário para
Propósito
Ca.crt
Servidor + todos os
clientes
Certificado mestre da CA
NÃO
Ca.key
Máquina que assina
somente
Chave mestre da CA
SIM
Dh1024.pem
Servidor apenas
Parâmetros Diffie Hellman
NÃO
Matriz.crt
Servidor apenas
Certificado do Servidor
NÃO
matriz.key
Servidor apenas
Chave privada do servidor
SIM
filial1.crt
Cliente 1 apenas
Certificado do Cliente 1
NÃO
Filial1.key
Cliente 1 apenas
Chave privada do Cliente
1
SIM
Filial2.crt
Cliente 2 apenas
Filial2.key
Cliente 2 apenas
Chave privada do Cliente
2
SIM
Windows.crt
Micro Windows apenas
Certificado do micro
Windows
NÃO
Windows.key
Micro Windows apenas
Chave privada do micro
Windows
SIM
Certificado do Cliente 2
Quadro 3 - Características de uso e localização de chaves e certificados
NÃO
99
O passo final desse processo é copiar todos os arquivos indicados na tabela para seus
respectivos locais de utilização, tomando o cuidado básico de transferir os arquivos secretos
através de um meio de transmissão seguro.
6.1.2.6 Preparação do arquivo de configuração da Matriz e setup dos demais elementos
necessários ao funcionamento do OpenVPN.
Uma vez definida a estrutura de PKI e geradas as chaves e certificados necessários, deve-se
preparar o servidor da VPN (Matriz), cuja configuração estará inteiramente contida num
arquivo de configuração localizado em /etc/openvpn.
A seguir é mostrado o arquivo de configuração que dará suporte ao cenário proposto, no lado
do servidor, com os devidos comentários sobre as principais opções. Este arquivo não é
obrigatório, podendo-se especificar cada uma de suas linhas como parâmetro do comando que
carrega o daemon openvpn (cada linha constitui uma opção co comando e deve ser precedida
de dois hífens). Entretanto, a utilização do arquivo de configuração permite uma melhor
visualização e organização das opções utilizadas, sendo a forma adotada neste trabalho.
#====================================
# Arquivo de configuração do OpenVPN versão 2
# (multi-client server)
#
# MATRIZ
#
# Este arquivo configura o lado server (Matriz)
# de uma configuração vários-clientes <-> um
# servidor.
#
# Esta configuração se aplica a sistemas baseados
# no Windows ou em Linux/BSD.
#
# Comentários são precedidos de '#' ou ';' e
# são permitidas linhas em branco.
#=====================================
# Define o IP local que o OpenVPN deve monitorar (opcional).
local 192.168.254.1
# Este é o endereço IP associado à placa eth0 do servidor
# openvpn da matriz.
# Define a porta TCP/UDP o OpenVPN deve monitorar. # Se por
# alguma razão se deseja executar múltiplas instâncias do
# OpenVPN na mesma máquina, deve-se utilizar um número de
# porta diferente para cada uma delas. Será necessário ainda
# abrir essa porta no firewall da rede. Valor default: 1194.
port 5100
100
# TCP ou UDP?
;proto tcp
proto udp
# "dev tun" irá criar um túnel IP roteado. "dev tap" irá criar
# um túnel ethernet. Em muitos sistemas a VPN não funcionará
# a menos que seja desabilitada parcial ou completamente o
# firewall para a interface.
# TUN/TAP.
;dev tap
dev tun
# SSL/TLS: certificado mestre da CA (ca), certificado (cert) e
# chave privada (key). Cada cliente ou servidor deve ter seu
# próprio arquivo de certificado e de chave privada. O servidor
# e todos os clientes irão utilizar o mesmo arquivo "ca".
#
# No diretório "easy-rsa" existe uma série de scripts para a
# geração de certificados RSA e chaves privadas. Deve-se
# utilizar Common Names exclusivos para os certificados do
# servidor e de cada cliente.
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/matriz.crt
key /etc/openvpn/keys/matriz.key # Deve ser mantido secreto
# Parâmetros Diffie-Hellman. Podem ser gerados pelo comando
# ‘./build-dh’ do OpenVPN ou ‘openssl dhparam -out dh1024.pem
# 1024’ da biblioteca OpenSSL. 1024 deve ser substituído por
# 2048 quando se deseja usar chaves de 2048 bits.
dh /etc/openvpn/keys/dh1024.pem
# A configuração abaixo fornece uma sub-rede VPN para o OpenVPN
# a partir da qual serão gerados outros endereços para os
# clientes. O servidor irá tomar o primeiro endereço (10.8.0.1)
# para si e os endereços a seguir serão disponibilizados para
# os clientes. cada cliente estará apto a encontrar o servidor
# em 10.8.0.1.
server 10.8.0.0 255.255.255.0
# A próxima opção mantém um registro das associações cliente
# x endereço IP virtual no arquivo especificado. Se OpenVPN
# fica indisponível ou é reiniciado, na reconexão dos clientes
# o mesmo endereço IP virtual que estava previamente associado
# é mantido.
ifconfig-pool-persist ipp.txt
# Envia rotas para os clientes para possibilitar que eles
# encontrem outra ou outras sub-redes privadas atrás do servidor
# (nesse caso, conectadas a eth1). Deve-se lembrar que estas
# sub-redes privadas (nesse caso apenas uma) também precisarão
# saber como rotear o pool de endereços dos clientes do OpenVPN
# de volta para o servidor.
push "route 192.168.0.0 255.255.255.0"
# OBS: 192.168.0.0 é o endereço de rede local da matriz.
# Para associar endereços IP específicos a determinados
# clientes ou se um cliente da VPN possui uma sub-rede
# privada atrás de si cujos micros também devam ter acesso
# à VPN, deve-se utilizar o subsdiretório "clients-config"
# para manter arquivos de configuração específicos para cada
101
# cliente.
# Neste estudo de caso, os clientes com certificados
# de common name "filial1" e "filial2" têm atrás de si as
# sub-redes 192.168.1.0 e 192.168.2.0, respectivamente.
client-config-dir clients-config
route 192.168.1.0 255.255.255.0
# CN=filial1
route 192.168.2.0 255.255.255.0
# CN=filial2
route 192.168.254.250 255.255.255.0 #CN=Windows
# Então, deve-se criar no diretório clients-config da matriz
# os arquivos "filial1", “filial2" e “Windows”(nomes idênticos aos
# common names de seus respectivos certificados) com as
# seguintes linhas:
# filial1
--> iroute 192.168.1.0 255.255.255.0 # filial1
#
ifconfig-push 10.8.0.3 10.8.0.4 # filial1
# filial2
--> iroute 192.168.2.0 255.255.255.0 # filial2
#
ifconfig-push 10.8.0.5 10.8.0.6 # filial2
# Windows --> iroute 192.168.2.0 255.255.255.0 # Windows
#
ifconfig-push 10.8.0.7 10.8.0.8 # Windows
# Isto possibilitará às máquinas existentes em cada uma das
# duas sub-redes acessar a VPN e também fixará seus IPs
# virtuais (10.8.0.3/10.8.0.4, 10.8.0.5/10.8.0.6 e 10.8.0.7/
# 10.8.0.8) respectivamente).
# A diretiva abaixo deve ser descomentada para permitir que
# os clientes da VPN estejam aptos a se enxergar mutuamente.
# Por default, os clientes podem ver apenas o servidor.
# Nesse estudo de caso, será mantida a opção default, e
# a diretiva permanecerá comentada.
;client-to-client
# Se for desejado que múltiplos clientes se conectem com os
# mesmos arquivos de certificado, chaves privadas e common
# names, a diretiva abaixo deve ser descomentada. Tal opção
# só deve ser usada para fins de teste. Em ambiente de
# produção cada cliente deve ter seu próprio par certificado/
# chave. Assim foi feito neste trabalho.
;duplicate-cn
# A opção keepalive faz com que mensagens similares ao ping
# sejam enviadas através do link para que cada lado saiba
# quando outro lado caiu. Os valores especificados informam
# que são enviados “pings” a cada 10 segundos e assumido que
# o outro lado caiu se nenhum “ping” for recebido durante o
# intervalo de tempo de 120 segundos.
keepalive 10 120
# Para um nível de segurança além daquele proporcionado pelo
# protocolo SSL/TLS, é possível criar um “firewall HMAC" para
# ajudar no bloqueio de ataques DoS e “UDP port flooding”.
# Para isso deve ser gerada uma chave estática através do
# comando:
#
# openvpn --genkey --secret ta.key
#
# O servidor e cada cliente devem ter uma cópia desta chave.
# O segundo parâmetro da diretiva deve ser “0” para o servidor
# e “1” para os clientes.
tls-auth ta.key 0 # Este arquivo é secreto
# OpenVPN permite escolher o cifrador criptográfico. Esta
102
# escolha # deve ser reproduzida nos arquivos de configuração
# dos clientes. As opções são Blowfish, AES e 3DES.
cipher BF-CBC
# Blowfish (default)
;cipher AES-128-CBC # AES
;cipher DES-EDE3-CBC # Triple-DES
# Esta diretiva habilita a compressão no link VPN. Se for
# habilitada no servidor, é obrigatório que também seja nos
# clientes.
comp-lzo
# Número máximo de clientes conectados concorrentemente.
max-clients 100
# Por questões de seguranças, é uma boa idéia reduzir os
# privilégios do daemon OpenVPN após sua inicialização
# (válido apenas para sistemas não-Windows). Significa que
# o OpenVPN é inicializado com direitos de root e a seguir
# sofre um “rebaixamento”. Assim, em caso de um ataque
# bem sucedido, o invasor terá direitos limitados.
user nobody
group nobody
# As opções “persist” irão tentar evitar que certos recursos
# sejam acessados durante eventuais restarts, uma vez que eles
# poderão não estar mais disponíveis em função do downgrade
# de privilégios ocasionado pelas duas opções anteriores.
persist-key
persist-tun
# A opção abaixo gera um pequeno arquivo de status mostrando
# as conexões ativas (é reescrito a cada minuto).
status openvpn-status.log
# Por default, as mensagens do OpenVPN serão enviadas ao syslog,
# no Linux. No Windows, se o OpenVPN estiver rodando como um
# serviço, as mensagens serão gravadas no diretório “\Arquivos
# de Programas\OpenVPN\log". As opções log e log-append mudarão
# a definição default.
# "log" irá reiniciar o arquivo de log a cada startup do OpenVPN.
# "log-append" irá adicionar mensagens no final do arquivo de
# log. Deve ser utilizado um ou outro, mas não os dois.
;log
openvpn.log
log-append openvpn.log
# A diretiva “verb” estabelece o nível apropriado de detalhes que
# será relatado nos logs.
# 0 é silêncio, exceto para erros fatais.
# 3 e 4 são níveis razoáveis para uso geral.
# 5 e 6 podem ajudar na depuração de problemas de conexão.
# 9 é o nível mais detalhado.
verb 3
# A opção abaixo estabelece que no máximo 20 mensagens seqüenciais
# da mesma categoria serão direcionadas para os logs. Visa evitar
# que o log se torne “inchado” pela repetição exaustiva de
# mensagens.
mute 20
103
Além do arquivo de configuração principal (matriz.conf), processado diretamente pelo
daemon OpenVPN durante sua carga, existem ainda os arquivos por ele referenciados, a
saber:
/etc/openvpn/keys/ca.crt
/etc/openvpn/keys/matriz.crt
/etc/openvpn/keys/matriz.key
/etc/openvpn/keys/dh1024.pem
/etc/openvpn/ipp.txt
/etc/openvpn/clients-config/filial1
/etc/openvpn/clients-config/filial2
/etc/openvpn/keys/ta.key
/etc/openvpn/openvpn.log
(1)
(2)
(3)
(4)
(5)
(6)
(7)
(8)
(9)
A função de todos eles já foi detalhada anteriormente, no item sobre PKI e nos comentários do
próprio arquivo matriz.conf. Resumidamente, os três primeiros são gerados pelo sistema PKI
a partir de parâmetros informados durante o processo de geração dos certificados e chaves. O
mesmo ocorre com o 4º e 8º arquivos, que também são gerados através do OpenSSL. O
arquivo 5 é para controle do OpenVPN, sendo gerado e atualizado em tempo de operação da
VPN, automaticamente.
O arquivo 9 é o log do OpenVPN e também é gerado
automaticamente. Restam então os arquivos 6 e 7, que são construídos manualmente, estando
reproduzidos abaixo.
# Filial 1
iroute 192.168.1.0 255.255.255.0
ifconfig-push 10.8.0.3 10.8.0.4
# Filial 2
iroute 192.168.2.0 255.255.255.0
ifconfig-push 10.8.0.5 10.8.0.6
# Windows
iroute 192.168.254.250 255.255.255.0
ifconfig-push 10.8.0.7 10.8.0.8
Definida a estrutura de arquivos, é necessário ainda preparar o Linux para executar algumas
tarefas necessárias e complementares ao correto funcionamento do OpenVPN. São elas:
No arquivo /etc/rc.d/rc.local, incluir as seguintes linhas:
104
echo 1 > /proc/sys/net/ipv4/ip_forward
(1)
route add default gw 192.168.254.254
(2)
/usr/bin/inadyn -u labvpn -p LabVPN2006 –a
labvpn-matriz.dyndns.org --syslog --background
(3)
/etc/firewall/iptables.conf
(4)
/usr/local/sbin/openvpn --config /etc/openvpn/matriz.conf
--daemon -–float
(5)
Como é sabido, este arquivo contém comandos ou chamadas de scripts que devem ser
executados em tempo de carga do Linux. As linhas acima têm os seguintes significados:
(1)
Ativa o roteamento entre as interfaces de rede do Linux, que por default está
desabilitado.
(2)
Define a rota default do gateway matriz, apontando-a para a interface LAN do modem
ADSL.
(3)
Executa o aplicativo inadyn, responsável pela associação do identificador labvpnmatriz.dyndns.org ao IP público do link ADSL. Esse aplicativo monitora as mudanças
de IP e quando ocorrem providencia sua atualização junto ao serviço DYNDNS. Os
cinco parâmetros especificados na linha significam: 1º) nome do usuário responsável
pelo identificador junto ao serviço DYNDNS (-u labvpn), 2º) senha do usuário (-p
LabVPN2006), 3º) identificador do gateway matriz na Internet (-a labvpn.dyndns.org),
4º) direciona o log do aplicativo para o syslog e 5º) executa a aplicação inadyn em
background, tornado-a residente em memória e apta a efetuar o monitoramento do IP.
O aplicativo é um freeware e pode ser baixado do link http://www.softpicks.net/
software/inadyn-22675.htm.
(4)
Executa o script /etc/firewall/iptables.conf, que contem os comandos que constituem o
firewall da rede matriz (entre esses comandos estão os necessários para liberar o
tráfego através da VPN (vide detalhamento abaixo).
(5)
Executa o daemon openvpn. Os três parâmetros do comando significam: 1º) arquivo
de configuração que deve ser utilizado (--config /etc/openvpn/matriz.conf), 2º)
estabelece que a finalização do processo de carga do OpenVPN seja retardada até que
as funções de inicialização capazes de gerar erros fatais estejam completas (--daemon),
3º) É importante quando se trabalha com IPs dinâmicos, como é o caso aqui (links
ADSL), e define que nas mudanças de IP dos clientes haverá um novo processo de
autenticação e o novo endereço passará a ser considerado na mesma sessão, sem perda
da comunicação. É útil também em conexões dial-up.
105
No script que contém os comandos de firewall do servidor matriz (no caso o arquivo
/etc/firewall/iptables.conf), devem ser incluídos os comandos para liberação do tráfego da
VPN através da interface virtual tun0. No script utilizado, reproduzido a seguir, foram
omitidas as linhas não relacionadas à VPN, representadas por seqüências de três pontos (...). A
designação tun+ especifica todas as interfaces tun possíveis: tun0, tun1, tun2, etc).
# Firewall do Servidor Matriz – Implementação para o laboratório labvpn
#
# Internet -------> eth0
# Rede interna ---> eth1
#
LAN=192.168.0.0/24
...
...  declaração de outras variáveis
...
#
iptables.conf()
{
#
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
#
...
...  outros comndos do firewall (tabela filter)
...
# Permite tráfego para conexões já existentes
iptables -A FORWARD -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -p udp -m state --state RELATED,ESTABLISHED -j ACCEPT
#
# Permite conexões através da interface "tun" (OpenVPN)
iptables -A INPUT
-i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT
#
# Abre a porta UDP 5100 para conexoes ao OpenVPN Server
iptables -A INPUT
-p udp --dport 5100 -j ACCEPT
iptables -A FORWARD -p udp --dport 5100 -j ACCEPT
#
#
...
...  outros comndos do firewall (tabela filter)
...
#
iptables -t mangle -P INPUT ACCEPT
iptables -t mangle -P FORWARD ACCEPT
iptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P POSTROUTING ACCEPT
iptables -t mangle -P OUTPUT ACCEPT
#
#
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT
#
106
...
...  outros comndos do firewall (tabela nat)
...
#
# Efetua NAT dos pacotes originados na rede interna
iptables -t nat -A POSTROUTING -s $LAN -j MASQUERADE
#
}
iptables.conf
#
# -------------------------------------------------------------------
Uma vez iniciado o OpenVPN, pode-se visualizar sua presença através de alguns comandos
do Linux, como ifconfig e route, reproduzidos a seguir. O ifconfig reporta a presença da
interface virtual tun0 (destacada em negrito), onde pode-se observar os IPs 10.8.0.1 e 10.8.0.2.
No comando route pode-se observar referências a esses IPs virtuais, bem como aos IPs reais,
tanto da matriz quanto das filiais 1 e 2.
[root@labvpn-matriz vanderlei]# ifconfig
eth0
Encapsulamento do Link: Ethernet Endereço de HW 00:0A:E6:6B:E0:46
inet end.: 192.168.254.1 Bcast:192.168.254.255 Masc:255.255.255.0
endereço inet6: fe80::20a:e6ff:fe6b:e046/64 Escopo:Link
UP BROADCASTRUNNING MULTICAST MTU:1500 Métrica:1
RX packets:4538183 errors:0 dropped:0 overruns:0 frame:0
TX packets:4249691 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:1000
RX bytes:2848927465 (2716.9 Mb) TX bytes:613270031 (584.8 Mb)
IRQ:11 Endereço de E/S:0xae00
eth1
Encapsulamento do Link: Ethernet Endereço de HW 00:40:F4:61:81:AC
inet end.: 192.168.0.250 Bcast:192.168.0.255 Masc:255.255.255.0
endereço inet6: fe80::240:f4ff:fe61:81ac/64 Escopo:Link
UP BROADCASTRUNNING MULTICAST MTU:1500 Métrica:1
RX packets:4529129 errors:0 dropped:0 overruns:0 frame:0
TX packets:4529779 errors:0 dropped:0 overruns:3 carrier:0
colisões:0 txqueuelen:1000
RX bytes:2773409343 (2644.9 Mb) TX bytes:2978568558 (2840.5 Mb)
IRQ:12 Endereço de E/S:0xe800
lo
Encapsulamento do Link: Loopback Local
inet end.: 127.0.0.1 Masc:255.0.0.0
endereço inet6: ::1/128 Escopo:Máquina
UP LOOPBACKRUNNING MTU:16436 Métrica:1
RX packets:6642 errors:0 dropped:0 overruns:0 frame:0
TX packets:6642 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:0
RX bytes:1490177 (1.4 Mb) TX bytes:1490177 (1.4 Mb)
107
tun0
Encapsulamento do Link: Protocolo Ponto-a-Ponto
inet end.: 10.8.0.1 P-a-P:10.8.0.2 Masc:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Métrica:1
RX packets:485919 errors:0 dropped:0 overruns:0 frame:0
TX packets:389266 errors:0 dropped:0 overruns:0 carrier:0
colisões:0 txqueuelen:100
RX bytes:239529196 (228.4 Mb) TX bytes:69509712 (66.2 Mb)
[root@labvpn-matriz vanderlei]#_
[root@labvpn-matriz vanderlei]# route -n
Tabela de Roteamento IP do Kernel
Destino
Roteador
MáscaraGen. Opções MétricaRef
10.8.0.2
0.0.0.0
255.255.255.255 UH
0
0
192.168.2.0 10.8.0.2
255.255.255.0 UG
0
0
192.168.1.0 10.8.0.2
255.255.255.0 UG
0
0
10.8.0.0
10.8.0.2
255.255.255.0 UG
0
0
192.168.0.0
0.0.0.0
255.255.255.0 U
0
0
192.168.254.0 0.0.0.0
255.255.255.0 U
0
0
127.0.0.0
0.0.0.0
255.0.0.0
U
0
0
0.0.0.0
192.168.254.254 0.0.0.0
UG
0
0
Uso Iface
0 tun0
0 tun0
0 tun0
0 tun0
0 eth1
0 eth0
0 lo
0 eth0
[root@labvpn-matriz vanderlei]#_
6.1.2.7 Preparação dos arquivos de configuração das Filiais e setup dos demais elementos
necessários ao funcionamento do OpenVPN.
Nesta etapa, deve-se preparar as filiais que têm gateway Linux (Filial1 e Filial2), cujas
configurações estarão inteiramente contidas num arquivo de configuração localizado em
/etc/openvpn/clients-config. Este diretório foi criado na estrutura do OpenVPN da matriz, e
para efeito de padronização, será mantido também nas filiais.
De forma análoga à Matriz, a seguir é mostrado o arquivo de configuração da Filial1
(filial1.conf).
#=======================================================
# Arquivo de configuração do OpenVPN versão 2
# (multi-client server)
#
# FILIAL 1
#
# Este arquivo configura o lado cliente(Filial1)
# de uma configuração vários-clientes <-> um
# servidor do OpenVPN. Cada cliente deve ter seu
# próprio arquivo de configuração e seu certificado
# e chave privada.
#
# Esta configuração se aplica a sistemas baseado
# no Windows ou em Linux/BSD.
108
#
# Para ambiente Windows, este arquivo deve ter
# entensão .ovpn.
#
# Comentárioss são precedidos de '#' ou ';' e
# são permitidas linhas em branco.
#====================================
# Especifica que este arquivo refere-se a um lado cliente e
# que irá puxar certas diretivas do arquivo de configuração
# do servidor.
client
# Aqui deve ser utilizada a mesma configuração definida para o
# servidor.
# "dev tun" irá criar um túnel IP roteado. "dev tap" irá criar
# um túnel ethernet. Em muitos sistemas a VPN não funcionará
# a menos que seja desabilitada oarcial ou completamente o
# firewall para a interface.
;dev tap
dev tun
# Aqui deve ser utilizada a mesma configuração definida para o
# servidor.
# A conexão será feita com um servidor TCP ou UDP?
;proto tcp
proto udp
# Configuração do hostname ou IP e porta do servidor. Pode-se
# ter múltiplas entradas nesta opção, o que estabeleceria
# um balanceamento de carga entre os servidores especificados.
#remote <servidor> 1194
remote labvpn.dyndns.org 5100
# Define a escolha do servidor randomicamente a partir de uma
# lista para fins de balanceamento de carga. Não será utilizado
# neste projeto.
;remote-random
# Define que o cliente deve tentar indefinidamente resolver o
# hostname do servidor OpenVPN. Muito útil em máquinas que não
# permanecem conctadas à Internet full time (exemplo: notebooks).
resolv-retry infinite
# A opção abaixo pode ser usada se o cliente não necessita de
# ligação (bind) a uma porta local específica.
nobind
# Por questões de seguranças, é uma boa idéia reduzir os
# privilégios do daemon OpenVPN após sua inicialização
# (válido apenas para sistemas não-Windows).
user nobody
group nobody
# As opções “persist” irão tentar evitar que certos recursos
# sejam acessados durantes os restarts, uma vez que eles
# poderão não estar mais disponíveis em função do downgrade
# de privilégios ocasionado pelas duas opções anteriores.
persist-key
persist-tun
109
# Se a conexão ao servidor OpenVPN deve ser feita através de
# um proxy http, coloque o IP e a porta do proxy aqui.
# Se o proxy requer autenticação, consulte a “man page” para
# mais informações.
;http-proxy-retry # retry on connection failures
;http-proxy [proxy server] [proxy port #]
# Redes wireless diversas vezes produzem uma grande
# quantidade de pacotes duplicados. Esta opção deve ser
# utilizada para evitar as advertências a respeito de
# pacotes duplicados.
mute-replay-warnings
# SSL/TLS: certificado mestre da CA (ca), certificado (cert) e
# chave privada (key). Cada cliente ou servidor deve ter seu
# próprio arquivo de certificado e de chave privada. O servidor
# e todos os clientes irão utilizar o mesmo arquivo "ca".
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/filial1.crt
key /etc/openvpn/keys/filial1.key
# A opção abaixo verifica o certificado do servidor checando
# se o campo nsCertType está setado para "server". Esta é
# uma importante precaução contra um potencial ataque
# discutido no site http://openvpn.net/howto.html#mitm.
# Para utilizar esse recurso, é necessário gerar o certificado
# do servidor com o campo nsCertType setado para “server”.
ns-cert-type server
# Para um nível de segurança além daquele proporcionado pelo
# protocolo SSL/TLS, é possível criar um “firewall HMAC" para
# ajudar no bloqueio de ataques DoS e “UDP port flooding”.
# Para isso deve ser gerada uma chave estática através do
# comando:
#
# openvpn --genkey --secret ta.key
#
# O servidor e cada cliente devem ter uma cópia desta chave.
# O segundo parâmetro da diretiva deve ser “0” para o servidor
# e “1” para os clientes.
#
# Se a opção tls-auth key é usada no servidor, então todos os
# clientes também deverão stilizá-la.
tls-auth ta.key 1 # Este arquivo é secreto
# OpenVPN permite escolher o cifrador criptográfico. Esta
# escolha deve reproduzir aquela feita no arquivo de
# configuração do servidor.
cipher BF-CBC
# Blowfish (default)
;cipher AES-128-CBC # AES
;cipher DES-EDE3-CBC # Triple-DES
# Esta diretiva habilita a compressão no link VPN. Se for
# habilitada no servidor, é obrigatório que também seja nos
# clientes.
comp-lzo
# A diretiva “verb” estabelece o nível apropriado de detalhe que
# será relatado nos logs.
110
# 0 é silêncio, exceto para erros fatais.
# 3 e 4 são níveis razoáveis para uso geral.
# 5 e 6 podem ajudar na depuração de problemas de conexão.
# 9 é o nível mais detalhado.
verb 3
# A opção abaixo estabelece que no máximo 20 mensagens seqüenciais
# da mesma categoria serão direcionadas para os logs.
mute 20
O arquivo da Filial 2 é idêntico, mudando apenas a sessão relativa ao certificado e à chave
privada, que são individualizadas para cada filial. Na reprodução deste arquivo, as partes
idênticas às da Filial 1 estão representadas por uma seqüência de três pontos (...).
#====================================
# Arquivo de configuração do OpenVPN versão 2
# (multi-client server)
#
# FILIAL 2
#
# Este arquivo configura o lado cliente(Filial1)
# de uma configuração vários-clientes <-> um
# servidor do OpenVPN. Cada cliente deve ter seu
# próprio arquivo de configuração e seu certificado
# e / chave privada.
#
# Esta configuração se aplica a sistemas baseado
# no Windows ou em Linux/BSD.
#
# Para ambiente Windows, este arquivo deve ter
# entensão .ovpn.
#
# Comentárioss são precedidos de '#' ou ';' e
# são permitidas linhas em branco.
#====================================
...
...
...
# SSL/TLS: certificado mestre da CA (ca), certificado (cert) e
# chave privada (key). Cada cliente ou servidor deve ter seu
# próprio arquivo de certificado e de chave privada. O servidor
# e todos os clientes irão utilizar o mesmo arquivo "ca".
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/filial2.crt
key /etc/openvpn/keys/filial2.key
...
...
...
Também de forma análoga à Matriz, além do arquivo de configuração principal (filialx.conf),
processado diretamente pelo daemon OpenVPN durante sua carga, existem ainda os arquivos
por ele referenciados:
111
/etc/openvpn/keys/ca.crt
/etc/openvpn/keys/filialx.crt
/etc/openvpn/keys/filialx.key
/etc/openvpn/keys/dh1024.pem
/etc/openvpn/ipp.txt
/etc/openvpn/keys/ta.key
/etc/openvpn/openvpn.log
(1)
(2)
(3)
(4)
(5)
(6)
(7)
Os arquivos filialx em (2) e (3) referem-se a filial1 e filial2.
A função de todos eles já foi
detalhada anteriormente, e não serão repetidas aqui. Cabe apenas chamar a atenção para a
inexistência dos arquivos filial1 e filial2, necessários apenas no servidor da Matriz.
Também aqui, além dessa estrutura de arquivos, é necessário preparar o Linux para executar
algumas tarefas adicionais, que são:
No arquivo /etc/rc.d/rc.local, incluir as seguintes linhas:
echo 1 > /proc/sys/net/ipv4/ip_forward
(1)
route add default gw 192.168.254.254
(2)
/etc/firewall/iptables.conf
(3)
/usr/local/sbin/openvpn --config /etc/openvpn/clientesconfig/filialx.conf --daemon -–float
(4)
As explicações são as mesmas feitas para a Matriz, e deve-se notar a ausência da linha de
execução do inadyn. Conforme já frisado, apenas o servidor precisa ser referenciado através
da Internet, e daí a necessidade de associar um identificador fixo ao IP variável da conexão
ADSL. Pode-se observar no arquivo de configuração das filiais a referência a esse
identificador, bem como à porta UDP utilizada, na linha “remote labvpn.dyndns.org 5100”.
Os scripts de firewall das filiais (/etc/firewall/iptables.conf), também devem conter comandos
para liberação do tráfego da VPN através da interface virtual tun0. A única linha diferente,
em relação à Matriz, no que diz respeito à VPN, é aquela que define a variável LAN, que deve
ser:
Para a Filial 1  LAN=192.168.1.0/24
Para a Filial 2  LAN=192.168.2.0/24
112
Uma vez iniciado o OpenVPN na filial1, as estações de sua rede interna já conseguem
“enxergar” a matriz. O comando tcpdump executado na matriz para a interface tun0, cujo
resultado é visto abaixo, mostra os pacotes ‘echo request’ e ‘echo reply’ correspondentes à
execução do comando ping 192.168.0.1 na estação host-f1. É importante observar o campo
‘link type’ mostrando LINUX_SSL, o que confirma o uso de protocolo TLS/SSL no túnel
VPN.
[root@labvpn-matriz vanderlei]# tcpdump -i tun0
tcpdumo: verbose output supressed, use -v or -vv for full protocol decode
listening on tun0, link type LINUX_SSL (Linux cooked), capture size 96 bytes
12 packets captured
12 packets received by filter
0 packets dropped by kernel
15:08:20.622317 IP 10.8.0.3 > 192.168.0.1: icmp 64: echo request seq 235
15:08:20.623667 IP 192.168.0.1 > 10.8.0.3: icmp 64: echo reply seq 235
15:08:21.622614 IP 10.8.0.3 > 192.168.0.1: icmp 64: echo request seq 236
15:08:21.623614 IP 192.168.0.1 > 10.8.0.3: icmp 64: echo reply seq 236
15:08:22.626053 IP 10.8.0.3 > 192.168.0.1: icmp 64: echo request seq 237
15:08:22.627056 IP 192.168.0.1 > 10.8.0.3: icmp 64: echo reply seq 237
15:08:23.622067 IP 10.8.0.3 > 192.168.0.1: icmp 64: echo request seq 238
15:08:23.623047 IP 192.168.0.1 > 10.8.0.3: icmp 64: echo reply seq 238
15:08:24.619606 IP 10.8.0.3 > 192.168.0.1: icmp 64: echo request seq 239
15:08:24.620586 IP 192.168.0.1 > 10.8.0.3: icmp 64: echo reply seq 239
15:08:25.624525 IP 10.8.0.3 > 192.168.0.1: icmp 64: echo request seq 240
15:08:25.625537 IP 192.168.0.1 > 10.8.0.3: icmp 64: echo reply seq 240
[root@labvpn-matriz vanderlei]#_
6.1.2.8 Instalação e configuração do OpenVPN no micro standalone (ambiente Windows).
Para obter o arquivo de instalação do OpenVPN para Windows, deve-se efetuar o download a
partir do endereço http://openvpn.se/download.htm.
O módulo para instalação em Windows é o openvpn-2.0.9-gui-1.0.3-install.exe. Ele está
escrito em código C win32 puro, e não requer nenhuma biblioteca run-time para executar. Até
este momento, a versão 1.03 é a última versão estável da interface gráfica para Windows e já
traz consigo a versão 2.0.9 do OpenVPN.
O OpenVPN para Windows é suportado nas versões 2000, XP e posteriores. Sua instalação
requer basicamente a execução do arquivo executável baixado. Nesse processo é criado um
diretório openvpn sob a pasta ‘arquivos de programas’. O restante da estrutura de pastas e do
113
processo de instalação é bem parecido com o do Linux: adaptar o arquivo de configuração
para as características estabelecidas no cenário descrito em 6.1.1 para a máquina standalone,
copiar os certificados e chaves geradas para a máquina Windows e definir os mecanismos de
carga do software (manual ou automático).
O arquivo de configuração é:
#====================================
# Arquivo de configuração do OpenVPN versão 2
# (multi-client server)
#
# MICRO STANDALONE WINDOWS
#
# Este arquivo configura o lado cliente (Windows)
# de uma configuração vários-clientes <-> um
# servidor do OpenVPN. Cada cliente deve ter seu
# próprio arquivo de configuração e seu certificado
# e chave privada.
#
# Esta configuração se aplica a sistemas baseado
# no Windows ou em Linux/BSD.
#
# Para ambiente Windows, este arquivo deve ter
# entensão .ovpn.
#
# Comentárioss são precedidos de '#' ou ';' e
# são permitidas linhas em branco.
#====================================
# Especifica que este arquivo refere-se a um lado cliente e
# que irá puxar certas diretivas do arquivo de configuração
# do servidor.
client
# Aqui deve ser utilizada a mesma configuração definida para o
# servidor.
# "dev tun" irá criar um túnel IP roteado. "dev tap" irá criar
# um túnel ethernet. Em muitos sistemas a VPN não funcionará
# a menos que seja desabilitada oarcial ou completamente o
# firewall para a interface.
;dev tap
dev tun
# Aqui deve ser utilizada a mesma configuração definida para o
# servidor.
# A conexão será feita com um servidor TCP ou UDP?
;proto tcp
proto udp
# Configuração do hostname ou IP e porta do servidor. Pode-se
# ter múltiplas entradas nesta opção, o que estabeleceria
# um balanceamento de carga entre os servidores especificados.
#remote <servidor> 1194
remote labvpn.dyndns.org 5100
114
# Define a escolha do servidor randomicamente a partir de uma
# lista para fins de balanceamento de carga. Não será utilizado
# neste projeto.
;remote-random
# Define que o cliente deve tentar indefinidamente resolver o
# hostname do servidor OpenVPN. Muito útil em máquinas que não
# permanecem conctadas à Internet full time (exemplo: notebooks).
resolv-retry infinite
# A opção abaixo pode ser usada se o cliente não necessita de
# ligação (bind) a uma porta local específica.
nobind
# Por questões de seguranças, é uma boa idéia reduzir os
# privilégios do daemon OpenVPN após sua inicialização
# (válido apenas para sistemas não-Windows).
#user nobody
#group nobody
# As opções “persist” irão tentar evitar que certos recursos
# sejam acessados durantes os restarts, uma vez que eles
# poderão não estar mais disponíveis em função do downgrade
# de privilégios ocasionado pelas duas opções anteriores.
persist-key
persist-tun
# Se a conexão ao servidor OpenVPN deve ser feita através de
# um proxy http, coloque o IP e a porta do proxy aqui.
# Se o proxy requer autenticação, consulte a “man page” para
# mais informações.
;http-proxy-retry # retry on connection failures
;http-proxy [proxy server] [proxy port #]
# Redes wireless diversas vezes produzem uma grande
# quantidade de pacotes duplicados. Esta opção deve ser
# utilizada para evitar as advertências a respeito de
# pacotes duplicados.
mute-replay-warnings
# SSL/TLS: certificado mestre da CA (ca), certificado (cert) e
# chave privada (key). Cada cliente ou servidor deve ter seu
# próprio arquivo de certificado e de chave privada. O servidor
# e todos os clientes irão utilizar o mesmo arquivo "ca".
ca c:\\arquiv~1\\openvpn\\keys\\ca.crt
cert c:\\arquiv~1\\openvpn\\keys\\Windows.crt
key c:\\arquiv~1\\openvpn\\keys\\Windows.key
# A opção abaixo verifica o certificado do servidor checando
# se o campo nsCertType está setado para "server". Esta é
# uma importante precaução contra um potencial ataque
# discutido no site http://openvpn.net/howto.html#mitm.
# Para utilizar esse recurso, é necessário gerar o certificado
# do servidor com o campo nsCertType setado para “server”.
ns-cert-type server
# Para um nível de segurança além daquele proporcionado pelo
# protocolo SSL/TLS, é possível criar um “firewall HMAC" para
# ajudar no bloqueio de ataques DoS e “UDP port flooding”.
115
# Para isso deve ser gerada uma chave estática através do
# comando:
#
# openvpn --genkey --secret ta.key
#
# O servidor e cada cliente devem ter uma cópia desta chave.
# O segundo parâmetro da diretiva deve ser “0” para o servidor
# e “1” para os clientes.
#
# Se a opção tls-auth key é usada no servidor, então todos os
# clientes também deverão stilizá-la.
tls-auth ta.key 1 # Este arquivo é secreto
# OpenVPN permite escolher o cifrador criptográfico. Esta
# escolha deve reproduzir aquela feita no arquivo de
# configuração do servidor.
cipher BF-CBC
# Blowfish (default)
;cipher AES-128-CBC # AES
;cipher DES-EDE3-CBC # Triple-DES
# Esta diretiva habilita a compressão no link VPN. Se for
# habilitada no servidor, é obrigatório que também seja nos
# clientes.
comp-lzo
# A diretiva “verb” estabelece o nível apropriado de detalhe que
# será relatado nos logs.
# 0 é silêncio, exceto para erros fatais.
# 3 e 4 são níveis razoáveis para uso geral.
# 5 e 6 podem ajudar na depuração de problemas de conexão.
# 9 é o nível mais detalhado.
verb 3
# A opção abaixo estabelece que no máximo 20 mensagens seqüenciais
# da mesma categoria serão direcionadas para os logs.
mute 20
Deve-se observar um detalhe importante de sintaxe entre os arquivos de configuração do
OpenVPN para Linux e para Windows: na especificação dos caminhos de localização dos
certificados e chaves, a barra “\” deve ser grafada em duplicidade “\\” e o diretório “arquivos
de programas” deve ser escrito com “arquiv~1” (nome DOS no formato 8.3). Seguidas essas
regras, a grafia ficou:
ca c:\\arquiv~1\\openvpn\\keys\\ca.crt
cert c:\\arquiv~1\\openvpn\\keys\\Windows.crt
key c:\\arquiv~1\\openvpn\\keys\\Windows.key
Também de forma análoga à Matriz, além do arquivo de configuração principal (c:\arquivosde
programas\openvpn\config\Windows.ovpn), processado diretamente pelo OpenVPN durante
sua carga, existem ainda os arquivos por ele referenciados:
116
c:\arquivos de programas\openvpn\keys\ca.crt
c:\arquivos de programas\/openvpn\keys\Windows.crt
c:\arquivos de programas\openvpn\keys\Windows.key
c:\arquivos de programas\openvpn\keys\dh1024.pem
c:\arquivos de programas\openvpn\ipp.txt
c:\arquivos de programas\openvpn\keys\ta.key
(1)
(2)
(3)
(4)
(5)
(6)
A função de todos eles já foi detalhada anteriormente, cabendo apenas chamar a atenção para
a inexistência do arquivo Windows, necessário apenas no servidor da Matriz. O log do
OpenVPN fica integrado ao sistema de logs do Windows, inexistindo o arquivo openvpn.log.
Também aqui, além dessa estrutura de arquivos, é necessário preparar o Windows para
executar algumas tarefas adicionais, que são:
-
Tornar o firewall do Windows (ou de terceiros, se for o caso) ON para a interface
TAP. OBS: No Windows, mesmo utilizando “tun” no arquivo de configuração do
OpenVPN, a interface virtual da VPN será mostrada como TAP.
-
A escolha do modo de carga do OpenVPN é feita durante a instalação. A escolha
dependerá do uso do host. Se for necessária conexão com a Matriz em regime fulltime, deve-se escolher start automático. Senão, manual. Neste último caso, podese utilizar um ícone criado pelo instalador na bandeja do sistema (system tray).
Um clique com o botão direito do mouse exibe um menu com as opções, conforme
Figura 38.
Figura 38 – Menu de opções do OpenVPN para Windows
117
As opções “Connect” e “Disconnect” podem ser usadas a qualquer momento que se
deseje. Além delas, tem-se outras opções de gerenciamento do OpenVPN (View Log,
Edit Config, Change Password, Proxy Settings, About e Exit), todas auto-explicativas.
A disponibilidade das opções no menu depende do nível de privilégios do usuário
logado.
O log de uma conexão bem sucedida está mostrado abaixo, com as linhas que
referenciam elementos de segurança e dos protocolos de compactação do link em
negrito.
Sun Nov 19 16:04:45 2006 OpenVPN 2.0.9 Win32-MinGW [SSL] [LZO] built on Oct 1 2006
Sun Nov 19 16:04:45 2006 IMPORTANT: OpenVPN's default port number is now 1194, based on an
official port number assignment by IANA. OpenVPN 2.0-beta16 and earlier used 5000 as the default
port.
Sun Nov 19 16:04:45 2006 LZO compression initialized
Sun Nov 19 16:04:45 2006 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Sun Nov 19 16:04:46 2006 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0
AF:3/1 ]
Sun Nov 19 16:04:46 2006 Local Options hash (VER=V4): '41690919'
Sun Nov 19 16:04:46 2006 Expected Remote Options hash (VER=V4): '530fdded'
Sun Nov 19 16:04:46 2006 UDPv4 link local: [undef]
Sun Nov 19 16:04:46 2006 UDPv4 link remote: 201.78.227.1:5100
Sun Nov 19 16:04:47 2006 TLS: Initial packet from 201.78.227.1:5100, sid=674d6008 f38bf356
Sun Nov 19 16:04:52 2006 VERIFY OK: depth=1, /C=BR/ST=ES/L=Vitoria/O=labvpn
/OU=/CN=windows/[email protected]
Sun Nov 19 16:04:52 2006 VERIFY OK: depth=0, /C=BR/ST=ES/L=Vitoria/O=labvpn
/OU=/CN=matriz/[email protected]
Sun Nov 19 16:04:59 2006 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sun Nov 19 16:04:59 2006 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC
authentication
Sun Nov 19 16:04:59 2006 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sun Nov 19 16:04:59 2006 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC
authentication
Sun Nov 19 16:04:59 2006 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256SHA, 1024 bit RSA
Sun Nov 19 16:04:59 2006 [server] Peer Connection Initiated with 201.78.227.1:5100
Sun Nov 19 16:05:00 2006 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Sun Nov 19 16:05:01 2006 PUSH: Received control message: 'PUSH_REPLY,route 192.168.0.0
255.255.255.0,route 10.8.0.1,ping 10,ping-restart 120,ifconfig 10.8.0.1 10.8.0.8'
Sun Nov 19 16:05:01 2006 OPTIONS IMPORT: timers and/or timeouts modified
Sun Nov 19 16:05:01 2006 OPTIONS IMPORT: --ifconfig/up options modified
Sun Nov 19 16:05:01 2006 OPTIONS IMPORT: route options modified
Sun Nov 19 16:05:01 2006 TAP-WIN32 device [Conexão local 2] opened: \\.\Global\{26D1FB41E7C0-4038-BB3D-3AFD6C1D8FCF}.tap
Sun Nov 19 16:05:01 2006 TAP-Win32 Driver Version 8.4
Sun Nov 19 16:05:01 2006 TAP-Win32 MTU=1500
Sun Nov 19 16:05:01 2006 Notified TAP-Win32 driver to set a DHCP IP/netmask of
10.8.0.7/255.255.255.252 on interface {26D1FB41-E7C0-4038-BB3D-3AFD6C1D8FCF} [DHCP-serv:
10.20.0.2, lease-time: 31536000]
Sun Nov 19 16:05:01 2006 Successful ARP Flush on interface [65540] {26D1FB41-E7C0-4038-BB3D3AFD6C1D8FCF}
Sun Nov 19 16:05:01 2006 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down
118
Sun Nov 19 16:05:01 2006 Route: Waiting for TUN/TAP interface to come up...
Sun Nov 19 16:05:03 2006 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down
Sun Nov 19 16:05:03 2006 Route: Waiting for TUN/TAP interface to come up...
Sun Nov 19 16:05:04 2006 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down
Sun Nov 19 16:05:04 2006 Route: Waiting for TUN/TAP interface to come up...
Sun Nov 19 16:05:05 2006 TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down
Sun Nov 19 16:05:05 2006 Route: Waiting for TUN/TAP interface to come up...
Sun Nov 19 16:05:06 2006 TEST ROUTES: 2/2 succeeded len=2 ret=1 a=0 u/d=up
Sun Nov 19 16:05:06 2006 route ADD 192.168.0.0 MASK 255.255.255.0 10.8.0.8
Sun Nov 19 16:05:06 2006 Route addition via IPAPI succeeded
Sun Nov 19 16:05:06 2006 route ADD 10.8.0.1 MASK 255.255.255.255 10.8.0.8
Sun Nov 19 16:05:06 2006 Route addition via IPAPI succeeded
Sun Nov 19 16:05:06 2006 Initialization Sequence Completed
Nesse ponto fica concluído o capítulo de implementação da VPN proposta, utilizando
o OpenVPN como ferramenta principal. No capítulo seguinte será feita a conclusão
do trabalho expondo os aspectos mais relevantes de todo o estudo efetuado, bem como
apresentadas sugestões de novas pesquisas sobre features suportadas pelo OpenVPN
que não puderam ser abordadas nesta oportunidade.
119
7 CONSIDERAÇÕES FINAIS E FUTUROS TRABALHOS
As pesquisas feitas ao longo do desenvolvimento deste trabalho permitiram constatar que
VPN é uma tecnologia em franco crescimento. Dados do IDC mostram que as vendas de
soluções proprietárias de VPN baseadas em IP comercializadas pelas principais empresas da
área (Nortel, Check Point, Cisco, Lucent, Axent, Nokia, Citrix, etc) subiram de U$ 5,4 bilhões
em 2001 para U$ 14,7 bilhões em 2006, ficando as projeções para 2009 em U$ 34,6 bilhões.
Pode-se inferir daí que tais crescimentos de demanda aplicam-se também às soluções open
source. As principais razões para esta crescente procura estão relacionadas à segurança,
flexibilidade e economia no tráfego de informações que o estágio atual da tecnologia já
proporciona. (IDC, 2002)
Esta segurança, conforme ficou demonstrado neste trabalho, é obtida principalmente pela
utilização de algoritmos de criptografia e protocolos específicos, que interpõem grandes
obstáculos às tentativas de invasão. Conforme foi visto, nesse campo as VPNs, e notadamente
o OpenVPN, incorporam o estado da arte dessas tecnologias.
Entre as funções de segurança oferecidas pela tecnologia de VPN estão a garantia de
integridade e confidencialidade das informações transmitidas, bem como a autenticação e o
controle de acesso aos gateways, itens que conferem maior confiança às empresas e
organizações interessadas neste tipo de solução.
Este trabalho mostrou também que a combinação do sistema operacional Linux com o
OpenVPN e outras ferramentas open source é bastante eficaz, tornando-se, pela sua qualidade
e ampla gama de recursos,
uma solução atrativa para qualquer organização, mas
especialmente para aquelas que dispõem de recursos financeiros insuficientes para investir em
softwares de VPN proprietários. Também a característica de portabilidade do OpenVPN para
os mundos Unix/Linux, Windows e Mac torna-o uma solução muito flexível: implementações
comuns que misturam servidores Linux e Windows a estações de trabalho Windows, Linux ou
Mac estariam completamente cobertas, mesmo considerando a utilização de notebooks
remotos efetuando acessos do tipo “road warrior”16.
16
Road warrior é um termo que designa um computador com acesso à VPN a partir de local remoto onde não há
um gateway de VPN disponível. Esse computador deve ser capaz por si só de estabelecer a conexão com o
gateway da VPN que deseja acessar.
120
Ficou evidente também, em comparação com as VPNs baseadas em IPSEc, a vantagem do
OpenVPN em relação a redes que implementam NAT e IP dinâmico. Em relação à questão
do NAT, é indiferente ao OpenVPN a localização do gateway de VPN relativamente ao
firewall da rede. Nas soluções baseada em IPSec, torna-se obrigatória a utilização do modo
túnel quando o gateway de VPN situa-se atrás do firewall, o que acarreta alguns sacrifícios de
funcionalidade, como por exemplo a perda de transparência na comunicação entre dois nós
quaisquer que implementem IPSec. Em relação à utilização de links com IP variável (ADSL,
por exemplo), o OpenVPN oferece grande resiliência17 através das opções de configuração -ifconfig-pool, --push e --pull, que permitem, entre outros usos, enviar endereços para o lado
remoto (quando o endereço IP muda, seja no servidor ou no cliente, o fato é prontamente
comunicado à outra ponta, restabelecendo-se imediatamente o link).
Outros pontos importantes dizem respeito à facilidade de configuração e utilização e à
estabilidade do código executável. As VPNs baseadas em IPSec são complexas quando se
deseja um ajuste criterioso dos aspectos de segurança. Conforme Hosner, “VPNs basedas em
IPSec ou são muito caras ou muito difíceis de utilizar de forma segura. IPSec é denso e
contém uma grande quantidade de opções a serem configuradas e administradas. Por
operarem no espaço do kernel, oferecem a oportunidade de falhas catastróficas. OpenVPN
rejeita a complexidade do IPSec utilizando um protocolo exaustivamente testado, o TLS/SSL,
e bibliotecas de criptografia que provêem igual ou melhor funcionalidade, tudo isso num
único e simples pacote. OpenVPN opera no espaço do usuário, o que aumenta a segurança e a
estabilidade”.(HOSNER, 2004)
Do ponto de vista da configuração da VPN, foi visto e testado com sucesso que o OpenVPN é
capaz de exportar (push) rotas, endereços de servidores DNS e outros detalhes de
configuração para os clientes. Como conseqüência, a configuração de clientes móveis (“road
warriors”) fica extremamente facilitada, pois pode ser modificada sem necessidade de acesso
físico aos computadores remotos. Isso vale para notebooks em trânsito, por exemplo, mas
também para gateways clientes (o gateway de VPN de uma filial, por exemplo). Outro item
facilitador é que o código do servidor e dos clientes é o mesmo: a configuração é que
determina a função, conforme pôde ser constatado no capítulo 6 (vide a semelhança entre os
arquivos de configuração da matriz, das filiais e do cliente Windows).
17
Resiliência é um termo da física que expressa a propriedade que alguns materiais têm de acumular energia,
quando exigidos e estressados, e voltar ao seu estado original sem qualquer deformação.
121
De tudo o que foi visto, chega-se à conclusão que as VPNs, em conjunto com outras
ferramentas de segurança, são capazes de garantir integridade, confidencialidade, autenticação
e controle de acesso, permitindo uma comunicação tão segura quanto o estágio atual da
tecnologia possibilita. Entretanto, para usufruir de todos os benefícios hoje disponíveis, a
implementação deve ser cuidadosamente planejada, procurando-se ajustar os recursos
existentes às diversas situações possíveis do cenário prático real. Isso envolve políticas
rígidas de segurança tanto para a parte física quanto lógica da rede, aplicáveis aos diversos
elementos que a compõem: servidores, proxies, firewalls, gateways, gateways de VPN,
estações de trabalho, anti-vírus, anti-spyware, anti-spam, etc.
Além dos aspectos citados acima, a execução deste trabalho permitiu um contato mais estreito
com os conceitos e teorias relacionadas aos temas segurança de redes e VPN, vistos no curso
de pós-graduação. Foi possível visualizar com clareza a utilização dos diversos mecanismos
de segurança e as questões envolvidas em sua escolha, dada a variedade de opções oferecidas:
TCP ou UDP, tamanho de chave versus performance versus nível de segurança, DiffieHelmann ou RSA, modo túnel ou modo bridge, e assim por diante.
Pesquisas de mercado indicam um crescimento significativo das VPNs baseadas em
TLS/SSL, onde o OpenVPN se destaca como a melhor solução open source. Levantamento
da Sinergy Research feito no início de 2007, que compara o crescimento de 2006 sobre 2005,
aponta um avanço de 8% nas vendas de soluções proprietárias de fireawall/VPN e de 41% nas
vendas de soluções de VPN baseadas em TLS/SSL. (SINERGY, 2007)
A conclusão final é que o OpenVPN é uma solução importante, apresentando vantagens
significativas sobre outras soluções em diversos aspectos. A aliança de suas características
técnicas a uma relativa facilidade de implementação torna-a uma solução bastante indicada.
Espera-se que este trabalho contribua para sua maior divulgação e funcione como um guia,
inclusive de instalação, para aqueles que se interessarem em implementá-la na prática.
Tomando os dados do parágrafo anterior como referência, pode-se prever uma demanda
crescente e significativa para soluções baseadas no OpenVPN. Pode-se considerar também
que haverá boas perspectivas profissionais para quem domine bem essa tecnologia, podendo
este trabalho servir de ponto de partida para os interessados. Entretanto, dada a amplitude do
tema, muitas questões com as quais houve contato durante a realização do trabalho ficaram
122
em aberto. A sugestão é que se dê continuidade ao trabalho, complementando-o com alguns
dos seguintes tópicos, entre tantos outros possíveis:
-
Implementar na VPN detalhada neste trabalho a possibilidade de browsing SMB. O
objetivo é permitir que estações Windows ou Linux com Samba possam “enxergar” as
estações localizadas nos outros lados dos túneis VPN criados, utilizando ferramentas de
browsing tais como “ambiente de rede” ou “meus locais de rede” do Windows, por
exemplo, ou comandos de mapeamento do tipo “net use”.
-
Implementar uma VPN com OpenVPN no modo bridge, de forma a possibilitar o tráfego
de pacotes de camada 3 não-IP. Os testes podem ser feitos com Netbeui do Windows ou
IPX/SPX da Novell.
-
Implementar VPNs com OpenVPN e IPSec, estabelecendo comparações relativas a
facilidade de configuração, facilidade de utilização e desempenho. Os testes podem ser
feitos em rede local, se não houver facilidade com links ADSL.
-
Efetuar modificações na VPN detalhada neste trabalho de forma a explorar outros
protocolos de autenticação, compressão e cifragem. Deve-se lembrar que foram utilizados
Os protocolos Diffie-Hellman, Blowfish, SHA-1 e LZO, mas o OpenVPN suporta um
amplo leque de opções, incluindo túneis UDP sem cifragem.
123
REFERÊNCIAS
ALBUQUERQUE, Fernando. TCP/IP Internet: Protocolos e Tecnologias. 3. ed.. Rio de
Janeiro: Axcel Books, 2001. 362 p.
BATISTA, Thaís Vasconcelos. Segurança em Redes de Computadores. Natal, 2002. Aula 1.
Disponível em: <http://www.dimap.ufrn.br/~thais/Seguranca/home.html>. Acesso em: 22 mai
2006.
BROCARDO, Marcelo Luiz. I2AC: Um Protocolo Criptográfico para Análise Segura de
Crédito. 2001. 122 f. Dissertação de Mestrado em Ciência da Computação - Universidade
Federal de Santa Catarina, Florianópolis, 2001.
CARMO, Alexandre Pereira. Guia VPN em Linux – Apostila Gerência de Segurança de
Redes Linux. Vitória: FACULDADE SALESIANA, 2005. 48 p.
CYCLADES. Guia Internet de Conectividade. 6. ed. São Paulo: SENAC, 2000. 167 p.
D’ÁVILA, Márcio. Segurança de Redes. FUMEC, 2001. Disponível em: <http://www.
mhavila.com.br/aulas/seguranca/material/segredes01.pdf>. Acesso em: 17 set 2006.
FREES/WAN, Version 1.99. FreeS/WAN. [S.l.], 2002. Disponível em: <http://www.
freeswan.org/download.html>. Acesso em: 09 jul 2006.
HOSNER, Charlie. OpenVPN and the SSL VPN Revolution. SANS Institute, 2004.
Disponível em <http://www.sans.org/reading_room/whitepapers/vpns/1459.php>. Acesso
em 13 Jan 2007.
IDC. IP VPN Services: U.S. Market Forecast and Analysis, 2001-2006. IDC #25861,
2002. Referência disponível em: <http://www.vpnlabs.com/vpn-categories/MarketResearch/143/ index.html> sob o título IP-VPN Market Forecast. Acesso em 28 Mar 2007.
KOLENISKOV, Oleg; HATCH, Brian. Building Linux Virtual Private Networks (VPNs).
1. ed. EUA: New Riders, 2002. 385 p.
LEWIS, Chris. Cisco TCP/IP Routing Professional Reference. [S.l.]: McGraw Hill,
1997. 402 p.
MARGI, Cíntia Borges;RUGGIERO, Wilson Vicente.Tutorial sobre segurança de
redes – Networld + Interop Brasil. EPUSP, 2000. Disponível em: <http://
www.larc.usp.br/~cbmargi/pdf/Tutorial-comdex-ot.pdf>. Acesso em 14 Out 2006.
MENDES, Hammurabi Chagas.Usando OpenSSL - Uma implementação livre do
protocolo SSL. Universidade de Brasília, 2003. Disponível em: <http://www.cic.unb.br/
docentes/pedro/trabs/hammurabi.htm>. Acesso em: 25 Jul 2006.
MONTEIRO, Edmundo. Segurança em Redes. Coimbra, Portugal, 1999. Capítulo 1.
Disponível em: <http://eden.dei.uc.pt/~sr/Teoricas/>. Acesso em: 08 abr 2006.
124
NAKAMURA, Emilio Tissato; GEUS, Paulo Licio de. Segurança de Redes em Ambientes
Cooperativos. 3. ed. São Paulo: Editora Futura, 2002.
OPENSSL, Página Oficial do projeto. Disponível em : <http://www.openssl.org>. Acesso
em: 25 Jul 2006.
OPENVPN, Página Oficial do projeto. Disponível em : <http://www.openssl.org>.
Acesso em: 10 Jun 2006.
RENDON, Jim. VPN market makes room for IPsec and SSL. 2004. Disponível em:
<http://searchnetworking.techtarget.com/originalContent/0,289142,sid7_gci996711,00.html
>. Acesso em 24 mar 2007.
SARLO, Lino, da Silva. Virtual Private Network. Aprenda a construir redes privadas
virtuais em plataformas Linux e Windows. Rio de Janeiro: Editora Novatec, 2003.
SCHNEIER, Bruce. Applied Cryptography. New York, NY: John Wiley & Sons, 1996.
SCRIMGER, Rob et al. TCP/IP: A Bíblia. 1. ed. Rio de Janeiro: Campus, 2002. 642 p.
SETTING up a VPN Gateway. [S.l.], 2002. Disponível em: <http://www.Linuxjournal.
com/ article.php?sid=4772>. Acesso em: 09 jun 2006.
SINERGY. Decision Report: Soluções de segurança de rede movimentam US$ 5 bi. ed.
23/02/2007, 2007, Disponível em: <http://www.decisionreport.com.br/publique/cgi/
cgilua.exe/sys/start.htm?infoid=910&sid=23>. Acesso em: 28 mar 2007.
SOARES, L. F. G.; LEMOS, G.; COLCHER, S. Redes de computadores: das LANs,
MANs e WANs às Redes ATM. 2. ed. rev. aum. Rio de Janeiro: Campus, 1995. 705 p.
TANENBAUM, Andrew S. Redes de Computadores. 3. ed. Rio de Janeiro: Campus,
1997. 923 p.
125
ANEXO I
O ALGORITMO DIFFIE-HELLMAN
É um algoritmo é bastante interessante por permitir o estabelecimento de uma chave secreta
(criptografia simétrica) num processo de comunicação segura entre dois hosts, sem utilizar
nenhum algoritmo de chave pública para alcançar esse objetivo, a exemplo do que o RSA faz.
O texto abaixo foi transcrito do site da RSA, cujo acesso pode ser feito pela URL
<http://www.rsasecurity .com/rsalabs/node.asp?id=2248>.
[…] What is Diffie-Hellman?
The Diffie-Hellman key agreement protocol (also called exponential key agreement) was
developed by Diffie and Hellman [DH76] in 1976 and published in the ground-breaking
paper "New Directions in Cryptography." The protocol allows two users to exchange a secret
key over an insecure medium without any prior secrets.
The protocol has two system parameters p and g. They are both public and may be used by
all the users in a system. Parameter p is a prime number and parameter g (usually called a
generator) is an integer less than p, with the following property: for every number n between
1 and p-1 inclusive, there is a power k of g such that n = gk mod p.
Suppose Alice and Bob want to agree on a shared secret key using the Diffie-Hellman key
agreement protocol. They proceed as follows: First, Alice generates a random private value a
and Bob generates a random private value b. Both a and b are drawn from the set of integers
. Then they derive their public values using parameters p and g and their private values.
Alice's public value is ga mod p and Bob's public value is gb mod p. They then exchange
their public values. Finally, Alice computes gab = (gb)a mod p, and Bob computes gba = (ga)b
mod p. Since gab = gba = k, Alice and Bob now have a shared secret key k.
The protocol depends on the discrete logarithm problem for its security. It assumes that it is
computationally infeasible to calculate the shared secret key k = gab mod p given the two
public values ga mod p and gb mod p when the prime p is sufficiently large. Maurer [Mau94]
126
has shown that breaking the Diffie-Hellman protocol is equivalent to computing discrete
logarithms under certain assumptions.
The Diffie-Hellman key exchange is vulnerable to a man-in-the-middle attack. In this attack,
an opponent Carol intercepts Alice's public value and sends her own public value to Bob.
When Bob transmits his public value, Carol substitutes it with her own and sends it to Alice.
Carol and Alice thus agree on one shared key and Carol and Bob agree on another shared
key. After this exchange, Carol simply decrypts any messages sent out by Alice or Bob, and
then reads and possibly modifies them before re-encrypting with the appropriate key and
transmitting them to the other party. This vulnerability is present because Diffie-Hellman
key exchange does not authenticate the participants. Possible solutions include the use of
digital signatures and other protocol variants.
The authenticated Diffie-Hellman key agreement protocol, or Station-to-Station (STS)
protocol, was developed by Diffie, van Oorschot, and Wiener in 1992 [DVW92] to defeat
the man-in-the-middle attack on the Diffie-Hellman key agreement protocol. The immunity
is achieved by allowing the two parties to authenticate themselves to each other by the use of
digital signatures (see Question 2.2.2) and public-key certificates (see Question 4.1.3.10).
Roughly speaking, the basic idea is as follows. Prior to execution of the protocol, the two
parties Alice and Bob each obtain a public/private key pair and a certificate for the public
key. During the protocol, Alice computes a signature on certain messages, covering the
public value ga mod p. Bob proceeds in a similar way. Even though Carol is still able to
intercept messages between Alice and Bob, she cannot forge signatures without Alice's
private key and Bob's private key. Hence, the enhanced protocol defeats the man-in-themiddle attack.
In recent years, the original Diffie-Hellman protocol has been understood to be an example
of a much more general cryptographic technique, the common element being the derivation
of a shared secret value (that is, key) from one party's public key and another party's private
key. The parties' key pairs may be generated anew at each run of the protocol, as in the
original Diffie-Hellman protocol. The public keys may be certified, so that the parties can be
authenticated and there may be a combination of these attributes. The draft ANSI X9.42 (see
Question 5.3.1) illustrates some of these combinations, and a recent paper by Blake-Wilson,
Johnson, and Menezes provides some relevant security proofs.
127
APÊNDICE A
COMPARATIVOS ENTRE OPENVPN E VPNS IPSEC
Na Internet existem diversos artigos que ressaltam aspectos diversos das duas tecnologias,
fornecendo visões interessantes sobre determinados pontos de vista, alguns de caráter
meramente prático, outros mais teóricos ou voltados para situações específicas. Os links de
acesso são:
SSL VPNs and OpenVPN: A lot of lies and a shred of truth
September 2005
Charlie Hosner
Acesso pela URL <http://software.newsforge.com/software/05/09/22/164231.shtml?tid=78>
OpenVPN and the SSL VPN Revolution
August 2004
Charlie Hosner
Acesso pela URL <http://www.sans.org/reading_room/whitepapers/vpns/1459.php>
SSL Remote Access VPNs: Is this the end of IPSec?
October 2003
Steven Ferrigni
Acesso pela URL < http://www.sans.org/reading_room/whitepapers/vpns/1285.php>
Linux's answer to MS-PPTP
September 2003
Peter Gutmann
Acesso pela URL <http://www.cs.auckland.ac.nz/~pgut001/pubs/Linux_vpn.txt>
SSL VPNs dissected
December 2005
Joel Snyder
Acesso pela URL <http://www.networkworld.com/reviews/2005/121905-ssl-test-intro.html?review=sslvpn>
Meet OpenVPN
December 2004
Hans-Cees Speel
Acesso pela URL <http://www.Linuxjournal.com/article/7949>
128
APÊNDICE B
CARACTERÍSTICAS DO OPENVPN
Introdução
O OpenVPN é uma solução completa de VPN baseada no protocolo SSL que suporta uma
grande variedade de configurações, incluindo acesso remoto, acessos LAN-to-LAN,
Segurança Wi-Fi e soluções de acesso remoto em escala enterprise, com balanceamento de
carga, failover e controle de acesso granular.
O OpenVPN implementa extensões de segurança de rede nas camadas OSI 2 ou 3 usando o
protocolo padrão da indústria TLS/SSL, que apresenta flexibilidade nos métodos de
autenticação de clientes (suporta certificados digitais, smart cards, etc) e permite políticas de
controle de acesso por usuários ou grupos usando regras de firewall aplicadas à interface
virtual VPN (TUN/TAP).
O OpenVPN não é um proxy web e não opera através de um browser web.
OpenVPN é um projeto open source e é licenciado sob a forma GPL. Também pode ser
licenciado comercialmente para empresas que desejem redistribuí-lo como parte de sua
aplicação proprietária.
Portabilidade
OpenVPN roda nos seguintes sistemas operacionais: Linux, Windows 2000/XP e versões
posteriores, OpenBSD, FreeBSD, NetBSD, Mac OS X
e Solaris. As famílias de
processadores suportados incluem: Intel x86, Alpha, Sparc, AMD64 e ARM.
Recursos
Com OpenVPN é possível:
-
Efetuar tunneling de qualquer sub-rede IP ou adaptador virtual ethernet através de uma
única porta UDP ou TCP.
129
-
Configurar servidores VPN com escalabilidade e balanceamento de carga, usando uma ou
mais máquinas, que serão capazes de manusear milhares de conexões dinâmicas
provenientes de clientes VPN.
-
Utilizar todos os recursos de encriptação, autenticação e certificação da biblioteca
OpenSSL para proteger os dados das redes privadas quando em trânsito pela Internet.
-
Utilizar qualquer algoritmo de cifragem (cipher), tamanho de chave ou digestor HMAC
(para checagem de integridade) suportados pela biblioteca OpenSSL.
-
Escolher entre utilizar encriptação convencional baseada em chave estática ou encriptação
de chave pública baseada em certificados digitais.
-
Usar chaves estáticas pré-compartilhadas ou distribuição dinâmica de chaves através do
protocolo TLS/SSL.
-
Utilizar compressão de link em tempo real e de forma adaptativa e gerenciar a utilização
da largura de banda disponível.
-
Fazer tunneling de redes cujos pontos de conexão com a Internet utilizem IPs dinâmicos
tais como clientes DHCP ou dial-in.
-
Fazer tunneling de redes através de firewalls stateful orientados a conexão sem
necessidade de utilizar regras de firewall explícitas.
-
Fazer tunneling de redes sobre NAT.
-
Criar bridges ethernet seguras usando “virtual tap devices”. Isso permitirá o tráfego pelo
túnel de outros protocolos de camada 3 tais como sobre IPX, Appletalk, Netbeui, etc.
-
Controlar e gerenciar o OpenVPN usando uma interface gráfica em ambiente Windows ou
Mac OS X.
Diferenciais em relação a outros softwares de VPN
Os principais pontos fortes do OpenVPN incluem portabilidade para diversas plataformas
conhecidas do universo computacional (PC, Mac, Sun, etc), grande estabilidade,
escalabilidade para centenas ou milhares de clientes, instalação relativamente fácil e suporte
para IP dinâmico e NAT.
130
-
O OpenVPN fornece um framework para VPN projetado para permitir customizações
diversas, tais como capacidade para distribuir pacotes de instalação pré-configurados para
clientes ou suporte a métodos alternativos de autenticação através de plugins (por
exemplo, o módulo “openvpn-auth-pam” permite que o OpenVPN autentique clientes
usando qualquer método de autenticação PAM), que podem ser usados exclusivamente ou
combinados com certificados X509.
-
O OpenVPN oferece uma interface de gerenciamento que pode ser utilizada para controlar
remotamente ou gerenciar de forma centralizada o daemon OpenVPN. A interface de
gerenciamento pode também ser utilizada para desenvolver um front end gráfico ou web
para o OpenVPN.
-
No ambiente Windows, o OpenVPN pode ler certificados ou chaves privadas a partir de
smart cards que suportem a API Crypto do Windows.
-
O OpenVPN utiliza um modelo de segurança que protege as redes contra ataques passivos
e ativos. Esse modelo é baseado do uso de SSL/TLS para autenticação de sessão.
OpenVPN suporta X509 PKI (public key infrastructure) para autenticação de sessão, o
protocolo TLS para distribuição de chaves, uma interface cipher-independent para
encriptação dos dados enviados pelo túnel e o algoritmo HMAC SHA-1 para autenticação
dos dados enviados pelo túnel.
-
O OpenVPN foi construído para ser portável. Atualmente, OpenVPN roda em Linux,
Solaris, OpenBSD, FreeBSD, NetBSD, Mac OS X e Windows 2000/XP. Em função do
OpenVPN ser escrito como um daemon que roda no espaço do usuário (user-space
daemon) e não como um módulo do kernel ou uma complexa modificação da camada IP,
os esforços requeridos para portá-lo ficam dramaticamente menores.
-
O OpenVPN é fácil de usar. Em geral, um túnel pode ser criado e configurado com um
simples comando (e sem nenhum arquivo de configuração ser necessário). A
documentação do OpenVPN contém exemplos ilustrativos de sua utilização.
-
O OpenVPN é projetado e testado com rigor para operar de forma robusta em redes não
confiáveis. O principal objetivo do design do OpenVPN é que ele deve ser o responsável,
tanto na operação normal quanto em situações de recuperação de erros, pela continuidade
e restabelecimento do túnel. Isso significa que, se a camada IP cai por 5 minutos, quando
ela voltar, o tráfego no túnel será imediatamente retomado, sem intervenção humana.
131
-
O OpenVPN tem um projeto fortemente modular. Toda a criptografia é manuseada pela
biblioteca OpenSSL e todas as funcionalidades de IP tunneling são providas pelo driver de
rede virtual TUN/TAP. Os benefícios dessa modularidade podem ser vistos, por exemplo,
na forma como o OpenVPN pode ser dinamicamente linkado com novas versões da
biblioteca SSL e imediatamente ter acesso a qualquer nova funcionalidade trazida pelo
novo release. Por exemplo, quando o OpenVPN foi construído com a versão 0.9.7 da
biblioteca OpenSSL, ele automaticamente ganhou acesso a novos encriptadores (ciphers)
tais como AES-256 (Advanced Encryption Standard com chave de 256 bits). De forma
semelhante, o design para rodar no espaço do usuário permite portabilidade direta para
qualquer sistema operacional para o qual exista o driver de rede virtual TUN/TAP.
-
O OpenVPN é rápido. Rodando em Red Hat 7.2 num PC Pentium II 266 MHz, usando
autenticação de sessão baseada em TLS, o cifrador Blowfish, autenticação de dados no
tunnel SHA-1 e fazendo tunneling de uma sessão FTP com arquivos grandes e précomprimidos, OpenVPN alcançou uma taxa de envio/recebimento de 1,455 megabytes por
segundo de tempo de CPU.
-
Ainda que o OpenVPN possua um vasto número de opções para controlar os parâmetros
de segurança do túnel VPN, ele provê também opções para proteger a segurança do
servidor propriamente dito, o que inclui --chroot para restringir a parte do filesystem que
o daemon OpenVPN tem acesso, --user e --group para diminuir os privilégios do daemon
após a inicialização e --mlock para garantir que seqüências relativas às chaves e aos dados
que trafegam no túnel nunca sejam paginados para o disco rígido, de onde poderiam ser
recuperados posteriormente.
Uso do protocolo TLS para autenticação e negociação de chaves
O TLS é a última evolução da família de protocolos SSL e foi desenvolvida originalmente
pela Netscape para o seu primeiro web browser seguro. O TLS e seus predecessores SSL
têm se espalhado pela web ao longo dos anos e têm sido extensivamente analisados à procura
de falhas. Isso tem permitido sua evolução e fortalecimento, de forma que nos dias de hoje
TLS/SSL é considerado um dos mais robustos e maduros protocolos disponíveis.
132
Compatibilidade com IPSec ou PPTP
Existem três famílias de implementações de VPN IP usadas extensivamente nos dias de hoje:
SSL, IPSec e PPTP. OpenVPN é uma VPN SSL e como tal não é compatível com IPSec e
PPTP.
O protocolo IPSec foi projetado para ser implementado como uma modificação da pilha IP no
espaço do kernel, e, dessa forma, cada sistema operacional requer sua própria implementação
do IPSec.
Em contraste, a implementação do OpenVPN no espaço do usuário permite portabilidade
entre sistemas operacionais e arquiteturas de processador.
Existem vantagens e desvantagens nas duas abordagens. A principal vantagem da abordagem
do OpenVPN é a portabilidade, facilidade de configuração e compatibilidade com NAT e
endereçamento dinâmico. A curva de aprendizado para instalar e usar o OpenVPN é parecida
com a de outros daemons relacionados a segurança, tais como SSH.
Historicamente, uma das vantagens do IPSec tem sido o suporte multi-vendor, o que começa
ocorrer também com o OpenVPN, com o surgimento de dispositivos de hardware dedicados
que o utilizam internamente.
A vantagem do protocolo PPTP é ter um cliente pré-instalado na plataforma Windows.
Entretanto, análises feitas por especialistas em criptografia têm revelado muitas
vulnerabilidades, o que não recomenda sua utilização em situações onde a segurança seja um
fator crítico.
Padrões seguidos pelo OpenVPN
Como um daemon que roda no espaço do usuário, OpenVPN é compatível com TLS/SSL,
certificados RSA e X509, PKI, NAT, DHCP e TUN/TAP virtual devices.
OpenVPN não é compatível com IPSec,
IKE (Internet Key Exchange, que negocia
associações de segurança entre duas entidades e realiza a troca de chaves), PPTP e L2TP.
133
Uso de web browser como cliente OpenVPN
Não é possível. Ainda que o OpenVPN use o protocolo TLS/SSL para segurança, ele não é
uma aplicação web proxy. Ele é uma solução de tunneling de camada 2 ou 3 e requer que o
OpenVPN esteja instalado nos lados servidor e cliente.
Construção do OpenVPN
OpenVPN pode ser facilmente construído a partir dos fontes para as variantes Linux e BSD.
Construir OpenVPN para Windows é mais complexo, entretanto um instalador pré-construído
está disponível no site de download do OpenVPN.
OpenVPN pode ser construído:
-
Com as bibliotecas OpenSSL Crypto e SSL
(versão 0.9.6 ou superior requerida),
oferecendo autenticação baseada em certificados, encriptação de chave pública e
distribuição dinâmica de chaves baseada em TLS.
-
Só com a biblioteca OpenSSL Crypto, oferecendo encriptação e autenticação
convencional baseadas em chaves estáticas.
-
Sozinho, com suporte a túneis UDP não criptografados.
OpenVPN pode também ser “linkado” com a biblioteca de compressão em tempo real LZO.
Suporta também compressão adaptativa (adaptive compression), significando que irá habilitar
a compressão somente quando os dados que trafegam no túnel forem comprimíveis.
OpenVPN roda inteiramente no espaço do usuário e não requer nenhum componente especial
do kernel além do driver de rede virtual TUN/TAP, disponíveis para Linux, Windows e
variantes do BSD.