Instituto Superior de Engenharia do Porto Departamento de Engenharia Informática Setembro 2002
Autor do projecto Rui Sousa Número: 950700 Coordenador do projecto Eng.º Paulo Ferreira I
Agradecimentos Gostaria de agradecer ao Engº Paulo Ferreira, coordenador deste projecto, por me ter facultado documentos, que se afiguraram imprescindíveis para a realização deste trabalho, bem como pelos conselhos que me concedeu. Também gostaria de agradecer à família Sousa (pai, mãe e irmã) e à Katia, pelo apoio que sempre me deram nos bons e maus momentos. Ao IPATIMUP e a todos aqueles com quem convivo. A todos eles o meu obrigado. II
Índice Introdução...5 VPN...6 Introdução... 6 O que é exactamente uma VPN?... 6 Tunneling... 6 VPN s para acesso remoto... 6 VPN s para Internetworking... 7 VPN s no lado interno da firewall... 7 O que é uma VPN e o que é que faz?... 7 Linhas dedicadas tradicionais... 7 A tecnologia por detrás das VPN s... 8 Point-to-Point Tunneling Protocol (PPTP)... 8 Layer Two Tunneling Protocol (L2TP)... 8 Internet Protocol Security (IPSec)... 8 SOCKS Network Security Protocol... 9 CIPE (Crypto IP Encapsulation)... 9 Segurança da VPN... 9 Categorias de VPN... 9 VPN prós e contras...10 Vantagens de uma VPN...10 O baixo custo de uma VPN...11 Escalabilidade e VPN s...11 Desvantagens das VPN s...11 O futuro das VPN s...12 CIPE... 13 Introdução...13 Camadas de rede...13 Endereçamento IP e VPN s...13 Como funciona o CIPE...14 Componentes do software CIPE...14 Notas do funcionamento interno...14 Instalação do pacote de software CIPE...16 Pré-requisitos...16 Versões do kernel...16 Compilar os módulos...16 A opção do kernel IP forwarding...16 Protocolos e cifras...18 Compilação avançada...18 Instalação...19 Erros de compilação...19 Execução do CIPE...19 Nomes dos programas...19 Carregando (loading) o módulo...20 Executando o daemon ciped...20 Configuração do software CIPE...22 Especificando as opções...22 Lista de todos os parâmetros...23 Incompatibilidades de chaves com versões antigas do CIPE...23 Trabalhando com os SOCKS...24 Endereços dinâmicos de transporte...24 Tratamento de erros no ciped...25 III
A ferramenta PKCIPE...26 Como é que funciona...26 Chaves públicas...26 Executando o programa pkcipe...27 Exemplos de utilização... 28 Conselhos gerais...28 Exemplo 1...29 Exemplo 2...30 Tipos de ligações...31 Descrição dos protocolos...33 O protocolo CIPE...33 O protocolo PKCIPE...37 Apontamentos...41 Construir uma VPN com o CIPE... 42 Introdução...42 Configuração da máquina...42 Criação de um novo script executável chamado ciped...42 Configuração das interfaces do túnel...44 Criação da chave secreta...44 Configuração do interface cipcb0...44 Atribuição dinâmica de IP...45 Configuração da firewall...45 Configuração do /etc/cipe/ip-up...46 Iniciar automaticamente o daemon no arranque do sistema...47 Masquerading da firewall numa VPN que utiliza o CIPE... 48 Introdução...48 Configuração da firewall...48 Diagrama da rede VPN...48 Notas adicionais sobre scripts e a VPN...48 Configuração especifica da máquina A...49 /etc/cipe/options.machineb...49 /etc/cipe/options.machinec...49 /etc/rc.d/rc.cipe...49 Gateway...50 Configuração específica da máquina B...50 /etc/cipe/options.machinea...50 /etc/rc.d/rc.cipe...51 Gateway...51 Configuração específica da máquina C...52 /etc/cipe/options.machinea...52 /etc/rc.d/rc.cipe...52 Gateway...53 Configuração comum...53 /etc/cipe/ip-up...53 /etc/cipe/ip-down...58 Exemplos de scripts de firewall masquerading...62 Para finalizar...67 Ligação a uma WAN...68 Conclusão... 69 Referências... 70 IV
Introdução Este documento tem como intuito explicar o funcionamento duma VPN em Linux que utilize o CIPE (Crypto IP Encapsulation). E porquê o CIPE? A razão desta escolha é fácil, pois o CIPE é uma ferramenta estável e pouco pesada, ao nível das comunicações. Caso não seja preciso a administração de chaves ou suporte à distância então temos a ferramenta ideal, desde que tenhamos duas gateways Linux em ambas as pontas da ligação. A implementação tem pouco impacto ao nível do CPU se compararmos com outras soluções de alta segurança. Foi desenhado para transmitir pacotes encriptados entre máquinas (previamente configuradas) na forma de pacotes UDP, isto não é tão flexível como o IPSec (Internet Protocol Security) mas é o suficiente para atingir o objectivo de uma VPN, que é criar uma ligação segura entre duas máquinas (ou duas redes, ou uma máquina e uma rede) através de uma rede de transporte insegura. A utilização do protocolo UDP torna fácil o endereçamento e obtêm uma melhor performance do que os túneis baseados em TCP. Além do CIPE, existem outras ferramentas para criar VPN s tais como: SSH e PPP - conjuntamente criam uma VPN, o SSH é utilizado para a criação da ligação sobre o túnel, enquanto o PPP (através do pppd) redirecciona o tráfego através deste túnel. FreeS/Wan - usa o IPSec, enquanto o IPSec fornece serviços de autenticação e encriptação ao nível da camada de rede protegendo o tráfego transportado sobre IP, já o FreeS/Wan faz o manuseamento dos pacotes ao nível do kernel, negoceia as conexões e fornece vários scripts que são a interface com a pessoa responsável. VPNd o Virtual Private Network Daemon, disponível em http://sunsite.dk/vpnd/, é um daemon que liga duas redes ao nível de rede via TCP/IP ou uma linha dedicada (virtual) conectada a uma porta de série. Toda os dados transferidos entre as duas redes são encriptados usando o algoritmo de encriptação Blowfish. O VPNd não pretende ser o substituto de software de comunicações seguras tais como o SSH ou as capacidades de tunneling de um sistema operativo. Contudo pretende ser um meio transparente de segurança de intercomunicações através de canais potencialmente inseguros. tinc é um daemon VPN que usa o tunneling e a encriptação para criar uma rede privada segura entre duas máquinas, sobre a Internet. Com esta ferramenta o túnel aparece ao nível do IP de rede como um dispositivo de rede normal, por isso não é necessário adaptar nenhum software já existente. Este tunnelling permite aos sítios VPN s a partilha de informação entre ambos por cima da Internet, sem expor nenhuma informação a terceiros. Um único daemon tinc pode aceitar mais do que uma ligação ao mesmo tempo, o que possibilita a criação de grandes redes virtuais. O tinc encapsula cada pacote de rede em pacotes UDP, o que provoca menor latência, menor overhead e em média uma melhor resposta. Para mais informações consultar http://tinc.nl.linux.org/. Virtual Tunnel também conhecido como VTUN, suporta uma variedade de métodos para estabelecer uma conexão, e vários algoritmos (http://vtun.sourceforge.net/). Zebedee providencia a encriptação de tráfego TCP entre máquinas e está disponível para UNIX e Windows (http://www.winton.org.uk/zebedee/). L2TP Daemon para Linux. Rui Sousa 5
VPN Introdução As Virtual Private Networks (VPN s) tem atraído a atenção de muitas empresas na expansão das suas capacidades de rede e reduzir os seus custos. As VPN s podem ser encontradas no trabalho mas também em casa, onde se permite aos empregados o acesso seguro à rede interna da companhia. Para aqueles que tem de viajar muito as VPN s são o modo mais conveniente para estar ligado à intranet da empresa. Não interessa qual o nosso envolvimento actual com as VPN s, esta é uma boa tecnologia da qual devemos saber qualquer coisa. Os estudos sobre as VPN s acrescentam muitos pontos de interesse a considerar nas áreas de esquematização dos protocolos de rede, segurança da Internet, serviços outsourcing de rede, e tecnologias standards. O que é exactamente uma VPN? Uma VPN fornece conectividade entre redes que se encontram possivelmente a grandes distâncias físicas entre si. A este respeito, as VPN s são uma espécie de Wide Area Network (WAN). Contudo o ponto chave de uma VPN é a possibilidade de usar redes públicas como a Internet em vez de fazê-lo através de linhas dedicadas privadas, mantendo a privacidade dos dados através de um protocolo de tunneling e certas medidas de segurança. As tecnologias VPN implementam acessos restritos a redes que usem a mesma cablagem e routers como são usados na rede pública, e isto é feito sem sacrificar recursos ou segurança básica. As VPN s suportam pelo menos três modos diferentes de utilização: Acessos remotos de clientes LAN-to-LAN internetworking Acesso controlado dentro de uma intranet Usar uma VPN envolve a encriptação de dados antes de os transmitir através da rede pública e a desencriptação à sua chegada ao destino. Um nível adicional de segurança envolve a encriptação não só dos dados mas também dos endereços de origem e chegada. O software de uma VPN é instalado normalmente na firewall da companhia. Tunneling A tecnologia VPN é baseada numa estratégia de tunneling. O tunneling envolve o encapsulamento de pacotes construído num formato base de um protocolo dentro de outro protocolo. No caso das VPN s que são executadas sobre a Internet, os pacotes de um dos vários formatos de protocolos VPN são encapsulados dentro de pacotes IP. VPN s para acesso remoto Uma VPN pode suportar os mesmos serviços intranet/extranet como uma WAN tradicional, mas as VPN s podem também crescer em popularidade devido à sua possibilidade de suportar serviços de acessos remotos. Nos anos mais recentes, muitas companhias aumentaram a mobilidade dos seus trabalhadores ao permitirem o tele-trabalho. Os empregados podem continuar a viajar e estarem conectados à rede interna da companhia. As linhas dedicadas não suportam a mobilidade dos trabalhadores pois as linhas não podem ser estendidas a todos os sítios onde as pessoas vão de viajem nem até às suas casas. As companhias que não utilizem VPN s devem, neste caso, implementar serviços de dial-up seguros. Para aceder a uma intranet através do dial-up, o trabalhador remoto deve-se ligar a um servidor de acessos remotos. O custo de manutenção deste sistema interno, mais o custo das chamadas de longa distância realizadas pelos seus trabalhadores, torna a opção VPN mais atractiva. 6 Rui Sousa
Arquitectura de uma VPN de tipo acesso remoto Este diagrama mostra uma solução de um acesso remoto usando uma VPN. O nó remoto (cliente) que quer aceder à VPN da companhia liga a um servidor local ligado à rede pública. O cliente VPN estabelece a conexão ao servidor VPN localizado na companhia. Uma vez a conexão estabelecida, o cliente remoto pode comunicar com a rede da companhia através da rede pública com a mesma segurança como se estivesse dentro da própria LAN. VPN s para Internetworking Uma simples extensão da arquitectura de acessos remotos através de VPN ilustrada acima, permite a uma rede remota inteira (em vez de ser somente um único cliente remoto) juntarse à rede local. Em vez de uma ligação cliente-servidor, temos uma ligação servidor-servidor que une as duas redes formando assim uma intranet ou extranet estendida. VPN s no lado interno da firewall As intranets podem também utilizar a tecnologia VPN para implementarem o controlo de acessos a subnets individuais na sua rede privada. Deste modo, os clientes VPN ligam-se ao servidor VPN que actua como um gateway para os computadores por detrás deste na subnet. Contudo, tira proveito das capacidades de segurança e conveniência da tecnologia VPN. O que é uma VPN e o que é que faz? As VPN s não oferecem nenhum serviço de rede que já não seja oferecido através de mecanismos alternativos. Contudo, uma VPN utiliza uma mistura de tecnologias que prometem melhorar as abordagens tradicionais. Linhas dedicadas tradicionais Tradicionalmente uma organização que queira construir uma wide-area network precisa de linhas dedicadas para ligar as suas secções entre si. Somente grandes companhias podem suportar o custo destas linhas para poderem ter o privilégio de usar cabos que não são usados por mais ninguém. Uma organização típica instala uma linha dedicada WAN para suportar uma intranet de longa distância. Além de partilha de ficheiros e e-mail, estas WANs providenciam acesso às páginas Web da empresa e a sistemas de vídeo conferência. Existem também Rui Sousa 7
algumas organizações que abrem o acesso à sua WAN a certos parceiros de negócio para providenciar serviços extranet. A tecnologia por detrás das VPN s No desenvolvimento das VPN s vários protocolos tornaram-se populares, tais como: PPTP L2TP IPSec SOCKS CIPE Estes protocolos dão ênfase à autenticação e encriptação nas VPN s. A autenticação permite aos clientes e servidores VPN s estabelecerem correctamente a identidade das pessoas na rede. A encriptação permite que dados potencialmente sensíveis sejam escondidos dos público em geral. Muitos vendedores desenvolveram produtos de hardware e/ou software de VPN s, mas infelizmente standards VPN imaturos implicam que parte destes produtos sejam incompatíveis uns com os outros. Vários protocolos de rede interessantes têm sido implementados para o uso com as VPN s. Estes protocolos tentam fechar algumas falhas de segurança próprias das VPN s, e continuam a competir entre si para serem aceites pela indústria. Point-to-Point Tunneling Protocol (PPTP) O PPTP é uma especificação de um protocolo desenvolvido por várias companhias. As pessoas geralmente associam o PPTP com a Microsoft porque quase todos os Windows incluem suporte próprio de base para este protocolo. As versões iniciais do PPTP para Windows pela Microsoft continham certas características de segurança que, segundo alguns peritos, eram demasiado frágeis para uma utilização a séria. A Microsoft continua contudo a melhorar o suporte para o PPTP. A principal força do PPTP é a capacidade de suportar outros protocolos além do IP. O maior retrocesso do PPTP é a falta de um standard para a encriptação e autenticação. Dois produtos que possam ser perfeitamente compatíveis com as especificações PPTP podem ser completamente incompatíveis com eles próprios se encriptarem os dados de maneira diferente. Layer Two Tunneling Protocol (L2TP) O competidor original do PPTP nas soluções VPN era o L2F um protocolo implementado pela Cisco. Na tentativa de melhorar o L2F, as melhores características deste com o PPTP foram combinadas para criar este novo standard chamado L2TP. O L2TP existe na camada de ligação de dados (camada dois) no modelo OSI daí vem a origem do seu nome, layer 2. Tal como o PPTP, o L2TP suporta outros clientes além dos clientes IP. Também falha na definição de um standard de encriptação. Mas no entanto, o L2TP suporta VPN s que usem outros protocolos, além do TCP/IP, tais como a frame relay, ATM, e SONET. Internet Protocol Security (IPSec) O IPsec é actualmente uma colecção de múltiplos protocolos relacionados. Pode ser usado como uma solução VPN completa, ou pode ser unicamente usada como um esquema de encriptação dentro do L2TP ou PPTP. O IPsec existe na camada de rede (camada três) na pilha OSI. 8 Rui Sousa
O IPsec estende o IP standard com o intuito de suportar serviços baseados em Internet mais seguros (incluindo, mas não limitados unicamente a, VPN s). O IPSec protege especificamente contra ataques do estilo man in the middle ao esconder os endereços IP que apareceriam nos pacotes. SOCKS Network Security Protocol O sistema SOCKS providencia para as VPN s uma alternativa única para a utilização de outros protocolos. As funções SOCKS situam-se na camada de sessão (camada cinco) no modelo OSI, enquanto todos os outros protocolos VPN s se encontram nas camadas dois e três. Esta implementação oferece vantagens e desvantagens sobre a escolha de outros protocolos. Ao funcionar num nível mais elevado, o SOCKS permite aos administradores limitar o tráfego VPN a certas aplicações. Porém para usar o SOCKS os administradores devem configurar os servidores proxy SOCKS dentro do ambiente dos clientes assim como o software SOCKS nos próprios clientes. CIPE (Crypto IP Encapsulation) O CIPE é um dispositivo para a encriptação, ao nível do kernel, de um túnel IP. Isto pode ser usado para construir routers de encriptação para VPN s (Virtual Private Networks) e aplicações similares, este protocolo está mais talhado para configurações de grandes empresas. O método de funcionamento baseia-se na encriptação de pacotes IP, que atravessam o túnel, para pacotes UDP. O protocolo foi desenhado para ser pouco pesado nas comunicações e simples na sua utilização. Foi tomado um cuidado especial para fazer este protocolo funcionar para endereços dinâmicos, proxies NAT e SOCKS. As implementações estão actualmente disponíveis para Linux e Windows. O material de Windows está sendo desenvolvido por Damion K. Wilson e pode ser encontrado na página do CIPE para Windows. Segurança da VPN O grande objectivo das VPN s é garantir que os dados estejam seguros, mas mesmo os seus mecanismos de segurança podem ser quebrados. Particularmente na Internet, hackers sofisticados com grandes quantidades de tempos livres irão igualmente trabalhar no duro para roubar os dados da VPN, caso eles acreditem que estes dados contenham informações valiosas, tais como os números de cartões de crédito. A grande parte das tecnologias VPN implementam uma encriptação forte de modo que os dados não possam ser vistos directamente utilizando sniffers de rede. As VPN s podem ser mais susceptíveis aos ataques man in the middle, que consiste em interceptar a sessão e fazer-se passar por cliente ou servidor. Além do mais, certos dados privados podem não ser encriptados pela VPN antes de serem transmitidos pela linha pública. Os cabeçalhos IP, por exemplo, irão conter os endereços IP de ambos (cliente e servidor). Os hackers podem capturar estes endereços e escolher como alvo estes dispositivos para ataques futuros. Categorias de VPN Muitos vendedores oferecem um leque enorme de produtos relacionados com VPN s. Estes produtos algumas vezes não funcionam entre si por causa da escolha de protocolos incompatíveis (como foi descrito acima) ou simplesmente por falta de testes standards. Embora exista um grande número (e cada vez mais a aumentar) de produtos VPN, todos estes pertencem a uma destas categorias: sistemas VPN baseados em hardware, VPN s baseadas em firewalls e pacotes de aplicações VPN. Rui Sousa 9
A maior parte dos sistemas VPN baseados em hardware são routers eficientes que integram a funcionalidade de encriptação. Estes são seguros e fáceis de usar, pois o equipamento de encriptação que providenciam é muito plug and play. Estes sistemas tem disponível uma maior performance de rede do que todos os outros sistemas VPN, pois estes não gastam overhead do processador na execução do sistema operativo ou qualquer outra aplicação. Contudo, podem não ser tão flexíveis como os sistemas baseados em software. Os melhores produtos de sistemas VPN baseados em hardware oferecem somente software cliente para a instalação remota, e engloba algumas características de controle de acesso que são tradicionalmente geridas pelas firewalls e outros dispositivos de segurança do perímetro. As VPN's baseadas em firewalls tiram partido dos mecanismos de segurança das próprias firewalls, incluindo o acesso restrito à rede interna. Também proporcionam a tradução de endereços; satisfazem os pedidos de uma forte autenticação; e disponibilizam alarmes em tempo real além de registar os eventos num log extenso. A maior parte das firewalls comerciais artilham o kernel do sistema operativo retirando os serviços perigosos e desnecessários, providenciando uma segurança adicional ao servidor VPN. A protecção do sistema operativo é uma grande vantagem, pois são poucas as aplicações de VPN comerciais que disponibilizam ajuda sobre este capítulo. A performance pode ser um problema, especialmente se a firewall já estiver sobrecarregada com processamentos, contudo, algumas firewalls comerciais vem com processadores de encriptação baseados em hardware para minimizar o impacto da administração da VPN no sistema. As VPN s baseadas em software são ideais para situações onde ambos os pontos terminais da VPN não são controlados pela mesma organização (são típicas em suporte para clientes e parcerias de negócios), ou quando existem implementações de firewalls e routers diferentes dentro da própria organização. De momento, as standalone VPN s oferecem grande flexibilidade no modo em como o tráfego da rede é gerido. Muitos produtos baseados em software permitem que o tráfego passe pelo túnel baseando-se no endereço ou protocolo, e não como nos produtos baseados no hardware, que geralmente enviam todo o tráfego que manuseiam através do túnel, sem olharem para o protocolo utilizado. Fazer tunneling de um tipo específico de tráfego é vantajoso em situações onde os locais remotos consigam ver uma mistura de tráfego, alguns que precisam ser transportados através da VPN (tais como entradas para uma base de dados na central) e alguns que não precisam (tal como, a visualização de páginas Web). Em situações onde os requisitos de performance são modestos (tais como utilizadores conectando-se através de ligações dial-up), VPN s baseadas em software são a melhor opção. Mas estes sistemas são mais difíceis de gerir do que routers de encriptação. Estes precisam que estejamos familiarizados com o sistema operativo da máquina, com a própria aplicação, e com os mecanismos de segurança apropriados. E alguns pacotes de software de VPN precisam de mudanças nas tabelas de routing e nos esquemas de endereçamento da rede. VPN prós e contras Na realidade as VPN s providenciam somente algumas potenciais vantagens básicas e fáceis de compreender sobre as formas mais tradicionais de wide-area networking. Estas vantagens podem ser realmente significantes, mas nem todas são gratuitas. Os potenciais problemas com as VPN s ultrapassam as vantagens e são geralmente mais difíceis de compreender. (As desvantagens não tem necessariamente mais peso do que as vantagens). Desde os capítulos de segurança e performance para com um largo leque de produtos comerciais que algumas vezes são incompatíveis, contudo a decisão de utilizar uma VPN ou não deve ser feita através de planeamento e preparação correcta. Vantagens de uma VPN As VPN s prometem duas vantagens sobre outras abordagens competitivas, a diminuição de custos e a escalabilidade (que é outra forma da diminuição de custos). 10 Rui Sousa
O baixo custo de uma VPN Uma maneira de uma VPN baixar os custos é eliminando a necessidade de linhas dedicadas de longa distância muito caras. Com as VPN s, uma organização precisa unicamente uma ligação relativamente curta ao fornecedor de serviços Internet (ISP). Esta ligação pode ser uma linha dedicada local (mais barata do que uma linha dedicada de longa distância), ou pode ser uma ligação local tal como o DSL. Outra maneira das VPN s reduzirem os custos é ao cortarem a necessidade de chamadas de longa distância para acessos remotos. É de recordar que para providenciar o serviço de acesso remoto, os clientes VPN precisam apenas ligar ao ISP mais próximo. Em certos casos podem na mesma implicar uma chamada de longa distância, mas na maior parte dos casos esta chamada deverá ser local. A terceira, e o modo mais subtil de uma VPN baixar os custos é através do pouco suporte que é necessário dar. Com as VPN s, o fornecedor de serviços em vez da organização deve fornecer suporte para o acesso dial-up, por exemplo. Os ISPs podem na teoria cobrar muito menos pelo suporte dado do que o suporte dado internamente na companhia, porque o custo de um fornecedor público é partilhado por entre milhares de clientes. Escalabilidade e VPN s O custo para uma organização de linhas dedicadas tradicionais pode ser razoável no princípio, mas pode aumentar exponencialmente à medida que a organização cresce. Uma companhia com dois escritórios, por exemplo, pode colocar unicamente uma linha dedicada para ligar estes dois sítios. Se um terceiro escritório precisa de estar também on-line, irão ser necessárias mais duas linhas para ligar directamente esta nova localização com as outras já existentes. Porém, como uma organização cresce e mais companhias devem ser adicionadas à rede, o número de linhas dedicadas precisas aumentam dramaticamente. Quatro escritórios precisam de seis linhas para conectividade total, cinco precisam de dez linhas, e por aí fora. Os matemáticos chamam a este fenómeno de explosão combinatória, e numa WAN tradicional esta explosão limita a flexibilidade do crescimento. As VPN s que utilizem a Internet evitam este problema ao simplesmente ligarem-se a um acesso já disponível, qualquer que seja a sua distribuição geográfica. Desvantagens das VPN s Com a publicidade que rodeou historicamente as VPN s, as potenciais armadilhas ou pontos fracos no modelo VPN podem ser facilmente esquecidas. Estas quatro preocupações com as soluções VPN são muitas vezes levantadas. 1. As VPN s precisam uma compreensão profunda dos problemas de segurança da rede pública e da entrega de precauções próprias. 2. A disponibilidade e performance de uma VPN wide-area (particularmnete sobre a Internet) de uma organização, dependem de factores largamente fora do seu controle. 3. As tecnologias VPN de vendedores diferentes podem não funcionar bem em conjunto devido a standards imaturos. 4. As VPN s precisam de acomodar outros protocolos além do IP e tecnologia existente da rede interna (legada). Genericamente falando, estes quatro factores englobam os custos escondidos de uma solução VPN. Os defensores das VPN s dizem que a poupança de custos é a vantagem primordial desta tecnologia, enquanto os opositores citam estes custos escondidos como a principal desvantagem da utilização das VPN s. Rui Sousa 11
O futuro das VPN s O sucesso das VPN s no futuro depende fundamentalmente na dinâmica da indústria. O maior valor das VPN s reside no seu potencial para as empresas de poupar dinheiro. Se o custo das chamadas de longa distância e das linhas dedicadas continuarem a baixar, poucas serão as companhias que sintam a necessidade de mudar para VPN s para acessos remotos. Mas se os standards VPN solidificarem e os vendedores de produtos VPN interoperarem inteiramente com outros produtos, a atracção das VPN s irá subir. Este sucesso também depende da disponibilidade das intranets e extranets em entregar as suas promessas. As empresas tem dificuldade em medir qual a redução de custos da sua rede privada, mas se for demonstrado que esta tecnologia providencia uma mais valia, o uso da tecnologia VPN internamente pode também vir a aumentar. 12 Rui Sousa
CIPE Introdução Camadas de rede Existem diversos lugares diferentes onde a encriptação pode ser feita na infra-estrutura de uma rede, correspondendo a diferentes camadas no protocolo: 1. Na "camada de rede": Os pacotes que viajam entre máquinas na rede são encriptados. O motor de encriptação é colocado perto do driver que emite e recebe pacotes. Uma implementação que encontramos no CIPE. 2. Na "camada de sockets": Uma conexão lógica entre os programas que são executados em máquinas diferentes (conexão TCP; a camada do transporte ou de sessão na pilha OSI) é encriptada. O dispositivo de encriptação intercepta ou funciona como proxy da ligação. O SSH e o SSL funcionam deste modo. 3. Na camada de aplicação : As aplicações contêm o seu próprio dispositivo de encriptação e elas mesmas encriptam os seus dados. O melhor exemplo deste método é o PGP para a encriptação do correio electrónico. A encriptação a baixo nível como é implementada no CIPE tem a vantagem de poder trabalhar de um modo transparente, sem ser preciso fazer qualquer alteração ao software da aplicação. No caso da encriptação de pacotes IP, pode ser realizada em routers IP que na maior parte das vezes funcionam como caixas negras que encaminham o tráfego entre máquinas, as próprias máquinas não vêm como este encaminhamento é realizado. Por isso um router de encriptação torna-se semelhante a um router que não seja de encriptação, pois não é notada nenhuma diferença pelas outras máquinas ou aplicações. Pode ser usado em locais onde as mudanças de software a níveis mais elevados não sejam fiáveis. A encriptação a baixo nível tem como desvantagem a impossibilidade de não proteger as intrusões num nível mais elevado (Ex.: aplicações troianas, exploração de falhas no sistema ou utilizadores com permissões elevadas a fazerem sniffing em terminais). Endereçamento IP e VPN s Uma VPN é uma rede 1 que pertence a uma organização, usando a sua gama de endereços próprios, mas coberta na infra-estrutura de rede existente. O IP-in-IP tunneling torna possível construir VPN s IP em cima de outras redes de transporte baseadas em IP, tal como a Internet. Os tuneis encriptados protegem os dados contra ataques passivos (sniffing) e activos (injecção de mensagens falsas) na rede de transporte. Assim a rede de transporte apenas vê os dados encriptados. Dependendo na escolha de protocolo, toda a informação original que vai nos pacotes pode ser encriptada. Isto inclui não apenas os dados actuais (payload) mas também os cabeçalhos TCP/IP, não deixando vestígios dos endereços e que serviços são usados. Os ataques de análise de tráfego, que tentam obter informação útil através do sniffing sobre quem contacta quem, tornam-se assim impraticáveis ou menos fiáveis. Uma técnica mais sofisticada de iludir os ataques de análise de tráfego implica a injecção de pacotes falsos (dummy) com informações inúteis na rede que os transporta, mas que não são distinguidos (ao nível da camada de transporte) de pacotes de dados reais. O encaminhamento IP numa solução VPN consiste no encaminhamento da rede de transporte, que na maior parte das situações é uma configuração standard Internet, e o encaminhamento da VPN é sobreposta a esta ligação. Isto é fácil quando a gama de endereços de transporte e 1 CIPE é uma aplicação de encaminhamento IP, este documento fala apenas de redes IP. Rui Sousa 13
VPN não se sobrepõem de modo algum. É muito comum que VPN s tenham gamas de endereços 10.0.0.0/8 e 192.168.0.0/16, que não fazem parte da Internet e que nunca entram em conflito com o endereçamento Internet actual: qualquer endereço dentro destas gamas deve ser local à organização que a usa. Um exemplo típico deste caso é o Exemplo 1 que iremos ver mais adiante. O standard IPSEC define que um conjunto de protocolos podem ser usados (entre outras coisas) para construir VPN s encriptadas. Contudo, o IPSEC é um protocolo pesado e complicado com uma larga quantidade de opções, o conjunto das implementações totais do protocolo raramente são usadas e alguns itens (tais como o gerenciamento de chaves) ainda não estão completamente resolvidos. O CIPE utiliza uma abordagem muito mais simples, onde muitas coisas podem ser parametrizadas (tal como a escolha do algoritmo de encriptação actualmente usado) no período de instalação. Isto limita a flexibilidade mas permite uma implementação mais simples (eficiente, facilidade de depuração de erros, etc.). Como funciona o CIPE O CIPE encapsula os datagramas IP encriptados em datagramas UDP e envia-os através do mecanismo UDP normal. Este mecanismo difere da encapsulação standard IP IP e por isso, o UDP foi escolhido, porque desta maneira os datagramas são mais facilmente distinguidos nos vários pontos terminais (este pontos terminais diferem uns dos outros) pelos números das portas; porque um número do protocolo IP precisa de um registo formal; e porque o manuseamento dos datagramas UDP é mais fácil de utilizar do que usar um número separado do protocolo IP, especialmente em configurações de firewalls. O UDP pode ser especificamente usado ao nível do utilizador por aplicações tais como o SOCKS5. Uma conexão CIPE liga sempre dois pontos terminais. De qualquer modo, a conexão funciona (de um modo similar) como uma conexão dial-up PPP. De momento, cada conexão tem a sua própria chave secreta de 128-bit que tem de ser conhecida por ambos os pontos (e mais ninguém). Esta ligação de chaves (chamada chave estática na descrição do protocolo) é usada para negociar a mudança frequente da chave dinâmica, que encripta os dados actuais. Desde da versão 1.5 do CIPE que também é possível negociar chaves através do mecanismo de chaves públicas, semelhante ao pacote SSH. Isto retira a necessidade de chaves secretas partilhadas. Componentes do software CIPE O pacote CIPE consiste num modulo kernel e um programa. O modulo kernel faz o tratamento dos pacotes IP: envio e recepção dos pacotes, e encapsulação (incluindo a encriptação). É implementado um dispositivo de rede, que é tratado como qualquer outro dispositivo de rede, sendo toda a configuração e o processo de troca de chaves processados pelo programa ao nível do utilizador, chamado ciped. O ciped é muito parecido e comporta-se de um modo semelhante ao pppd. De uma maneira em particular, a abertura e o fecho de um dispositivo CIPE está ligado ao início e fim de um processo ciped (um por dispositivo), as especificações de opções na instalação do daemon pppd e ciped invocam scripts na abertura e fecho do dispositivo. O programa pkcipe é um programa adicional ao ciped que maneja as chaves e outros parâmetros. Notas do funcionamento interno O modulo consiste num driver de output, um driver de input, de rotinas de encapsulamento e algo para manter tudo isto ligado. O driver de output é uma versão que é muito usada do 14 Rui Sousa
new_tunnel da distribuição 2 Linux. No Linux 2.0 o envio de pacotes é feita via IP forwarding do kernel. Isto implica que: a) O IP fowarding deve estar activo no kernel b) Os pacotes encriptados, sendo pacotes UDP com o endereço de origem/destino chamadas me e peer, são verificadas nas regras da firewall que depois executa o seu forwarding para o seu destino final, caso sejam concordantes com estas regras (o mesmo se passa com os pacotes de output), senão são rejeitados ou revogados. Se isto não funcionar, primeiro é preciso ver se as regras da firewall deixam passar os pacotes! O driver de input é uma adaptação do receptor UDP do kernel. Para activa-lo, o ciped deve configurar o socket de um modo especial com a chamada do ioctl. Esta tem que ser um socket UDP conectado. A chamada da função ioctl_attach(2cipe) substitui as operações sendto(2) e recvfrom(2) dos sockets, por versões especiais que descodificam todo o tráfego interno e passam apenas blocos de trocas de chaves para o nível de utilizador. Todo o trabalho de descodificação e re-encaminhamento do tráfego que chega é feita dentro do recvfrom(2). Isto significa que ao contrário do IP forwarding, é chamado a partir do modo utilizador e o tempo necessário de CPU é acrescentado no processo ciped, contudo os dados nunca passam ao modo utilizador. O sendto(2) codifica o bloco como um bloco de troca de chaves e envia-o para o destino. O socket não deve usar read(2), write(2), select(2) ou o modo de nonblocking (pelo menos para já). Antes de adicionarmos o socket, os parametros operacionais do dispositivo devem ser activados usando a chamada ioctl_setpar(2cipe). O processo de troca de chaves fornece chaves ao kernel via ioctl_setkey(2cipe). O dispositivo de rede só pode ser aberto (UP) se tiver um socket de controle. Quando o socket de controle é fechado, o dispositivo de rede é também fechado. O oposto também se aplica, pois se fecharmos o dispositivo de rede (com ifconfig(8)) o socket de controle também é encerrado. O fecho implica que toda a informação que é enviada pelo ciped é apagada no dispositivo. Os dispositivos podem ser reservados e desocupados dinamicamente usando a chamada ioctl_alloc(2cipe). O primeiro dispositivo fica sempre reservado como um gancho para as chamadas ioctl. 2 Para o Linux 2.2, isto foi introduzido no modulo ipip, mas a funcionalidade é a mesma. Rui Sousa 15
Instalação do pacote de software CIPE O CIPE está disponível no seguinte endereço: http://sites.inka.de/~bigred/devel/cipe.html. É distribuído num ficheiro tar.gz e ocupa actualmente 138k. Depois de descompactada a distribuição, deve-se executar o script configure, e caso seja necessário, especificando outras opções. Após isto executa-se o make. Pré-requisitos Versões do kernel O CIPE funciona nas versões Linux 2.0.* a partir da versão 2.0.12, 2.1.* a partir da 2.1.103, 2.2.* e 2.3.*/2.4.* a partir da versão 2.3.48. Foi desenvolvido para a arquitectura i386; mas deve funcionar também para outras arquitecturas. Compilar os módulos Deve-se ter a certeza de que se tem o código fonte, ou pelo menos o directório include completo, do kernel instalado (geralmente em /usr/src/linux). A versão e configuração do código fonte do kernel deve coincidir com o kernel onde se vai executar o programa, senão corre-se o risco de se construir um modulo que não funciona. Também temos de usar a mesma versão do compilador que foi utilizado para compilar o kernel. Depois de reconfigurado e reconstruído o kernel, deve-se reconstruir também o modulo CIPE (isto também se aplica a todos os módulos externos compilados). É fortemente recomendado que se active os versioned symbols no kernel, porque assim temos protecção contra variações de versões entre o kernel e os módulos. A opção do kernel IP forwarding No kernel, nas versões 2.0, é necessário activar na sua configuração o IP Forwarding/Gatewaying. Temos de ter a certeza de activar o IP forwarding da seguinte maneira: echo 1 > /proc/sys/net/ipv4/ip_forward no arranque do sistema nas versões 2.2 ou mais recentes e nos kernels mais recentes 2.0. O dispositivo urandom deve estar disponível. Uma versão adequada de utilitários de módulos (modprobe e acompanhantes com este) deve ser instalada. Em caso de dúvida deve-se consultar a documentação do código fonte do kernel. A ferramenta PKCIPE precisa do pacote OpenSSL, versão 0.9.6 ou mais recentes. Se este não estiver disponível, o resto do pacote CIPE pode ser compilado na mesma e instalado da forma habitual. Como na versão 1.3, o CIPE utiliza um script de configuração autoconf-generated para configurar os ficheiros Makefiles. Este script tem à sua disposição parâmetros para a linha de comando. Todos os parâmetros têm valores por defeito que são suficientes para uma instalação simples. --with-linux=dir Caminho para o directório com o código fonte do Linux (Ex.: /usr/src/linux). --with-linux-include=dir Caminho para o directório include do Linux, caso não tenhamos o código fonte completo. Este directório deve conter todos os ficheiros gerados no processo de configuração do kernel. É preferível ter o código fonte completo (necessário em certas arquitecturas) porque nesse caso os parâmetros do Makefile do kernel são 16 Rui Sousa
também usados. --with-ssl-includes=dir Caminho para o directório de includes do OpenSSL, no caso do script não o encontre. --with-ssl-libs=dir Caminho para as livrarias do OpenSSL, no caso do script não o encontre. --enable-protocol=n Usar o protocolo de encapsulamento n. Os valores suportados no CIPE 1.5 são 3 e 4. Ver protocolos e cifras, para como escolher o valor adequado, o valor por defeito é o 3. --enable-idea Usa a cifra IDEA, o valor por defeito é Blowfish. --disable-debug Desactiva o código de depuração no módulo do kernel. Na verdade não é muito útil. --disable-dyndev Desactiva a atribuição do dispositivo dinâmico. Também não é muito útil. --enable-logfacility=x Coloca o syslog do ciped e o pkcipe apontar para outro ficheiro de log, o valor por defeito e geralmente correcto é LOG_DAEMON. --disable-asm Desactiva a utilização de código assembler, não é muito utilizado. --enable-name=n Coloca um nome para a directoria de compilação. --enable-bug-compatible Usa as chaves de interpretação velhas e quebradas, são chaves de versões anteriores do CIPE. --disable-send-config Não envia a informação da configuração para o destino. Isto é normalmente enviado no arranque para ajudar diagnóstico de ajuda de discrepâncias, mas é enviado desencriptado, o que pode não ser pretendido. --disable-pkcipe Não compila e nem instala a ferramenta PKCIPE. O script procura por certos parâmetros (como quando é realizada a compilação de um sistema SMP) nos cabeçalhos do kernel, e cria um novo directório, que se chama 2.2.6-i386-cb, na qual a compilação do módulo e do daemon tem lugar (isto acontece para a versão 2.2.6 do Linux com uma arquitectura i386, que utilize o protocolo 3 (c), e o Blowfish (b)). A ferramenta PKCIPE e alguns componentes da livraria são construídos nas directorias do seu código fonte, estas não dependem da configuração (em teoria, pois infelizmente o pkcipe está particularmente amarrado à utilização do ciped, mas isto está em vias de ser ultrapassado). Rui Sousa 17
Protocolos e cifras O CIPE suporta versões diferentes de protocolos de encriptação, que por sua vez podem ser utilizados com cifras diferentes (algoritmos de encriptação). Qualquer que seja usado é escolhido no tempo de compilação com os argumentos do script configure. Como na versão 1.5 do CIPE, as seguintes opções são possíveis: Protocolo versão 3: Este é o protocolo por defeito e recomendado para a maior parte das vezes. O dispositivo funciona como um dispositivo ponto por ponto unicamente IP muito semelhante com o SLIP ou o PPP. Protocolo versão 4: Este protocolo usa o mesmo formato dos dados como no protocolo 3, excepto que os pacotes transmitidos contêm cabeçalhos ao nível da camada de ligação compatíveis com a Ethernet. Com isto é possível executar outros protocolos payload sem ser o protocolo IP, e é particularmente possível fazer com que o dispositivo CIPE faça parte de uma bridge Ethernet. A desvantagem é que os pacotes são maiores do que os utilizados pelo protocolo 3. Pode ser necessário colocar o endereço MAC usando a opção hwaddr para tornála única ao longo da VPN. Com este protocolo, o dispositivo tem uma mascara de sub-rede e endereços de broadcast que podem ser colocados com as opções apropriadas. Blowfish: Este é o algoritmo de encriptação por defeito, usado com uma chave de 128 bit. IDEA: Um algoritmo de encriptação alternativo com uma chave de 128 bit. Este algoritmo é patenteado e pode necessitar de uma licença para o uso comercial. É incluído principalmente devido à compatibilidade com instalações mais antigas que possuem unicamente este algoritmo disponível. Como no CIPE 1.4, ambos o Blowfish e o IDEA estão disponíveis em implementações C genérico e assembler i386. As versões em assembler são usadas sempre que possível. Compilação avançada A utilização de uma directoria objecto separada significa que é possível compilar o CIPE para alvos separados na mesma directória. Um exemplo poderá ser uma máquina que tem kernels diferentes para testes, etc. Neste caso teremos directorias kernel tais como usr/src/linux- 2.0.36, /usr/src/linux-2.2.6, e por aí fora. Executando o configure withlinux=/usr/src/linux-2.0.36 e depois disso o configure withlinux=/usr/src/linux-2.2.6 deixa-nos com duas directorias, a directoria 2.0.36-i386-cb e a 2.2.6-i386-cb. Depois podemos executar o comando make separadamente em cada directoria objecto. Outro caso muito comum é uma configuração onde uma caixa (máquina) central compila os kernels para máquinas diferentes. Podemos renomear as directorias de compilação do CIPE com a opção -enable-name, se calhar a melhor opção será dar-lhe um nome da máquina alvo:./configure --with-linux=/usr/src/linux-2.2.6-bigbox \ --enable-name=bigbox make -C 2.2.6-i386-cb-bigbox./configure --with-linux=/usr/src/linux-2.2.6-satellite \ --enable-name=satellite make -C 2.2.6-i386-cb-satellite./configure --with-linux=/mounts/srv1/linux-2.2.5-small \ --enable-name=laptop make -C 2.2.5-i386-cb-laptop 18 Rui Sousa
Do mesmo modo as pessoas responsáveis pela manutenção da distribuição podem preparar um conjunto de módulos de configuração diferentes (IDEA versus Blowfish) para uma máquina alvo. Os nomes dos módulos e drivers são escolhidos de modo que as diferentes configurações possam coexistir numa máquina. É de notar que uma compilação realmente cruzada não é possível de momento, devido ao script configure que assume a arquitectura do sistema onde é executado. Instalação O comando make compila tudo. Os avisos de possíveis erros de compilação não deverão ocorrer. Executa-se o comando make install como root para instalar os componentes do software nos seus locais finais. Estes são módulos do kernel e o programa, ao qual (tal como o CIPE 1.3) é dado o nome depois da versão do protocolo e do algoritmo de encriptação. Os Makefiles aceitam opções semi-standards (BINDIR, MODDIR, INFODIR) para especificar onde os ficheiros são instalados. Se o PKCIPE foi compilado, o make install também instala o programa pkcipe e um programa de ajuda rsa-keygen, configura as directorias necessárias e gera uma chave para a máquina caso esta ainda não tenha nenhuma chave. É necessário criar a directoria /etc/cipe que contém pelo menos dois ficheiros, options e ipup. Podemos copiar os ficheiros da directoria samples da distribuição fornecida, e editá-los conforme as nossas necessidades. Erros de compilação Existe um problema conhecido em vários pré-lançamentos das versões 2.0.30 e 2.0.31 onde se discorda se contém determinada característica SO_BINDTODEVICE, e detectar a dependência destas versões através do número da versão não é cem porcento garantido. Aparentemente, só a partir da versão 2.0.32, este problema foi resolvido. Se o output.c não compilar na versão 2.0.*. deve-se mudar a linha para #ifdef SO_BINDTODEVICE #if 1 ou #if 0 como for necessário. Um problema semelhante existe nas versões de pré-lançamentos 2.3.99, onde a parte name da estrutura net_device foi alterada. Se um erro ocorrer durante a compilação do device.c dentro do 2.3.99pre-n, muda-se a definição condicional HAVE_DEVNAME_ARRAY no ficheiro cipe.h para #if 1 ou #if 0 como for necessário. A partir da versão 2.4.0 este problema foi resolvido. Execução do CIPE Uma vez instalado, o início da execução do software CIPE é feita pelo módulo loading e é executado o daemon ciped. Nomes dos programas O nome do módulo é cip seguido pela versão do protocolo com uma letra e pela primeira letra do algoritmo de encriptação. Por exemplo, cipcb implica que é utilizado o protocolo 3 ( c ), e o algoritmo de encriptação usado é o Blowfish (por defeito). O nome dos dispositivos que este módulo administra é o nome do módulo seguido por um número, por exemplo cipcb0. Rui Sousa 19