Opportunistic Encryption Guia

Transcrição

1 Opportunistic Encryption Guia Este guia destina-se a mostrar os passos seguidos por nós para a opportunistic encryption (OE) usando o Linux FreeS/WAN. OE permite criar túneis IPsec sem ser necessário a coordenação com o outro site administrador, nem configurar manualmente cada túnel. Introdução Se o opportunism estiver enabled, uma Geteway segura que estará a correr no FreeS/Wan irá interceptar o primeiro pacote para fora das fronteiras do PC, com um destino particular (morada IP), e irá tentar negociar um túnel seguro adaptando-se ao tráfego que irá para aquele destino. De modo a funcionar, a Gateway segura deverá negociar com os peers tentando proteger o tráfego iniciado por eles. O primeiro problema, será que a Gateway segura precisa de discobrir o endereço IP da outra Gateway segura para o pacote que inicia a negociação. Sendo que se não houver outra Gateway segura, essa negociação será impossivél. O segundo problema é que a Gateway segura precisa autenticar o outra Gateway segura. Esta autenticação precisa assegurar que a outra Gateway segura é que ela diz ser, e que esta autorizada a representar o cliente, o qual diz que é a gateway. Os papeis nesta fase particular da negociação são: Fonte ---- Iniciador Resposta --- Destino (Source----Initiator Responder----Destination) A fonte e o destino são pontos finais do tráfego que será protegido. A fonte será o primeiro a enviar o primeiro pacote de tráfego. Nenhum deles precisa de estar a par do IPSEC ou o FreeS/WAN. Este será o trabalho das respectivas Gateways seguras, iniciador e resposta. Os nomes iniciador (Iniciator) e resposta (Responder), coincidem com os que são usados no IPSEC. É bem possível que os dois possam estar presentes na mesma máquina, ou seja podem ser o mesmo. Todo o tráfego da fonte para o destino deve fluir através das suas Gateways seguras, para serem consideradas seguras. Iremos usar o DNS (Domain Name System) como uma base de dados que irá possuir toda a informação a ser distribuída. Requerimentos FreeS/WAN 2.02 ou posterior Controlo sobre o servidor DNS (para full oportunism) Para full oportunism um IP estático Nota: A nossa instalação decorreu numa versão Linux Debian com o Kernel

2 Procedimento Após a instalação do FreeS/Wan 2.04, iniciamos o ipsec: ipsec setup start Para verificarmos se a instalação foi bem sucedida, executamos: ipsec verify Deverá visualizar-se: Checking your system to see if IPsec got installed and started correctly Version check and ipsec on-path Checking for KLIPS support in kernel Checking for RSA private key (/etc/ipsec.secrets) Checking that pluto is running Escolhemos os nomes que identificam os nossos PCs no servidor. Os nomes escolhidos são os mesmos que o hostname: hostname --fqdn Gerámos um registo forward TXT que contém a nossa chave pública: ipsec showhostkey onde xy.exemplo.pt é o nosso hostname. Este comando utiliza o conteúdo de /etc/ipsec.secrets. O resultado é parecido com o seguinte: ; RSA 2192 bits xy.exemplo.pt Thu Jan 2 12:41: IN TXT "X-IPsec-Server(10)=@xy.exemplo.pt" "AQOF8tZ2 +bufufn/" - Em relação ao resultado obtido: isto é uma string simples, no que diz respeito ao DNS. - O X.IPsec-Server é um prefixo que significa que o arquivo TXT contém informação de configuração oportunista. - O (10) especifica uma precedência para este registo. Isto significa que é igual ao registo MX. Sendo os números de valor menor os que tem maior preferência Especifica o endereço IP da Gateway segura para esta máquina. - AQ0F8tZ2 +bufufn/ é a (encurtada) codificação da chave pública RSA da Gateway segura.

3 Publicámos este registo no servidor forward e reverse DNS. Para verificarmos se no servidor DNS está tudo ok: ipsec verify --host xy.exemplo.pt e como parte do verify output deverá aparecer: Looking for TXT in forward map: xy.exemplo.pt Passando através do DNS Os blocos outbound (fora de fronteiras) oportunistas, comunicam com um endereço IP até que o Pluto descubra quando esse endereço IP possa ter uma ligação IPSEC negociada. Esta descoberta acarreta trocas DNS. Estas trocas DNS podem envolver comunicações com endereços IP arbitrários. Embora precisemos trocas de DNS para sermos bem sucedidos nas comunicações anteriores, incluindo as mesmas trocas de DNS. O modo de sair deste ciclo, é libertar pelo menos algumas trocas do DNS no tráfego do IP com oportunismo. Existem várias soluções possíveis, todas as quais tem vantagens e desvantagens. 1.Caso esteja a utilizar apenas uma máquina, fora da sua Gateway segura, como servidor DNS, pode construir um caminho livre (ou até um túnel IPSEC, mas não oportunistico) directamente para essa máquina. - poderá usar type=passthrough conn de modo a providenciar um caminho livre entre essa maquina e a maquina DNS. - melhor ainda, pode criar explicitamente uma ligação IPSEC para o servidor DNS. Certifique-se que o Pluto não necessita do acesso DNS para encontrar o endereço IP ou a chave publica RSA para a ligação. - também poderá instalar uma rota até á maquina DNS através do seu interface publico (não ipsecn). Assim passara o processo KILPS. 2. Geralmente, é melhor correr o DNS na Gateway segura. Isto leva a que seja preciso caminhos não-oportunisticos para um número de servidores DNS na Internet. Uma maneira de fazer isto é não ter oportunismo outbound (fronteira) coberto pela SG, mas apenas na subnet que esta inserido. Ou seja: ipsec auto --route sg-to-anyone (não usado por nós) Deverá também adicionar uma type=passthrough eroute especificada para sg-to-anyone (sem isto, o tráfego será manejado pela politica KILPS no-eroute). 3. Actualmente é possível usar apenas uma máquina dentro da subnet do nosso cliente como um servidor DNS. As técnicas listadas em 1 podem ser usadas para deixar comunicar com outros servidores DBS sem interferências. Isto pode ter vantagens sobre o ponto 1 se a maquina DNS só fizer DNS.

4 Outra técnica (impossível muitas vezes) é fornecer á maquina outro caminho (route) para a Internet, um que evite a SG. 4. As trocas DNS eventualmente irão fazer time out e então o Pluto ira desistir e estabelecer %pass eroutes, de modo a que as comunicações comecem a fluir. Politicas Para dizer que hosts ou redes queremos que sejam cifrados temos que definir políticas, para tal basta colocar os endereços de hosts e/ou redes nos ficheiros das respectivas políticas e reiniciar o ipsec, no nosso caso não houve necessidade de recorrer á configuração destes ficheiros, pois tudo é feito automaticamente. Mas o que são as politica de grupo? As políticas de grupo são um mecanismo geral para configurar o FreeS/WAN. Elas são úteis para muitos utilizadores do FreeS/WAN. Em versões anteriores do FreeS/WAN, era preciso configurar cada ligação IPsec explicitamente, em cada local e em hosts remotos. Isto poderia a vir tornar-se complexo. Em contraste, as politicas de grupo permitem definir localmente politicas IPsec para uma lista de hosts remotos e redes, para isso basta simplesmente listar esses hosts e redes, os quais poderemos querer que tenha um tratamento diferente dos outros. Sendo assim o FreeS/WAN internamente cria as ligações necessárias de modo a implementar cada politica. Como saber o que se está a passar? Desde que o oportunismo deixa que a Gateway segura opera com menos supervisão, podemo-nos perguntar como estará ela a funcionar. A ferramenta usual existe, mas o seu uso é mais importante. Para vermos o que o Pluto está a fazer, usamos: ipsec auto status Para vermos o que o KILIPS está a fazer, usamos: ipsec look Para apenas vermos a tabela do kernel eroute, basta observar o ficheiro /proc/net/ipsec_eroute. Que contém uma descrição de todos os eroutes no kernel. Exemplo: /24 -> /0 => %trap /32 -> /32 => tun0x1002@ /32 -> /0 => %trap /32 -> /32 => %pass Devemos ler cada linha como: um pacote dentro da primeira subnet, destinada para a segunda subnet, sendo seguida pela Security Association Identity (SAID) especificada em ultimo. A primeira coluna é o número de (outbound) pacotes processados pela eroute.

5 Para shunt eroutes, o SAID é imprimido simplesmente como o tipo de shunt: %pass deixa o pacote passar sem o processar. %drop rejeita o pacote. %reject rejeita o pacote e avisa que o envia. %hold mantém o último pacote; rejeita os outros. %trap faz com que um pacote apanhado gere uma PF_KEY_ACQUIRE para um pedido de negociação; instala o correspondente %hold shunt e anexa este pacote ao %hold. Para outros eroutes, o SAID é imprimido em triplo: protocolo (três letras), SPI (numero de 32 bit em hex), e o endereço IP de destino. O protocolo inclui: tun esp IP a IP encapsulamento (usado para a maior parte dos túneis). ESP encapsulamento parte do grupo IPSEC SA. Então, olhando para outros exemplos de eroutes: /24 -> /0 => %trap Isto é uma TRAP (armadilha) (int 0x104) shunt eroute. Foi instalada pelo pluto de modo a que possa capturar todo o tráfico desde a subnet do cliente até qualquer local. Dez pacotes outbound (fora de fronteiras) foram capturados /32 -> /32 => tun0x1002@ Isto é um túnel eroute: os pacotes que vão de (dentro da subnet do nosso cliente) para serão encriptados e enviados até a SG Isto é resultante de uma negociação oportunista. 259 pacotes foram enviados através deste túnel /32 -> /0 => %trap Isto é outra TRAP (armadilha) shunt eroute. Serve para captar tráfico a partir da Gateway segura para qualquer local. Tendo sido capturados 71 pacotes outbound (exteriores) /32 -> /32 => %pass Isto é um %pass (passagem) (0x100) shunt eroute. Foi instalado quando uma tentativa de negociação oportunistica falhou devido ao domínio reverso de não ter um registo TXT compatível. Tendo passado 4119 pacotes.