Servidor de rede com OpenVPN e Shorewall

Giovanni Schmitt Salvador
SERVIDOR DE BORDA DE CÓDIGO LIVRE PARA CONEXÃO
REMOTA E SEGURANÇA DE REDE
Trabalho submetido ao Programa de
Graduação da Universidade Federal de
Santa Catarina para a obtenção do Grau
de Bacharelado em Ciências da Computação.
Orientador: Prof. Dr. Carlos Becker Westphall
Florianópolis – SC
2013

Ficha de identificação da obra elaborada pelo autor, através do
Programa de Geração Automática da Biblioteca Universitária da UFSC.
Salvador, Giovanni Schmitt
Servidor de Borda de Código Livre para Conexão
Remota e Segurança de Rede / Giovanni Schmitt Salvador ;
orientador, Carlos Becker Westphall -
Florianópolis, SC, 2013.
99 p.
Trabalho de Conclusão de Curso (graduação) -
Universidade Federal de Santa Catarina, Centro
Tecnológico.
Graduação em Ciências da Computação.
Inclui referências
1. Ciências da Computação. 2. Servidor Roteador Linux.
3. Servidor DHCP. 4. Servidor VPN. 5. Servidor Firewall.
I. Westphall, Carlos Becker. II. Universidade Federal de
Santa Catarina. Graduação em Ciências da Computação. III.
Título.

Giovanni Schmitt Salvador
SERVIDOR DE BORDA DE CÓDIGO LIVRE PARA CONEXÃO
REMOTA E SEGURANÇA DE REDE
Este Trabalho foi julgado adequado para obtenção do Título de
Bacharel em Ciências da Computação, e aprovado em sua forma final pelo
Programa de Graduação da Universidade Federal de Santa Catarina.
Florianópolis, 11 de Dezembro de 2013
_________________________________
Prof. Vitório Bruno Mazzola
Coordenador do Curso
Banca Examinadora:
_______________________________
Prof. Dr. Carlos Becker Westphall
_______________________________
Prof.ª Dr.ª Carla Merkle Westphall
_______________________________
Me. Rafael de Souza Mendes

Este trabalho é dedicado a todos os colegas, professores e
profissionais do Departamento de Informática e Estatística, que no
decorrer do período de graduação, me instruíram, orientaram e auxiliaram
no meu crescimento pessoal e acadêmico.
Dedico este trabalho principalmente aos meus pais, sem o apoio
deles, a elaboração deste trabalho não seria possível.

AGRADECIMENTOS
Agradeço primeiramente a Deus, por iluminar meu caminho e
permitir que eu obtenha o grau de bacharel neste prestigiado curso,
fornecido por esta instituição acadêmica de excelência.
Agradeço também ao meu orientador, que ao longo do curso, foi o
principal responsável por me manter motivado na área em que este trabalho
foi realizado, onde pretendo seguir carreira me aperfeiçoando
constantemente.
Agradeço a minha companheira pela enorme paciência.
Agradeço principalmente a meus pais, que estiveram ao meu lado e
me apoiaram em todas as decisões, acadêmicas ou não, que tomei até o
presente momento.

RESUMO
Neste trabalho foi pesquisado e apresentado a parte teórica dos
firewalls e redes virtuais remotas (VPNs). Foi feita uma análise de
desempenho de rede das tecnologias VPNs estudadas. E por fim, foi
implantado em um computador o Sistema Operacional Ubuntu, o serviço de
DHCP com encaminhamento de pacotes (para o servidor funcionar como
um roteador), o serviço de VPN OpenVPN e o serviço de firewall
Shorewall.
Palavras-chave: Servidor roteador. Servidor DHCP. Servidor
VPN. Servidor Firewall. Tecnologia VPN. Tecnologia Firewall. Sistema
Operacional Linux. Sistema Operacional Ubuntu. Openvpn. Webmin.
Shorewall. XFCE v4. Servidor periférico de rede. Servidor de segurança de
rede. Rede de computadores.

ABSTRACT
This work was researched and is presented, the theoretical context
of network firewalls and virtual private networks (VPNs). An analysis of
network performance over VPNs technologies is presented. And finally, a
computer network server was implemented using Ubuntu Operating
System, DHCP service with packet forwarding (for the server to work as a
router), the VPN service OpenVPN and Shorewall firewall service.
Keywords: Server router. DHCP server. VPN server. Firewall
Server. VPN technology. Firewall technology. Linux Operating System.
Ubuntu Operating System. Openvpn. Webmin. Shorewall. XFCE v4. Edge
network server. Security network Server. Computer network.

LISTA DE FIGURAS
FIGURA 1 - EXEMPLO DE REDE DISTRIBUÍDA IDEAL. .......................................................11
FIGURA 2 - ARQUITETURA BÁSICA DA TECNOLOGIA DE FIREWALL ....................................13
FIGURA 3 - AGRUPAMENTO DE VPN POR PROTOCOLO DE SEGURANÇA.............................42
FIGURA 4 - ARQUITETURA DA REDE LOCAL .................................................................57
FIGURA 5 - CONEXÃO DA ÁREA DE TRABALHO REMOTA WINDOWS .................................60
FIGURA 6 - LOGIN DO XRDP....................................................................................60
FIGURA 7 - LOG DE CONEXÃO XRDP.........................................................................61
FIGURA 8 - ACESSO REMOTO COM INTERFACE GRÁFICA AO SERVIDOR. ............................61
FIGURA 9 - ACESSO AO WEBADMIN ..........................................................................63
FIGURA 10 - PRIMEIROS PASSOS WEBADMIN..............................................................64
FIGURA 11 - APLICANDO CONFIGURAÇÕES WEBADMIN. ...............................................65
FIGURA 12 - MELHRAR EXPERIÊNCIA DE USUÁRIO NO WEBADMIN..................................66
FIGURA 13 - INTERFACE MELHORADA EM PORTUGUÊS DO WEBADMIN.............................66
FIGURA 14 - ARQUITETURA 1 DE TOPOLOGIA DE REDE VIRTUAL PRIVADA.........................71
FIGURA 15 - ARQUITETURA 2 DE TOPOLOGIA DE REDE VIRTUAL PRIVADA - ROADWARRIOR. 73
FIGURA 16 - RESUMO DO SERVIDOR IMPLEMENTADO...................................................86

LISTA DE TABELAS
TABELA 1 - DADOS DE TECNOLOGIAS FIREWALL...........................................................25
TABELA 2 – RESUMO DOS PROTOCOLOS DE TUNELAMENTO DE VPN...............................34
TABELA 3 - TECNOLOGIAS VPN................................................................................43
TABELA 4 - DESEMPENHO DE SOBRECARGA NORMALIZADA [23]. ...................................45
TABELA 5 - DESEMPENHO DE UTILIZAÇÃO DE LARGURA DE BANDA [23]...........................46
TABELA 6 - DESEMPENHO, INSTABILIDADE NORMALIZADA [23]......................................47
TABELA 7 - DESEMPENHO, LATÊNCIA NORMALIZADA [23].............................................47
TABELA 8 - COMPLEXIDADE DE INSERIR ALGORITMOS PROPRIETÁRIOS DE CRIPTOGRAFIA. .....51
TABELA 9 - SUPORTE DE ROTEAMENTO EMBUTIDO. ......................................................51
TABELA 10 - SEGURANÇA DAS VPNS.........................................................................52

SUMÁRIO
1 INTRODUÇÃO: ........................................................................... 9
1.1 MOTIVAÇÃO..............................................................................9
2 FIREWALL ................................................................................ 11
2.1 INTRODUÇÃO:..........................................................................11
2.2 FUNDAMENTOS DA TECNOLOGIA DE FIREWALL...............................12
2.3 FILTRAGEM DE PACOTES ............................................................12
2.3.1 Vantagens e Desvantagens............................................14
2.3.2 Onde estão os firewalls de filtro de pacotes ..................15
2.4 FIREWALL DE INSPEÇÃO DE PACOTES DINÂMICO.............................16
2.4.1 Pacotes TCP....................................................................17
2.4.2 Pacotes UDP...................................................................18
2.4.4 Onde estão os firewalls de inspeção dinâmica?.............20
2.5 APLICAÇÕES PROXY FIREWALLS ...................................................20
2.5.2 Onde estão as aplicações proxy firewall ........................22
2.6 SOFTWARES FIREWALL DE CÓDIGO ABERTO:..................................22
Coyote Linux ...............................................................................22
Firestarter...................................................................................22
IPCop ..........................................................................................23
IPFilter ........................................................................................23
IPFire...........................................................................................23
Netfilter ......................................................................................23
m0n0wall....................................................................................23
pfSense .......................................................................................23
Shorewall....................................................................................23
Smoothwall.................................................................................24
Untangle.....................................................................................24
Vyatta.........................................................................................24
UFW............................................................................................24
2.7 CONCLUSÃO ............................................................................24
3 VPN ......................................................................................... 27
3.1 INTRODUÇÃO:..........................................................................27
3.2 TÚNEIS ...................................................................................28

3.2.1 Protocolos de Túneis ......................................................29
MPLS .................................................................................................29
Ipsec ..................................................................................................30
L2TP...................................................................................................31
IP-in-IP...............................................................................................31
GRE....................................................................................................31
PPTP ..................................................................................................31
SSTP...................................................................................................32
3.2.2 Resumo dos Protocolos de Tunelamento.......................33
3.3 ESTUDO DE DESEMPENHO ..........................................................34
3.4 A ARQUITETURA DE SOFTWARE DE UM ROTEADOR SVBLCA..............35
3.5 CARACTERÍSTICAS VPN..............................................................36
3.5.1 Desempenho da Rede ....................................................36
Overhead...........................................................................................37
Utilização de banda...........................................................................37
Latência / Instabilidade.....................................................................38
3.5.2 Características suportadas e funcionalidades................38
Código de modularidade...................................................................38
Roteamento ......................................................................................39
3.5.3 Preocupações operacionais............................................39
Segurança..........................................................................................39
Escalabilidade....................................................................................40
3.6 O BANCO DE ENSAIO EXPERIMENTAL ...........................................41
3.7 RESULTADOS DA AVALIAÇÃO DE DESEMPENHO...............................44
3.7.1 O desempenho da rede ..................................................45
3.7.2 Características/funcionalidades suportadas..................48
A modularidade do código................................................................48
Roteamento ......................................................................................49
3.7.3 Preocupações Operacionais...........................................49
Segurança..........................................................................................49
Escalabilidade....................................................................................50
3.8 FUNCIONAMENTO VPNS USANDO PROTOCOLO UDP. .....................52
3.8.1 SSL/TLS sobre UDP no OpenVPN....................................53
Canal de Controle..............................................................................53
Canal de Dados..................................................................................54
3.9 CONCLUSÕES SOBRE VPNS E TRABALHOS FUTUROS ........................54
4 DESENVOLVIMENTO:............................................................... 56
4.1 SISTEMA OPERACIONAL .............................................................56
4.2 CONFIGURANDO AS INTERFACES DE REDE E SERVIÇO DHCP...............56
4.3 CONFIGURANDO O SERVIDOR COMO ROTEADOR DHCP/GATEWAY DE
DUAS INTERFACES 57

4.4 INSTALANDO INTERFACE GRÁFICA NO SERVIDOR..............................59
4.5 INSTALANDO O WEBADMIN........................................................62
4.5.1 Pré-configurando o serviço de Firewall..........................63
4.6 INSTALANDO SERVIÇO DE VPN OPENVPN.....................................67
4.7 INSTALANDO E CONFIGURANDO O SERVIÇO DE FIREWALL SHOREWALL.70
4.8 DNS DINÂMICO.......................................................................81
4.8.1 Introdução......................................................................81
4.8.2 Registrar IP com um provedor de DNS dinâmico ...........81
4.8.3 Utilitário de software para realizar atualizações de DNS
dinâmico 82
No-IP .................................................................................................82
5 CONCLUSÃO: ........................................................................... 86
5.1 TRABALHOS FUTUROS................................................................87
6 REFERÊNCIAS BIBLIOGRÁFICAS:............................................... 89

1 Introdução:
Firewall (em português, “muro anti-chamas”) é um dispositivo de
rede de computadores, que tem por objetivo aplicar uma política de
segurança a um determinado ponto da rede. A complexidade de instalação
depende do tamanho da rede, da política de segurança, da quantidade de
regras que controlam o fluxo de entrada e saída de informações e do grau de
segurança desejado. O firewall pode ser usado para bloquear acessos
remotos a portas abertas dentro da rede local, serve também para delimitar
regras de uso e acesso à rede, podendo ser entre elas, regras de acesso a
sites, e-mails, spams, entre outros.
VPN (Virtual Private Network) significa Rede Privada Virtual. É
uma rede de comunicações privada normalmente utilizada por uma empresa
ou um conjunto de empresas/instituições, construída em cima de uma rede
de comunicações pública (como por exemplo, a Internet). O tráfego de
dados é levado pela rede pública, utilizando protocolos padrão, não
necessariamente seguros.
VPNs seguras usam protocolos de criptografia por tunelamento que
fornecem a confidencialidade, autenticação e integridade necessárias para
garantir a privacidade das comunicações requeridas. Quando
adequadamente implementados, estes protocolos podem assegurar
comunicações seguras através de redes inseguras.
Deve ser notado que a escolha, implementação e uso destes
protocolos não são triviais, e várias soluções de VPN inseguras são
atualmente distribuídas no mercado.
Com o acesso remoto à “rede administrativa principal” (onde
geralmente encontram-se os servidores de dados e aplicativos) aumentam-
se os pacotes recebidos e enviados pela rede.
1.1 Motivação
Existem empresas e laboratórios que compartilham entre diversas
redes de computadores distribuídas geograficamente, recursos necessários
para a elaboração de suas funções, pesquisas e serviços.
Percebe-se também, que as empresas e laboratórios necessitam
utilizar diversos recursos de software para acessar programas remotos,
distribuídos entre as redes de computadores da organização - programas
como de gerenciamento da empresa (financeiro, recursos humanos, compra
e venda de materiais e serviços, emissão de nota fiscal, etc.), banco de
dados, acesso a área de trabalho remota, cópias de segurança de arquivos,
entre outros.

Para utilizar estes serviços/recursos espalhados geograficamente,
muitas vezes utilizam-se diversos softwares diferentes, que necessitam de
roteamento de portas entre os nodos da rede, a abertura de variadas portas
na rede de computadores, permissões especiais nos firewalls dos sistemas
operacionais dos usuários (se não houver um firewall de rede de borda),
entre outras coisas que podem ocasionar o comprometimento da segurança
da rede de computadores, implicando no comprometimento dos dados e
serviços oferecidos.
Para resolver este problema, pode ser feito o acesso remoto a rede,
via VPN, para acessar os serviços disponíveis nas diversas redes
distribuídas geograficamente, como se todas estivessem conectadas
diretamente, ou melhor, como se todas estivessem no mesmo escritório.
Assim não seria necessário abrir diversas portas para a rede pública/externa.
E com a segurança criptográfica dos túneis VPN, ainda obter-se-á toda a
segurança necessária para os dados trafegarem de uma rede para outra com
confidencialidade, autenticidade e integridade.
Para reforçar a segurança da rede, seria ideal ter um firewall de
rede nas bordas das redes de computadores, aumentando a segurança geral
dos sistemas de TI das empresas e laboratórios, impedindo determinados
tipos de ataque, e deixando os administradores de rede com menos
sobrecarga de trabalho.
Portanto não existe um documento sucinto com os tipos de
softwares disponíveis no mercado quanto a programas de VPN e Firewall.
Analisar suas características, qualidades e defeitos para implementar a
melhor solução de servidor VPN para acesso remoto, com serviço de
firewall pode ser uma tarefa árdua e demorada.
O objetivo do desenvolvimento deste trabalho é a implementação
de um servidor VPN-Firewall para proteger uma rede local qualquer e
conectá-la a outra rede local, separadas geograficamente por uma rede
pública, seja esta rede de instituições de ensino, empresas privadas ou até
mesmo, domésticas.
Ainda, este trabalho foi desenvolvido para ter o custo mais baixo
possível, sendo as duas tecnologias implementadas no mesmo servidor, e
contando que todas as tecnologias são de códigos abertos e por isso,
gratuitas. Portanto, o único gasto que as empresas e laboratórios teriam, é o
da aquisição do servidor em si, que não necessitar ter hardware de
desempenho alto, inclusive, nota-se que pode ser utilizado qualquer
computador mesmo que considerado desatualizado tecnologicamente.

Figura 1 - Exemplo de rede distribuída ideal.
2 Firewall
2.1 Introdução:
Firewall é uma ferramenta importante para o perímetro de
segurança da rede de computadores, porque é usada para prevenir que
qualquer usuário ou objeto, de dentro ou fora da rede, façam qualquer tipo
de rotina maliciosa dentro dela. Também pode se referir a qualquer método
ou tecnologia cujo propósito seja o controle do tráfego de entrada e saída de
pacotes na rede para propósitos de segurança [1]. Muitos tipos diferentes
de controle de tráfego de pacotes têm sido utilizados. Podendo ser utilizado
tanto hardware e software como forma de controle de tráfego de rede [2].
Neste capítulo discutiremos no geral os fundamentos das tecnologias (ou
aplicações), que possuem diferentes tipos de configurações, incluindo suas
vantagens e desvantagens.

2.2 Fundamentos da Tecnologia de Firewall
Os estudos mostram que existem três tipos principais de
tecnologias que involvem desenvolvimento de sistemas de firewall. As três
tecnologias são; (1) filtragem de pacotes, (2) inspeção dinâmica de pacotes,
e (3) aplicações proxy. São estes três métodos, ou processos básicos,
atualmente envolvidos em sistemas de firewall. Cada uma das tecnologias
tem suas vantagens e desvantagens. Algumas são mais aconselháveis em
certas situações e ambientes.
2.3 Filtragem de Pacotes
Esta é a primeira geração da tecnologia de firewall. Faz apenas a
função básica do sistema de firewall onde se verifica pacote por pacote no
tráfego da rede. Esta tecnologia checa cada pacote que passa pela rede e
decide se deixa o pacote passar ou se o descarta/bloqueia [3]. Tudo isso
acontece de acordo com uma coleção de regras previamente configuradas
no sistema de firewall.
Este firewall de filtragem de pacotes tem duas ou mais interfaces
de rede, esta característica é conhecida como arquitetura multi homed. Na
prática, este tipo de firewall precisa de duas placas de rede dentro do
ambiente de rede de área local (LAN) [4]. Uma das interfaces de rede é
responsável pela conexão com a rede interna e a outra fica responsável pela
conexão com a rede externa ou internet.
Este tipo de tecnologia de firewall irá fazer o trabalho
correspondente ao de um policial de tráfego de pacotes, no qual direciona
pacotes permitidos para seus destinos e interrompe pacotes que podem
causar dano à rede, ou que não estão de acordo com as políticas de uso da
mesma.
A arquitetura básica desta tecnologia de firewall é apresentada a
seguir na Figura 2.

Figura 2 - Arquitetura básica da Tecnologia de Firewall
Todos os pacotes cuja origem é de fora da rede, e cujo destino é
dentro da rede, serão checados em detalhes pelo firewall de filtro de
pacotes. O sistema de firewall confere as informações básicas dos pacotes
como endereço de origem e de destino, portas de origem e destino,
protocolos, conteúdo e outras informações relacionadas. Para então ser feita
uma comparação entre as informações dos pacotes e de um conjunto de
regras previamente configuradas no sistema de firewall.
Como exemplo de configuração de firewall de filtro de pacotes,
podemos citar as requisições de conexão FTP, cuja porta de aplicação
padrão, a de número 21, é bloqueada. Portanto, todos os pacotes que
chegarem com esta porta de destino serão descartados. Em outra situação,
podemos citar o exemplo de sistemas de firewall configurados para permitir
o recebimento de pacotes web, cuja porta padrão é a de número 80 (para o
protocolo HTTP), permitindo assim, o encaminhamento de pacotes
recebidos por esta porta (geralmente, nestes casos, com a conotação de o
firewall deixar a porta 80 “aberta”) para seus endereços de destino, no
sentido dentro para fora e vice versa.
Combinaçoes de diferentes tipos de regras podem fazer um sistema
de firewall permitir conexões apenas a um servidor em particular. Neste
caso, o encaminhamento de pacotes só será permitido quando a porta e
endereço de destino correponderem às regras de configuração pré-
estabelecidas [5].
No sistema de firewall de filtragem de pacotes pode-se ainda
definir regras para determinar ações no caso de um pacote que chega à rede
e que não coincide com nenhuma das regras previamente estabelecidas, ou

que não há definições para as características do pacote. Normalmente,
nestes casos, o pacote será descartado por questões de segurança. Portanto,
para permitir certos pacotes de transitar na rede de computadores, devem-se
estabelecer regras claras e objetivas nas configurações do sistema de
firewall.
A seguir são demonstrados diversos exemplos de regras que podem
ser consideradas como guia para configurar sistemas de firewall de
filtragem de pacotes:
Nas redes privadas, como as LANs, os pacotes permitidos para
trafegar pelo sistema de firewall devem ser de origens interna, pois os
pacotes possuem, em seus cabeçalhos, informações oriundas de sua origem;
Esta regra é usualmente utilizada para prevenir ataques baseados em
spoofing, ela também previne os ataques de crackers, os quais utilizam a
rede interna para lançar um ataque.
Nos locais de rede pública, todos os pacotes terão como porta de
acesso à de número 80 por padrão. Esta regra permite o recebimento de
conexões na forma de sítios web, mas todas as conexões que utilizam esta
porta também estarão liberadas para acessar a rede interna, como por
exemplo, alguns softwares de conexão remota da área de trabalho.
Fazer o descarte de todos os pacotes que chegam da rede externa
com endereço IP de origem da rede interna; Assim evitando ataques spoof
de IP.
Descartar quaisquer pacotes de origem externa que contenham
informções de roteamento de origem interna para prevenir ataques de
roteamento de origem. Este tipo de ataque acontece quando os pacotes de
entrada contêm informações que subtituirão as informações dos pacotes na
rede passando por sua segurança.
2.3.1 Vantagens e Desvantagens
A seguir serão enumeradas as vantagens do firewall de filtro de
pacotes:
Processo simples, pois há baixo controle sobre cada pacote que
entra e sai da rede.
Checar de maneira básica cada campo do pacote como seu
endereço de origem, endereço de destino, protocolo, número da porta e tipo
de serviço.
Os pacotes podem ser identificados e descartados ao identificar
tentativa de spoofing no endereço IP de origem.

Todo o tráfego da rede local deve passar pelo firewall. Então, o
firewall se torna o único ponto de acesso entre a rede externa e interna.
Normalmente este tipo de filtro de pacotes é incluído nos
roteadores amplamente comercializados.
Seguem abaixo as desvantagens do firewall de filtro de pacotes:
Firewall de filtro de pacotes é complicado e difícil de criar as
regras de filtragem. Pode ser facilmente esquecido de incluir regras
excenciais para a rede, criar regras com conflitos, ou errar a especificação
de alguma regra causando vulnerabilidades na rede [6]. Portanto, sugere-se
utilizar alguma interface (GUI) para gerenciar as configurações de regras do
firewall.
Cada porta aberta que possuem serviços definidos, como Telnet,
SSH, FTP, entre outros, podem ser usadas para transporte de pacotes por
outras aplicações, como o RealPlayer. Estes tipos de aplicações testam a
rede para descobrir quais portas estão abertas, então usa a porta aberta para
efetuar as conexões relativas ao seu funcionamento. Normalmente, este tipo
de aplicação usa a porta 80, pois esta porta está geralmente aberta para
conexões web.
Para quebrar a segurança da rede, mesmo sem “ultrapassar” o
sistema de firewall basta fazer uma conexão de discagem, ou outros tipos
de conexão relacionados, como o de modens de internet 3G portáteis que
usam a porta USB do computador.
2.3.2 Onde estão os firewalls de filtro de pacotes
Este tipo de tecnologia de firewall é mais bem aplicada em redes
pequenas com nível de segurança crítico baixo. Pode ser encontrada em
diversos tipos de sistemas operacionais, implementados em hardware ou
software.
Sistemas Operacionais baseados em UNIX (Linux e BSD): Na
maioria dos sistemas operacionais baseados em UNIX, podem ser
configurados como roteadores ou firewall de filtro de pacotes. Possuem a
possibilidade de atribuir regras de configuração de filtragem de pacotes e
agir como um sistema de firewall. Este tipo de firewall pode ser
implementado utilizando tecnologias como ipfwadm, ipchains, iptables,
entre outros [7]. Utilizando-se para isto, duas placas de rede, uma conectada
à rede externa e a outra, à rede interna; sendo montado um firewall simples

e sem quaisquer hardwares adicionais [8]. Esta implementação fica limitada
pelo fato de haver necessidade de alto grau de conhecimento, pesquisa e
testes para configurar e atualizar o sistema de firewall e o funcionamento da
rede.
Roteadores baseado em software e hardware: Normamente
roteadores baseados em software ou hardware podem ser configurados
como sistema de firewall de filtro de pacotes simples. Por conseguinte, para
habilitar o roteamento de tráfego entre a internet e rede interna, deve-se
estipular um conjunto de regras de filtro de pacotes.
Sistemas Operacionais baseados em Windows Server e Serviços de
Acesso Remoto: Este é um serviço integrado dentro do SO do Windows
Server. Este provê roteamento de serviços como filtro de pacotes entre
outros. Estes recursos são valiosos se o SO executa o MPS (Microsoft
Proxy Server), ou proxy baseado em janelas, ou outro tipo de firewall de
filtro de pacotes baseado em Windows. Estes possuem as mesmas
limitações daqueles disponibilizados em sistemas UNIX.
2.4 Firewall de Inspeção de Pacotes Dinâmico
Este tipo de tecnologia de firewall é usada para manter registro das
atividades das conexões e pacotes que passam pela rede. Então, se utiliza
estes registros como critérios adicionais para decidir se permite ou nega o
tráfego do pacote na rede. Este, também utiliza a tecnologia de firewall de
filtro de pacotes aplicada.
No firewall de filtro de pacotes, não há histórico, passado
ou futuro, no que diz respeito ao funcionamento do firewall. As decisões
serão tomadas baseadas nas informações contidas nos pacotes, como
endereço de origem, endereço de destino, número da porta e assim por
diante. Neste tipo de tecnologia, o pacote é sem estado, por causa da falta
de informações sobre seu lugar no fluxo de informações.
No firewall de inspeção de pacotes dinâmico, será mantido
um acompanhamento das informações contidas dentro dos pacotes,
chamado de estado dos pacotes, que mantem todas as informações úteis nas
quais podem ser identificados os pacotes de conexão de rede existentes,
requisições de saída de dados, entre outras coisas relacionadas.
Como exemplo pode-se citar pacotes que entram na rede,
referentes a um streaming de vídeo. O firewall manterá informações da
conexão, como o tipo de protocolo, o endereço IP do servidor que está

enviando os pacotes de streaming, e o endereço IP da máquina que está
requisitando o serviço. Se o endereço externo de envio de pacotes do
protocolo da aplicação anterior for o mesmo dos pacotes sendo recebidos,
assim como o protocolo e o endereço destino dentro da rede, os pacotes
serão automaticamente liberados para trafegar na rede interna sem ser
analisado o seu conteúdo pelo firewall de inspeção de pacotes dinâmicos.
Normalmente, ele bloqueia todo o tráfego de entrada de
pacotes da rede externa, enquanto permite a saída de todos os pacotes de
dentro da rede. O sistema de firewall mantém o acompanhamento das
requisições internas enquanto as envia para fora da rede e mantem também
o acompanhamento de todos os dados de entrada referentes às requisições
citadas anteriormente, permitindo a passagem dos pacotes relacionados até
a conexão ser encerrada. Contudo, irá bloquear somente os pacotes de
entrada que não foram solicitados.
As configurações para este tipo de firewall podem ser mais
complexas se houver algum servidor rodando dentro da rede que atende
requisições externas, mas este tipo de tecnologia é mais flexível e
sofisticada. Como exemplo de configurações que permitem tráfego de
entrada de pacotes, podemos citar o caso em que podem ser permitidas
conexões a uma determinada porta, como a porta 80, para serem
encaminhados ao endereço de IP do servidor rodando um serviço web. Ou
seja, o firewall encaminha todo o tráfego que chega pela porta 80, com IP
de origem externo, para o servidor rodando o aplicativo web.
Ainda existem diversos serviços adicionais que este
sistema de firewall permite serem executados, como redirecionar certos
tipos de conexões para autenticação de serviços e bloquear o tráfego de rede
que contenham certo tipo de conteúdo, como mensagens de e-mail com
arquivos executáveis anexados, ou até mesmo bloquear websites que
contenham programas ActiveX [9].
O processo de acompanhamento do estado de conexões
depende do tipo de protocolo de comunicação dos pacotes que querem
atravessar a rede, como TCP (Transmission Control Protocol) ou UDP
(User Datagram Protocol).
2.4.1 Pacotes TCP
No estabelecimento de conexões do tipo TCP, existem SYN flags
que identificarão o primeiro pacote, que irá estabelecer a configuração da
comunicação e por consequente, a transferência de pacotes síncrona.

Normalmente, o firewall bloqueará todas as tentativas de conexão
externa, a não ser que tenha sido configurada alguma regra específica para
garantir a passagem de um pacote para um determinado tipo de conexão.
No caso de tentativas de conexão interna para hosts remotos, o sistema de
firewall notificará a conexão de pacotes e permitirá as respostas e pacotes
subsequentes entre os dois sistemas até a conexão se der por encerrada [10].
O sistema de firewall permitirá a passagem dos pacotes que
chegarem à rede, se eles corresponderem a uma configuração existente,
neste sentido do fluxo de pacotes.
2.4.2 Pacotes UDP.
Pacotes UDP são mais simples que pacotes TCP, pois no contexto
deste tipo de pacote, não há qualquer tipo de conexão síncrona, nem mesmo
há uma sequência exata das informações neles contidas. Possui apenas o
endereço IP da origem, do destino; e um resumo – número total de
dados/pacotes que estão sendo enviados/transferidos – para certificar que
tudo está de acordo.
Sistemas de firewall tem dificuldade em determinar a validade de
pacotes UDP, por causa da ausência de conexão síncrona, não há parâmetro
para certificar a validade dos pacotes que entram, assim sendo, não há como
decidir se permite ou não a passagem do pacote. Então só pode ser
determinada a permissão da passagem do pacote com os dados do registro
do estado e das requisições de conexões feitas de dentro da rede. Portanto,
pacotes de entrada, cujo endereço destino tem sido usado em uma requisião
prévia, e que inclusive utilize o protocolo UDP, coincidindo com uma
requisição previamente efetuada, terão seu tráfego permitido na rede. No
entanto, o sistema de firewall não permite pacotes UDP provenientes de
endereço IP de rede externa, a não ser que haja regras previamente
estabelecidas permitindo a passagem desse tipo de protocolo, ou endereço
de origem, ou se existiu alguma requisição feita a partir de dentro da rede
para esta conexão em específico. Este tipo de comportamento também
acontece para outros tipos de pacotes. O sistema de firewall necessita
manter o acompanhamento de requisições feitas para fora da rede
cuidadosamente. O firewall também necessita manter informações
importantes comos os endereços IP, protocolos e tipos de pacotes
utilizados. Finalmente, precisa checar se as informações salvas coincidem
com as informações dos pacotes que tentarem entrar na rede para assegurar
que os pacotes foram realmente requisitados.

A seguir enumeramos as vantagens e desvantagens do sistema de
firewall de inspeção dinâmica de pacotes:
O sistema de firewall checa cada campo do cabeçalho do pacote,
como endereço de origem, de destino, protocolo (TCP, UDP, entre outros),
número da porta e tipo de serviço (Telnet, FTP, SSH, entre outros). As
regras para filtragem dos pacotes serão aplicadas baseadas nestas
informações.
Possui a habilidade de identificar pacotes verificando o endereço IP
de origem.
Todo o tráfego de rede deve passar por este firewall. Portanto, é a
única ponte de acesso entre a entrada e saída de pacotes, tornando-se
extramamente difícil burlar este sistema.
Este sistema está apto a determinar o estado do pacote baseado nas
informações da aplicação e das comunicações prévias. Como exemplo de
informação de aplicação, podemos citar a autenticação prévia de conexão
para continuar a comunicação com os serviços autorizados. Entre os
exemplos de comunicação estão as conexões Telnet, este irá permitir o
retorno de pacotes Telnet que tenham sido previamente configurado.
Ele registra todos os detalhes das informações de acordo com cada
pacote que passa pela rede. Todas essas informações usadas pelo firewall
podem ser usadas para determinar o estado do pacote, como o tempo de
duração da conexão, sistemas externos fazendo requisições de conexão,
aplicações requisitando pacotes, etc.
Há apenas uma desvantagem no firewall de inspeção de pacotes
dinâmico. Sua operação faz com que o tempo de processamento global seja
alto, por causa dos registros mantidos pelo sistema, testes e análises no
tráfego da rede. A rede pode se tornar mais lenta na medida em que são
acrescentadas mais conexões ativas de transferência de pacotes simultâneas,
assim tornando mais lenta o tráfego de pacotes na rede, outro fator que pode
contribuir para deixar a rede mais lenta é a grande quantidade de regras
estabelecidas, que precisarem ser verificadas pelo sistema de firewall.
Como solução para este problema, os fabricantes de sistemas de firewall de
inspeção de pacotes dinâmicos, tem adotado o costume de melhorar a
velocidade do sistema com o aprimoramento do desempenho das máquinas
onde o sistema está instalado, como velocidade de CPU (Central
Processing Unit), placas de rede mais velozes, cabeamento da rede mais
veloz entre outros.

2.4.4 Onde estão os firewalls de inspeção dinâmica?
Existem diversos tipos deste tipo de firewall no mercado. O mais
comum são aplicações de software que podem ser instaladas em
computadores, geralmente com sistema operacional UNIX; Em alguns
roteadores mais sofisticados; E aplicativos de software e hardware
comerciais específicos para este fim.
2.5 Aplicações Proxy Firewalls
Este tipo de tecnologia de firewall não permite o tráfego direto
entre redes através de nodos conectados a ela. Ela o faz, aceitando o tráfego
da rede de certa aplicação cliente dentro da rede interna e configurará uma
conexão diferente para a rede pública até o servidor. Todavia, o servidor
não poderá ser acessado facilmente pelos nodos existentes na rede interna.
Uma conexão não pode ser estabelecida e os serviços não serão
suportados se o uso da aplicação não contiver o código de instalação do
proxy. Contudo, é amplamente utilizado por razões de segurança,
controlando e limitando as conexões de rede. O firewall descarta todas as
conexões que foram configuradas de maneira precária ou inapropriada.
Por exemplo, ao utilizar serviços web, usuários podem utilizar
navegadores de internet para conectar a um proxy firewall HTTP na rede
utilizando a porta 80. No entanto, o pedido de conexão web será controlado
pelo sistema de firewall e redirecionado para o servidor web requisitado.
Isto acontece de maneira rápida do ponto de vista do usuário e é feita de
forma automática pelo firewall proxy.
A seguir estão enumerados diversas aplicações que são suportadas
pelos firewalls proxy:
HTTP (Internete)
HTTPS/SSL (Internete Segura)
SMTP (E-Mail)
POP3 (E-Mail)
IMAP (E-Mail)
NNTP (Leitores de Notícias)
Telnet (Acesso à Shell remoto)
FTP (Transferência de Arquivos)
IRC (Bate papo)

A aplicação firewall proxy pode ser configurada para acessar
qualquer tipo de conexão da rede interna. Ainda possui características de
autenticação de usuário, para atribuição de diferentes políticas de acesso às
conexões. Este nível de segurança de acesso é feita mediante restrição de
conexões efetuadas para fora da rede por usuários conhecidos. Portanto,
pode ser considerado um ataque sendo lançado internamente se a rede for
comprometida.
A seguir enumeramos as principais vantagens de usar aplicações de
firewall proxy:
Possui bom controle das conexões, como permitir ou negar acesso
aos servidores baseado em seus endereços IP, ou baseado no IP de endereço
do usuário requisitante.
Esta tecnologia irá restringir requisições emitidas para certos tipos
de protocolos e eliminar serviços desnecessários. Pode permitir, nas
configurações do firewall conexões HTTP mas não conexões FTP. Ao
desabilitar estes serviços, não podem ser usados como plataformas para
lançar um ataque.
A maioria dos firewalls proxy podem manter registros de todas as
informações de conexão, como endereço fonte, endereço destino e duração.
É importante registrar tentativas de ataques e acessos não autorizados
dentro da rede.
Seguem abaixo as principais desvantagens de utilizar aplicações de
firewall proxy:
Os utilizadores devem personalizar aplicações de rede de acordo
com a sua utilização. Como o uso de navegadores web, que suportam
conexão à servidores proxy e devem ser configurados para ter uma conexão
com esta tecnologia. Outras aplicações podem ter uma necessidade
diferente de configuração.
Em algumas aplicações, frequentemente não é suportada conexões
de firewall proxy. Portanto, é necessário consultar a documentação dos
aplicativos ou seus fabricantes.
A tecnologia de firewall proxy tem um conjunto extra de segurança
útil para a rede, mas que ainda tem carências e não pode ser uma solução de
segurança completa.

2.5.2 Onde estão as aplicações proxy firewall
Este tipo de tecnologia de firewall pode ser elaborada a partir do
firewall existente ou usá-lo como um sistema autônomo, que reside dentro
da rede ou de uma localização DMZ existente [11]. Normalmente, a sua
localização é entre a rede interna e a internete.
Locais onde as aplicações de proxy firewall podem ser encontras,
incluem:
Pacotes de software que pertencem à sistemas existentes.
Roteadores de rede.
Sistemas operacionais baseados em UNIX.
2.6 Softwares Firewall de Código Aberto:
Enquanto você está na internet é importante proteger os seus
sistemas contra ameaças e ataques. Se você é o administrador de TI, ou não,
precisa proteger sua rede adicionando uma proteção de firewall. Faze-lo é
garantir que o tráfego que entra e sai da rede local é seguro e, está
acessando as aplicações corretas sobre os sistemas implantados. Embora
existam muitos firewalls disponíveis comercialmente, aqui está uma lista de
alternativas de código aberto. Esta lista não está ordenada por qualquer tipo
de classificação.
Coyote Linux: É uma pequena distribuição de Linux embutido,
projetado para funcionar como um firewall para redes de pequeno a médio
porte. Os planos atuais para Coyote Linux incluem uma interface de
administração completamente reformulada, recursos de segurança muito
mais robustos, suporte acelerador de segurança de hardware, e muito mais.
Firestarter: É uma ferramenta de firewall pessoal, livre e de
código aberto que usa o Netfilter (iptables /ipchains) sistema embutido no
kernel do Linux. Firestarter tem a capacidade de controlar as conexões de
entrada e saída, proporciona uma interface gráfica fácil de usar para
configurar regras e outras funcionalidades do firewall. Ele também oferece
monitoramento em tempo real de todo o tráfego de rede. Este firewall,
apesar de promissor, está descontinuado desde meados de 2007.

IPCop: É uma distribuição Linux firewall que é voltada para
usuários domésticos e pequenas empresas. O IPCop possui interface
amigável e de uso fácil.
IPFilter: É um pacote de software de código aberto que fornece
serviços de firewall e tradução de endereços de rede (NAT) para sistemas
operacionais UNIX. IPFilter suporta ambos os protocolos IPv4 e IPv6, e é
um firewall de filtro de pacotes dinâmico .
IPFire: É uma distribuição sólida de código aberto Linux projetado
para uso como firewall. Ele oferece proteção de rede com níveis desde
usuários domésticos até grandes corporações, redes de ensino e autoridades.
Ele pode ser mantido através de uma interface web.
Netfilter: É um programa de aplicação de usuário, que permite que
um administrador do sistema configure as tabelas fornecidas pelo firewall
do kernel do Linux. É um programa de linha de comando usado para
configurar o conjunto de regras de filtragem de pacotes dos Linux 2.4.xe
2.6.x com protocolo IPv4. Ele é voltado para administradores de sistema. O
conjunto de aplicações também inclui iptables e ip6tables. Ip6tables é usado
para configurar o filtro de pacotes IPv6.
m0n0wall: É uma distribuição firewall embutido no FreeBSD, um
dos descendentes do sistema operacional BSD. Ele fornece uma pequena
imagem de sistema operacional, que pode ser colocado em cartões de
memória flash, bem como em CD-ROMs e discos rígidos. Ele roda em uma
série de plataformas embarcadas e PCs genéricos. A versão para PC pode
ser executado com apenas um Live CD e um disquete para armazenar dados
de configuração, ou em um único cartão de memória (com um adaptador
IDE). Isto elimina a necessidade de uma unidade de disco rígido, o que
reduz os níveis de ruído e calor.
pfSense: Presente em distribuição personalizada do FreeBSD
adaptada para uso como um firewall e roteador. Além de ser uma poderosa
plataforma de firewall e roteamento, flexível, inclui uma longa lista de
recursos relacionados e um sistema de pacotes permitindo mais capacidade
de expansão sem acrescentar inchaço e potenciais vulnerabilidades de
segurança para a distribuição base.
Shorewall: (ou Shoreline Firewall) é uma ferramenta de firewall
de código aberto para Linux que se baseia nos Netfilter (iptables /ipchains)

sistema embutido no kernel do Linux , tornando-o mais fácil de gerenciar
os esquemas de configuração mais complexos.
Smoothwall: O Projeto de código aberto Smoothwall foi criado em
2000 para desenvolver e manter Smoothwall Express - um firewall gratuito
que inclui seu próprio sistema operacional com segurança reforçada
GNU/Linux e uma interface web fácil de usar. Smoothwall é uma
distribuição Linux concebida para ser utilizada como uma fonte de firewall
aberta. Projetado para facilidade de uso, é configurável através de uma
interface gráfica web e requer muito pouco ou nenhum conhecimento de
Linux para instalar ou usar.
Untangle: É um Firewall de código livre que filtra o tráfego com
base no endereço IP, protocolo e porta, que permite aos administradores
designar os sistemas e serviços que estão disponíveis publicamente (HTTP,
FTP, FTP, etc). Funciona como uma ponte transparente que complementa
os firewalls pré-existentes e controla o acesso de entrada e/ou saída para IPs
e portas específicas.
Vyatta: Esta empresa fabrica software de roteador virtual baseado
em software, firewall virtual e produtos de VPN para redes de Internet
(IPv4 e IPv6). Pode ser baixado gratuitamente da página Vyatta e já está
disponível um pacote com código aberto, uma distribuição Linux baseada
no Debian, com aplicações de rede tais como Quagga , OpenVPN , e muitas
outras.
UFW: Denominado Ubuntu Firewall, é um firewall simples
embutido nas distribuições Ubuntu. Apenas gerencia de maneira mais
amigável as tabelas do IPTables (presente em todas as distribuições Linux).
2.7 Conclusão
Ferramentas de segurança de redes perimetrais são o começo de
algo que pode proteger a rede interna do acesso externo indevido. Então,
firewall é a melhor defesa de perímetro, que se desenvolve para
proporcionar a proteção do tráfego da rede.
Sistemas de Firewall vem evoluindo no ambiente de rede de
computadores ao longo dos anos a partir de métodos simples, inicialmente
com apenas sistemas de filtragem de pacotes, para termos atualmente os
inspetores de pacotes sofisticados que podem decidir permitir ou bloquear o

tráfego, dependendo da sua finalidade, origens e destinos [12]. O método de
inspeção de pacotes dinâmico é a melhor tecnologia entre as demais
tecnologias de firewalls. É um sistema bom, constantemente considerado
completo, para proteção do tráfego de pacotes na rede.
Por último, o melhor do melhor sistema de firewall não depende
apenas de sua metodologia ou tecnologia, mas também deve ter a
capacidade de fornecer um bom registro de atividades e relatórios de
utilização. Com esses recursos, todo o trabalho que é feito pelo sistema de
firewall, e toda tentativa de intrusão que acontece na rede de computadores
será gravado e poderá ser informado ao administrador da rede.
Tabela 1 - Dados de Tecnologias Firewall.
Firewall Fabricante Website Oficial
Coyote Linux Vortech Consulting http://www.coyotelinux.com
Firestarter Tomas Junnonen http://www.fs-security.com
IPCop IPCop http://www.ipcop.org
IPFilter Darren Reed http://coombs.anu.edu.au/~avalon/
IPFire Lightning Wire Labs http://www.ipfire.org
Netfilter Noris Network http://www.netfilter.org
m0n0wall Manuel Kasper http://m0n0.ch/wall/
pfSense
Eletric Sheep
Fencing LLC
http://www.pfsense.org
Shorewall Gareth Davies http://www.shorewall.net
Smoothwall Smoothwall http://www.smoothwall.org
Untangle Untangle http://www.untangle.com
Vyatta Brocade http://www.vyatta.org
UFW Canonical http://wiki.ubuntu-br.org/UFW

3 VPN
3.1 Introdução:
A Internete é considerada a base de conectividade para as
organizações expandirem suas operações e aumentar suas receitas.
Conforme as organizações crescem, diferentes métodos devem ser
empregados para fornecer conectividade segura e eficiente entre os
escritórios filiais distribuídos geograficamente, parceiros estratégicos e
funcionários móveis (à distância). Apesar de várias tecnologias existentes,
mais recentemente com base na internete, redes privadas virtuais (VPNs)
evoluíram como o meio mais seguro e rentável de alcançar esses objetivos.
VPN pertence a uma família de redes sobrepostas que utilizam túneis IP
para formar uma rede virtual no topo da internete. Estes túneis utilizam
técnicas criptográficas para garantir segurança robusta e privacidade. Para
um usuário remoto, VPN oferece todos os benefícios de uma rede privada,
enquanto as corporações beneficiam-se dos baixos custos operacionais, alta
segurança, e cobertura global instantânea oferecida por ela [13].
Vários produtos VPN comerciais são agora amplamente
disponíveis, diferindo principalmente em termos de custo e capacidades.
Nos últimos anos, no entanto, soluções VPN de código aberto têm atraído
muita atenção dos pesquisadores e desenvolvedores. Trata-se de uma
ramificação de soluções de software que podem fornecer serviços VPN de
nível comercial, a preços razoavelmente baixos, utilizando computadores
rodando Linux. A disponibilidade de licenciamento de código fonte aberto
permite que os desenvolvedores personalizem e aperfeiçoem (e às vezes
comercializem) estes produtos para dispositivos físicos especializados, para
extrair o máximo de desempenho, como por exemplo, produtos
SnapGerar’s [14] LITE+ e SME550 usam uma porta de FreeS/WAN (uma
implementação aberta de IPSec) em μClinux (Linux para
microcontroladores). Como o Linux é usado como o sistema operacional
base, a implantação é rápida e fácil, evitando a necessidade de
administradores de sistemas terem de aprender sistemas operacionais
proprietários. Tudo isso juntamente com suporte técnico gratuito,
disponível através grupos de notícias, listas de discussão e foruns online,
apresentam uma boa alternativa para pequenas e médias empresas para
operar globalmente em praticamente custo zero. Com os avanços nos
roteadores movidos a Linux, essas soluções têm o potencial de encontrar
um nicho no mercado de VPN.

3.2 Túneis
Um túnel é um meio de transmissão dos dados através de uma rede
de um nó para outro, como se os dois nós estivessem diretamente
conectados. Isto é possível através do encapsulamento dos dados - um
cabeçalho adicional é adicionado aos dados enviados pela extremidade de
transmissão do túnel, e os dados são encaminhados por nós intermédiários,
com base em um cabeçalho exterior deste, sem olhar para o conteúdo do
pacote original.
Isto é ilustrado na figura 3, que mostra dados que vão ser enviados
do ponto A ao B, através de um túnel com nós X e Z. O nó intermediário do
túnel, nó Y, não precisa estar ciente do destino final B, mas apenas
encaminhar para frente os dados ao longo do túnel para Z. (Neste cenário,
X é conhecida como a entrada para o túnel e Z como o egresso).
Figura 3 - Fluxo de Dado em Túneis VPN
Este tunelamento de dados significa que os dispositivos P
(representados por círculos) não precisam estar cientes das VPNs, mas só
precisam ser capaz de encaminhar os dados encapsulados. Isso é
importante, pois reduz os recursos de rede consumidos pela VPN e da
quantidade de configuração necessária para configurá-lo.
Além disso, através do envio de dados entre os locais de VPN
usando túneis, é possível manter a separação de dados entre diferentes
VPNs, e ainda impedir que os dados de uma VPN possam ser vazados na
rede do provedor de internet ou global. Isso também significa que os
endereços de dispositivos dentro dos locais VPN estão escondidos nos
dados transportados ao longo do túnel, para que eles não precisem ser
alterados para permitir que eles se comuniquem através da Internet.

Há certo número de protocolos que podem ser usados para
estabelecer esses túneis, e as propriedades do túnel tem um efeito
significativo sobre as propriedades globais da VPN usando esse túnel. No
entanto, muitas das soluções de VPN que vamos descrever não dependem
de uma tecnologia de encapsulamento específica e funcionam com um, ou
mais, dos vários tipos.
3.2.1 Protocolos de Túneis
Os principais protocolos de túnel que são usados pelas VPNs são,
IPsec, SSL/TLS, IP-in-IP, L2TP e GRE. Uma breve descrição de cada
tecnologia das siglas citadas é dada abaixo.
MPLS (Switching Multi-Protocol Label): é uma tecnologia que
está sendo padronizado pelo IETF, que fornece transmissão de dados de alta
velocidade com reserva de banda.
O princípio deste protocolo é o envio dos pacotes através de um
túnel MPLS ligando rótulos anexados, sem olhar para o conteúdo do
cabeçalho IP. O nó de entrada do túnel adiciona um rótulo ao pacote, e nós
subsequente encaminham os pacotes para frente, com base na interface de
entrada e do rótulo, enviando o pacote para o próximo nó com um novo
valor de rótulo. O último nó no túnel MPLS remove o rótulo antes de
encaminhar o pacote para o seu destino final. O caminho percorrido pelos
dados é conhecido como um Caminho Comutado por Rótulo (LSP – Label
Switched Path).
Um dos benefícios do MPLS é a possibilidade de criar LSPs dentro
de LSP (dentro LSP...), o que dá boas propriedades de multiplexação.
Tunelamento de um LSP através de outro é simplesmente uma questão de
adicionar um novo rótulo para a "pilha de rótulos" (a coleção de rótulos
anexados ao pacote). À medida que o pacote avança, ele é encaminhado de
acordo com a informação contida no rótulo no topo da pilha. No final do
LSP, o rótulo no topo da pilha é descartado, e o pacote é encaminhado
utilizando o novo rótulo no topo da pilha.
Outra vantagem do MPLS como uma tecnologia de túnel VPN é
que a engenharia de tráfego MPLS pode dedicar recursos para um LSP. Isso
é bom para um cliente com uma VPN baseada em MPLS, que tenha uma
quantidade de largura de banda determinada.
A única coisa que o cliente precisa se preocupar é a segurança. No
entanto, uma análise da segurança de VPNs MPLS utilizando túneis,
mostrou que a segurança é semelhante ao que seria assegurado se os sites

VPN fossem ligados através de conexões virtuais ATM/Frame Relay. Em
particular, os dados são mantidos em sigilo - como acontece com ATM e
Frame Relay, problemas de rede podem causar perda de pacotes, mas não
são susceptíveis de resultar em pacotes sendo entregues para o destino
errado. Por outro lado, ainda é uma precaução sensata para criptografar os
dados particularmente sensíveis.
IPSec: muito popular para a construção de VPNs, possui várias
características desejáveis. Desde que o protocolo IPsec foi desenvolvido por
razões de segurança, não é surpreendente que ele tem tudo na lista de
quisitos de segurança - integridade sem conexão, autenticação da origem
dos dados, anti-repetição e criptografia. Note que há um impacto negativo
no desempenho, resultado do uso de codificação criptográfica no
encaminhamento de pacotes.
Outra vantagem do IPsec é não possuir conexão - um túnel IPsec
entre dispositivos não consome quaisquer recursos nos roteadores no
caminho. A única necessidade é algumas informações de segurança comum
entre os dispositivos, que pode ser configurados manualmente ou
distribuído automaticamente (por exemplo, usando IKE).
Porém, não há desmultiplexador natural para túneis IPsec, embora
seja possível contornar essa deficiência - por exemplo, através da execução
MPLS através de um túnel IPsec.
Mesmo sem olhar para as aplicações de tunelamento, IPsec pode
ser útil em qualquer VPN. Independentemente do tipo de VPN que você
usa, se você está enviando tráfego IP sensível entre os locais, você pode
querer protegê-los de olhos curiosos, usando o modo de transporte IPsec
sobre o transporte subjacente.
SSL/TLS: O protocolo SSL provê a confidencialidade
(privacidade) e a integridade de dados entre duas aplicações que se
comuniquem pela Internet. Isto ocorre através da autenticação das partes
envolvidas e da cifra dos dados transmitidos entre as partes. Esse protocolo
ajuda a prevenir que intermediários entre as duas pontas da comunicação
tenham acesso indevido ou falsifiquem os dados transmitidos. O servidor
que está sendo acessado envia uma chave pública ao cliente, usada por este
para enviar uma chamada secreta, criada aleatoriamente. Desta forma, fica
estabelecida a trocas de dados criptografados entre dois computadores.
Baseia-se no protocolo TCP da suíte TCP/IP e utiliza-se do conceito

introduzido por Diffie-Hellman nos anos 70 (criptografia de chave pública)
e Phil Zimmermann (criador do conceito PGP).
L2TP: L2TPv3 (Layer 2 Tunneling Protocol versão 3) é um
protocolo projetado para tunelamento da camada 2 de informações através
de uma rede de camada 3. Como tal, não é surpreendente que o protocolo é
particularmente útil para a VPN de camada 2.
Felizmente para o provedor de VPN, a escalabilidade é boa - túneis
só consomem recursos para as extremidades do túnel, e os túneis podem ser
multiplexados. Apesar de L2TP não ter segurança embutida, L2TP pode ser
executado com o modo de transporte IPsec, proporcionando um nível
saudável de segurança para a VPN de camada 2.
IP-in-IP: RFC2003 descreve um mecanismo de encapsulamento de
pacotes IP sobre IP. Embora a escalabilidade desde seja boa em um sentido
- não há a necessidade de configuração do túnel, tornando-se desnecessário
manter diferentes estados de configuração - o principal problema é a
impossibilidade de multiplexação, assim, um endereço IP diferente é
necessário para cada extremidade do túnel. A carência de endereços IPv4,
juntamente com a falta de segurança faz com que o protocolo IP-in-IP não
seja o ideal para o uso em VPNs.
GRE (Generic Routing Encapsulation): este foi originalmente
definido na RFC1701, mais tarde foi atualizado em RFC2784 com menos
funções. GRE permite efetuar túneis de um protocolo qualquer dentro de
outro protocolo qualquer.
O principal uso do GRE no contexto VPN é levar IP-in-IP. Tal
como acontece com RFC2003, este tem as vantagens de que não há
necessidade de qualquer sinal de ligação, e não há recursos consumidos
pelo túnel GRE.
Até agora, esta é muito semelhante às propriedades de RFC2003
IP-in-IP. No entanto, existe uma diferença fundamental. As extensões para
GRE descritos na RFC2890 permitem a multiplexação de túneis GRE. Isso
nos permite configurar os dados do túnel de múltiplas VPNs, usando GRE,
sem a necessidade de esgotar o estoque restante de endereços IP não
utilizados.
PPTP (Point-to-Point Tunneling Protocol) usa um canal de
controle sobre TCP e um túnel GRE operacional para encapsular pacotes
PPP .

O protocolo PPTP não descreve criptografia ou recursos de
autenticação e conta com o protocolo Point-to-Point tunelado para
implementar a funcionalidade de segurança. No entanto, a implementação
mais comum do PPTP, disponibilizado nas famílias de produtos Microsoft
Windows implementa vários níveis de autenticação e criptografia nativa
como recursos padrão da pilha de PPTP do Windows. O uso pretendido
deste protocolo é proporcionar níveis de segurança e níveis de acesso
remoto, comparáveis com produtos típicos de VPN.
PPTP tem sido objeto de muitas análises de segurança e sérias
vulnerabilidades de segurança foram encontrados no protocolo. As
vulnerabilidades conhecidas referem-se aos protocolos de autenticação PPP
subjacentes utilizadas, o design do protocolo MPPE, bem como a
integração entre MPPE e autenticação PPP para o estabelecimento de chave
de sessão. PPTP é (a partir de outubro de 2012) considerado quebrado
criptograficamente e seu uso não é mais recomendado pela Microsoft [22].
SSTP (Secure Socket Tunneling Protocol) é uma forma de túnel
VPN que fornece um mecanismo para transporte de PPP ou de tráfego
L2TP através de um canal SSL 3.0. SSL fornece segurança de nível de
transporte com chave de negociação, criptografia e verificação de
integridade de tráfego. O uso de SSL através da porta TCP 443 permite
SSTP passar por praticamente todos os firewalls e servidores proxy, exceto
para a web proxies autenticados.
Servidores SSTP devem ser autenticados durante a fase de SSL.
SSTP clientes podem, opcionalmente, ser autenticado durante a fase de SSL
e deve ser autenticado na fase de PPP. O uso de PPP permite suporte para
métodos de autenticação comuns, tais como EAP-TLS e MS-CHAP.
SSTP está disponível para Linux, BSD e Windows. O Mikrotik
RouterOS também inclui um cliente SSTP e servidor.
Para o Windows , SSTP só está disponível desde a versão
Windows Vista SP1, em RouterOS, e em SEIL desde a sua versão de
firmware 3.50. É totalmente integrado com a arquitetura RRAS nesses
sistemas operacionais, permitindo o seu uso com a autenticação de cartão
inteligente ou Winlogon, políticas de acesso remoto e o cliente Windows
VPN.
SSTP foi destinado apenas para acesso do cliente remoto, ele
geralmente não suporta túneis VPN site-to-site. A versão RouterOS não tem
tais restrições.
SSTP sofre das mesmas limitações de desempenho que qualquer
outro túnel IP-sobre-TCP. Em geral, o desempenho será aceitável somente

enquanto houver excesso de largura de banda suficiente para a ligação de
rede não encapsulada para garantir que os temporisadores de túnel TCP não
expirem. Se os temporisadores de túnel TCP expirarem, o desempenho cai
drasticamente, isto é conhecido como o "problema de fusão TCP ".
3.2.2 Resumo dos Protocolos de Tunelamento
A tabela a seguir mostra as principais propriedades dos diferentes
tipos de túneis. As características dos túneis que são considerados são as
seguintes:
Será que os túneis têm a vantagem de escalabilidade de uma
capacidade de multiplexação?
Quão seguros são os túneis?
Pode engenharia de tráfego ser aplicada nos túneis para fornecer
QoS para a VPN?
Será que os túneis requerem estado armazenado, em caso
afirmativo, o que é preciso para armazenar o estado?

Tabela 2 – Resumo dos Protocolos de Tunelamento de VPN [23].
Multiple-
xação
Segurança
Engenharia
de Tráfego
Estado Armazenado
MPLS SIM
Equivalente
a ATM/FR
SIM
Todos os nós do
túnel, para o túnel
inferior. No final do
túnel somente para
túneis aninhados.
IPSec NÃO BOA NÃO
Somente no final do
Túnel
IP-in-IP NÃO NÃO NÃO NÃO
L2TP SIM NÃO NÃO
Somente no final do
Túnel
GRE SIM NÃO NÃO NÃO
PPTP SIM BAIXA SIM
Somente no final do
Túnel
SSTP SIM SIM NÃO NÃO
SSL/TLS SIM BOA SIM
Somente no final do
Túnel
3.3 Estudo de desempenho
Nesta seção apresentamos o estudo de desempenho, baseados nos
trabalhos de Pena e Evans [15]; nos trabalhos de Clercq e Paridaens [20] e
nos trabalhos de Khanvilkar e Khokhar [23] para os SVBLCAs
selecionados.
Neste capítulo vamos mostrar o estudo e avaliações de algumas das
Soluções de VPNs Baseado em Linux de Código Aberto mais populares
(SVBLCA). Apresentando o estudo comparativo, com base no desempenho
da rede, recursos/funcionalidades suportados, e as preocupações
operacionais, por várias SVBLCA populares que estão disponíveis
livremente na internete. A partir deste estudo, destacar-se-á inconvenientes
comuns que existem atualmente no SVBLCA e também, questões de
pesquisas futuras que podem ser abordadas. Recentemente, Pena e Evans
[15] estudaram diferentes VPNs em termos de rendimento e uso da CPU em
redes de alta e baixa velocidade. Embora importante, ainda existem vários
aspectos (“overhead”, segurança, modularidade, etc) que caracterizam uma
solução de VPN e, portanto, garante a comparação [23]. Este capítulo é
abrangente em termos de quantidade de soluções VPNs consideradas, e do
número de características comparadas.

Este capítulo revela que não existe uma única SVBLCA que se
destaca em todos os atributos considerados, selecionar uma solução
adequada é um processo complicado, que envolve análise de muitas
vantagens e desvantagens, dependendo da política da empresa e dos
aplicativos utilizados. Por exemplo, FreeS/WAN demonstra baixa latência e
instabilidade, tornando-o adequado para aplicações em tempo real. No
entanto, ele apresenta alta sobrecarga e baixa utilização de largura de
banda. Assim, para situações em que esses fatores são importantes,
alternativas como Cipe ou PPTP podem ser empregadas. Em suma, vários
fatores devem ser cuidadosamente avaliados antes de uma solução
SVBLCA ser selecionada para implantação e múltiplas soluções podem ser
feitas para interagir e extrair o máximo de desempenho.
3.4 A arquitetura de um roteador SVBLCA
A arquitetura de software de um roteador SVBLCA é caracterizada
pela modificação da pilha de protocolos de rede TCP/IP com dois
componentes adicionais: o daemon VPN e a interface de rede virtual (VNI).
O daemon VPN é um processo em nível do usuário, ou do kernel, com um
plano de controle separado para manutenção da conexão e um plano de
dados para processamento de dados. O plano de controle é usado para
autenticação de pares e geração de chaves de sessão que são posteriormente
utilizados para garantir túneis. Ele também mantém um mapeamento entre
endereços IP dos roteadores SVBLCA ponto a ponto e sub-redes privadas,
o que é consultado quando do tunelamento de pacotes VPN. O plano de
dados é como um gasoduto proporcionando criptografia, autenticação e
serviços de compressão. Planos de controle geralmente usam TCP para o
transporte, enquanto o plano de dados pode usar TCP ou UDP. Mais tarde,
veremos que VPNs que utilizam protocolos orientados à conexão (como o
TCP) tem o desempenho da rede significativamente mais pobre do que
aqueles que utilizam protocolos sem conexão (como o UDP).
A VNI é um dispositivo abstrato especificamente criado durante a
inicialização VPN para trocar facilmente pacotes entre o daemon de
roteamento IP e o daemon VPN. Qualquer pacote encaminhado através do
VNI é automaticamente entregue ao daemon VPN e vice-versa. Como
qualquer interface de rede real, um protocolo de enlace de dados como PPP
ou SLIP controla a entrega de pacotes sobre a VNI.
Pode-se descrever o caminho de dados feito por um pacote se
deslocando a partir de uma rede privada para outra em três partes:

Ao chegar na eth1, o pacote VPN é posteriormente entregue ao
daemon de roteamento IP, que determina o próximo salto para
roteador/interface-de-saída usando um prefixo mais longo correpondente
em seu endereço de destino.
Uma vez que o destino é um endereço privado, o daemon de
roteamento vai descatar este pacote, a menos que a tabela de roteamento foi
atualizada para encaminhá-lo através da VNI, ou o daemon de roteamento é
modificado para reconhecer um pacote VPN e entregá-lo diretamente para o
servidor VPN. Embora o segundo método elimine uma viagem extra para
baixo da pilha de protocolos, que exige mudanças no protocolo de
roteamento, o que é muito mais complicado. Assim, o primeiro método é
geralmente preferido.
O daemon VPN todos os pacotes de dados e os sujeita à
compressão e outras funções criptográficas. Em seguida, determina o
IP/Porta pública do roteador SVBLCA ponto a ponto, envolve-o em um
novo cabeçalho IP e envia-lo como um pacote de dados normal. No
receptor, ocorrem exatamente os mesmo passos, porém inversamente, na
medida em que os pacotes são entregues ao destino correto.
3.5 Características VPN
Características VPN diferentes desempenham um papel
significativo na escolha de uma solução ótima para um determinado cenário
de aplicação. Na discussão que se segue, podemos classificar essas
características ao longo das seguintes três dimensões: o desempenho da
rede, características e funcionalidades suportadas, e preocupações
operacionais [23].
3.5.1 Desempenho da Rede
O desempenho da rede de um SVBLCA é medido em termos de
sobrecarga (overhead), a utilização da largura de banda e
latência/instabilidade. É de conhecimento geral que VPNs têm mal
desempenho de rede, o que implica em sobrecarga alta, utilização de banda
baixa e alta latência/instabilidade. Abaixo identificamos algumas causas
desta anomalia e discutir soluções utilizadas popularmente.

Overhead - A arquitetura do software discutido anteriormente
explica em parte a grande sobrecarga adicionada a um pacote de dados
básicos por ele viajar através de várias camadas de protocolo.
Todos os SVBLCAs invariavelmente sofrem com essa grande
sobrecarga, 75 por cento do que é essencialmente contribuído pelos
cabeçalhos adicionados pelas diversas camadas de protocolo, e os restantes
25 por cento pelos algoritmos de criptografia utilizados para segurança.
Sobrecarga de cabeçalho pode ser reduzida através de compressão. Alguns
SVBLCA s (como PPP sobre SSH e Stunnel) utilizam rotinas de
compressão de cabeçalho fornecidas pelo link de protocolos da camada de
dados (como PPP) que operam sobre a VNI, enquanto outros (como Tinc e
Open-VPN) fornecem utilitários de compressão embutidos.
Compressão, no entanto, apresenta latência adicional e, se
cegamente utilizado para cada pacote, independentemente do seu tamanho
ou tipo (compactados ou criptografados), pode não melhorar o desempenho
[16]. A sobrecarga introduzida pelos algoritmos criptográficos tipicamente
não pode ser reduzida, e é contribuído pelo algoritmo específico de
codificação/controle de acesso ao meio (MAC) em utilização.
Cifras de fluxo não adicionam qualquer sobrecarga, mas as cifras
de bloco mais populares (como 3DES ou Blowfish) exigem que a entrada
seja um múltiplo de 8 ou 16 bytes (chamado de tamanho do bloco), o que
aumenta a sobrecarga. Algoritmos MAC tais como MD5 e SHA1
contribuiem com um adicional 16-20 bytes. Outras contribuições menores
são de números de seqüência e marcas de tempo usadas para derrotar os
ataques de replay.
Utilização de banda - Esta é a largura de banda máxima atingida
por um fluxo TCP e é afetada pela sobrecarga, latência e empilhamento
TCP. Enquanto sobrecarga reduz a quantidade de bytes úteis transferidos, a
latência afeta o resultado no atraso da largura de banda para uma ligação
TCP. Para tubos virtuais grandes e longos (como no presente caso), a
latência introduzida muitas vezes é tão grande que é fisicamente impossível
alocar buffers maiores, necessários para suportar o aumento correspondente
em tamanhos de janela TCP, para manter a utilização da largura de banda.
O último fator, empilhamento TCP, se refere ao uso do TCP várias
vezes ao longo do caminho dos pacotes de dados. Isso acontece se um fluxo
TCP flui sobre uma SVBLCA que usa canais de dados baseados em TCP.
Interferência entre temporizadores do TCP em diferentes camadas
acarretam nessa degradação [17]. Nós achamos que este seja o efeito mais

impactante, com SVBLCAs usando TCP, resultando em desempenho muito
pior do que aqueles que usam UDP.
Latência / Instabilidade - Latências mais elevadas ocorrem
devido ao caminho de pacote de dados alongado. Ocorrem com computação
intensiva de funções criptográficas e cópia múltipla de pacotes de dados
entre o kernel e o espaço do usuário. Um bom método para encurtar
caminhos de dados é recorrer à troca da camada 2, como no modo de
transferência assíncrona (Asynchronous Transfer Mode - ATM), Troca de
Etiqueta Multiprotocolo (Multiprotocol Label Switching - MPLS),
enquanto tempo computacional elevado pode ser reduzido pelo uso de
hardware mais rápido [18] ou melhores algoritmos de criptografia.
Finalmente, cópias múltiplas de pacotes de dados ocorrem devido
aos SVBLCAs existirem como daemons no espaço do usuário e poderem
ser eliminadas por integrá-las no kernel do sistema operacional (SO). Isso,
no entanto, reduz a flexibilidade operacional, como a maioria dos usuários
não é especialista de kernel. Aumento similar da instabilidade depende do
esquema de escalonamento do SO, e só pode ser reduzida aumentando a
prioridade de seu processo.
3.5.2 Características suportadas e funcionalidades
Espera-se que SVBLCAs suportem certas características
importantes para melhorar o desempenho. Aqui, a importância de apoiar
estes recursos é discutida, enquanto a seção de resultados apresenta o
quanto bem equipado são os SVBLCAs atuais, para suportar tais
características [23].
Código de modularidade - Refere-se à flexibilidade de uma
solução SVBLCA quando se trata de usar algoritmos de escolha do usuário.
Assim, código modular pode ser definido como o apoio da SVBLCA para
algoritmos de plugins, que pode variar de plugins simples para criptografia
aos mais complexos para roteamento e segurança. Algoritmos de plugins
são uma excelente maneira de permitir a integração rápida e fácil de
algoritmos mais recentes para a solução SVBLCA e oferece aos seus
usuários uma opção para criar ou comprar plugins desenvolvidos
independentemente de criptografia, compressão de dados, entre outros.
Soluções SVBLCA projetadas com plugins podem sobreviver potenciais
ameaças à segurança, alargando assim a sua vida útil, e também permitem
que as empresas usem seu próprio código proprietário.

Roteamento - Roteamento precisa ser definido uma vez que os
túneis são estabelecidos e a topologia está definida. A tabela de roteamento
em cada nó roteador SVBLCA precisa ser atualizada com informações
sobre como alcançar seus nodos ponto a ponto. Isto pode ser feito
manualmente ou automaticamente. As rotas podem ser atualizadas
manualmente usando uma rotina no terminal de linha de comando
(disponível na maioria dos sistemas UNIX). No entanto, isto apresenta um
exercício pesado e muitas vezes propenso a erros quando o número de nós é
grande, e muitas vezes, resulta em uma topologia de grafo completa.
Roteamento automático utiliza um daemon de roteamento
independente para trocar informações de roteamento e configurar tabelas de
roteamento. Para VPNs de domínio único, onde o espaço de endereço
privado é único, um programa de roteamento separado pode ser usado para
atualizar as informações de roteamento privado. Esta abordagem permite
que topologias arbritárias sejam criadas e que algoritmos proprietários
sejam usados.
Para vários domínios VPNs, onde o espaço de endereço não é
único, o roteamento torna-se uma questão complicada. Esta é atualmente
uma área importante de pesquisa, e uma solução possível é fazer instâncias
de roteamento separadas com tabelas de roteamento (chamados de
roteadores virtuais) para cada VPN.
3.5.3 Preocupações operacionais
Selecionar uma solução SVBLCA para implantação requer uma
boa base de informações sobre muitas características operacionais, como
segurança e escalabilidade, o que acaba decidindo a utilidade da solução
VPN. Estes são os parâmetros qualitativos que são difíceis de definir e
comparar. Nesta seção, apresentamos uma série de propriedades para cada
um desses aspectos para ter uma ideia melhor sobre eles [23].
Segurança - Embora a segurança oferecida por uma solução
SVBLCA é uma característica importante, é altamente relativa e difícil de
definir em termos absolutos. Até o passado recente, sigilo e obscurecimento
foi utilizado principalmente para garantir a segurança, o que foi
manifestado na utilização em larga escala de algoritmos proprietários não
padronizados (por exemplo, MPPE usado em PPTP) onde o código fonte é
mantido em segredo. No entanto, este conceito tem sido abandonado,
porque muitos desses algoritmos já foram quebrados [19]. A norma nova e

amplamente aceita é a de protocolos padronizados abertos, onde os
algoritmos e suas implementações são amplamente publicados na Internet,
o que permite análise sobre a força dos algoritmos por multidões de
especialistas.
Neste momento não existem testes para determinar a segurança
oferecida por diferentes protocolos, o que torna difícil, senão impossível de
medir. Assim, todos os comentários preconcebidos sobre este tema seriam
inconclusivos. No entanto, temos avaliado protocolos padrão, como SSH,
SSL/TLS e IPSec como mais seguro do que os protocolos não
padronizados. Determinando a força relativa da segurança oferecida pelos
SVBLCAs pertencentes ao mesmo grupo, está fora do âmbito deste artigo.
Escalabilidade - Clercq e Paridaens [20] analisaram a
escalabilidade do fornecedor de VPNs provisionadas em termos de
consumo de memória, poder de processamento e, configuração e
gerenciamento de carga. Foram usadas linhas semelhantes de raciocínio
para resolver problemas de escalabilidade neste trabalho. O consumo de
memória e poder de processamento, principalmente em função do número
de túneis estabelecidos. Cada túnel requer certo estado (chaves de sessão,
certidões, informações de roteamento, etc) para ser mantido em cada
extremidade. O tamanho máximo desse estado determina o consumo de
memória com N túneis consumindo N vezes a memória disponível.
O poder de processamento, por outro lado, é afetado pela natureza
de computação intensiva de funções criptográficas. Com maior número de
túneis, a fatia de tempo da CPU alocado para cada túnel é reduzida pela
mesma fração. Por fim, a configuração e o gerenciamento de carga podem
ser quantificados pelo total de esforços necessários para edição de arquivos
de configuração, atualização de informações de roteamento e distribuição
de chaves de segurança quando novos túneis são adicionados ou excluídos.
O consumo de memória e poder de processamento limitam a
escalabilidade de um único nó SVBLCA, este problema pode ser
parcialmente eliminado usando desktops poderosos, com maior memória
principal ou maior poder de processamento. Desde que SVBLCAs são
direcionados principalmente para as empresas de pequeno porte
(geralmente constituídos por 10-50 locais de rede), esses fatores não
desempenham um papel significativo e têm sido negligenciados neste
trabalho. Este trabalho foi concentrado no último fator, que afeta a
escalabilidade do sistema inteiro.

3.6 O Banco de Ensaio Experimental [20]
O banco de ensaio utilizado nos ensaios é constituído por dois
roteadores SVBLCA (SVBLCA A e B) e cria um túnel seguro entre duas
redes privadas (RP-1, RP-2) situados no mesmo edifício. SVBLCA A
contém um processador Intel Pentium 4 de 2.0 GHz, com 512 Mbytes de
memória RAM e rodando Ubuntu 12.04. SVBLCA B é um desktop com
características ultrapassadas, com um processador de 400 MHz Pentium II,
com 128 Mbytes de memória RAM e funcionando Ubuntu 12.04. PC-1 (em
RP-1) e PC-2 (no RP-2) são computadores Linux, que são usados para
conduzir experiências de desempenho da rede. O banco de ensaio é isolado
(sem congestionamento externo) e todas as conexões usam interfaces de
rede com característica 100Mb/s Fast Ethernet.
A sobrecarga foi avaliada, primeiramente através da análise da
solução SVBLCA e, posteriormente, verificando-lo, através da captura de
pacotes UDP de tamanho conhecido. Estes pacotes foram gerados usando
um programa gerador UDP simples, e capturados usando um utilitário de
“espionagem” de pacotes como o Ethereal. Largura de banda e instabilidade
foram medidas utilizando Iperf, enquanto Ping foi utilizado para medir a
latência. Cada experiência foi repetida 10 vezes em ambas as direções, e só
a média foi avaliada. Como não havia cifra/MAC comum que poderia ser
usada com todos os SVBLCA s, foram realizados experimentos usando um
dos {Blowfish, 3DES ou nenhum} para cifras e {SHA1, MD5 ou nenhuma}
para MAC. Compressão foi desativada em todos os níveis.
Foi agrupado as soluções SVBLCA selecionadas com base no
protocolo de segurança utilizado na figura 3, uma vez que VPNs usando o
mesmo protocolo de segurança pode ser esperado que suas performances
sejam quase semelhantes. Por conseguinte, temos VPN baseado em SSH,
SSL/TLS, IPsec e outros protocolos proprietários, como mostrado na figura
a seguir. Todos os SVBLCAs na metade superior da figura usam canais
TCP, enquanto aqueles inferiores à linha usam UDP.
SSH, padronizado pelo grupo de trabalho Secsh do IETF, fornece
suporte para logins seguros e transferências seguras de arquivos. PPP sobre
SSH é a única solução VPN que utiliza SSH. Ambos PPP e SSH são
protocolos maduros de uso generalizado, e uma VPN simples pode ser
configurada usando um único comando [21].
SSL/TLS, padronizado pelo grupo de trabalho TLS, foi
inicialmente desenvolvido pela Netscape, para fornecer transações seguras
da Web (versões 1 e 2), mas ao longo dos últimos anos, este protocolo
evoluiu para uma solução padrão para comunicações seguras

(SSLv3/TLSv1). Stunnel, AmritaVPN e LinVPN são os SVBLCAs que
utilizam SSL/TLS, com Stunnel e AmritaVPN usando SSLv3/TLSv1 e
LinVPN usando SSLv2.
Figura 4 - Agrupamento de VPN por protocolo de segurança [23].
IP Secure (IPSec) estende a segurança no nível de rede. No entanto,
IPSec também suporta um mecanismo de encapsulamento que pode ser
utilizado para fornecer serviços de VPN. FreeS/WAN é uma
implementação baseada em Linux do protocolo IPSec. Ele consiste de dois
componentes; KLIPS e PLUTO. O primeiro oferece serviços de criptografia
de pacotes IP e é construído como um módulo do kernel, enquanto o último
é um programa em nível de aplicativo utilizado para a negociação de chaves
de sessão, posteriormente, utilizados por KLIPS.
Os SVBLCAs restantes usam seus próprios protocolos
proprietários para proporcionar segurança. Este grupo foi dividido entre
aqueles que utilizam funções criptográficas padrão exportados pelo
OpenSSL (Proprietary/OpenSSL) e aqueles que usam suas próprias
implementações proprietárias (Proprietary). OpenVPN, VTUN, Tinc e
Yavipin pertencem ao primeiro grupo, enquanto o segundo grupo contém
Cipe, PPTP, Vpnd, Htun e L2tpd. Enquanto Vtun pode ser usado com duas
VNIs diferentes (tun/tap driver e pseudo-terminais), consideramos estes
dois organismos como SVBLCAs separados, sendo o primeiro designado
como Vtun e o segundo como VTUN_PPP.
A tabela abaixo fornece detalhes adicionais sobre cada SVBLCA
incluindo links para as receitas passo-a-passo para configurar uma VPN. A

última coluna quantifica a nossa experiência com a complexidade de
configuração (um menor número de asteriscos implica em configuração
simplificada) avaliada com base em critérios comuns que envolvem a
instalação, configuração e suporte.
Tabela 3 - Tecnologias VPN [23].
Ver-
são
Pa-
drão
de
Inter-
nete
Compre-
ssão
Criptografia
Website
oficial
Nota
confi-
guração
PPP sobre
SSH
-- Sim
ppp-ccp,
gzip
SSH, bf-
cbc/md5
http://w
ww.buil
dinglin
uxvpns.
net/sour
cecode/
*****
Stunnel 4.04 Não ppp-ccp
OpenSSL,
3Des/Sha1
http://w
ww.stu
nnel.or
g/
***
AmritaVP
N
0.96 Não Nenhum
Sem
especificação
http://ai
tf.amrit
a.edu/
***
LinVPN 2.6 Não ppp-ccp
Sem
especificação
http://m
rtg.plan
etmirro
r.com/p
ub/linv
pn/
*******
Vpnd 1.1 Não
Disponíve
is com
bugs
Bf-cbc / (md5
| sha1 |
ripemd160)
http://s
unsite.d
k/vpnd/
***
Htun 0.9.5 Não Nenhum Nenhum
http://h
tun.run
slinux.n
et/
*****
Cipe 1.5.4 Não Nenum
(bf-cbc |
Idea)
http://si
tes.inka
.de/sites
/bigred/
devel/ci
pe.html
**
PPTP 1.2.0 Sim ppp-ccp MPPE
http://p
ptpclien
t.source
****

forge.ne
t/
L2TPD 0.69 Sim ppp-ccp Nenhum
http://w
ww.l2tp
d.org/
***
OpenVPN 1.4.2 Não lzo
OpenSSL,
bf-cbc/md5
http://o
penvpn.
sourcef
orge.net
/
**
VTUN 2.6 Não zlib, lzo bf-cbc/md5
http://vt
un.sour
ceforge.
net/
***
VTUN_P
PP
2.6 Não
ppp-ccp,
zlib, lzo
bf-cbc/md5
http://vt
un.sour
ceforge.
net/
****
Tinc -- Não zlib, lzo
OpenSSL, bf-
cbc/md5
http://ti
nc.nl.lin
ux.org/
***
Yavipin 0.9.5 Não zlib
(bf-cdc | des-
cbc)/md5
http://y
avipin.s
ourcefo
rge.net/
*****
FreeS/Wa
n
2.01 Sim Sim 3des-cbc
http://w
ww.free
swan.or
g/
******
3.7 Resultados da Avaliação de Desempenho
Nesta seção apresentamos os resultados experimentais, baseados
nos trabalhos de Pena e Evans [15]; nos trabalhos de Clercq e Paridaens
[20] e nos trabalhos de Khanvilkar e Khokhar [23] para os SVBLCAs
selecionados e seus desempenhos com base em métricas descritas
anteriormente.

3.7.1 O desempenho da rede
Tabela 4 - Desempenho de Sobrecarga Normalizada [23].
GRP_TCP GRP_UDP
Sobrecarga Normalizada
O desempenho de sobrecarga normalizada para 80 bytes/pacote,
que também foi a menor sobrecarga computada por qualquer solução
SVBLCA.
Entre eles, encontram-se a maioria dos SVBLCAs no grupo de
segurança proprietária (exceto Vpnd e Htun) para apresentar relativamente
menor sobrecarga (overhead) do que outros, tornando-os relativamente
adequados para aplicações que geram tamanhos de pacotes menores (por
exemplo: Telnet e Login Remoto). No geral, SVBLCAs que utilizam canais
de dados baseados em UDP (GRP_UDP) possuem 50 por cento menos
sobrecarga do que aqueles que utilizam canais de dados baseados em TCP
(GRP_TCP).
Diferenças menores entre os diferentes membros do mesmo grupo
são principalmente devido a diferentes formatos de embalagem e
preenchimento aleatório anexado aos pacotes. Daí em diante, Htun foi
deixado de fora de todos os cálculos de desempenho, uma vez que
demonstrou que o desempenho da rede foi muito menor do que o caso
médio. Isto é em parte devido à natureza dualista de seu protocolo de
comunicação.

Tabela 5 - Desempenho de Utilização de Largura de Banda [23].
GRP_TCP GRP_UDP
Utilização de Banda (%)
No gráfico de largura de banda, os números no topo de cada barra
indicam o intervalo de confiança de 95 por cento. Novamente, todas as
SVBLCAs foram encontradas para executar no pior caso, com o melhor
deles (Cipe) utilizando menos do que 50 por cento da largura de banda.
Aqui, o cálculo da média acumulada, encontramos GRP_UDP para ser pelo
menos 80 por cento melhor do que GRP_TCP.
A normalização é realizada em relação às latências totais (e
instabilidade) observadas entre cada salto da rede, quando a VPN não está
em uso. Na FreeS/WAN se observa as menores características de latência e
instabilidade, tornando-a adequada para aplicações em tempo real, como
voz e vídeo. Acreditamos que menor latência/instabilidade em FreeS/WAN
ocorre devido ao fato dele ser integrado no kernel do Linux. Aqui,
GRP_UDP mostra uma melhora de 40-60 por cento em relação GRP_TCP.

Tabela 6 - Desempenho, Instabilidade Normalizada [23].
GRP_TCP GRP_UDP
Instabilidade Normalizada
Tabela 7 - Desempenho, Latência Normalizada [23].
GRP_TCP GRP_UDP
Latência Normalizada

A partir dos resultados acima, é difícil julgar qual SVBLCA tem o
melhor desempenho geral. No entanto, uma heurística simples pode ser
aplicada para seleccionar uma solução ótima. Por exemplo, ao classificar os
SVBLCAs para cada atributo e atribuindo peso proporcional à importância
de cada atributo, pode-se determinar a classificação média ponderada.
Assim, quando todos os atributos são igualmente importantes, VTun, PPTP
e FreeS/WAN (possuem desempenho médio quase igual) são os melhores.
Por meio da variação dos pesos, o SVBLCA ótimo para qualquer ambiente
pode ser facilmente determinado. No entanto, este método requer que o
desempenho de rede para cada SVBLCA seja previamente determinado.
3.7.2 Características/funcionalidades suportadas
Anteriormente, discutimos diferentes características e funções que
um SVBLCA deve fornecer. Aqui, vamos avaliá-los com base nos recursos
que são suportados atualmente. Se um determinado recurso está ausente,
nós também comentaremos o quão simples (ou complexo) é integrá-lo no
código do SVBLCA atual.
A modularidade do código - Nenhuma das soluções SVBLCA
apoia fortemente algoritmos de plugins como definido anteriormente. Por
isso, a definição é “relaxada” e o nível de dificuldade com que novos
algoritmos de cifragem podem ser usados com uma solução SVBLCA
também foi avaliado. Apesar de considerar este aspecto, avaliou-se também
o estilo geral de codificação para determinar as funções de criptografia
usadas internamente. Assim, dividimos os níveis de dificuldade em baixa,
média e alta, conforme detalhado abaixo.
Baixa - Este é o caso quando o SVBLCA usa bibliotecas padrão de
terceiros, como OpenSSL, para implementar seus protocolos de segurança.
OpenSSL possui uma interface genérica de programação de aplicativos
chamada, EVP API, que fornece um acesso padrão para todas as suas cifras.
Assim, sempre que algoritmos mais recentes são inventados e integrados ao
OpenSSL, podem ser utilizado imediatamente sem recompilar o código
SVBLCA.
Médio - O nível de dificuldade é considerado médio quando novos
algoritmos precisam ser inseridos manualmente no código SVBLCA. Por
exemplo, Cipe e Vpnd usam suas próprias implementações de criptografia
proprietários. Assim, os algoritmos mais recentes podem ser usados apenas
se forem integrados com o código. Esta categoria também inclui aqueles

SVBLCAs que usam API de criptografia OpenSSL diretamente em vez do
mais genérico EVP API.
Alto - Isto significa algoritmos mais recentes só podem ser
utilizados se modificações substanciais forem feitas no código fonte. Isso
ocorre se o SVBLCA originalmente não apoia quaisquer métodos de
criptografia. Assim, para utilizar algoritmos mais recentes um teria que
começar do zero. A exceção aqui é FreeS/WAN, incluído aqui porque o
código fonte parecia muito grande e complicado para localizar onde ele
precisa ser modificado.
Roteamento – A tabela abaixo apresenta a avaliação dos
mecanismos de roteamento suportados pelos SVBLCAs atuais, mais uma
vez quantificados em:
Manual: rotas diretas devem ser estabelecidas manualmente,
usando o comando “rotear” ou scripts embutidos no shell.
Automático (para VPNs de domínio único): O daemon de
roteamento é parte da solução SVBLCA, que lida com VPNs de domínio
único. Tinc é a única solução que emprega este tipo de roteamento, embora
ainda crie uma rede em grafo completo. No entanto, o administrador tem
que configurar apenas um único local quando um novo local é adicionado,
o que torna a solução extremamente escalável.
Automático (para vários domínios VPNs): Este emprega
roteamento virtual que cria uma instância de roteamento separado para cada
domínio VPN. Infelizmente, neste momento, nenhum dos SVBLCAs
suporta esta opção.
3.7.3 Preocupações Operacionais
Segurança - Como discutido anteriormente, a segurança de um
SVBLCA não pode ser medida. No entanto, muitas situações podem ser
imaginadas, onde a segurança forte não é um requisito, e as pessoas podem
apenas se contentar com os protocolos mais fracos. Assim, temos avaliado a
nossa confiança na segurança como:
Os padrões abertos: Inclui todas as soluções SVBLCA que usam
protocolos de segurança padronizados, tais como SSH, SSL/TLS e IPSec.
Estes protocolos foram considerados como implicitamente seguro porque
eles já foram submetidos à revisão por pares exaustiva. Além disso, falhas
de segurança, se houverem, são amplamente divulgadas através da Internet
com atualizações quase imediatas. PPP sobre SSH, AmritaVPN, Stunnel,
Lin-VPN, e FreeS/WAN caem nesta categoria.

Proprietário: Inclui soluções SVBLCA que são baseados em
protocolos de segurança proprietários com classificação inferior a padrões
abertos. Foi analizado a segurança oferecida por estes protocolos em termos
de apoio para as propriedades básicas, incluindo a confidencialidade,
integridade de dados, autenticação/não repúdio e proteção antirepetição.
Novamente, enfatizamos que todas estas propriedades não significam
necessariamente que o protocolo é seguro, e uma análise mais exaustiva
claramente precisa ser feita. OpenVPN e Tinc são as únicas soluções que
suportam todas as quatro propriedades.
Escalabilidade - Para comparar escalabilidade das soluções
SVBLCA, assumiu-se um grafo VPN total entre N nós e foi analizado o
esforço total necessário para atualizar os arquivos de configuração, edição
de informações de roteamento e distribuição de chaves de segurança,
quando túneis são adicionados/excluídos.
Para um grafo completo, tudo se resume à criação de (N-1) túneis
adicionais. Uma vez que a infraestrutura de gerenciamento central está
ausente, os arquivos de configuração para todos os sites de N podem
precisar ser atualizados com informações de acessibilidade. Da mesma
forma, já que a maioria SVBLCAs não tem um daemon de roteamento
integrado, informações de roteamento podem precisar ser atualizadas
manualmente em cada local.
Finalmente, para a distribuição de chaves de segurança, se a
solução SVBLCA utiliza a chave secreta ou criptografia de chave pública,
sem uma infraestrutura de chave pública, a chave secreta compartilhada
precisa ser distribuída manualmente para N-1 pares. Por outro lado, se a
tecnologia utiliza o certificado digital, apenas o local recentemente
adicionado terá de adquirir um certificado assinado.
Abaixo é fornecido mais detalhes sobre o número de tarefas que
precisam ser executadas para cada SVBLCA. Por exemplo, em PPP sobre
SSH apenas um arquivo de configuração (~/.ssh/config no N-ésimo nó)
precisa ser atualizado, 2 (N-1) rotas precisam ser adicionados (em ambas as
extremidades), e a chave pública do novo nó precisa ser distribuída a seus
pares (para o login sem senha). Total de esforço pode ser calculado
somando-se todas as tarefas e multiplicando-se por N (uma vez que este
tem de ser repetido N vezes para uma VPN de N-nodos). Atribuindo
unidade de esforço para cada tarefa, a última coluna dá uma boa estimativa
da escalabilidade.
Observe que cada solução não é escalável com um total de esforço
O (N²) variado. No entanto, para N pequenos (digamos N=10), pode-se ver

a diferença drástica na quantidade de trabalho necessária (indicado por
números entre colchetes na última coluna). Aqui, Tinc comprova ser a
solução SVBLCA mais escalável.
Tabela 8 - Complexidade de inserir algoritmos proprietários de criptografia
[23].
Solução
SVBLCA
Considerações
Baixo
Stunnel,
Amrita,
LinVPN
Utiliza implementação OpenSSL do SSL/TLS.
Novo algoritmos podem ser utilizados
prontamente, sem quaisquer mundanças no
código fonte.
OpenVPN,
Tinc
OpenSSL EVP API é usado para acessar
diferentes cifras/MACs.
Médio
PPP sobre
SSH
A implementação OpenSSH do SSH usa uma
quantidade fixa de cifras que utilizam o
OpenSSL EVP API. Para usar novas cifras, o
código do OpenSSH deve ser modificado.
Cipe, Vpnd
Utiliza a cifra proprietária Blowfish. No entanto,
novos algoritmos devem ser explicitamente
adicionados no código fonte.
Yavipin,
VTUN,
VTUN_PPP
Utiliza as funções criptográficas do OpenSSL
para algumas cifras seleciondas. Para usar novos
algoritmos, o código fonte deverá ser modificado.
Alto
FreeS/WAN
Utiliza Eric Young’s DES. É difícil localizar onde
devem ser feitas as modificações.
PPTP Utiliza somente a criptografia P2P da Microsoft.
L2TPD, Htun Não utiliza criptografia.
Tabela 9 - Suporte de roteamento embutido [23].
Roteamento Solução SVBLCA Considerações
Manual
PPP sobre SSH,
Stunnel, L2TPD,
Htun
Comando explícitos de
roteamento são utilizados.
OpenVPN, LinVPN,
Yavipin, VTUN,
VTUN_PPP,
PPPTPD
Quando o link de VPN é
estabelecido, o roteamento é
configurado por scripts de shell.
Cipe, AmritaVPN,
FreeS/WAN, Vpnd
Informações de roteamento estão
inclusos no arquivo conf.
Automático,
VPNs de
domínio único.
Tinc
Suporta Daemon de roteamento
embutido que estabelece uma
rede de grafo completo.

Tabela 10 - Segurança das VPNs [23].
Confiden-
cialidade
Integridade
dos Dados
Autenticação/N
ão repúdio
Anti-
Replay
Vpnd Sim Sim Sim Não
Htun Não Não Não Não
Cipe Sim Sim Não Não
PPTP Sim Sim Não Sim
L2TPD Não Não Não Sim
OpenVPN Sim Sim Sim Sim
VTUN Sim Não Não Não
VTUN_PPP Sim Não Não Não
Tinc Sim Sim Sim Sim
Yavipin Sim Sim Não Sim
3.8 Funcionamento VPNs usando protocolo UDP.
Nas análises de desempenho das VPNs que utilizam o protocolo de
comunicação UDP, foi explicitado que sua utilização implica em menos
largura de banda, menor instabilidade, menor latência e menor sobrecarga.
No entanto existem diversas preocupações referentes à sua
aplicação direta, como perda de pacotes e desordenação de pacotes.
Nas soluções mais atuais é utilizado o conjunto de protocolos
SSL/TLS para configurar uma conexão VPN, o que resulta em transporte
confiável. O protocolo Transport Layer Security (TLS), cujo seu
predecessor é o protocolo Secure Sockets Layer (SSL), são protocolos
criptográficos que foram projetados para fornecer comunicação de
segurança sobre a Internete.
Portanto os pacotes UDP são encapsulados para transporte via
SSL/TLS, que resulta em transporte confiável. Porém ainda podem ocorrer,
mesmo que significativamente menos, a perda de pacotes ou a
desordenação dos mesmos. Para isto cada tecnologia utiliza algoritmos
próprios para corrigir estes problemas, ou seja, um algoritmo para
recuperação de pacotes e outro algoritmo para ordenação dos pacotes.
Ainda há tecnologias que utilizam o protocolo DTLS (Datagram
Transport Layer Security – RFC4347). O protocolo DTLS fornece
comunicação privativa para protocolos “Datagram”. O protocolo permite a
comunicação de aplicativos cliente/servidor de uma forma mais eficiente,
evitando espionagem, adulteração ou falsificação de mensagens. Ele é

Servidor de rede com OpenVPN e Shorewall

Servidor de rede com OpenVPN e Shorewall

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Servidor de rede com OpenVPN e Shorewall

Semelhante a Servidor de rede com OpenVPN e Shorewall (20)

Mais de SoftD Abreu

Mais de SoftD Abreu (20)

Servidor de rede com OpenVPN e Shorewall