Embed Size (px)
Citation preview
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.3 Vantagens e Desvantagens ............................................ 19 2.4.4 Onde estão os firewalls de inspeção dinâmica?............. 20
2.5 APLICAÇÕES PROXY FIREWALLS ................................................... 20 2.5.1 Vantagens e Desvantagens ............................................ 21 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.
2.4.3 Vantagens e Desvantagens
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.
2.5.1 Vantagens e Desvantagens
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 é
baseado no Transport Layer Security (TLS) e fornece garantia de segurança
equivalente.
3.8.1 SSL/TLS sobre UDP no OpenVPN.
Como o OpenVPN foi a solução escolhida para implementação da
tecnologia de VPN neste trabalho, detalharemos neste capítulo como
funciona o protocolo de comunicação SSL/TLS sobre UDP.
Camadas de transporte confiável em geral não são ideais, como no
caso do IPSec, por causa do mau desempenho e as situações que podem
piorar ainda mais a conexão, como multicamada de “time-out” e
mecanismos de retransmissão necessários pelo TCP.
Quando usando o conjunto de protocolos SSL/TLS para configurar
uma VPN, o primeiro desafio é mudar a camada de transporte confiável
nativa do protocolo SSL/TLS para o UDP sem conexão sob SSL/TLS.
Assim como os truques do protocolo DTLS, o OpenVPN usou um
técnicas semelhantes. O qual define o canal de controle, cujas
características são equivalentes à camada de transporte confiável do IPSec,
que são necessárias para a troca de parâmetros iniciais e autenticação de
identidades; e define também outro canal, o canal de dados, um túnel UDP
sem conexão para transportar dados da VPN. Enquanto o IPSec utiliza duas
conexões, uma para negociação IKE e outra para comunicação de dados;
OpenVPN simplesmente possui os canais de controle e dados dentro de
uma sessão baseada em UDP.
Canal de Controle
O canal de controle age tanto na fase incial, com a negociação
incial (handshake) do SSL/TLS (incluindo início de sessão, troca de chaves,
acordo de conjunto de cifras, autenticação de identidades, etc.), quanto na
fase final da conexão, onde algumas limpezas e ajustes são necessários.
Por causa da camada de transporte orientada a conexão necessária
pelo protocolo de início de sessão do SSL/TLS, o canal de controle deve
compensar pela desvantagem do transporte UDP não confiável,
introduzindo um simples reconhecedor de pacotes, tempo de espera e um mecanismo de retransmissão.
Existem dois tipos de mensagens no canal de controle do
OpenVPN; a mensagem do tipo P_CONTROL, que é um jeito de
implementar um pacote de cifras TLS necessário para ser encapsulado
dentro de uma camada de confiabilidade; e a camada de confiabilide, esta é
implementada com um reconhecimento (ACK) de modelo simples e a
função de restransmissão implementada através da mensagem de tipo
P_ACK.
Canal de Dados
O canal de dados, criado após o início de sessão SSL/TLS, é um
túnel UDP sem conexão, onde não há retransmissão e não há mecanismo de
reconhecimento. O tipo de mensagem P_DATA representa dados
criptografados, pacotes de túnel encapsulados, que tendem a ser tanto
pacotes IP quanto quadros Ethernet, que são essencialmente o conteúdo da
VPN.
3.9 Conclusões sobre VPNs e Trabalhos Futuros
Neste artigo, nós avaliamos 15 SVBLCAs populares em termos de
desempenho de rede, características e funcionalidades, e suas preocupações
operacionais.
O desempenho relativamente fraco de SVBLCAs em quase todos
os atributos considerados abre novas oportunidades para pesquisas. Uma
dessas áreas é a melhoria do desempenho da rede. O grande gargalo para
desempenhos pobres de rede foi descoberto ser de natureza da computação
intensiva de criptografia, autenticação e funções de compressão (chamadas
de funções de VPN) cuidadosamente aplicadas a todos os pacotes enviados
através da VPN. Uma vez que estas funções e os respectivos algoritmos são
negociados durante a inicialização do túnel, que permanece estática durante
toda a vida do túnel e não pode ser alterada sem o repor. No entanto, esse
comportamento pode ser redundante para fluxos de tráfego que já estão
criptografados ou compactados. Muitas aplicações podem também requerer
apenas um subconjunto de tais funções para ser aplicado às suas
transmissões, por exemplo, as chamadas de voz através de IP podem
precisar de encriptação e autenticação, mas o podem fazer, sem
compressão. Enquanto alguns podem precisar de criptografia forte, outros
podem se contentar com os protocolos mais fracos, que são mais rápidos e
não possuem computação tão intensiva.
Experimentos revelam que VPNs que usam canais de dados
baseados em UDP são muito melhores do que aqueles que utilisam TCP.
Nenhumas das soluções atuais de SVBLCAs são flexíveis o suficiente para
aplicar a funcionalidade específica do aplicativo - arquiteturas mais
recentes terão de ser concebidas - que possam permitir funções de VPN
serem aplicadas em nível do pacote. Neste sentido, estamos propõe-se uma
arquitetura de VPN de última geração, que forneça uma implementação de
túnel flexível, onde dentro de um único túnel VPN, diferentes funções de
VPN possam ser aplicadas a diferentes aplicações, oferecendo assim, um
tratamento diferenciado e personalizado. Ainda, esta aplicação deve
permitir que hosts finais especificassem o tipo de tratamento que eles
esperam para os seus fluxos de tráfego, ou ainda, ela própria tomar parte
ativa na aplicação das funções de tunelamento.
Os resultados apresentados neste trabalho também podem ajudar os
usuários finais a selecionar uma solução SVBLCA, que melhor se adapte às
suas necessidades específicas. O algoritmo heurístico simples discutido na
seção de resultados pode ser estendido para aceitar as necessidades dos
utilizadores ponderados e produzir uma lista ordenada das melhores
soluções.
Como resultado, um usuário doméstico interessado em largura de
banda máxima pode se contentar com Cipe ou Vtun, enquanto um
administrador de rede que está mais interessado em segurança, pode se
contentar com IPSec. Este método, no entanto, exige que o desempenho de
cada SVBLCA deve ser predeterminada. Estes resultados não estão
prontamente disponíveis através da Internet, e este trabalho ajuda a
preencher esta lacuna.
4 Desenvolvimento:
4.1 Sistema Operacional
Para implementar o servidor, foi instalado como sistema
operacional principal, o Ubuntu Server LTS 12.04.3 x64 (de código livre e
amplamente utilizado por instituições de ensino, pesquisa e
desenvolvimento, usuários domésticos e empresas corporativas), com suas
configurações no modo padrão, com serviço SSH ativado.
O servidor possui duas interfaces de rede. A placa de rede eth0 será
utilizada para se conectar a rede externa (até o modem ADSL, ou seja, até a
internete). A placa de rede eth1 será utilizada para se conectar a rede interna
(LAN). A primeira placa de rede foi configuradas para ter IP dinâmico
(baseado nas definições do modem ADSL e do provedor de serviço de
internete, que neste caso não necessitam de autenticação PPoE ou similar),
enquanto a segunda para ter IP estático, cujo é ideal para controlar
conexões.
4.2 Configurando as interfaces de rede e serviço DHCP
Nota: Nos textos de ajuda do Nano (editor de texto para terminal
de comando), a tecla “Ctrl” é representada por um chapéu (^), portanto
“Ctrl+W” é visto como “^W”, e assim em diante. A tecla “Alt” é
representada por um M (de "Meta"), portanto “Alt+W” é visto como “M-
W”. Se for necessário instalar o aplicativo utilize o seguinte comando:
“$sudo apt-get install nano”
Precisamos efetuar mudanças para deixar o servidor com IP
estático para a rede local “eth1”. Enquanto que para a interface “eth0”
deve-se deixar obter o IP dinâmico. Então, para configurarmos as interfaces
de rede, é necessário alterar o arquivo de interfaces em
“/etc/network/interfaces” como mostrado abaixo:
auto lo
iface lo inet loopback
auto eth0
iface eth0inet dhcp
auto eth1
iface eth1inet static
address 190.170.50.1
netmask 255.255.255.0
4.3 Configurando o servidor como Roteador DHCP/Gateway de
duas interfaces
Figura 5 - Arquitetura da Rede Local
É necessário instalar o serviço de roteador DHCP e DNS no
servidor, para isto, basta instalar os seguintes programas, com o comando:
Nota: Sempre que iniciar o sistema, digite o comando “$sudo apt-get update” para ter certeza de que a última versão dos aplicativos seja
instalada.
$sudo apt-get install isc-dhcp-server bind9
Após instalados, por haver mais de uma interface de rede, é
necessário configurar o serviço DHCP para responder as requisições de IP
da interface eth1. Para isso foi alterado a última linha do arquivo
“/etc/default/isc-dhcp-server”.
# Defaults for isc-dhcp-server initscript
# sourced by /etc/init.d/isc-dhcp-server
# installed at /etc/default/isc-dhcp-server by the maintainer scripts
#
# This is a POSIX shell fragment
#
# Path to dhcpd's config file (default: /etc/dhcp/dhcpd.conf).
#DHCPD_CONF=/etc/dhcp/dhcpd.conf
# Path to dhcpd's PID file (default: /var/run/dhcpd.pid).
#DHCPD_PID=/var/run/dhcpd.pid
# Additional options to start dhcpd with.
# Don't use options -cf or -pf here; use DHCPD_CONF/
DHCPD_PID instead
#OPTIONS=""
# On what interfaces should the DHCP server (dhcpd) serve DHCP
requests?
# Separate multiple interfaces with spaces, e.g. "eth0 eth1".
INTERFACES="eth1"
Precisamos agora mudar as configurações padrão do serviço DHCP
com os dados da rede a ser implantada. Neste caso o endereço da rede é
192.168.0.0. Para isto é recomendado apagar todo o conteúdo do arquivo,
mas antes faça uma cópia de segurança com o comando:
$sudo mv /etc/dhcp/dhcpd.conf /etc/dhcp/dhcpd.conf.bkp
Apague o conteúdo do arquivo anterior e insira o seguinte conteúdo
com o comando “$sudo nano /etc/dhcp/dhcpd.conf”:
ddns-update-style none;
default-lease-time 600;
max-lease-time 7200;
authoritative;
log-facility local7;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168. 0.255;
option routers 192.168. 0.1;
option domain-name-servers 192.168. 0.1;
option domain-name "servidor-vpn-firewall.secto.fln";
subnet 192.168. 0.0 netmask 255.255.255.0 {
range 192.168. 0.100 192.168. 0.200;
}
No arquivo acima, observe os dados de IPs relativos à configuração
de rede deste trabalho. Observe também, que o espaço de endereçamento destinado ao DHCP, é do intervalo final 100 ao 200 do IP da rede. Para
prosseguir com a instalação, reinicie o serviço DHCP com o seguinte
comando:
$sudo service isc-dhcp-server restart
Para permitir o encaminhamento de pacotes entre endereços IP,
basta retirar o símbolo de comentário “#” da seguinte instrução
“net.ipv4.ip_forward=1” no arquivo “/etc/sysctl.conf”. Abaixo mostramos a
parte relevante do arquivo alterada:
…
# Uncomment the next line to enable TCP/IP SYN cookies
# See http://lwn.net/Articles/277146/
# Note: This may impact IPv6 TCP sessions too
#net.ipv4.tcp_syncookies=1
# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1
…
Se você desejar renovar o endereço IP da interface WAN, digite o
comando abaixo:
$sudo dhclient –r && sudo dhclient
4.4 Instalando interface gráfica no servidor
A versão do Ubuntu para servidores não acompanha interface
gráfica, a interface mais utilizada no Ubuntu, o Gnome, é uma interface
sofisticada, porém “pesada”, utilizando muito processamento que poderia
ser disponibilizado para outras tarefas. Para melhorar a experiência do
administrador, foi instalado a interface gráfica XFCE versão 4, também de
código livre, de fácil instalação e mais leve que a interface Gnome, com
tamanho de 230MB na versão 4. A interface será utilizada apenas na
conexão de área de trabalho remota.
Suas principais facilidades é permitir a utilização de navegadores
web, acessar/montar dispositivos de memória externa (HDs, pendrives,
CDs, etc.), utilizar editores de texto no modo gráfico e gerenciar arquivos e
pastas por janelas. Além de possibilitar a instalação e execução de
gerenciadores gráficos para diversos serviços de administração e
gerenciamento de rede, banco de dados, entre outros. Segue comando para
instalar o XFCE, se houver necessidade:
$sudo apt-get install xfce4
Para acessar a interface gráfica do servidor pela conexão de área de
trabalho remota do Windows, utilize o programa XRDP. No terminal de
comando do Ubuntu, utilizamos os seguintes passos para instalar o XRDP
com o XFCE.
$ sudo apt-get install xrdp
$ sudo echo xfce4-session >~/.xsession
$ sudo chmod +x ~/.xsession
$ sudo service xrdp restart
Para acessar o servidor de um computador com sistema operacional
Windows, abra o software “Conexão da Área de Trabalho Remota”,
disponível no Painel de Controle. Nele coloque o IP do servidor, neste caso
192.168.0.1. Aceite as notificações de segurança.
Figura 6 - Conexão da Área de trabalho Remota Windows
Insira o usuário e senha:
Figura 7 - Login do XRDP
Espere conectar:
Figura 8 - Log de Conexão XRDP
Figura 9 - Acesso Remoto com Interface Gráfica ao Servidor.
Se desejar, você ainda pode baixar o navegador “chromium”
(Google Chrome para Linux), o editor de texto “gedit” e o navegador de
pastas “nautilus” com os seguintes comandos:
$sudo apt-get install chromium-browser gedit nautilus
4.5 Instalando o Webadmin
O Webadmin é uma ferramenta, acessada via navegador web, para
auxiliar o administrador a configurar todos os serviços de rede instalados no
servidor (para fins específicos deste trabalho, apenas utilizaremos esta
ferramenta para configurar o NAT pela primeira vez, portanto toda a
configuração do programa de firewall Shorewall pode ser feita através deste
programa, neste trabalho utilizaremos somente linha de comando para ser
mais claro e objetivo). Para instalar os pré-requisitos do software execute o
seguinte comando:
$sudo apt-get install perl libnet-ssleay-perl openssl libauthen-pam-
perl libpam-runtime libio-pty-perl apt-show-versions python
Para baixar o aplicativo para o servidor, execute o comando:
$wget
http://sourceforge.net/projects/webadmin/files/webmin/1.660/webmin
_1.660_all.deb
Para instalar o pacote baixado execute o commando:
$sudo dpkg –install webmin_1.660_all.deb
O Webadmin encontra-se instalado e pode ser acessado pelo
navegador de qualquer máquina conectada a rede local no endereço:
https://”ip-servidor”:10000/ - No caso deste trabalho, o endereço
utilizado é: https://192.168.0.1:10000/ - Se for apresentado um aviso de
segurança, apenas aceite e prossiga.
Entre com seu usuário e senha da conta de administrador do
Ubuntu.
Figura 10 - Acesso ao Webadmin
4.5.1 Pré-configurando o serviço de Firewall
1. Efetue o acesso no seu Webadmin. Para um gerenciamento
mais fácil e prático.
2. Acesse no menu da esquerda a entrada “Networking” e
então “Linux Firewall”.
3. Selecione o campo “Do network address translation on
external interface:” e selecione a interface “NET”. Esta
função é necessária para habilitar o “Masquarade(NAT)”.
4. Marque a caixa de seleção “Enable firewall at boot time?”
no fundo da página. Para habilitar o firewall na
inicialização do Ubuntu.
5. Para seguir, clique no botão “Setup Firewall”.
Figura 11 - Primeiros Passos Webadmin.
6. Para finalizar, apenas clique no botão “Apply
Configuration”.
Figura 12 - Aplicando Configurações Webadmin.
7. Se desejar obter uma melhor experiência de usuário e usá-
lo em português do Brasil, vá no menu “Webmin”, então
em “Change Language and Theme”. Para “Webmin UI
language” selecione “Personal choice ..” e escolha
“Portuguese (Brazilian) (PT_BR.UTF-8). Em “Webmin UI
theme” selecione “Personal choice ..” e escolha
“MSC.Linux Theme”.
Figura 13 - Melhrar Experiência de Usuário no Webadmin.
Clique em “Make Changes”.
Figura 14 - Interface melhorada em português do Webadmin.
Depois destes passos, nota-se uma linha adicional abaixo das
configurações da interface de rede eth0, como visto abaixo:
netadmin@ubuntu-vpn-firewall:~$ cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
post-up iptables-restore < /etc/iptables.up.rules
auto eth1
iface eth1 inet static
address 192.168.0.1
netmask 255.255.255.0
4.6 Instalando serviço de VPN OpenVPN
Porquê OpenVPN: Se você quer mais do que apenas chaves pré-
compartilhadas, OpenVPN torna fácil usar e configurar uma infraestrutura
de chave pública (PKI) para usar certificados SSL/TLS em autenticações e
troca de chaves entre o servidor VPN e clientes. OpenVPN pode ser usado
em modo de roteamento ou no modo de ponte (bridge) e pode ser
configurado para usar UDP ou TCP. A porta padrão é 1194, no entanto, o
número da porta pode ser configurado. Ele utiliza somente esta porta para
todas as comunicações. Implementações de cliente VPN estão disponíveis
para quase todas plataformas, incluindo todas as distribuições Linux, OS X,
Windows, Android e roteadores com firmware OpenWRT.
Para instalar o OpenVPN, utilize o comando:
$sudo apt-get install openvpn
O primeiro passo na construção de uma configuração do OpenVPN
é estabelecer uma PKI (Public Key Infrastructure). O PKI é composta por:
Um certificado separado (também conhecido como a chave pública) e uma chave privada para o servidor e cada cliente;
Um certificado mestre de autoridade de certificação (CA) e uma
chave que é utilizada para assinar cada um dos servidores e certificados de
cliente.
OpenVPN suporta a autenticação bidirecional baseada em
certificados, o que significa que o cliente deve autenticar o certificado do
servidor e o servidor deve autenticar o certificado do cliente antes de
confiança mútua.
Tanto o servidor quanto o cliente devem autenticar o outro em
primeiro lugar, verificar se o certificado apresentado foi assinado pelo
certificado mestre da autoridade certificadora (CA), e, em seguida, por
meio de testes de informações no cabeçalho do certificado agora
autenticado, como o nome comum do certificado ou do tipo de certificado
(cliente ou servidor).
Nota: Todos os comandos a partir de agora serão feitos com
usuário root. Para isto digite o comando “$sudo su” e insira a senha do
usuário quando necessário. Para saber se você está utilizando o usuário root
(super usuário do Linux), verifique nas informações antes do bash ($) do
terminal. Como por exemplo “root@servidor-vpn-firewall$”. Se for
necessário, defina uma senha para o usuário root com o comando: “$sudo
passwd root”.
Para configurar a sua própria Autoridade de Certificação (CA) para
a geração de certificados e chaves para um servidor OpenVPN e para vários
clientes, primeiro copie o diretório “easy-rsa” para “/etc/openvpn” . Isto irá
assegurar que quaisquer alterações aos scripts não serão perdidos quando o
pacote for atualizado. A partir de uma mudança de terminal de usuário root
faça o comando:
$ mkdir /etc/openvpn/easy-rsa/cp -r
/usr/share/doc/openvpn/examples/easy-rsa/2.0/* /etc/openvpn/easy-
rsa/
Em seguida, edite o arquivo “/etc/openvpn/easy-
rsa/vars” ajustando o seguinte conteúdo ao seu ambiente de rede:
export KEY_COUNTRY="BR"
export KEY_PROVINCE="SC"
export KEY_CITY="Cidade"
export KEY_ORG="Empresa"
export KEY_EMAIL="usuario@dominio"
Para os comandos de geração de chaves e certificados, é necessário
renomear o arquivo de configuração do OpenSSL (gerador de certificados e
chaves) para os scripts do OpenVPN terem acesso ao seu conteúdo:
$cd /etc/openvpn/easy-rsa/
$ln –s openssl-1.0.0.cnf openssl.cnf
Digite os comando abaixo para gerar a chave e o certificado mestre
da Autoridade Certificadora (CA):
$source vars
$./clean-all
$./build-ca
Para gerar os certificados do servidor:
$./build-key-server NOME_SERVIDOR
Tal como na etapa anterior, a maioria dos parâmetros pode ser
padronizado. Duas outras perguntas exigem respostas positivas (y) "Sign
the certificate? [y/n]" and "1 out of 1 certificate requests certified, commit?
[y/n]".
Parâmetros Diffie Hellman deverão ser gerados para o servidor
OpenVPN:
$./build-dh
Todos os certificados e chaves foram gerados no subdiretório
/keys. A prática comum é copiá-los para “/etc/openvpn/”:
$cd keys/
$cp NOME_SERVIDOR.crt NOME_SERVIDOR.key ca.crt
dh1024.pem /etc/openvpn/
O cliente VPN também vai precisar de um certificado para
autenticar-se ao servidor. Normalmente, você cria um certificado diferente
para cada cliente. Para criar o certificado, digite o seguinte comando como usuário root:
$cd /etc/openvpn/easy-rsa/
$source vars
$./build-key NOME_CLIENTE
Copie os arquivos enumerados abaixo para o cliente usando um
método seguro – no caso deste trabalho, foi feita a cópia dos arquivos para
um pendrive. Para isto, foi feito acesso via conexão de área de trabalho
remota com login e senha do usuário root.
“/etc/openvpn/ca.crt”
“/etc/openvpn/easy-rsa/keys/NOME_CLIENTE.crt”
“/etc/openvpn/easy-rsa/keys/NOME_CLIENTE.key”
Como os certificados e chaves de clientes, só serão necessários na
máquina do cliente, você deve removê-los do servidor.
4.7 Instalando e Configurando o serviço de firewall Shorewall
Requisitos do Sistema: Shorewall requer que você tenha o pacote
iproute/iproute2 instalado. Como usuário root, você pode usar o comando
“swich” para verificar se este programa já está instalado, se estiver
instalado o retorno do comando deve ser como mostrado abaixo:
root@server$which ip
/sbin/ip
Para instalar o Shorewall, efetua o seguinte comando:
$sudo apt-get update
$sudo apt-get install shorewall
No caso deste trabalho, a configuração padrão do servidor é de
duas interfaces físicas. Portanto serão usadas as configurações padrão do
Shorewall de duas interfaces. Estas configurações podem ser obtidas da
seguinte forma:
$cd /etc/shorewall
$sudo cp /usr/share/doc/shorewall/examples/two-interfaces/*
/etc/shorewall/
$sudo mv shorewall.conf shorewall.conf.bkp
$sudo gzip –d /etc/shorewall/*.gz
Shorewall enxerga a rede onde está rodando, como sendo composta
por zonas. Na configuração de duas interfaces, os seguintes nomes de zona
são usados (“/etc/shorewall/zones”):
#ZONE TYPE OPTIONS IN OUT
# OPTIONS OPTIONS
fw firewall
net ipv4
loc ipv4
Note que o Shorewall reconhece o sistema de firewall como uma
zona própria. Quando o arquivo “zones” é processado, o nome da zona do
firewall é armazenada no shell como a variável $FW, a qual pode ser usada
para se referir a zona de firewall por todas as configurações do Shorewall.
Se as suas redes que serão ligadas por uma VPN forem como
mostrado abaixo, então queremos que o sistema na subrede 192.168.0.0/24
esteja apto a se comunicar com o sistema na rede 10.0.0.0/8. Isto é possível
através dos arquivos “/etc/shorewall/tunnels”, “/etc/shorewall/policy” e da
configuração do OpenVPN.
Figura 15 - Arquitetura 1 de Topologia de Rede Virtual Privada.
Para a A1, é necessário alterar o arquivo
“/etc/openvpn/server.conf”, com o seguinte conteúdo no Servidor A:
dev tun
local 189.101.235.18
remote 186.222.13.187
ifconfig 192.168.99.1 192.168.99.2
route 10.0.0.0 255.0.0.0 192.168.99.2
tls-server
dh dh1024.pem
ca ca.crt
cert Servidor_A.crt
key Servidor_A.key
comp-lzo
verb 5
Já para o Servidor B, o arquivo “/etc/openvpn/server.conf” deve
conter o seguinte conteúdo:
dev tun
local 186.222.13.187
remote 189.101.235.18
ifconfig 192.168.99.2 192.168.99.1
route 192.168.0.0 255.255.255.0 192.168.99.1
tls-server
dh dh1024.crt
ca ca.crt
cert Servidor_B.crt
key Servidor_B.key
comp-lzo
verb 5
Chamaremos esta arquitetura de rede como Arquitetura 1 (A1). Em
cada firewall, devem-se declarar as zonas para representar as subredes
remotas. Assumiremos que esta zona é chamada de “vpn”, para isto teremos
de complementar o arquivo de zona (“/etc/shorewall/zones”).
#ZONE TYPE OPTIONS IN OUT
…
vpn ipv4
Para a arquitetura de rede conhecida como “Roadwarrior”
(tradução literal – Guerreiro de estrada), cuja chamaremos de Arquitetura 2 (A2), temos o diagrama mostrado abaixo. No Servidor A, da A2, o arquivo
“/etc/openvpn/server.conf” deve conter o seguinte conteúdo:
dev tun
server 192.168.2.0 255.25.255.0
client-to-client
dh dh1024.crt
ca ca.crt
cert Servidor_A.crt
key Servidor_A.key
port 1194
comp-lzo
user nobody
group nogroup
ping 15
ping-restart 45
ping-timer-rem
persist-tun
persist-key
push “route 192.168.1.0 255.255.255.0”
verb3
Figura 16 - Arquitetura 2 de Topologia de Rede Virtual Privada -
Roadwarrior.
No sistema de gateway (Servidor A), é preciso uma zona para
representar os clientes remoto, chamaremos esta zona de “road”, para isto
teremos de complementar o arquivo de zona (“/etc/shorewall/zones”).
#ZONE TYPE OPTIONS IN OUT
…
road ipv4
Tanto na A1, quanto na A2, cria-se um arquivo
“/etc/shorewall/tunnels”. Este arquivo abre o firewall de modo que o
tráfego da OpenVPN na porta padrão 1194, protocolo padrão UDP, serão
aceitos de/para o gateway remoto. O conteúdo deste arquivo deve possuir –
a primeira e segunda linhas são referentes à respectivamente A1 e A2:
#TYPE ZONE GATEWAY GATEWAY
ZONE
openvpn net 186.222.13.187
openvpnserver:1194 net 0.0.0.0/0
Para A1, no Servidor 2, o arquivo mostrado acima deve ser:
#TYPE ZONE GATEWAY GATEWAY
ZONE
openvpn net 189.101.235.18
Regras sobre qual tráfego permitir e qual tráfego negar, são
expressas em termos de zonas. Você expressa a política padrão para
conexões de uma zona para outra no arquivo “/etc/shorewall/policy”. Você
define exceções para as políticas padrão no arquivo “/etc/shorewall/rules”.
Para cada requisição de conexão que entra no firewall, a requisição
é checada primeiramente pelo arquivo “/etc/shorewall/rules”. Se nenhuma
regra neste arquivo coincide com a requisição de conexão, então a primeira
política no arquivo “/etc/shorewall/policy” que coincidir com a requisição é
aplicada. Se houver alguma ação comum definida para a política a ser
aplicada no arquivo “/etc/shorewall/actions” ou
“/usr/share/shorewall/actions.std”, então esta ação será executada antes da
política ser aplicada. O propósito da ação comum é dividida em duas:
Ela rejeita ou descarta silenciosamente o tráfego comum que, de
outra forma, iria desordenar/poluir as informações no log – por exemplo, os
Broadcasts.
Ela garante que tráfego crítico para operações corretas são
permitidos através do firewall – por exemplo, tráfego ICMP com
fragmentação necessária.
O arquivo “/etc/shorewall/rules” não foi alterado do exemplo
Shorewall de duas interfaces:
# Don't allow connection pickup from the net
#
Invalid(DROP) net all
#
# Accept DNS connections from the firewall to the network
#
DNS(ACCEPT) $FW net
#
# Accept SSH connections from the local network for
administration
#
SSH(ACCEPT) loc $FW
#
# Allow Ping from the local network
#
Ping(ACCEPT) loc $FW
#
# Drop Ping from the "bad" net zone.. and prevent your log from
being flooded..
#
Ping(DROP) net $FW
ACCEPT $FW loc icmp
ACCEPT $FW net icmp
#
O arquivo “/etc/shorewall/policy” incluído nos exemplos de duas
interfaces possui as seguintes políticas:
#SOURCE DEST POLICY LOG LEVEL LIMIT:BURST
loc net ACCEPT
net all DROP info
#
# THE FOLLOWING POLICY MUST BE LAST
#
all all REJECT info
Porém gostaríamos que o firewall pudesse se comunicar com
servidores na internete (para o próprio servidor poder se conectar a internet
e atualizar aplicativos, por exemplo). Então foi adicionado entre a terceira e
quarta linha a política “$FW net ACCEPT”. Ainda para permitir a
conexão com o Webadmin, necessitamos permitir conexões no sentido
firewall para rede local e vice-versa. Para isto foi adicionado logo acima da política anterior as seguintes políticas: “$FW loc ACCEPT” e
“loc $FW ACCEPT”. Ainda para o caso das Arquiteturas 1 e 2 do
OpenVPN, adicionamos as políticas “road loc ACCEPT” e
“vpn loc ACCEPT”. Deixando o arquivo “/etc/shorewall/policy” como
mostrado abaixo:
#SOURCE DEST POLICY LOG LEVEL LIMIT:BURST
loc net ACCEPT
net all DROP info
$FW net ACCEPT
$FW loc ACCEPT
loc $FW ACCEPT
road loc ACCEPT
vpn loc ACCEPT
# THE FOLLOWING POLICY MUST BE LAST
all all REJECT info
Com estas políticas, foi definido que:
São permitidas todas as requisições de conexão da rede local para a
internete.
Descartamos todas as requisições de conexão da internete para o
firewall ou a rede local.
Aceitamos todas as requisições de conexão do firewall para a
internete.
Aceitamos as requisições de conexão do firewall para rede local e
vice versa.
Aceitamos as requisições do “Roadwarrior” para rede local.
Aceitamos as requisições da subrede remota “vpn” para rede local.
Rejeitamos todas as outras requisições de conexão.
A palavra “info” na coluna “LOG LEVEL” para as políticas
“DROP” ou “REJECT” de conexões, indicam todos os pacotes descartados
ou rejeitados sobre estas políticas devem ser registrados em log.
É importante ressaltar que as políticas do Shorewall (e regras)
referem-se a conexões, e não ao sentido do fluxo de pacotes.
Os exemplos de configuração de duas interfaces do Shorewall
assumem que, a interface de rede externa é a “eth0”, enquanto a interface
de rede local é a “eth1”. O que coincide com a configuração escolhida para
este trabalho. Abaixo já foram adicionadas as interfaces referentes às duas arquiteturas do OpenVPN.
Altere as seguintes linhas do arquivo /etc/shorewall/interfaces:
#ZONE INTERFACE BROADCAST OPTIONS
net eth0 detect dhcp,tcpflags,nosmurfs,routefilter,logmartians
loc eth1 detect dhcp,tcpflags,nosmurfs,routefilter,logmartians
vpn tun0
road tun+ routeback
Definições das opções (OPTIONS):
dhcp : Especificar esta opção quando qualquer um dos itens abaixo
forem verdadeiros:
A interface obtém o endereço IP através de um servidor DHCP.
A interface é usada por um servidor DHCP que está rodando dentro
do firewall.
A interface possui IP estático, mas está em um segment de rede
com muitos clients DHCP.
A interface é uma ponte simples de outra interface (simple bridge)
com um servidor DHCP em uma porta e clientes em outra porta.
tcpflags: Pacotes que chegam nesta interface são checados por
certas combinações ilegais de flags TCP. Pacotes onde forem encontradas
estas flags serão tratados de acordo com a configuração do
TCP_FLAGS_DISPOSITION depois de terem sido registrados de acordo
com a configuração do TCP_FLAGS_LOG_LEVEL.
Nosmurfs: Filtra pacotes por smurfs (pacotes com endereço de
broadcast como fonte). Smurfs serão registrados no log opcionalmente,
baseado na configuração do SMURF_LOG_LEVEL no arquivo
“/etc/shorewall/shorewall.conf”. Depois de registrado no log, os pacotes
são descartados.
routefilter: Habilita o filtro de roteamento do kernel para esta
interface (medida anti-spoofing). Esta opção pode ser habilitada
globalmente na configuração ROUTE_FILTER no arquivo
“/etc/shorewall/shorewall.conf”.
logmartians: Habilita o registro martian do kernel (registra no log
os pacotes com endereço fonte impossível. É altamente recomendável que
se você definir a opção routefilter em uma interface, que também habilite
esta opção.
Mascaramento IP (SNAT): Os endereços reservados pelo RFC
1918 são muitas vezes referidos como não roteáveis, porque os roteadores
de “backbone” da Internet não encaminham pacotes que tenham um
endereço RFC-1918 de destino. Quando um de seus sistemas locais envia
um pedido de conexão a um host de Internet, o firewall deve executar a
tradução do endereço de rede (NAT - Network Address Translation). O
firewall reescreve o endereço de origem no pacote a ser o endereço da
interface externa do firewall, em outras palavras, o firewall faz com que
pareça o anfitrião do destino na Internet, como se o firewall é que estivesse
iniciando a conexão. Isso é necessário para que o host de destino seja capaz
de rotear pacotes de retorno de volta para o firewall (lembre-se que os
pacotes cujo endereço de destino é reservado pela RFC 1918 não podem ser
encaminhados através da Internet para o host remoto). Quando o firewall
recebe um pacote de retorno, ele reescreve o endereço de destino de volta
para o endereço local (ex. 192.168.0.101) e encaminha o pacote para o
computador correto.
Em sistemas Linux, o processo acima é muitas vezes referida
como “IP Masquerading”, mas você também verá o termo “Source
Network Address Translation (SNAT)” usado. Shorewall segue a
convenção usada com Netfilter:
Masquerade descreve o caso em que você deixar o seu sistema de
firewall detectar automaticamente o endereço de interface externa.
SNAT refere-se ao caso em que você especificar explicitamente o
endereço de origem que deseja usar para pacotes de saída da sua rede local.
No Shorewall, tanto Masquerade quando SNAT são configurados
com entradas no arquivo “/etc/shorewall/masq”. Normalmente usa-se o
Masquerade se o IP da internete é dinâmico e SNAT se o IP é estático
(fixo). Segue conteúdo do arquivo mencionado:
#INTERFACE SOURCE ADDRESS PROTO PORT(S) IPSEC
MARK
eth0 10.0.0.0/8,\
169.254.0.0/16,\
172.16.0.0/12,\
192.168.0.0/16
A configuração no Cliente Remoto da A2 segue uma linha similar
ao do Servidor.
Primeiramente temos que definir uma “zona” para representar a
LAN remota em “/etc/shorewall/zones” com o conteúdo “home ipv4”.
Em “/etc/shorewall/interfaces”, o conteúdo “home tun0”.
Em “/etc/shorewall/tunnels”, o conteúdo “openvpnclient:1194 net
189.101.235.18”.
Em “/etc/shorewall/policy”, o conteúdo “$FW home ACCEPT”.
No Cliente Remoto, da A2, o arquivo “/etc/openvpn/server.conf”
deve conter o seguinte conteúdo:
dev tun
remote 189.101.235.18
up /etc/openvpn/home.up
tls-client
pull
dh dh1024.crt
ca ca.crt
cert Cliente_Remoto.crt
key Cliente_Remoto.key
port 1194
comp-lzo
user nobody
group nogroup
ping 15
ping-restart 45
ping-timer-rem
persist-tun
persist-key
verb3
Registros de Log: Shorewall não mantém um registro de log
próprio, mas depende do registro de log do sistema. Os
seguintes comandos dependem da localização de onde as mensagens
Netfilter são registradas:
“shorewall show log” - Exibe as últimas 20 mensagens de log do
Netfilter.
“shorewall logwatch” - sonda o log em um intervalo de tempo
configurável.
“shorewall dump” - Produz um extenso relatório para inclusão em
relatórios de problemas Shorewall.
É importante que esses comandos funcionem corretamente, porque
quando você encontrar problemas de conexão, quando Shorewall está sendo
executado, a primeira coisa que você deve fazer é olhar para o log do
Netfilter, normalmente você pode resolver o problema rapidamente.
A localização do registro de log Netfilter no Ubuntu é:
“/var/log/kern.log”.
Importante: A definição LOGFILE não controla onde o log do
Netfilter é mantido, apenas indica sua localização.
Antes de iniciar o Shorewall, tenha certeza que o IPTables foi
desabilitado. Para isto execute os comandos:
$sudo /etc/init.d/iptables stop
$sudo update-rc.d iptables disable
Para o Shorewall poder iniciar automaticamente, é necessário
alterar a linha “STARTUP_ENABLED=Yes” em
“/etc/shorewall/shorewall.conf”.
O firewall é iniciado usando o commando “$sudo shorewall start”, parado usando o comando “$sudo shorewall stop” e reiniciado utilizando o
comando “$sudo shorewall restart”. Quando o firewall é parado, o
roteamento é habilitado nos hosts configurados no arquivo
“/etc/shorewall/routestopped”. Se você quiser remover todos os traços do
Shorewall do seu Netfilter, use o comando “$sudo shorewall clear”. Configurações que não são necessárias neste trabalho, mas que
aqui ficam documentadas:
Serviços de DNS entre o Firewall e o ISP são configurados
automaticamente no arquivo “/etc/resolv.conf”. No entanto,
independentemente de como o serviço de DNS externo é configurado no
firewall, é de responsabilidade do administrador de rede configurar o DNS
interno da rede. Para isto você pode alterar o arquivo mencionado acima,
ou, adicionar a linha “DNS(ACCEPT) loc $FW” no arquivo
“/etc/shorewall/rules”.
Você pode rodar um servidor FTP dentro da rede local, para isto
adicione a linha “FTP(DNAT) net loc:SERVIDOR_FTP” no arquivo
“/etc/shorewall/rules”.
Você pode rodar um servidor Web dentro da rede local, para isto
adicione a linha “Web(DNAT) net loc:SERVIDOR_FTP” no arquivo
“/etc/shorewall/rules”.
De uma maneira geral, as regras de encaminhamento podem ser
criadas da seguinte forma:
DNAT net loc:<endereço IP local do servidor>[:<porta do servidor>]
<protocolo> <porta destino>
4.8 DNS Dinâmico
4.8.1 Introdução
Cada computador conectado à Internet tem um endereço
IP. Tradução de nomes é o processo de relacionar um nome (como
"www.google.com") para um endereço IP (como .125.19.103 '74 '), de
modo que um site (ou outro serviço) em um computador pode ser acessado
usando um nome fácil de lembrar, ao invés do número do endereço IP do
computador. Tradução de nomes é implementado por meio de um banco de
dados distribuído conhecido como Sistema de Nome de Domínio (DNS -
Domain Name System) . Esta base de dados é implementada na internet por servidores de
nomes DNS, que mantem o controle de registros de DNS e troca
informações um com os outros para manter a consistência. Cada pedido de
um nome (ou seja, um navegador web) é então direcionado para um desses
servidores de nome. A maioria dos servidores na Internet tem um endereço fixo (estático)
IP que nunca muda. O registro DNS para este nó só vai mudar com baixa
frequência. No entanto, para muitos usuários domésticos é atribuído um
endereço IP que muda com alta frequência. Estes endereços IP
dinâmicos são atribuídos por um provedor de serviços de internete (ISP –
Internet Service Provider). Isto se torna um desafio para traduzir um nome a
um desses endereços IP. Uma vasta quantidade de servidores de nomes DNS oferece um
método para atualizar o banco de dados do DNS com um nome IP de
tradução dinâmica. Isso é feito usando um pequeno programa no seu
computador ou um roteador local. Estes serviços de DNS dinâmico permitem que o usuário escolha
um nome de host, e defina um endereço IP inicial para corresponder ao
nome do host. O utilitário de software, em seguida, verifica periodicamente
se há uma mudança no endereço IP da interface conectada a internete, e
quando um novo endereço IP é descoberto, ele atualiza o banco de dados de
DNS dinâmico para refletir essa mudança.
4.8.2 Registrar IP com um provedor de DNS dinâmico
DNS exige que um servidor de nome em algum lugar da Internet
acompanhe "onde você está" (ou seja, o seu endereço IP atual). Ou seja, seu
banco de dados deve estar sempre atualizado para garantir que seu “hostname”
corresponda sempre ao seu endereço IP atual. Para utilizar um desses serviços de DNS dinâmico, é necessário
efetuar o registro em seus serviços. Aqui está uma seleção desses serviços.
DynDNS - http://dyn.com/
No-IP - http://www.noip.com/
EasyDNS - https://web.easydns.com/
ZoneEdit - http://www.zoneedit.com/
DNSPark - http://www.dnspark.com
NameCheap - http://www.namecheap.com
DSLReports - http://www.dslreports.com
FreeDNS - http://freedns.afraid.org/
OpenDNS - http://www.opendns.com/
Ao se cadastrar, você irá selecionar um nome de usuário e senha, bem
como um nome de host que você vai usar como o nome DNS (para permitir o
acesso externo ao seu aparelho usando o nome do host). Muitos provedores de DNS dinâmico oferecem uma seleção de nomes
de hosts disponíveis para uso livre com o seu serviço. No entanto, com um
plano pago, qualquer “hostname” (incluindo o seu próprio nome de domínio
registrado) pode ser usado.
4.8.3 Utilitário de software para realizar atualizações de DNS
dinâmico
Existem vários utilitários disponíveis. Cada serviço de DNS
dinâmico pode funcionar melhor com um utilitário específico.
No-IP
O gerenciador de DNS dinâmico compatível com o site
http://www.noip.com, é distribuído em uma versão não compilada, deve-se
primeiro instalar o compilador da linguagem C/C++ executando os
comandos:
$sudo apt-get update
$sudo apt-get install build-essentials
A versão do compilador “gcc” e do montador “make” podem ser
verificados com os seguinte comandos: “$gcc –v” e “make –v”.
netadmin@servidor-vpn-firewall:~$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-
1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-
languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --
enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib -
-without-included-gettext --enable-threads=posix --with-gxx-include-
dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-
clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-
gnu-unique-object --enable-plugin --enable-objc-gc --disable-werror --with-
arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-
linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
netadmin@servidor-vpn-firewall:~$ make -v
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR
A PARTICULAR PURPOSE.
This program built for x86_64-pc-linux-gnu
Para obter o programa no-ip de sincronização de IP para DNS
dinâmico, execute o comando:
$wget http://www.no-ip.com/client/linux/noip-duc-linux.tar.gz
Para o extrair e compilar, execute a sequência de comando no
terminal:
$tar xf noip-duc-linux.tar.gz
$cd noip-2.1.9-1/
$sudo make install
Você terá de selecionar a interface de rede conectada à rede
externa, neste caso a resposta é “0” (zero). Insira o nome de usuário e a
senha previamente cadastrados no site oficial. Insira o tempo de frequência
de atualização, neste caso foi inserido 600 segundos (10 minutos), visto que
o IP dinâmico da internete não é substituído com frequência alta. A
instalação também perguntará se você deseja rodar algo quando houver uma
atualização bem sucedida, neste caso foi selecionado “n” (não). E por fim,
ele avisará que foi criado com sucesso um arquivo de configuração em
“/usr/local/etc/no-ip2.conf”.
Auto configuration for Linux client of no-ip.com.
Multiple network devices have been detected.
Please select the Internet interface from this list.
By typing the number associated with it.
0 eth0
1 eth1
0
Please enter the login/email string for no-ip.com giovanni2s
Please enter the password for user 'giovanni2s' ********
Only one host [sarani.no-ip.biz] is registered to this account.
It will be used.
Please enter an update interval:[30] 600
Do you wish to run something at successful update?[N] (y/N) n
New configuration file '/tmp/no-ip2.conf' created.
mv /tmp/no-ip2.conf /usr/local/etc/no-ip2.conf
Finalizado, agora seu endereço de IP público estará sendo
redirecionado automaticamente para o domínio cadastrado gratuitamente no
site www.no-ip.com. Para testar se está funcionando, basta executar o
comando abaixo (para interromper as sequências de ping, pressione as
teclas [ctrl]+[c]):
$ping <domínio cadastrado>
Para uma configuração bem sucedida o retorno do comando deve ser:
netadmin@servidor-vpn-firewall:~/noip-2.1.9-1$ ping sarani.no-ip.biz
PING sarani.no-ip.biz (186.222.2.123) 56(84) bytes of data.
64 bytes from bade027b.virtua.com.br (186.222.2.123): icmp_req=1 ttl=63
time=20.6 ms
64 bytes from bade027b.virtua.com.br (186.222.2.123): icmp_req=2 ttl=63
time=16.0 ms
64 bytes from bade027b.virtua.com.br (186.222.2.123): icmp_req=3 ttl=63
time=13.8 ms
64 bytes from bade027b.virtua.com.br (186.222.2.123): icmp_req=4 ttl=63
time=23.3 ms
64 bytes from bade027b.virtua.com.br (186.222.2.123): icmp_req=5 ttl=63
time=15.4 ms
64 bytes from bade027b.virtua.com.br (186.222.2.123): icmp_req=6 ttl=63
time=16.1 ms
64 bytes from bade027b.virtua.com.br (186.222.2.123): icmp_req=7 ttl=63
time=15.4 ms
^C
--- sarani.no-ip.biz ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6008ms
rtt min/avg/max/mdev = 13.880/17.284/23.348/3.139 ms
Feito esta configuração, agora você pode substituir, nos campos das
configurações do OpenVPN, onde aparecem o seu IP público, pelo domínio
cadastrado.
5 Conclusão:
Apesar de todo esforço, todos os reinícios da implementação da
parte prática deste trabalho, foi uma enorme satisfação poder o ter
concluído. O produto final ficou bem configurado e 100% funcional. Em
suma, neste trabalho foi apresentados o funcionamento das tecnologias de
Firewall e VPN, foram apresentadas também, diversas aplicações destas
tecnologias com código aberto, procurou-se utilizar uma linguagem clara e
objetiva, onde até os menos entendidos poderão recorrer a este trabalho
para obter um melhor entendimento da necessidade, operação e
implementação das tecnologias. Por fim, foi desenvolvido um servidor
aplicando uma tecnologia de VPN e outra de Firewall, juntamente com
outros serviços necessários. A aplicação foi bem sucedida e serve de
exemplo para as diversas organizações que desejarem aplicar esta solução
em suas redes de computadores. A figura 16 demonstra como ficou a
implementação final do servidor, juntamente com os serviços instalados:
Figura 17 - Resumo do Servidor Implementado
Interface de Rede Eth0
Interface de Rede Eth1
Firewall ShoreWall
Roteador DHCP
Modem ADSL
VPN OpenVPN Servidor de Certificadosdo OpenVPN
Serviço de DNS Dinâmico
Rede de Computadores
Servidor Implementado
Internete
XFCE v4
Interface Gráfica
Acesso da Área de Trabalho Remota
XRDPServiço
SSH
WebAdmin
Gerenciamento Remoto por Navegador Web
5.1 Resumo da Parte Prática
Este capítulo é referente aos recursos instalados no servidor,
enumerados na figura 17.
O sistema operacional do servidor é Linux (Ubuntu Server 12.04.3
LTS), o único serviço habilitado no servidor foi o SSH para conexões
remotas ao shell de comandos.
O servidor possui duas interfaces de rede. A interface eth0 (placa
de rede onboard) está conectada à rede pública (internete) enquanto que a
interface eth1 (placa de rede offboard) está conectada à rede local. Assim
todo tráfego que atravessa da rede local para pública é analisada pelo
serviço de firewall instalado.
Foi instalado também o serviço de DHCP, para habilitar e
gerenciar a distribuição de IPs na rede local pelo servidor. Este processo
também é necessário para permitir o encaminhamento de pacotes de dados
de uma interface de rede à outra. Isto caracteriza o servidor como um
roteador. Foi adicionado ainda o serviço de DNS dinâmico para redes sem
IP público estático.
Para facilitar o manuseio dos serviços oferecidos no servidor, ainda
foi instalado o serviço de conexão remota (XRDP) juntamente com
interface gráfica (XFCE). Ainda foi instalado o WebAdmin, que permite
gerenciar e controlar diversos serviços do servidor, diretamente por
qualquer navegador web dentro da rede.
Dando continuidade a meta do trabalho, foi implantado o serviço
de VPN (OpenVPN), onde é necessário definir certificados e chaves de
autenticação, por isso, este servidor também possui características de
servidor de certificados.
O serviço de firewall instalado foi o Shorewall. Como ele é um
firewall de inspeção dinâmica de pacotes, ele é orientado à conexões. As
conexões permitidas são as seguintes:
Firewall Rede Local
Rede Local Internete
Firewall Internete
RoadWarrior Rede Local
VPN Rede Local
Onde RoadWarrior é o nome da extremidade de conexão de
usuário VPN fora da rede local; e VPN é o nome da extremidade de
conexão de um servidor cliente de rede de computadores. Ressaltando que
ele considera o próprio Firewall como uma extremidade de conexão.
5.2 Trabalhos futuros
Implantar um servidor de diretório de domínios, com LDAP para
restringir acesso e dar permissões exclusivas a usuários da rede de
computadores.
Implantar um Servidor Samba (para comunicação, acesso e troca
de arquivos entre computadores com sistemas operacionais diferentes) com
HDs em RAID.
Backup de arquivos via rede (sugere-se utilizar o programa Bacula)
e também a cópia de segurança de imagens de sistemas operacionais da
rede, para fácil formatação dos PCs.
Instalação de um servidor LAMP (Linux Apache MySQL PHP),
para implantar um website (em Joomla) na intranet, acessado de fora
somente por VPN, com calendário, chat, notícias internas, blog, wiki,
helpdesk, etc...
Servidor de envio e recebimento de e-mails (SMTP, POP, IMAP).
Entre outras funcionalidades para ampliar a capacidade das redes
de computadores empresariais, de pesquisa e desenvolvimento, e até
mesmo, redes domésticas.
6 Referências Bibliográficas:
[1] Scambray, J., Mcclure, S. and Kurtz G. (2001) Hacking Exposed: Network Security and Solutions, Osborne/McGraw-Hill.
[2] Tipton, H.F. and Krause, M. (2000) Information Security Management Handbook (4th Edition), Auerbach Publications
[3] Zacker, C. (2001) Networking: The Complete Reference,
Osborne/McGraw-Hill
[4] Firkhan Ali, H. A etl. , “Development Of Dual-Factor Authentication
For Web Based Application Using SMS”, Proceedings of the ICITS
2008, Kusadasi, Turkey, 2008.
[5] Firkhan Ali, H. A etl., “Development of Vulnerability and Security
Reporting System for Computer System and Networking” in SITIA
2008: Proceedings of the Seminar In The Intelligent Applications 2008,
Surabaya, Indonesia, 2008.
[6] Firkhan Ali, H. A., “ An Analysis of Possible Exploits in the Computer
Network’s Security “ in ISC 2005 : Proceedings of the International
Science Congress 2005. PWTC, Kuala Lumpur, 2005. pp.338.
[7] Deraison, R., Haroon Meer, Temmingh, R., Walt, C., Raven Alder,
Alderson, J., Johnston, A., Theall, G. A. (2004). “Nessus Network
Auditing.” Syngress.
[8] Bauer, M. (2001). “Paranoid Penguin: Seven Top Security Tools” Linux Journal. Volume 2004 , Isu 118 (Februari 2004).
[9] Guomin Yang, Duncan S. Wong, Huaxiong Wang dan Xiaotie Deng
(2006). “Formal Analysis and Systematic Construction of Two-factor
Authentication Scheme.” City University of Hong Kong, China.
[10] Richard A. Kemmerer et al., (2002), Intrusion Detection: A Brief
History and Overview, SECURITY & PRIVACY–2002, Reliable
Software Group, Computer Science Department, University of
California Santa Barbara.
[11] Wenke Lee et al., (2000), A Framework for Constructing Features and
Models for Intrusion Detection Systems, ACM Transactions on
Information and System Security (TISSEC), Volume 3 Issue 4, ACM Press.
[12] William Stallings, “Cryptography and network Security”, 3rd edition,
Prentice Hall,2003.
[13] R. Venkateswaran, “Virtual Private Networks,” IEEE Potentials, Mar.
2001.
[14] J. Epplin, “Peeking Under the Hood of SnapGear’s uClinux-powered
VPN Appliances,” LinuxDevices.com, Jan. 2003,
[15] C. J. C. Pena and J. Evans, “Performance Evaluation of Software
Virtual Private Networks (VPN),” Proc. 25th
Annual IEEE Conf. Local
Comp. Networks, Nov. 2000,
pp. 522–23.
[16] J. P. McGregor and R. B. Lee, “Performance Impact of Data
Compression on Virtual Private Network Transactions,” Proc. 25th Annual
IEEE Conf. Local Comp. Networks, 2000, pp. 500–10.
[17] O. Titz, “Why TCP over TCP Is a Bad Idea,”
http://sites.inka.de/sites/bigred/devel/tcp-tcp.html
[18] H. Lipmaa, “Crypto Hardware Pointers,”
http://www.tcs.hut.fi/~helger/crypto/link/practice/hardware.html
[19] B. Schneier, “Security in the Real World: How to Evaluate Security
Technology,” excerpts from a general session presentation at CSI’s NetSec
Conf., St. Louis, MO, June 1999; http://www.schneier.com/essay-
realworld.html
[20] J. De Clercq and O. Paridaens, “Scalability Implications of Virtual
Private Networks,” IEEE Commun. Mag., vol. 40, no. 5, May 2002, pp.
151–57.
[21] O. Kolesnikov and B. Hatch, “Building Linux Virtual Private
Networks,” New Riders, 2001.
[22] Jürgen Schmidt, “A death blow for PPTP”, http://www.h-
online.com/security/features/A-death-blow-for-PPTP-1716768.html
[23] S. Khanvilkar and A. Khokhar, “Virtual Private Networks: An
Overview with Performance Evaluation”.
Ubuntu Help Documentation
http://help.ubuntu.com/
OpenVPN Documentation
https://openvpn.net/index.php/open-source/documentation.html
Shorewall Documentation
http://www.shorewall.net/Documentation_Index.html
