Segurança informática é um termo geral que cobre uma ampla área de computação e processamento de informações. As indústrias que dependem de sistemas e redes de computadores para realizar transações comerciais diárias e acessar informações críticas consideram seus dados como uma parte importante de seu patrimônio geral. Vários termos e métricas entraram em nosso vocabulário comercial diário, tais como custo total de propriedade (TCO), retorno do investimento (ROI) e qualidade do serviço (QoS). Usando essas métricas, as indústrias podem calcular aspectos como integridade de dados e alta disponibilidade (HA) como parte de seus custos de planejamento e gerenciamento de processos. Em alguns setores, como o comércio eletrônico, a disponibilidade e confiabilidade dos dados pode significar a diferença entre o sucesso e o fracasso.

As empresas de todos os setores dependem de regulamentações e regras que são estabelecidas por organismos de normalização como a Associação Médica Americana (AMA) ou o Institute of Electrical and Electronics Engineers (IEEE). Os mesmos conceitos são válidos para a segurança da informação. Muitos consultores e fornecedores de segurança concordam com o modelo de segurança padrão conhecido como CIA, ou Confidentiality, Integrity, and Availability. Este modelo de três níveis é um componente geralmente aceito para avaliar os riscos de informações sensíveis e estabelecer uma política de segurança. A seguir, descrevemos o modelo da CIA em mais detalhes:

O Red Hat Enterprise Linux passa por várias certificações de segurança, tais como FIPS 140-2 ou Common Criteria (CC), para garantir que as melhores práticas da indústria sejam seguidas.

O RHEL 8 core crypto components O artigo Knowledgebase fornece uma visão geral dos principais componentes criptográficos do Red Hat Enterprise Linux 8, documentando quais são eles, como são selecionados, como são integrados ao sistema operacional, como suportam módulos de segurança de hardware e cartões inteligentes e como as certificações criptográficas se aplicam a eles.

A segurança de computadores é freqüentemente dividida em três categorias principais distintas, comumente referidas como controls:

Essas três grandes categorias definem os principais objetivos de uma implementação adequada da segurança. Dentro destes controles estão subcategorias que detalham ainda mais os controles e como implementá-los.

Com tempo, recursos e motivação, um atacante pode entrar em quase qualquer sistema. Todos os procedimentos e tecnologias de segurança atualmente disponíveis não podem garantir que qualquer sistema esteja completamente a salvo de intrusões. Os roteadores ajudam a proteger os gateways para a Internet. Os firewalls ajudam a proteger a borda da rede. Redes Privadas Virtuais passam dados com segurança em um fluxo criptografado. Os sistemas de detecção de intrusão advertem sobre atividades maliciosas. Entretanto, o sucesso de cada uma destas tecnologias depende de uma série de variáveis, inclusive:

Dado o estado dinâmico dos sistemas e tecnologias de dados, a segurança dos recursos corporativos pode ser bastante complexa. Devido a esta complexidade, muitas vezes é difícil encontrar recursos especializados para todos os seus sistemas. Embora seja possível ter pessoal com conhecimento em muitas áreas de segurança da informação de alto nível, é difícil reter pessoal que seja especialista em mais do que algumas áreas temáticas. Isto se deve principalmente porque cada área temática de segurança da informação requer atenção e foco constantes. A segurança da informação não fica parada.

Uma avaliação de vulnerabilidade é uma auditoria interna da segurança de sua rede e sistema; os resultados indicam a confidencialidade, integridade e disponibilidade de sua rede. Tipicamente, a avaliação de vulnerabilidade começa com uma fase de reconhecimento, durante a qual são coletados dados importantes sobre os sistemas e recursos alvo. Esta fase leva à fase de prontidão do sistema, na qual o alvo é essencialmente verificado quanto a todas as vulnerabilidades conhecidas. A fase de prontidão culmina com a fase de relatório, onde os resultados são classificados em categorias de alto, médio e baixo risco; e métodos para melhorar a segurança (ou mitigar o risco de vulnerabilidade) do alvo são discutidos

Se você realizasse uma avaliação de vulnerabilidade de sua casa, você provavelmente verificaria cada porta de sua casa para ver se elas estão fechadas e trancadas. Você também verificaria cada janela, certificando-se de que elas estejam completamente fechadas e trancadas corretamente. Este mesmo conceito se aplica a sistemas, redes e dados eletrônicos. Os usuários maliciosos são os ladrões e vândalos de seus dados. Concentre-se em suas ferramentas, mentalidade e motivações, e você poderá então reagir rapidamente às suas ações.

Tabela 1.1, “Explorações comuns” detalha algumas das explorações e pontos de entrada mais comuns usados por intrusos para acessar recursos da rede organizacional. A chave para estas explorações comuns são as explicações de como elas são realizadas e como os administradores podem proteger adequadamente sua rede contra tais ataques.

A proteção por senha do BIOS (ou equivalente) e do carregador de inicialização pode impedir que usuários não autorizados que tenham acesso físico aos sistemas inicializem usando mídia removível ou obtenham privilégios de raiz através do modo de usuário único. As medidas de segurança que você deve tomar para se proteger contra tais ataques dependem tanto da sensibilidade das informações na estação de trabalho quanto da localização da máquina.

Por exemplo, se uma máquina é utilizada em uma feira e não contém informações sensíveis, então pode não ser crítico para evitar tais ataques. Entretanto, se o laptop de um funcionário com chaves SSH privadas e não criptografadas para a rede corporativa for deixado sem supervisão nessa mesma feira comercial, isso pode levar a uma grande quebra de segurança com ramificações para toda a empresa.

Se a estação de trabalho estiver localizada em um local onde somente pessoas autorizadas ou de confiança tenham acesso, no entanto, a fixação da BIOS ou do carregador de inicialização pode não ser necessária.

A Red Hat recomenda a criação de partições separadas para os diretórios /boot, /, /home, /tmp, e /var/tmp/. As razões para cada uma delas são diferentes, e vamos tratar de cada partição.

Ao instalar o Red Hat Enterprise Linux 8, o meio de instalação representa um instantâneo do sistema em um determinado momento. Devido a isto, ele pode não estar atualizado com as últimas correções de segurança e pode estar vulnerável a certos problemas que foram corrigidos somente após o sistema fornecido pelo meio de instalação ter sido liberado.

Ao instalar um sistema operacional potencialmente vulnerável, sempre limite a exposição somente à zona de rede necessária mais próxima. A escolha mais segura é a zona "sem rede", o que significa deixar sua máquina desconectada durante o processo de instalação. Em alguns casos, uma conexão LAN ou intranet é suficiente enquanto a conexão à Internet é a mais arriscada. Para seguir as melhores práticas de segurança, escolha a zona mais próxima com seu repositório durante a instalação do Red Hat Enterprise Linux 8 a partir de uma rede.

É a melhor prática instalar somente os pacotes que você usará, pois cada software em seu computador poderia conter uma vulnerabilidade. Se você estiver instalando a partir da mídia DVD, aproveite a oportunidade para selecionar exatamente quais pacotes você deseja instalar durante a instalação. Se você achar que precisa de outro pacote, você pode sempre adicioná-lo ao sistema mais tarde.

Os seguintes passos são os procedimentos relacionados à segurança que devem ser realizados imediatamente após a instalação do Red Hat Enterprise Linux 8.

Para ativar a auto-verificação do módulo criptográfico mandado pelo Federal Information Processing Standard (FIPS) Publication 140-2, você tem que operar o RHEL 8 no modo FIPS. Você pode conseguir isto através de:

Para evitar a regeneração de material criptográfico chave e a reavaliação da conformidade do sistema resultante associado à conversão de sistemas já implantados, a Red Hat recomenda iniciar a instalação no modo FIPS.

Uma vez estabelecida uma política para todo o sistema, as aplicações na RHEL a seguem e se recusam a usar algoritmos e protocolos que não atendem à política, a menos que você solicite explicitamente a aplicação para fazê-lo. Ou seja, a política se aplica ao comportamento padrão dos aplicativos quando em execução com a configuração fornecida pelo sistema, mas você pode anulá-la se necessário.

O Red Hat Enterprise Linux 8 contém os seguintes níveis de políticas:

A Red Hat ajusta continuamente todos os níveis da política de modo que todas as bibliotecas, exceto quando se utiliza a política LEGACY, forneçam padrões de segurança. Mesmo que o perfil LEGACY não forneça padrões seguros, ele não inclui nenhum algoritmo que seja facilmente explorável. Como tal, o conjunto de algoritmos habilitados ou tamanhos de chave aceitáveis em qualquer política fornecida pode mudar durante a vida útil do RHEL 8.

Tais mudanças refletem novos padrões de segurança e novas pesquisas de segurança. Se você deve garantir a interoperabilidade com um sistema específico durante toda a vida útil do RHEL 8, você deve optar por não utilizar políticas criptográficas para componentes que interagem com esse sistema.

Ferramenta para gerenciar políticas criptográficas

Para visualizar ou alterar a atual política de criptografia do sistema, use a ferramenta update-crypto-policies, por exemplo:

$ update-crypto-policies --show
DEFAULT
# update-crypto-policies --set FUTURE
Setting system policy to FUTURE

Para garantir que a mudança da política criptográfica seja aplicada, reinicie o sistema.

Padrões criptográficos fortes através da remoção de conjuntos e protocolos criptográficos inseguros

A lista a seguir contém conjuntos de cifras e protocolos removidos das bibliotecas criptográficas centrais no RHEL 8. Eles não estão presentes nas fontes, ou seu suporte é desativado durante a construção, de modo que as aplicações não podem usá-los.

Suítes de cifras e protocolos desabilitados em todos os níveis de políticas

Os seguintes conjuntos de cifras e protocolos são desativados em todos os níveis da política criptográfica. Eles só podem ser habilitados através de uma configuração explícita de aplicações individuais.

Suítes de cifras e protocolos habilitados nos níveis cripto-políticos

A tabela a seguir mostra os conjuntos e protocolos de cifras habilitados em todos os quatro níveis de criptografia.

A política padrão de criptografia de todo o sistema no Red Hat Enterprise Linux 8 não permite a comunicação usando protocolos mais antigos e inseguros. Para ambientes que requerem ser compatíveis com o Red Hat Enterprise Linux 5 e, em alguns casos, também com versões anteriores, o nível menos seguro da política LEGACY está disponível.

As políticas criptográficas de todo o sistema contêm um nível de política que permite a auto-verificação dos módulos criptográficos de acordo com os requisitos da Publicação 140-2 do Federal Information Processing Standard (FIPS). A ferramenta fips-mode-setup que habilita ou desabilita o modo FIPS internamente usa o nível de política criptográfica em todo o sistema FIPS.

Para permitir a auto-verificação dos módulos criptográficos de acordo com as exigências do Federal Information Processing Standard (FIPS) Publicação 140-2 em um contêiner:

RHEL 8.2 introduziu um método alternativo para mudar um contêiner para o modo FIPS. Ele requer apenas o uso do seguinte comando no contêiner:

# mount --bind /usr/share/crypto-policies/back-ends/FIPS /etc/crypto-policies/back-ends

A Red Hat recomenda a utilização de bibliotecas do conjunto de componentes criptográficos essenciais, uma vez que é garantido que eles passem todas as certificações criptográficas relevantes, tais como FIPS 140-2, e também sigam as políticas de criptografia do sistema RHEL.

Veja o artigo sobre componentes criptográficos do núcleo RHEL 8 para uma visão geral dos componentes criptográficos do núcleo RHEL 8, as informações sobre como são selecionados, como são integrados ao sistema operacional, como suportam módulos de segurança de hardware e cartões inteligentes, e como as certificações criptográficas se aplicam a eles.

Além da tabela a seguir, em alguns lançamentos da RHEL 8 Z-stream (por exemplo, 8.1.1), os pacotes do navegador Firefox foram atualizados e contêm uma cópia separada da biblioteca de criptografia NSS. Desta forma, a Red Hat quer evitar a interrupção do rebase de um componente de tão baixo nível em um lançamento de patch. Como resultado, estes pacotes Firefox não usam um módulo validado FIPS 140-2.

Você pode personalizar as configurações criptográficas usadas por sua aplicação, de preferência configurando as suítes de cifras suportadas e os protocolos diretamente na aplicação.

Você também pode remover um link simbólico relacionado à sua aplicação do diretório /etc/crypto-policies/back-ends e substituí-lo por suas configurações criptográficas personalizadas. Esta configuração impede o uso de políticas criptográficas de todo o sistema para aplicações que utilizam o back end excluído. Além disso, esta modificação não é suportada pela Red Hat.

$ wget --secure-protocol=TLSv1_1 --ciphers="SECURE128" https://example.com

$ curl https://example.com --ciphers '@SECLEVEL=0:DES-CBC3-SHA:RSA-DES-CBC3-SHA'

Use este procedimento para ajustar certos algoritmos ou protocolos de qualquer nível de política criptográfica de todo o sistema ou uma política totalmente personalizada.

A função hash SHA-1 tem um design inerentemente fraco e o avanço da criptanálise a tornou vulnerável a ataques. Por padrão, a RHEL 8 não usa SHA-1, mas algumas aplicações de terceiros, por exemplo, assinaturas públicas, ainda usam SHA-1. Para desativar o uso do SHA-1 em algoritmos de assinatura em seu sistema, você pode usar o módulo de política NO-SHA1.

Os passos seguintes demonstram a personalização das políticas criptográficas de todo o sistema através de um arquivo completo de políticas.

O PKCS #11 (Public-Key Cryptography Standard) define uma interface de programação de aplicação (API) para dispositivos criptográficos que contêm informações criptográficas e realizam funções criptográficas. Estes dispositivos são chamados tokens, e podem ser implementados em forma de hardware ou software.

Uma ficha PKCS #11 pode armazenar vários tipos de objetos, incluindo um certificado; um objeto de dados; e uma chave pública, privada ou secreta. Estes objetos são unicamente identificáveis através do esquema PKCS #11 URI.

Um PKCS #11 URI é uma forma padrão de identificar um objeto específico em um módulo PKCS #11 de acordo com os atributos do objeto. Isto permite configurar todas as bibliotecas e aplicações com a mesma cadeia de configuração na forma de um URI.

O Red Hat Enterprise Linux 8 fornece por default o driver OpenSC PKCS #11 para cartões inteligentes. Entretanto, os tokens de hardware e HSMs podem ter seus próprios módulos PKCS #11 que não têm sua contraparte no Red Hat Enterprise Linux. Você pode registrar tais módulos PKCS #11 com a ferramenta p11-kit, que atua como um invólucro sobre os drivers de Cartão Smart Card registrados no sistema.

Para fazer seu próprio módulo PKCS #11 funcionar no sistema, adicione um novo arquivo de texto ao diretório /etc/pkcs11/modules/

Você pode adicionar seu próprio módulo PKCS #11 ao sistema, criando um novo arquivo de texto no diretório /etc/pkcs11/modules/. Por exemplo, o arquivo de configuração do OpenSC em p11-kit tem a seguinte aparência:

$ cat /usr/share/p11-kit/modules/opensc.module
module: opensc-pkcs11.so

O Red Hat Enterprise Linux 8 permite que você use chaves RSA e ECDSA armazenadas em um cartão inteligente em clientes OpenSSH. Use este procedimento para habilitar a autenticação usando um Cartão Smart Card ao invés de usar uma senha.

Se você pular a parte id= de um PKCS #11 URI, o OpenSSH carrega todas as chaves que estão disponíveis no módulo proxy. Isto pode reduzir a quantidade de digitação necessária:

$ ssh -i pkcs11: example.com
Enter PIN for 'SSH key':
[example.com] $

Os servidores HTTP Apache e Nginx podem trabalhar com chaves privadas armazenadas em módulos de segurança de hardware (HSMs), o que ajuda a evitar a revelação das chaves e ataques "man-in-the-middle". Note que isto normalmente requer HSMs de alto desempenho para servidores ocupados.

SSLCertificateFile    "pkcs11:id=%01;token=softhsm;type=cert"
SSLCertificateKeyFile "pkcs11:id=%01;token=softhsm;type=private?pin-value=111111"

Instale o pacote httpd-manual para obter a documentação completa para o Servidor HTTP Apache, incluindo a configuração TLS. As diretrizes disponíveis no arquivo de configuração /etc/httpd/conf.d/ssl.conf são descritas em detalhes em /usr/share/httpd/manual/mod/mod_ssl.html.

ssl_certificate     /path/to/cert.pem
ssl_certificate_key "engine:pkcs11:pkcs11:token=softhsm;id=%01;type=private?pin-value=111111";

Note que o prefixo engine:pkcs11: é necessário para o PKCS #11 URI no arquivo de configuração Nginx. Isto porque o outro prefixo pkcs11 se refere ao nome do motor.

Com aplicações que requerem trabalhar com chaves privadas em cartões inteligentes e que não usam NSS, GnuTLS, ou OpenSSL, use p11-kit para implementar o registro dos módulos PKCS #11.

Consulte a página de manual p11-kit(8) para mais informações.

No Red Hat Enterprise Linux, a loja de confiança consolidada em todo o sistema está localizada nos diretórios /etc/pki/ca-trust/ e /usr/share/pki/ca-trust-source/. As configurações de confiança em /usr/share/pki/ca-trust-source/ são processadas com prioridade menor do que as configurações em /etc/pki/ca-trust/.

Os arquivos de certificados são tratados de acordo com o subdiretório em que são instalados nos seguintes diretórios:

Para reconhecer aplicações em seu sistema com uma nova fonte de confiança, adicione o certificado correspondente à loja em todo o sistema, e use o comando update-ca-trust.

O comando trust fornece uma maneira conveniente para gerenciar certificados na loja de confiança compartilhada em todo o sistema.

O Red Hat Enterprise Linux fornece ferramentas que permitem que você realize uma auditoria de conformidade totalmente automatizada. Estas ferramentas são baseadas no padrão Security Content Automation Protocol (SCAP) e são projetadas para a adaptação automatizada das políticas de conformidade.

Para realizar auditorias de conformidade automatizadas em múltiplos sistemas remotamente, você pode usar a solução OpenSCAP para o Red Hat Satellite.

Use este procedimento para remediar o sistema RHEL 8 para se alinhar com uma linha de base específica. Este exemplo usa o Perfil de Proteção para Sistemas Operacionais de Propósito Geral (OSPP).

Use este procedimento para remediar seu sistema com uma linha de base específica usando o arquivo Ansible playbook do projeto Guia de Segurança SCAP. Este exemplo utiliza o Perfil de Proteção para Sistemas Operacionais de Propósito Geral (OSPP).

Use este procedimento para criar um livro de jogo possível contendo apenas as remediações necessárias para alinhar seu sistema com uma linha de base específica. Este exemplo utiliza o Perfil de Proteção para Sistemas Operacionais de Propósito Geral (OSPP). Com este procedimento, você cria um playbook menor que não cobre os requisitos já satisfeitos. Seguindo estas etapas, você não modifica seu sistema de forma alguma, você apenas prepara um arquivo para aplicação posterior.

Use este procedimento para criar um Bash script contendo remediações que alinhem seu sistema com um perfil de segurança como o PCI-DSS. Usando as seguintes etapas, você não faz nenhuma modificação em seu sistema, você só prepara um arquivo para aplicação posterior.

SCAP Workbench, que está contido no pacote scap-workbench, é um utilitário gráfico que permite aos usuários realizar varreduras de configuração e vulnerabilidade em um único sistema local ou remoto, realizar remediação do sistema e gerar relatórios baseados em avaliações de varredura. Note que SCAP Workbench tem funcionalidade limitada em comparação com o utilitário de linha de comando oscap. SCAP Workbench processa o conteúdo de segurança na forma de arquivos de fluxo de dados.

Você pode usar o conjunto OpenSCAP para implantar sistemas RHEL que estejam em conformidade com um perfil de segurança, como OSPP ou PCI-DSS, imediatamente após o processo de instalação. Usando este método de implantação, você pode aplicar regras específicas que não podem ser aplicadas posteriormente usando scripts de correção, por exemplo, uma regra para a força da senha e particionamento.

Use este procedimento para encontrar vulnerabilidades de segurança em um contêiner ou em uma imagem de contêiner.

Siga estas etapas para avaliar a conformidade de seu container ou de uma imagem de container com uma linha de base de segurança específica, como o Perfil de Proteção do Sistema Operacional (OSPP) ou a Norma de Segurança de Dados da Indústria de Cartões de Pagamento (PCI-DSS).

As versões oficialmente suportadas do Guia de Segurança SCAP são versões fornecidas na versão menor relacionada do RHEL ou na atualização de lote relacionada do RHEL.

Use somente o conteúdo SCAP fornecido na versão menor em particular da RHEL. Isto ocorre porque os componentes que participam do endurecimento são às vezes atualizados com novas capacidades. O conteúdo SCAP muda para refletir essas atualizações, mas nem sempre é compatível com versões anteriores.

Nas tabelas a seguir, você pode encontrar os perfis fornecidos em cada versão menor da RHEL, juntamente com a versão da política com a qual o perfil se alinha.

Os seguintes passos são necessários para instalar AIDE e iniciar seu banco de dados.

Após verificar as mudanças de seu sistema, tais como, atualizações de pacotes ou ajustes de arquivos de configuração, é recomendável atualizar seu banco de dados de base AIDE.

Para obter informações adicionais em AIDE, consulte a página de manual aide(1).

O Linux Unified Key Setup-on-disk-format (LUKS) permite criptografar dispositivos de bloco e fornece um conjunto de ferramentas que simplifica o gerenciamento dos dispositivos criptografados. O LUKS permite que múltiplas chaves de usuário descriptografem uma chave mestra, que é usada para a criptografia em massa da partição.

A RHEL utiliza o LUKS para realizar a criptografia do dispositivo de bloqueio. Por padrão, a opção para criptografar o dispositivo de bloco é desmarcada durante a instalação. Se você selecionar a opção para criptografar seu disco, o sistema solicita uma senha toda vez que você inicia o computador. Esta frase-chave “desbloqueia” a chave de criptografia em bloco que descriptografa sua partição. Se você escolher modificar a tabela de partições padrão, você pode escolher quais partições deseja criptografar. Isto é definido nas configurações da tabela de partição.

No RHEL 8, o formato padrão para criptografia LUKS é LUKS2. O formato antigo LUKS1 permanece totalmente suportado e é fornecido como um formato compatível com os lançamentos anteriores da RHEL.

O formato LUKS2 é projetado para permitir futuras atualizações de várias partes sem a necessidade de modificar estruturas binárias. O LUKS2 usa internamente o formato de texto JSON para metadados, fornece redundância de metadados, detecta corrupção de metadados e permite reparos automáticos a partir de uma cópia de metadados.

Ao criptografar um dispositivo não criptografado, você ainda deve desmontar o sistema de arquivo. Você pode montar novamente o sistema de arquivo após uma breve inicialização da criptografia.

O formato LUKS1 não suporta a reencriptação on-line.

LUKS2 fornece várias opções que priorizam o desempenho ou a proteção de dados durante o processo de reencriptação:

Você pode selecionar o modo usando a opção --resilience de cryptsetup.

Se um processo de reencriptação LUKS2 termina inesperadamente pela força, a LUKS2 pode realizar a recuperação de uma das seguintes formas:

Este procedimento criptografa os dados existentes em um dispositivo ainda não criptografado usando o formato LUKS2. Um novo cabeçalho LUKS é armazenado na cabeça do dispositivo.

Este procedimento codifica os dados existentes em um dispositivo de bloco sem criar espaço livre para o armazenamento de um cabeçalho LUKS. O cabeçalho é armazenado em um local separado, o que também serve como uma camada adicional de segurança. O procedimento utiliza o formato de criptografia LUKS2.

Este procedimento fornece informações sobre a criptografia de um dispositivo de bloco em branco usando o formato LUKS2.

Você pode usar o papel storage para criar e configurar um volume criptografado com LUKS, executando um livro de brincadeiras Ansible playbook.

No Red Hat Enterprise Linux, a NBDE é implementada através dos seguintes componentes e tecnologias:

Figura 9.1. Esquema NBDE ao utilizar um volume encriptado de LUKS1. A embalagem luksmeta não é utilizada para volumes LUKS2.

Tang é um servidor para vincular dados à presença na rede. Ele torna um sistema contendo seus dados disponível quando o sistema está vinculado a uma determinada rede segura. Tang é stateless e não requer TLS ou autenticação. Ao contrário das soluções baseadas em escrow, onde o servidor armazena todas as chaves de criptografia e tem conhecimento de cada chave já utilizada, Tang nunca interage com nenhuma chave do cliente, portanto, nunca obtém nenhuma informação de identificação do cliente.

Clevis é uma estrutura plugável para a decriptação automatizada. No NBDE, Clevis fornece o desbloqueio automatizado de volumes LUKS. O clevis fornece o lado do cliente do recurso.

A Clevis pin é um plug-in para a estrutura Clevis. Um desses pinos é um plug-in que implementa as interações com o servidor NBDE

Clevis e Tang são componentes genéricos de cliente e servidor que fornecem criptografia vinculada à rede. No Red Hat Enterprise Linux, eles são usados em conjunto com o LUKS para criptografar e decodificar volumes de armazenamento raiz e não-raiz para realizar a criptografia de discos vinculados à rede.

Tanto os componentes do lado do cliente quanto do lado do servidor utilizam a biblioteca José para realizar operações de criptografia e decriptação.

Quando você começa a provisionar NBDE, o pin Clevis para o servidor Tang recebe uma lista das chaves assimétricas anunciadas do servidor Tang. Alternativamente, como as chaves são assimétricas, uma lista das chaves públicas Tang pode ser distribuída fora da banda para que os clientes possam operar sem acesso ao servidor Tang. Este modo é chamado offline provisioning.

O pino Clevis para Tang usa uma das chaves públicas para gerar uma chave de criptografia única e forte em termos criptográficos. Uma vez que os dados são criptografados usando esta chave, a chave é descartada. O cliente Clevis deve armazenar o estado produzido por esta operação de provisionamento em um local conveniente. Este processo de encriptação de dados é o provisioning step.

O LUKS versão 2 (LUKS2) é o formato padrão no Red Hat Enterprise Linux 8, portanto, o estado de provisionamento para NBDE é armazenado como um token em um cabeçalho LUKS2. A alavancagem do estado de provisionamento para NBDE pelo luksmeta é usado somente para volumes criptografados com LUKS1. O pino Clevis para Tang suporta tanto LUKS1 quanto LUKS2 sem necessidade de especificação.

Quando o cliente está pronto para acessar seus dados, ele carrega os metadados produzidos na etapa de provisionamento e responde para recuperar a chave de criptografia. Este processo é o recovery step.

Em NBDE, Clevis liga um volume LUKS usando um pino para que ele possa ser automaticamente desbloqueado. Após a conclusão bem sucedida do processo de encadernação, o disco pode ser desbloqueado usando o desbloqueador Dracut fornecido.

Use este procedimento para implantar e começar a usar a estrutura plugável Clevis em seu sistema.

Use este procedimento para implantar um servidor Tang rodando em uma porta personalizada como um serviço confinado no modo de aplicação do SELinux.

Use as seguintes etapas para girar suas chaves de servidor Tang e atualizar as ligações existentes nos clientes. O intervalo preciso no qual você deve rotacioná-las depende de sua aplicação, tamanho das chaves e política institucional.

Configurar o desbloqueio automático de um dispositivo de armazenamento criptografado LUKS usando uma chave fornecida por um servidor Tang.

O procedimento seguinte contém passos para configurar o desbloqueio automático de um volume criptografado com um servidor de rede Tang.

Use o seguinte procedimento para remover manualmente os metadados criados pelo comando clevis luks bind e também para limpar um rasgo de chave que contém a senha adicionada por Clevis.

# clevis luks unbind -d /dev/sda2 -s 1

O seguinte procedimento contém passos para configurar o desbloqueio automático de um volume criptografado com uma política do Trusted Platform Module 2.0 (TPM 2.0).

O pino também suporta dados de vedação para um estado de Registros de Configuração de Plataforma (PCR). Dessa forma, os dados só podem ser des selados se os valores dos PCRs corresponderem à política usada na selagem.

Por exemplo, para selar os dados para o PCR com índices 0 e 1 para o banco SHA-1:

$ clevis encrypt tpm2 '{"pcr_bank":"sha1","pcr_ids":"0,1"}' < input-plain.txt > secret.jwe

Use os seguintes passos para configurar o desbloqueio de volumes codificados com LUKS com NBDE.

# dracut -fv --regenerate-all --kernel-cmdline "ip=192.0.2.10::192.0.2.1:255.255.255.0::ens3:none:192.0.2.45"

# cat /etc/dracut.conf.d/static_ip.conf
kernel_cmdline="ip=192.0.2.10::192.0.2.1:255.255.255.0::ens3:none:192.0.2.45"

# dracut -fv --regenerate-all

Siga as etapas deste procedimento para configurar um processo de instalação automatizado que utiliza Clevis para a inscrição de volumes criptografados LUKS.

Você pode usar um procedimento análogo ao usar uma política TPM 2.0 ao invés de um servidor Tang.

Use este procedimento para configurar um processo de desbloqueio automático de um dispositivo de armazenamento USB criptografado LUKS.

Você pode usar um procedimento análogo ao usar uma política TPM 2.0 ao invés de um servidor Tang.

A Tang fornece dois métodos para a construção de uma implantação de alta disponibilidade:

# clevis luks bind -d /dev/sda1 sss "t":1,"pins":"tang":[url":http://tang1.srv",{\i1}"url":http://tang2.srv"]{\i1}

{
    "t":1,
    "pins":{
        "tang":[
            {
                "url":"http://tang1.srv"
            },
            {
                "url":"http://tang2.srv"
            }
        ]
    }
}

# clevis luks bind -d /dev/sda1 sss 't:2,"pins":"tang":[url":http://tang1.srv"tpm2], "tpm2": {"pcr_ids":"0,1"}}}'

{
    "t":2,
    "pins":{
        "tang":[
            {
                "url":"http://tang1.srv"
            }
        ],
        "tpm2":{
            "pcr_ids":"0,1"
        }
    }
}

O comando clevis luks bind não altera a chave mestra LUKS. Isto implica que se você criar uma imagem encriptada LUKS para uso em uma máquina virtual ou ambiente de nuvem, todas as instâncias que executam esta imagem compartilharão uma chave mestra. Isto é extremamente inseguro e deve ser evitado em todos os momentos.

Isto não é uma limitação de Clevis, mas um princípio de projeto da LUKS. Se você deseja ter volumes raiz criptografados em uma nuvem, você precisa ter certeza de que você realiza o processo de instalação (geralmente usando Kickstart) para cada instância do Red Hat Enterprise Linux em uma nuvem também. As imagens não podem ser compartilhadas sem também compartilhar uma chave mestra LUKS.

Se você pretende implementar o desbloqueio automatizado em um ambiente virtualizado, a Red Hat recomenda fortemente que você use sistemas como lorax ou virt-install juntamente com um arquivo Kickstart (veja Configurando o registro automatizado de volumes criptografados LUKS usando Kickstart) ou outra ferramenta de provisionamento automatizado para garantir que cada VM criptografada tenha uma chave mestra única.

A implantação de imagens criptografadas automaticamente registráveis em um ambiente de nuvem pode proporcionar um conjunto único de desafios. Como outros ambientes de virtualização, é recomendado reduzir o número de instâncias iniciadas a partir de uma única imagem para evitar o compartilhamento da chave mestra LUKS.

Portanto, a melhor prática é criar imagens personalizadas que não sejam compartilhadas em nenhum repositório público e que forneçam uma base para a implantação de uma quantidade limitada de instâncias. O número exato de instâncias a serem criadas deve ser definido pelas políticas de segurança da implantação e baseado na tolerância ao risco associado ao vetor de ataque da chave mestra LUKS.

Para construir implantações automatizadas habilitadas para LUKS, sistemas como o Lorax ou virt-install juntamente com um arquivo Kickstart devem ser usados para garantir a exclusividade da chave mestra durante o processo de construção da imagem.

Os ambientes em nuvem permitem duas opções de implementação de servidores Tang que consideramos aqui. Primeiro, o servidor Tang pode ser implantado dentro do próprio ambiente de nuvem. Segundo, o servidor Tang pode ser implantado fora da nuvem em infra-estrutura independente com um link VPN entre as duas infra-estruturas.

A implantação de Tang nativamente na nuvem permite uma implantação fácil. Entretanto, dado que ele compartilha a infra-estrutura com a camada de persistência de dados do texto cifrado de outros sistemas, pode ser possível que tanto a chave privada do servidor Tang quanto os metadados Clevis sejam armazenados no mesmo disco físico. O acesso a este disco físico permite um comprometimento total dos dados do texto criptografado.

As funções do sistema RHEL são uma coleção de funções e módulos possíveis que fornecem uma interface de configuração consistente para gerenciar remotamente vários sistemas RHEL.

A RHEL 8.3 introduziu funções possíveis para implantações automatizadas de soluções de decriptação baseada em políticas (PBD) usando Clevis e Tang. O pacote rhel-system-roles contém estas funções do sistema, os exemplos relacionados, e também a documentação de referência.

A função do sistema nbde_client permite que você implante vários clientes Clevis de forma automatizada. Note que a função nbde_client suporta apenas as ligações Tang, e você não pode utilizá-la para ligações TPM2 no momento.

A função nbde_client requer volumes que já estão criptografados usando LUKS. Esta função suporta ligar um volume criptografado pelo LUKS a um ou mais servidores Network-Bound (NBDE) - servidores Tang. Você pode preservar a criptografia de volume existente com uma frase-senha ou removê-la. Após remover a frase-senha, você pode desbloquear o volume somente usando NBDE. Isto é útil quando um volume é inicialmente criptografado usando uma chave temporária ou senha que você deve remover após o sistema que você fornece o sistema.

Se você fornecer tanto uma senha como um arquivo chave, a função usa primeiro o que você forneceu. Se não encontrar nenhuma delas válida, tenta recuperar uma frase-chave a partir de uma ligação existente.

PBD define uma ligação como um mapeamento de um dispositivo para um slot. Isto significa que você pode ter várias encadernações para o mesmo dispositivo. O slot padrão é o slot 1.

A função nbde_client fornece também a variável state. Use o valor present para criar uma nova ligação ou atualizar uma já existente. Ao contrário de um comando clevis luks bind, você pode usar state: present também para sobrescrever uma encadernação existente em seu slot de dispositivo. O valor absent remove uma encadernação especificada.

Usando a função nbde_server, você pode implantar e gerenciar um servidor Tang como parte de uma solução automatizada de criptografia de disco. Esta função suporta as seguintes características:

Siga os passos para preparar e aplicar um livro de jogo possível contendo as configurações do seu servidor Tang.

Siga os passos para preparar e aplicar um livro de jogo possível contendo suas configurações Clevis-cliente.

O sistema de Auditoria Linux fornece uma maneira de rastrear informações relevantes para a segurança em seu sistema. Baseado em regras pré-configuradas, o Audit gera entradas de registro para registrar o máximo de informações sobre os eventos que estão acontecendo em seu sistema. Estas informações são cruciais para ambientes de missão crítica para determinar o infrator da política de segurança e as ações que ele executou.

A seguinte lista resume algumas das informações que a Audit é capaz de registrar em seus arquivos de registro:

O uso do sistema de Auditoria também é um requisito para uma série de certificações relacionadas à segurança. A auditoria é projetada para atender ou exceder as exigências das seguintes certificações ou guias de conformidade:

A auditoria também tem sido:

O sistema de Auditoria consiste em duas partes principais: as aplicações e utilitários de espaço do usuário, e o processamento de chamadas do sistema do lado do kernel. O componente kernel recebe chamadas de sistema de aplicações de espaço do usuário e as filtra através de um dos seguintes filtros: user, task, fstype, ou exit.

Uma vez que uma chamada de sistema passa pelo filtro exclude, ele é enviado através de um dos filtros acima mencionados, que, com base na configuração da regra de Auditoria, o envia para o daemon de Auditoria para processamento posterior.

O daemon de Auditoria do espaço do usuário coleta as informações do kernel e cria entradas em um arquivo de log. Outras utilidades do espaço do usuário de Auditoria interagem com o daemon de Auditoria, o componente Audit do kernel ou os arquivos de log de Auditoria:

No RHEL 8, a funcionalidade do daemon de Auditoria (audisp) está integrada no daemon de Auditoria (auditd). Os arquivos de configuração dos plugins para a interação de programas analíticos em tempo real com eventos de Auditoria estão localizados no diretório /etc/audit/plugins.d/ por padrão.

A configuração padrão auditd deve ser adequada para a maioria dos ambientes. Entretanto, se seu ambiente tiver que atender a rígidas políticas de segurança, as seguintes configurações são sugeridas para a configuração do daemon de Auditoria no arquivo /etc/audit/auditd.conf:

As demais opções de configuração devem ser definidas de acordo com sua política de segurança local.

Uma vez configurado auditd, iniciar o serviço para coletar informações de Auditoria e armazená-las nos arquivos de registro. Use o seguinte comando como usuário root para iniciar auditd:

# service auditd start

Para configurar auditd para começar no momento da inicialização:

# systemctl enable auditd

Uma série de outras ações podem ser realizadas no site auditd usando o service auditd action onde action pode ser um dos seguintes:

Por padrão, o sistema de Auditoria armazena entradas de log no arquivo /var/log/audit/audit.log; se a rotação de log estiver ativada, os arquivos audit.log rodados são armazenados no mesmo diretório.

Adicione a seguinte regra de Auditoria para registrar cada tentativa de ler ou modificar o arquivo /etc/ssh/sshd_config:

# auditctl -w /etc/ssh/sshd_config -p warx -k sshd_config

Se o daemon auditd estiver em execução, por exemplo, usando o seguinte comando, cria-se um novo evento no arquivo de log de Auditoria:

$ cat /etc/ssh/sshd_config

Este evento no arquivo audit.log tem a seguinte aparência:

type=SYSCALL msg=audit(1364481363.243:24287): arch=c000003e syscall=2 success=no exit=-13 a0=7fffd19c5592 a1=0 a2=7fffd19c4b50 a3=a items=1 ppid=2686 pid=3538 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=1 comm="cat" exe="/bin/cat" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="sshd_config"
type=CWD msg=audit(1364481363.243:24287):  cwd="/home/shadowman"
type=PATH msg=audit(1364481363.243:24287): item=0 name="/etc/ssh/sshd_config" inode=409248 dev=fd:00 mode=0100600 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:etc_t:s0  nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0
type=PROCTITLE msg=audit(1364481363.243:24287) : proctitle=636174002F6574632F7373682F737368645F636F6E666967

O evento acima consiste em quatro registros, que compartilham o mesmo carimbo de tempo e número de série. Os registros sempre começam com a palavra-chave type=. Cada registro consiste de vários name=value pares separados por um espaço branco ou por uma vírgula. Segue-se uma análise detalhada do evento acima:

O sistema de Auditoria opera sobre um conjunto de regras que definem o que é capturado nos arquivos de registro. As regras de auditoria podem ser definidas tanto na linha de comando usando o utilitário auditctl ou no diretório /etc/audit/rules.d/.

O comando auditctl permite controlar a funcionalidade básica do sistema de Auditoria e definir regras que decidem quais eventos de Auditoria são registrados.

# auditctl -a always,exit -F exe=/bin/id -F arch=b64 -S execve -k execution_bin_id

Para definir as regras de Auditoria que são persistentes nas reinicializações, você deve incluí-las diretamente no arquivo /etc/audit/rules.d/audit.rules ou usar o programa augenrules que lê as regras localizadas no diretório /etc/audit/rules.d/.

Note que o arquivo /etc/audit/audit.rules é gerado sempre que o serviço auditd é iniciado. Os arquivos em /etc/audit/rules.d/ utilizam a mesma sintaxe de linha de comando auditctl para especificar as regras. Linhas vazias e texto seguindo um sinal de hash (#) são ignoradas.

Além disso, você pode usar o comando auditctl para ler regras de um arquivo específico usando a opção -R, por exemplo:

# auditctl -R /usr/share/audit/sample-rules/30-stig.rules

No diretório /usr/share/audit/sample-rules, o pacote audit fornece um conjunto de arquivos de regras pré-configuradas de acordo com vários padrões de certificação:

Para utilizar estes arquivos de configuração, copie-os para o diretório /usr/share/audit/sample-rules e use o comando augenrules --load, por exemplo:

# cd /usr/share/audit/sample-rules/
# cp 10-base-config.rules 30-stig.rules 31-privileged.rules 99-finalize.rules /etc/audit/rules.d/
# augenrules --load

O script augenrules lê regras localizadas no diretório /etc/audit/rules.d/ e as compila em um arquivo audit.rules. Este script processa todos os arquivos que terminam com .rules em uma ordem específica com base em sua ordem natural de classificação. Os arquivos neste diretório estão organizados em grupos com os seguintes significados:

As regras não devem ser usadas de uma só vez. Elas são partes de uma política que deve ser pensada e arquivos individuais copiados para /etc/audit/rules.d/. Por exemplo, para configurar um sistema na configuração STIG, copiar as regras 10-base-config, 30-stig, 31-privileged, e 99-finalize.

Uma vez que você tenha as regras no diretório /etc/audit/rules.d/, carregue-as executando o script augenrules com a diretiva --load:

# augenrules --load
/sbin/augenrules: No change
No rules
enabled 1
failure 1
pid 742
rate_limit 0
...

Use os seguintes passos para desativar o utilitário augenrules. Isto muda a Auditoria para usar as regras definidas no arquivo /etc/audit/audit.rules.

Para mais informações sobre o sistema de Auditoria, veja as seguintes fontes.

A estrutura de software fapolicyd controla a execução de aplicações com base em uma política definida pelo usuário. Esta é uma das formas mais eficientes de impedir a execução de aplicações não confiáveis e possivelmente maliciosas no sistema.

A estrutura fapolicyd fornece os seguintes componentes:

O administrador pode definir as regras de execução allow e deny para qualquer aplicação com a possibilidade de auditoria baseada em um caminho, hash, tipo MIME, ou trust.

A estrutura fapolicyd introduz o conceito de confiança. Uma aplicação é confiável quando devidamente instalada pelo gerente de pacotes do sistema e, portanto, é registrada no banco de dados RPM do sistema. O daemon fapolicyd usa o banco de dados RPM como uma lista de binários e scripts confiáveis. O plugin fapolicyd do YUM registra qualquer atualização do sistema que é gerenciada pelo gerenciador de pacotes YUM. O plugin notifica o daemon fapolicyd sobre mudanças neste banco de dados.

Uma instalação usando o utilitário rpm requer uma atualização manual do banco de dados, e outras formas de adicionar aplicações requerem a criação de regras personalizadas e o reinício do serviço fapolicyd.

A configuração do serviço fapolicyd está localizada no diretório /etc/fapolicyd/ com a seguinte estrutura:

Para implantar a estrutura fapolicyd na RHEL:

Você pode usar este procedimento para utilizar uma fonte adicional de confiança para fapolicyd. Antes da RHEL 8.3, fapolicyd confiava apenas nos arquivos contidos no banco de dados RPM. A estrutura fapolicyd agora suporta também o uso do arquivo de texto simples /etc/fapolicyd/fapolicyd.trust como fonte de confiança. Você pode modificar fapolicyd.trust diretamente com um editor de texto ou através dos comandos do fapolicyd CLI.

O conjunto padrão de regras do pacote fapolicyd não afeta as funções do sistema. Para cenários personalizados, como armazenar binários e scripts em um diretório não-padrão ou adicionar aplicações sem os instaladores yum ou rpm, é necessário modificar as regras existentes ou adicionar novas regras. Os passos seguintes demonstram a adição de uma nova regra para permitir um binário personalizado.

A seção a seguir fornece dicas para a solução de problemas básicos da estrutura de aplicação fapolicyd e orientações para adicionar aplicações usando o comando rpm.

Com a estrutura do software USBGuard, você pode proteger seus sistemas contra dispositivos USB intrusivos usando listas básicas de dispositivos permitidos e proibidos com base no recurso de autorização de dispositivos USB no kernel.

A estrutura do USBGuard fornece os seguintes componentes:

O arquivo de configuração do serviço do sistema usbguard (/etc/usbguard/usbguard-daemon.conf) inclui as opções para autorizar os usuários e grupos a usar a interface IPC.

Use este procedimento para instalar e iniciar a estrutura USBGuard.

Este procedimento delineia como autorizar e bloquear um dispositivo USB usando o comando usbguard.

Você pode bloquear e autorizar permanentemente um dispositivo USB usando a opção -p. Isto acrescenta uma regra específica do dispositivo à política atual.

O procedimento a seguir contém passos para criar um conjunto de regras para dispositivos USB que reflita as exigências de seu cenário.

Você pode organizar sua política personalizada USBGuard em vários arquivos .conf dentro do diretório /etc/usbguard/rules.d/. O usbguard-daemon combina então o arquivo principal rules.conf com os arquivos .conf dentro do diretório, em ordem alfabética.

Use este procedimento para autorizar um usuário específico ou um grupo a usar a interface pública IPC do USBGuard. Por padrão, somente o usuário root pode usar esta interface.

Use os seguintes passos para integrar o registro de eventos de autorização do USBguard ao registro de auditoria padrão do Linux. Por padrão, o daemon usbguard registra os eventos no arquivo /var/log/usbguard/usbguard-audit.log.