Por que você deve automatizar as atualizações do kernel do Linux

O software é complexo e está em constante mudança. Os bugs são inevitáveis. Antes da era da internet, os bugs eram apenas falhas a serem corrigidas. Hoje, são oportunidades — uma das formas pelas quais os hackers obtêm acesso não autorizado aos sistemas. O setor de segurança cibernética prospera com essa ameaça. Seus produtos “defendem” e “protegem”, mas não conseguem sanar uma lacuna de segurança simples: a exploração de vulnerabilidades que persistem em sistemas operacionais e aplicativos desatualizados e sem patches.

Este artigo analisa o contexto desse problema e oferece dicas para resolvê-lo por meio do uso de pacotes de atualização automáticos para Ubuntu, Red Hat e Fedora, além de soluções de correção dinâmica oferecidas pela KernelCare, Kgraft, Ksplice e Livepatch.

Mudança em alta velocidade

Há uma crise silenciosa no desenvolvimento de software.

Para os programadores, as coisas nunca estiveram tão boas. O trabalho deles alcança tantas pessoas em praticamente todas as esferas da vida. As oportunidades para os desenvolvedores são astronômicas, e as possibilidades para nós, usuários, são impressionantes.

Paradoxalmente, para os programadores, as coisas nunca foram tão difíceis. A pressão sobre eles para aprender e criar coisas novas nunca foi tão grande. Muito antes de escreverem uma única linha de código, eles passam horas lendo e aprendendo linguagens, relendo e reaprendendo quando as APIs e os comportamentos mudam. As linguagens de programação têm até mesmo seu próprio “hit parade” mensal (www.tiobe.com), e os programadores que se candidatam a vagas em gigantes da tecnologia precisam ter pelo menos seis linguagens em seus currículos para terem alguma chance de conseguir uma entrevista. Já se foram os dias em que era possível conseguir um emprego com um livro “K&R” com as páginas marcadas e uma folha de referência de SQL fotocopiada.

Não há mais heróis, de jeito nenhum

E não há mais heróis. Hoje, todos trabalham em equipes e se baseiam no trabalho dessas equipes. Seus membros estão espalhados por todos os cantos e são flexíveis, conectados e dedicados, mas poucos deles chegam a se encontrar pessoalmente. Desses membros, o código se espalha e flui para outras equipes, que o testam, o levam ao limite e fazem o possível para quebrá-lo.

Tudo isso leva tempo, mas não há tempo, porque você e eu estamos esperando pelas novidades, pela próxima versão, pela atualização mais recente. Recebemos isso na forma de código que se aglomera em uma enorme bola de chiclete de esforço humano concentrado chamada “lançamento”. É o resultado do trabalho de muitas pessoas escrevendo código em várias linguagens. É uma mudança acelerada, e a recompensa é o progresso.

Continue lendo: Garantindo a conformidade com um gerenciamento mais ágil de patches

O Bom, o Mau e o Fofinho

Como a complexidade do software se transforma em risco.

Primeiro, vamos concordar que o progresso é bom. Portanto, se o progresso é bom, então a mudança também é boa. Mas mudança significa risco, e isso não é bom, porque um código que está sempre mudando apresenta um risco maior de bugs. Antes da era da internet, bugs eram apenas bugs. Embora houvesse riscos associados a bugs não intencionais e não detectados, havia um limite para seu alcance e efeito. Na era da internet, esses limites não se aplicam mais.

Com a explosão da interconectividade entre aplicativos, os bugs não são mais apenas um incômodo. Eles se tornaram uma oportunidade para um tipo de programador cujo talento se equipara ao daqueles que criam o código. São programadores que tentam quebrar o código. Eles são conhecidos por vários nomes e trabalham com diversos objetivos. O nome mais popular é “hackers”, e seus objetivos são variados.

Vejo três tipos de hackers: os bons, os maus e os inofensivos. Os bons são a comunidade ativa de pesquisadores, que estão constantemente testando softwares novos e antigos em busca de vulnerabilidades. Os inofensivos fazem isso por diversão e emoção, por reputação e aprendizado. Os maus fazem isso por todas essas razões, mas principalmente por dinheiro ou seu equivalente: dados.

O ponto cego da segurança cibernética

Softwares desatualizados representam uma brecha na segurança cibernética.

A segurança cibernética é um setor amplo e em crescimento. Há uma infinidade de produtos à disposição, todos contribuindo, em maior ou menor grau, para proteger os sistemas de computador contra infiltrações e explorações ilegais. Esses produtos incluem antivírus e antimalware, firewalls de vários tipos, verificadores de login e de senha, além de sniffers de dados — componentes distintos, cada um projetado para se defender contra um método, ou vetor, diferente de ataque.

Mas eles têm um ponto cego. Mesmo o produto de segurança mais sofisticado não consegue proteger totalmente um sistema desatualizado. Deveria ser simples manter o software sempre atualizado, mas não fazemos isso. Isso fica evidente nos inúmeros incidentes registrados de sistemas comprometidos por vulnerabilidades em softwares desatualizados.

Então, vamos perguntar: “Por que os sistemas ficam desatualizados?”

A resposta mais óbvia é: porque deixamos que isso aconteça. Instalar e atualizar sistemas exige tempo e esforço. Precisamos programar o tempo de inatividade, fazer login, executar comandos ou usar uma interface gráfica. É trabalhoso e enfadonho. Podemos ter que repetir isso várias vezes por ano em dezenas ou até centenas de servidores.

A tarefa fica mais fácil com ferramentas de gerenciamento de configuração de servidores. Dessa forma, todos os servidores são atualizados ao mesmo tempo. Mas as ferramentas de qualidade custam dinheiro, e as gratuitas exigem tempo para serem aprendidas — poucos de nós podemos nos dar ao luxo de usar qualquer uma delas. Podemos automatizar o processo com scripts, mas isso requer conhecimentos de programação que alguns de nós não possuem.

A Perspectiva do Linux

O Linux não consegue se atualizar automaticamente, como outros sistemas operacionais.

Até agora, tudo o que foi dito se aplica à maioria das plataformas de computador contemporâneas, convencionais e não móveis. Quero me concentrar agora em um subconjunto delas: a comunidade de servidores Linux. O Linux evoluiu de maneira diferente dos outros sistemas operacionais. Começou como um hobby, com base no MINIX. Cresceu graças ao esforço da comunidade, em sua maioria não comercial. À medida que o número de plataformas Linux ativas aumentava, também crescia seu apelo para a comunidade hacker. Outro atrativo foi a popularidade do Linux como uma plataforma de hospedagem barata e flexível. Os hackers adoram isso: um único servidor costuma hospedar centenas de sites, e um site invadido pode se tornar uma porta de entrada para outros sites no mesmo servidor.

O Linux conta com um vasto acervo de softwares livres e com bom suporte, além de uma grande variedade de distribuições ativas; esses são os benefícios do desenvolvimento comunitário de código aberto. As desvantagens são que os recursos evoluem lentamente, possivelmente devido ao fenômeno da projeto em comitê, ou talvez porque a maioria dos desenvolvedores que contribuem trabalha de graça.

Por exemplo, o Linux ainda não dispõe de uma ferramenta de gerenciamento de software totalmente integrada, automática e com atualização automática, embora existam maneiras de fazer isso, algumas das quais veremos mais adiante. Mesmo com essas opções, o kernel do sistema não pode ser atualizado automaticamente sem reinicialização.

E aqui vemos mais um motivo pelo qual os sistemas ficam desatualizados com tanta facilidade: a necessidade de evitar tempo de inatividade. Os administradores de servidor podem decidir priorizar seus usuários ativos e aplicativos críticos, adiando a instalação de patches que exigem a reinicialização do sistema.

O sussurro de um paranóico

Mas, de todas as razões, há uma que os administradores de sistema preferem não mencionar abertamente. É o medo de que o servidor não consiga mais iniciar, de que um patch cause algum problema. Isso nem sempre é admitido porque soa a paranóia e é impossível de provar.

Acho que essa é uma preocupação legítima. Afinal, um patch no kernel é uma alteração no núcleo do sistema operacional. Existem patches mal escritos, e não é incomum que eles causem falhas ou alterem sutilmente o funcionamento de um sistema. Seja uma alteração no desempenho ou na funcionalidade, para a maioria dos gerentes responsáveis por sistemas em produção, nenhuma das duas opções é aceitável.

Fechando a brecha de segurança do Linux

A segurança melhora quando se automatizam as atualizações do Linux.

Você mesmo pode atualizar automaticamente os aplicativos e kernels do Linux combinando um programa de agendamento, como cron, com o responsável pela manutenção de pacotes da sua plataforma, como, por exemplo, yum, apt, ou dnf. Alguns fornecedores de Linux fizeram isso criando pacotes que fazem atualização automática para você. E, como tudo no Linux, cada versão faz isso de um jeito diferente.

• Debian e Ubuntu ter o unattended-upgrades pacote.
• O Fedora possui o dnf-automatic para atualizações automáticas.
• A Red Hat oferece o yum-cron (disponível apenas pelo canal “Supplementary”; ou seja, mediante pagamento).

No entanto, quem usar esses recursos sem reconfigurar as opções provavelmente terá uma surpresa como esta em algum momento:

The computer needs to restart to finish installing updates.

Isso ocorre porque, ao contrário dos aplicativos, as atualizações automáticas não significam que você possa instalar atualizações do kernel sem reiniciar o sistema.

E há a falha de segurança. Ninguém quer reiniciar arbitrariamente servidores que estão em uso ativo. É por isso que os kernels geralmente são excluídos nas configurações de atualização automática. Mas kernels desatualizados são kernels vulneráveis, e kernels vulneráveis estão sujeitos a exploração.

Artigo relacionado: 5 motivos ruins para atualizar seu kernel

Lacunas e falhas

A solução para esse dilema é a aplicação de patches em tempo real. É uma forma de manter os kernels atualizados com os patches de segurança mais recentes, sem a necessidade de reiniciar o sistema ou tolerar tempo de inatividade. É o elo que faltava na automação completa da sua estratégia de atualização do sistema Linux.

Assim como no caso das atualizações automáticas, cada fornecedor de Linux implementa a aplicação de patches em tempo real de maneira diferente. Além disso, oferecer esse serviço gratuitamente não é fácil; a aplicação de patches em tempo real tornou-se útil demais para que se evitasse sua comercialização.

No caso do Ubuntu, o Serviço Livepatch da Canonical instala patches de segurança do kernel do Linux sem a necessidade de reinicialização. A Red Hat lançou o Kpatch e a SUSE, o Kgraft, ambos com o mesmo objetivo; os dois fornecedores só entraram em ação quando a Oracle adquiriu a Ksplice, para depois retirar o suporte a tudo que não fossem suas próprias versões. Um salvador improvável surgiu em 2014, quando a KernelCare entrou no mercado, oferecendo suporte a todos os principais fornecedores e a kernels tão antigos quanto o 2.6.18.

Obtenha uma versão de avaliação GRATUITA de 7 dias do KernelCare com suporte técnico 

Conclusão

Automatize as atualizações do Linux por motivos de segurança, e não por conveniência.

O Linux tanto se beneficia quanto sofre com a forma como é desenvolvido. Por mais que se preocupe com a segurança cibernética, não é possível resolver o problema das vulnerabilidades sem correção.

Embora existam soluções para a atualização automática de aplicativos, o kernel continua sendo o ponto fraco — uma atualização dele quase sempre implica uma reinicialização.

A aplicação de patches em tempo real preenche a lacuna nas estratégias de atualização automática. Você deve considerá-la uma parte essencial da sua estratégia de segurança para servidores Linux, e não apenas uma conveniência.