Observação:

Usar o Firewall de Rede do OCI para proxy de encaminhamento de SSL e inspeção de entrada usando a regra de Decriptografia

Introdução

O serviço Oracle Cloud Infrastructure (OCI) Network Firewall é uma solução de firewall gerenciado baseada na nuvem que utiliza a tecnologia de firewall de última geração (NGFW) da Palo Alto Networks. Com seus recursos avançados de firewall baseado em aprendizado de máquina, o serviço OCI Network Firewall fornece proteção de alto nível para suas cargas de trabalho da OCI, sem esforço para uso dentro do ecossistema da OCI.

O Firewall de Rede do OCI inspeciona todas as solicitações, incluindo tráfego criptografado TLS (Transport Layer Security), à medida que passa pelo firewall. Com base nas suas regras de política de firewall definidas pelo usuário, o serviço pode tomar uma variedade de ações, incluindo permitir, rejeitar, eliminar, detecção de intrusão ou prevenção. Com esses recursos robustos, o Firewall de Rede da OCI é uma ferramenta poderosa para proteger suas cargas de trabalho da OCI de uma variedade de ameaças de segurança.

Objetivos

O objetivo deste tutorial é fornecer um guia abrangente para implementar o proxy de encaminhamento SSL e a inspeção de entrada usando regras de decriptografia no Firewall de Última Geração no OCI Cloud.

Seguindo este tutorial, você terá uma compreensão sólida do proxy de encaminhamento SSL e da inspeção de entrada usando regras de decriptografia e poderá aplicar esse conhecimento para proteger sua infraestrutura de rede no OCI Cloud.

Pré-requisitos

Observação: é recomendável que você tenha um ambiente de teste configurado no OCI para experimentar as configurações de firewall e as regras de decriptografia antes de implementá-las em um ambiente de Produção.

Arquitetura

Arquitetura

A política de firewall de Rede do OCI consiste em listas que incluem:

Caso de teste

Para este tutorial, criamos uma conexão SSH com a máquina Linux (em Sub-rede Pública: 129.146.201.118) pela Internet por meio de uma regra de segurança na política de firewall.

Agora você tem uma ideia de como as listas podem ser usadas para criar regras de segurança para seu firewall. Usando essa regra, fizemos um SSH para a máquina Linux.

Compreender a tecnologia de criptografia TLS/SSL

Observação:

TLS é um protocolo criptográfico que fornece segurança de ponta a ponta para quaisquer dados enviados entre aplicativos pela Internet. Os cenários mais comuns estão em uma navegação segura na web. No entanto, ele pode e também deve ser usado para outras aplicações, como e-mail, transferências de arquivos, vídeo/audioconferência, mensagens instantâneas e voz sobre IP, e assim por diante.

É importante entender que o TLS não protege dados em sistemas finais. Ele garante a entrega segura de dados pela Internet, evitando a possível escuta e/ou alteração do conteúdo que está sendo enviado (em trânsito). O TLS normalmente é implementado em cima do TCP para criptografar protocolos Application Layer como HTTP, FTP, SMTP e IMAP, embora também possa ser implementado no UDP, DCCP e SCTP.

Para proteger os dados, o TLS utiliza a tecnologia de criptografia para criptografar/descriptografar os dados em trânsito que estão sendo enviados pela internet. Abrangeremos termos e conceitos como criptografia simétrica e assimétrica, infraestrutura de chave pública (PKI) e certificados digitais X.509.

Para configurar, configurar e aplicar o Firewall de Última Geração à sua rede, você precisa entender como funcionam as conexões TLS (como https), incluindo a configuração e a implantação de certificados X.509 digitais.

Criptografia e tipos

A ideia por trás da criptografia é ocultar ou ocultar (criptografar) as informações que queremos enviar de A para B em um "canal inseguro". Um canal inseguro é um canal ou um caminho em que não podemos garantir que ninguém intercepte, roube ou modifique (escorra) as informações transmitidas de A a B e o contrário.

A criptografia nos permite proteger as informações que viajam por um canal inseguro, criptografando (ocultando) os dados originais para seu destino. Uma vez recebido pelo receptor, o receptor poderá decriptografar os dados criptografados recebidos em seu valor original.

Há dois tipos de criptografia: Simétrica e Assimétrica.

Criptografia simétrica

Para criptografar/descriptografar um pedaço de dados, os mecanismos de criptografia simétricos usam exatamente a mesma chave para criptografar e decriptografar os dados. Normalmente, isso é chamado de Chave mestre ou segredo compartilhado.

Criptografia de Chave Mestra

Embora pareça uma maneira fácil de alcançar a criptografia, o principal problema aqui é distribuir a chave principal entre as duas partes em um canal inseguro. Este processo de troca de chaves mestras será tratado neste tutorial usando diferentes técnicas, incluindo uma técnica explicada na seguinte seção: Criptografia assimétrica.

Alguns dos algoritmos de criptografia simétrica mais comuns são: AES128, AES256, Serpent, Camelia etc.

Criptografia assimétrica

Criptografia/criptografia assimétrica usa um par de chaves relacionadas com um relacionamento especial: Qualquer dado que você criptografa com uma das chaves de pares pode ser decriptografado SOMENTE POR a outra chave de par e a outra maneira de contornar.

Criptografia assimétrica

Normalmente, referimos essas chaves de par como Chave pública e Chave privada. A chave pública pode ser compartilhada com todos, enquanto a chave privada deve ser mantida secreta.

A criptografia assimétrica resolve o problema de distribuição de chaves usando chaves públicas para criptografia e chaves privadas para decriptografia (ou o contrário). O tradeoff, no entanto, é que os sistemas de criptografia assimétrica são muito lentos em comparação com os sistemas simétricos e exigem muito mais poder de computação devido aos seus comprimentos de chave muito mais longos.

Os algoritmos de criptografia simétrica são muito mais rápidos e exigem menos poder computacional, mas sua principal fraqueza é a distribuição de chaves, porque a mesma chave é usada para criptografar e decriptografar informações; essa chave deve ser distribuída a qualquer pessoa para acessar os dados.

O TLS usa criptografia assimétrica e simétrica, e não apenas para criptografar dados, mas para autenticar as partes envolvidas na conexão. Aqui é onde os certificados X.509 executam ação.

Certificados X.509

Um certificado X.509 é um certificado digital baseado no padrão ITU (International Telecommunications Union) X.509 amplamente aceito, que define o formato dos certificados de infraestrutura de chave pública (PKI ). Um certificado X.509 é arquitetado usando um par de chaves que consiste em uma chave pública relacionada e uma chave privada. Como mencionado acima, esse par de chaves é precisamente o par de chaves que são usadas na criptografia assimétrica, onde escolhemos uma como pública e a outra como privada. Lembre-se de que qualquer coisa que você criptografar com uma das chaves só pode ser descriptografada pela outra chave e o contrário.

Como você pode imaginar, a parte pública do par de chaves, como seu nome indica, é pública e pode ser distribuída frequentemente. A chave privada deve ser mantida e criptografada usando uma chave mestra no modo de criptografia simétrica, para que ninguém possa usá-la mesmo que seja roubada.

Além da chave pública, o certificado X.509 contém outras informações que representam uma identidade (um nome de host, uma organização ou um indivíduo), portanto, o certificado x.509 vincula essa identidade à chave pública contida.

A estrutura de um certificado digital X.509 v3 é a seguinte:

Certificado

Número da Versão

Número de Série

ID do Algoritmo de Assinatura

Nome do Emissor

Período de validade

Não Antes De

Não Depois De

Nome do assunto

Informações de Chave Pública do Assunto

Algoritmo de Chave Pública

Chave Pública do Assunto Esta é a CHAVE pública

Identificador Exclusivo do Emissor (opcional)

Identificador exclusivo do sujeito (opcional)

Extensões (opcional)

…

Algoritmo de Assinatura do Certificado

Assinatura do certificado

A chave pública está vinculada a uma identidade representada no nome do Assunto, que é uma string com o seguinte formato:

onde, Assunto: C = EUA, ST = Califórnia, L = Mountain View, O = Google LLC, CN = *.google.com

Portanto, essa identidade pertence ao Google, no país dos EUA, Estado da Califórnia e um nome comum como *.google.com.

Podemos usar esse certificado para atender dois propósitos: distribuir nossa chave pública E autenticar nossa identidade para outras pessoas. Tendo isso em mente, qualquer computador/móvel/dispositivo lá fora, ao receber o nosso certificado, ele possuirá a nossa chave e identidade públicas, portanto, ele será capaz de enviar informações criptografadas usando a chave pública, e só nós poderemos descriptografá-lo (com a chave privada). Além disso, o certificado possui nossa identidade interna, de modo que o dispositivo que o recebe poderá confiar nessa identidade e ter certeza de que está trocando informações com a identidade certa.

Como mencionamos acima, a criptografia assimétrica por meio de chaves públicas/privadas é muito mais lenta do que a criptografia simétrica (x4 ou mais) de modo que não é viável. Além disso, não explicamos como o dispositivo que recebe o certificado pode realmente confiar na identidade dentro do certificado. No final, o certificado X.509 é apenas um trecho de texto recebido em um canal inseguro. Para confiar/autenticar um certificado recebido, exigimos uma Autoridade de Certificação, uma organização que é confiável para assinar certificados digitais. Uma Autoridade de Certificação verifica a identidade e a legitimidade da empresa ou do indivíduo que solicitou um certificado e, se a verificação for bem-sucedida, a CA emite o certificado assinado. Exemplos de organizações da CA são Oracle, VeriSign , D-Trust, DigiCert entre muitos outros.

Da perspectiva da criptografia, como funciona esse processo de assinatura? Mais uma vez, usaremos o poder da criptografia assimétrica para isso, como se segue:

Portanto, agora que temos nosso certificado X.509 pronto para agir. Como um computador/móvel/dispositivo que recebe este certificado durante uma conexão TLS pode verificar se ele é um certificado X.509 válido? Mais uma vez, usaremos o poder da criptografia assimétrica, como se segue:

Agora que sabemos que temos um certificado válido que inclui o nome de domínio com o qual estamos tentando nos conectar, por exemplo, www.mycompanycomain.com (incluído no nome comum ou nos campos de nome Alternativo do Assunto do Certificado), o computador/móvel/navegador garantirá que estamos realmente nos conectando a esse nome de domínio DNS (www.mycompanycomain.com) e não a outro. Esta é uma validação obrigatória, pois qualquer um pode roubar o certificado X.509 e tentar usá-lo em outro servidor de domínio DNS (www.myfakecompany.com etc.) e passaria pelo processo de validação de assinatura da CA.

Assim, agora todos os computadores/mobiles/dispositivos lá fora podem baixar a chave pública do nosso certificado e enviar dados criptografados para que só possamos descriptografá-lo. Como a criptografia assimétrica é muito mais lenta do que a criptografia simétrica (x4 ou mais), ela não é viável. A solução é usar ambos, e é nesse caso que o SSL/TLS é obrigatório.

Noções básicas de TLS

TLS é um protocolo criptográfico que fornece segurança de ponta a ponta dos dados que estão sendo enviados entre aplicativos pela Internet. Ele é familiarizado principalmente com os usuários por meio de seu uso na navegação segura na web, e em particular o ícone de cadeado que aparece em navegadores da web quando uma sessão segura é estabelecida.

O TLS usa uma combinação de criptografia simétrica e assimétrica, pois fornece um bom compromisso entre desempenho e segurança ao transmitir dados de forma segura. Lembre-se de que a criptografia assimétrica requer 4x ou mais potência computacional do que a criptografia simétrica. No entanto, a criptografia simétrica requer que a mesma chave mestra em ambos os lados da comunicação possa criptografar/descriptografar a mensagem. Portanto, o objetivo do uso da criptografia simétrica é, ser capaz de trocar a mensagem chave mestra (ou segredo compartilhado) entre as duas partes por um canal inseguro primeiro e, em seguida, comece a usar essa chave mestra para proteger a comunicação, criptografando/descriptografando cada mensagem sendo enviada/recebida usando o mecanismo simétrico escolhido.

TLS, imagem do hacker

Para trocar uma chave mestra por um canal não seguro, o TLS usará duas técnicas diferentes que segue o mesmo objetivo, que é trocar a chave mestra/segredo compartilhado com segurança em um canal não seguro:

A metodologia RSA se baseará no uso do poder da criptografia assimétrica (chave privada e pública) para trocar a chave mestra por um canal não seguro.

DHE/ECDHE conta com o uso de cálculos matemáticos para gerar a mesma chave mestra entre duas partes em um canal não seguro. Ambas as partes trocarão certas informações benignas que serão misturadas com suas informações privilegiadas à medida que viajam por um canal inseguro e podem ser capturadas sem qualquer risco. No final da negociação, ambos os cálculos matemáticos das duas partes terminarão no mesmo segredo comum ou chave mestra. Mais informações https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange

Essas duas principais metodologias de intercâmbio ocorrem durante um processo chamado TLS handshake.

TLS handshake sem máscara

Um handshake SSL/TLS é uma negociação entre duas partes em uma rede - como um navegador e um servidor Web - para estabelecer os detalhes de suas conexões. Durante essa negociação, as duas partes autenticarão (usando certificados X509), concordo com uma suíte de cifragem (como a chave mestra será trocada e quais mecanismos de criptografia serão usados, como hash AES256, 128 como SHA1, 2 etc.) e finalmente, quando a autenticação ocorrer (certificado válido recebido) e acordo sobre como estabelecer um canal seguro é feito, então, teremos um canal seguro de ambas as partes. Estas são as etapas reais:

TLS handshake

Observe que no gráfico acima, estamos usando o RSA (chave privada/pública) para trocar a chave mestra (ou segredo compartilhado) a ser usada no mecanismo de criptografia simétrica acordado (ou seja, AES256 ) durante a negociação da suíte de cifragem. Se a DHE/ECDHE fosse usada, em vez de usar chave pública e privada para trocar a chave mestra, ambas as partes usariam cálculos de DHE, trocando material benigno, para calcular o mesmo resultado em ambos os lados. Esse resultado se tornará a chave mestra (segredo compartilhado) a ser usada para criptografia simétrica.

Tarefa 1: Usar o Firewall de Rede do OCI para proxy de encaminhamento e inspeção de entrada SSL usando a regra de decriptografia

  1. Crie dois certificados autoassinados usando openssl para tráfego de saída e inspeção de entrada usando SSL aberto na máquina Linux. Atualize a máquina Linux para confiar no certificado.

    Criação de certificados autoassinados

  2. Crie um Vault no OCI.

    Vault

  3. Depois que o Vault for criado, Crie uma Chave. O conteúdo do Segredo deve estar no seguinte formato.

    {

"caCertOrderedList":

[

"-----BEGIN CERTIFICATE

-----END CERTIFICATE-----\n"

],

"certKeyPair":

{

"cert" : "-----BEGIN CERTIFICATE

-----END CERTIFICATE----\n",

"key": "-----BEGIN RSA PRIVATE KEY

-----END RSA PRIVATE KEY----\n"

}

}

  4. Na política de firewall de rede, adicione o segredo mapeado.

    1. Escolha o tipo de Segredo Mapeado como Proxy de encaminhamento SSL ou inspeção de entrada SSL.

    2. Escolha o Vault criado.

    3. Escolha o segredo.

    4. Adicione o segredo mapeado.

      Segredo Mapeado

  5. Crie um perfil de decriptografia.

    1. Escolha o Proxy de Encaminhamento de SSL e verifique as opções de verificação do Certificado do Servidor ou escolha a inspeção de entrada de SSL e verifique as verificações de modo não suportadas necessárias para seu tráfego.

      encaminhamento do perfil de decriptografia

      entrada do perfil de decriptografia

    2. Adicione um Perfil de decriptografia.

      Adicionando perfil de decriptografia

  6. Crie uma Regra de Decriptografia.

    1. Selecione Endereços IP de Origem na lista de endereços IP que você criou na política ou escolha qualquer um.

    2. Selecione Endereços IP de Destino na lista de endereços IP que você criou na política ou escolha qualquer um.

      Endereço IP de destino

    3. Selecione Ação para descriptografar o tráfego com proxy de encaminhamento SSL, entrada SSL ou sem decriptografia.

    4. Escolha o Perfil de decriptografia e o Segredo Mapeado.

      Determinação do perfil de depreciação

Depois que a política for atualizada com a regra de decriptografia, ela poderá ser anexada ao firewall.

Tarefa 2: Anexar uma política ao firewall

Quando você estiver criando o Firewall de Rede, ele dará a você uma opção para escolher a política que deve ser anexada ao firewall.

Anexo NetworkFirewall

Criamos uma regra de decriptografia para decriptografar o tráfego por meio do proxy de encaminhamento SSL e outra para inspeção de entrada SSL. Conforme mencionado para conexão de saída SSL, todo o tráfego da nossa sub-rede pública vai para o Firewall de Rede do OCI e por meio do Firewall de Rede do OCI, ele está tomando um caminho do Gateway de Internet para a Internet.

Para inspeção de entrada, ele passa pelo Gateway de Internet levando o próximo HOP como o firewall e, em seguida, acessando nossa máquina Linux na sub-rede pública.

De acordo com a regra de decriptografia, para o endereço IP de origem, usamos o Hub-Linux-Machine e para qualquer endereço IP de destino, o tráfego deve ser descriptografado pelo proxy de encaminhamento SSL e para conexões de entrada para origem como qualquer e destino como Hub-Linux-Machine, ele deve decriptografar o tráfego com inspeção de entrada SSL.

Regras de decriptografia

Observação: Para qualquer tráfego que atinja o firewall, ele primeiro verifica as regras de Decriptografia e, em seguida, as regras de segurança.

Pergunta: Como posso identificar que a regra de Decriptografia está em vigor para o tráfego que atinge o firewall?

Resposta: Isso pode ser visto nas métricas com um nome de contagem de ocorrências da regra de decriptografia anexada ao firewall.

Toda vez que a máquina Linux tenta acessar sites https na Internet ou para qualquer conexão de entrada com a máquina Linux em https, a contagem de ocorrências da regra de de decriptografia aumenta.

Métrica do Serviço Network Firewall

Tarefa 3: Usar a regra de decriptografia com uma regra de segurança para permitir ou negar tráfego

Adicionando ao caso de uso acima, vamos ver como a regra de decriptografia pode ser usada com uma regra de segurança para permitir ou negar tráfego. Conforme mencionado no início do caso de teste, podemos usar listas para permitir ou negar o tráfego.

Aqui já criamos uma regra de decriptografia para proxy de encaminhamento SSL e inspeção SSL de entrada. Para fins de teste, criamos uma regra de segurança para conexões de saída da máquina Hub Linux com a Internet para permitir acesso a *.oracle.com.

Observação: Por padrão, todo o acesso ao tráfego é negado no firewall da Rede do OCI. Uma regra precisa ser criada para o tráfego que deve ser permitido.

Lista de URLs:

Lista de URLs

Regra de Segurança:

Regra de Segurança

Agora o que acontecerá quando a máquina Linux tentar acessar *.oracle.com na Internet por meio do Firewall de Rede do OCI.

Pergunta: Como posso ver qual regra está ocorrendo para o tráfego?

Resposta: Ela pode ser vista nos logs do Firewall de Rede do OCI.

Para oracle.com

Logs do Firewall de Rede 1

Para qualquer outro URL:

Logs do Firewall de Rede 2

Aquisições

Autores - Luis Catalán Hernández (Especialista em Rede em Nuvem do OCI e Multi Cloud), Sachin Sharma (Especialista em Nuvem Sênior do OCI)

Mais Recursos de Aprendizagem

Explore outros laboratórios no site docs.oracle.com/learn ou acesse mais conteúdo de aprendizado gratuito no canal YouTube do Oracle Learning. Além disso, visite education.oracle.com/learning-explorer para se tornar um Oracle Learning Explorer.

Para obter a documentação do produto, visite o Oracle Help Center.