Em 1991, dois eventos não relacionados ocorreram, cada um deles anunciando duas liberdades muito diferentes: o fim da Guerra Fria e o nascimento do Linux.
A possibilidade de patchear o kernel em tempo real surgiu em 2008, quando o Linux ainda era adolescente. Agora que o kernel do Linux está prestes a chegar aos 30, o patching em tempo real também está maduro e pronto para diminuir sua reputação como um complemento opcional que é simplesmente "bom ter na caixa".
Há duas razões para isso. O primeiro é o domínio do Linux como plataforma de escolha para hospedagem na web econômica e versátil: mais da metadetodos os sites conhecidos estão rodando no Linux. Em segundo lugar, o reconhecimento de que patching em tempo real é mais do que uma conveniência; também é uma maneira eficaz e de baixo custo de melhorar a segurança do seu sistema Linux.
Ksplice, a primeira solução de patching do kernel Linux em tempo real, ganhou status lucrativo sem esforço após o lançamento, apenas fortalecendo sua liderança quando a gigante da tecnologia Oracle a comprou em 2011. Hoje é a mais famosa das cinco organizações que oferecem serviços automatizados de patching de segurança para Linux. Em ordem alfabética, são:
- Serviço Canonical Livepatch para Ubuntu.
- KernelCare para Ubuntu, Red Hat Enterprise Linux, Oracle Linux, Amazon Linux e muito mais.
- Kpatch para Red Hat Enterprise Linux.
- Ksplice para Oracle Linux.
- SUSE Linux Enterprise Live Patching para SUSE Linux Enterprise.
Cada empresa promove seus serviços usando as mesmas palavras-chave clichê, as mesmas frases padrão, repetidas indefinidamente. Apresentarei os mais populares e como você deve entendê-los.
- Sem reinicialização : atualiza o kernel do Linux sem reinicializar.
- Automatizado: Verifica e instala atualizações de segurança do kernel sem um observador.
- Fácil instalação: A instalação e configuração são muito simples ou desnecessárias.
- Totalmente compatível: você não precisa escrever patches. (Dê uma olhada no Guia de criação de patches do Kpatch para ver por que isso é importante)
Ignore esses argumentos de venda óbvios e você encontrará outros recursos a serem considerados, outros fatores que você pode usar para comparar um serviço a outro. Este artigo explora alguns deles, ligeiramente temperados com afirmação e edificação. Mas primeiro, vamos lembrar o que é patching ao vivo.
O que é correção em tempo real do kernel do Linux?
O kernel do Linux contém mais de 20 milhões de linhas de código escrito principalmente (presumivelmente) por programadores humanos. Como acontece com todo software, ele tem bugs. Nesta época de maior foco na segurança cibernética, os bugs implicam em vulnerabilidades . Para resolver esse problema, os fornecedores de Linux tentam lançar atualizações para seus kernels o mais rápido possível. Os administradores de sistemas do Linux também estão tentando reagir rapidamente instalando essas atualizações, tornando o agendamento mais difícil. Isso ocorre porque não existe um padrão para detectar vulnerabilidades. Aqui estão algumas razões do porquê:
- Existem muitas versões diferentes do kernel Linux em uso a qualquer momento. Alguns precisarão de conserto; alguns não.
- , .
- Linux , .
- Linux . , , — .
Há mais uma coisa que raramente é mencionada: é o nojo instintivo do administrador do sistema em parar a máquina, causando desconforto físico por ter que dizer: “O servidor está fora do ar para manutenção”.
Por que parar o servidor? Porque a atualização do kernel não terá efeito até a reinicialização. Se você não reiniciar - se você colocá-lo em segundo plano ou esquecer - você se verá em um dilema, porque um servidor sem os patches mais recentes é inseguro . Falaremos sobre esse mantra com mais detalhes posteriormente, mas sua essência é esta:
quando as vulnerabilidades se tornam públicas, o mesmo acontece com seus exploits.
Ou, em outras palavras, você tem uma vulnerabilidade que não conhecia antes, mas agora conhece. E todo mundo também.
O salvador neste cenário é o patch ao vivo . Esta é uma forma de atualizar não todo o kernel do Linux, mas apenas sua parte problemática. E isso sem parar processos ou interromper o trabalho dos usuários.
No entanto, existem limitações. O patching do kernel em tempo real não pode corrigir todos os tipos de bugs. A enorme complexidade do código do kernel e os desafios técnicos de modificar o código em tempo real significa que essa técnica só é usada para solucionar problemas críticos geralmente relacionados à segurança.
Apesar disso, um sistema com recursos de patch em tempo real é mais seguro do que um sistema sem ele. Aqui estão algumas perguntas a serem feitas ao procurar uma solução de patch em tempo real:
1. O que há dentro do patch (e quem está por trás dele)?
Quando você se inscreve em um serviço de patching ativo, paga mais do que apenas o software em si. Isso fica claro quando você começa a vasculhar a origem do kernel do Linux e percebe como um patch mal escrito pode danificar um sistema Linux inteiro.
Mencionei anteriormente que o kernel é um grande corpo de trabalho que parece se expandir tanto em atividade quanto em volume. Observe o aumento no número de linhas de código no branch master do repositório do kernel Linux. (Conta a partir de 1º de janeiro de cada ano. Apenas arquivos C / C ++ e cabeçalhos, arquivos Python e Perl são contados.)
Com tanto código, escrever patches para o kernel Linux não é uma tarefa fácil. É necessário um conhecimento profundo da arquitetura do kernel e das estruturas de dados. Experiência com convenções de codificação e padrões de qualidade da comunidade Linux. E é preciso um talento especial para inventar soluções que não afetem a funcionalidade, o desempenho e a estabilidade.
Existem dois métodos opostos que os fornecedores de patches usam para desenvolver e fornecer patches de kernel. Eu os chamo de incrementais e monolíticos .
Os adesivos incrementais, como uma bola de goma de mascar, são empilhados uns sobre os outros, cada um modificando o comportamento do anterior. Como cliente, você deve acompanhar quais patches instala e quais não, e a ordem em que são instalados. A falha em dar atenção a esses problemas pode levar a mudanças imprevisíveis no comportamento do seu sistema. Esse método de patch permite que os fornecedores liberem rapidamente pequenos patches direcionados. Mas com o tempo, o sistema pode se tornar instável a ponto de apenas uma atualização completa do kernel poder restaurá-lo.
Um patch monolítico é um patch que inclui todos os patches anteriores. Basicamente, existe apenas um patch mestre que substitui o patch ativo ao invés de ser adicionado a ele. Essa abordagem torna a plataforma mais estável, aumentando significativamente o tempo de atividade do servidor, que geralmente é medido em milhares de dias.
2. Quanto tempo esperar até o próximo patch?
Há inevitavelmente um atraso entre relatar uma vulnerabilidade e corrigi-la. Leva tempo para analisar os erros do kernel e para avaliar seu impacto. É preciso engenhosidade e habilidade para encontrar uma solução, e toneladas de testes para garantir que ela funcione. Em seguida, está sujeito a revisão e aprovação obrigatórias como parte do processo de desenvolvimento do Linux.
Atrasos evitáveis ocorrem quando o fornecedor do Linux substitui a classificação de gravidade da comunidade por sua própria. Isso significa que um fornecedor pode corrigir várias vulnerabilidades com menos patches, mas, por causa disso, o cliente espera em média mais tempo para corrigir certos problemas.
Os administradores do Linux que entendem os motivos da natureza errática dos lançamentos de patches não se beneficiam muito mais do que aqueles que não entendem. Nenhum deles encontra conforto em saber que enquanto esperam por patches, seus sistemas estão ainda mais vulneráveis a uma exploração do que estavam antes de ser descoberta.
Eis o motivo: os membros da comunidade de pesquisa de segurança cibernética adoram anunciar vulnerabilidades junto com um caso de uso visual. Eles geralmente assumem a forma de uma prova de conceito, uma descrição técnica detalhada de como reproduzir um bug ou usar um exploit. Essas descrições são de boa fé para ajudar os desenvolvedores do kernel a encontrar e corrigir o problema. Mas eles também economizam muito tempo e esforço dos hackers, dando-lhes um atalho para uma receita literal para o desastre em sua corrida para explorar a vulnerabilidade como uma arma.
3. Quão sério deve ser o erro?
Quase todas as vulnerabilidades recém-descobertas são atribuídas a um identificador CVE. Posteriormente, após uma inspeção mais detalhada por pesquisadores de segurança, uma vulnerabilidade é classificada como gravidade, ou seja, uma medida de seu impacto.
Um esquema de classificação importante é uma Avaliação de Vulnerabilidade geral do sistema (CVSS - Common Vulnerability Scoring System) . Ele representa uma vulnerabilidade como um conjunto de números, cada um dos quais é uma pontuação para uma característica, por exemplo:
- Quão fácil é reproduzir (usar).
- Como é difícil consertar.
- A escala do impacto na disponibilidade de servidores e serviços.
- Importância ou confidencialidade dos dados abertos.
O conjunto completo inclui muitas outras avaliações semelhantes. O algoritmo combina isso em uma pontuação de linha de base , um número puro que representa a gravidade da vulnerabilidade, variando de 0 (baixo) a 10 (alto). O CVSS da segunda versão divide os intervalos desses números nas palavras-chave LOW, MEDIUM e HIGH. A nova versão do CVSS 3 adiciona mais dois: NONE e CRITICAL.
Assim, o número de vulnerabilidades varia não apenas por meses e anos, mas também pela gravidade.
Esquemas de classificação de vulnerabilidade, como CVSS, permitem que os fornecedores de Linux avaliem como responder a uma vulnerabilidade de kernel específica. Por exemplo, eles podem querer escrever patches para vulnerabilidades com uma pontuação cumulativa de 7 ou mais. Isso significa HIGH em CVSS v2, HIGH ou CRITICAL em CVSS v3. Um fornecedor que alega ter como alvo vulnerabilidades críticas só pode estar se referindo a vulnerabilidades com classificações de gravidade 9 e 10 ao usar CVSS v3.
4. Posso reverter um patch?
Instalar patches automaticamente sem qualquer supervisão é uma ideia terrível para muitos administradores de sistemas. Eles sabem que mesmo correções totalmente testadas podem alterar o comportamento de um sistema, afetando seu desempenho ou funcionalidade de uma forma sutil e não totalmente óbvia. Quando isso acontece, quando o servidor se comporta de maneira estranha após a instalação do patch, a maneira mais rápida de lidar com isso é removendo o patch.
Alguns serviços de patch em tempo real podem remover patches. Isso torna mais fácil determinar se uma atualização recente está causando uma mudança no comportamento do sistema.
5. Posso hospedar meu próprio servidor de patch?
O agente de software de patch verifica em tempo real os patches disponíveis nos servidores remotos do Patch. Ele faz isso em intervalos regulares configuráveis, geralmente com a capacidade de realizar verificações personalizadas. Se um patch estiver disponível, o software do agente fará o download e instalará. Porém, se o agente de patch não puder se comunicar com o servidor de patch onde o serviço de patch do fornecedor armazena os patches, o patch ao vivo não acontecerá.
Para resolver esse problema, você precisa criar seu próprio servidor de patch. Esse servidor local transmite patches para todos os computadores em sua empresa sob o seu firewall. O Copy Safe baixa o patch e o distribui pelo firewall após verificar a integridade dos arquivos do patch. Você pode gerenciar e auditar esse processo conforme sua conveniência, deixando o conselho de administração da sua empresa um pouco mais relaxado.
Há outros benefícios também:
- Você tem melhor controle sobre quais patches seus servidores recebem e quando.
- Você pode bloquear um grande número de servidores para níveis de patch conhecidos.
- É mais fácil separar clusters de servidores para desenvolvimento, teste, preparação e produção.
A correção dinâmica requer um agente local e um servidor de correção remoto. Controlar ambos é crítico para implantações corporativas.
Conclusão
Antes de acordar, aqui estão três perguntas adicionais para fazer a um potencial fornecedor de soluções de patch:
- Posso cancelar a renovação automática? Há momentos em que você não deseja atualizar os kernels automaticamente.
- Em quais plataformas funciona? Embora seu ambiente de servidor possa impedir qualquer flexibilidade na escolha de uma solução de patch em tempo real, é melhor se a assinatura do serviço não limitar qual variante do Linux você precisa usar.
- ? , Linux. . , .
O fato de serem menos proeminentes nas listas de descrição de produtos de fornecedores de patches não torna os recursos descritos neste artigo menos importantes. Qualquer um deles pode influenciar sua decisão de entrar em contato com um fornecedor específico. Cada um deles pode afetar diretamente a eficácia e a relevância da solução para o seu ambiente. Como as taxas de assinatura do servidor variam de algumas dezenas por mês a milhares de dólares americanos por ano, é útil ter cuidado ao escolher uma solução de patch do kernel do Linux.
Consulte Mais informação:
Instale e configure as
melhores práticas do AlienVault SIEM (OSSIM) 10 para proteger imagens Docker. Parte 1
10 práticas recomendadas para proteger imagens Docker. Parte 2