Gerenciamento de servidores Linux: aplicação de patches, monitoramento e segurança para MSPs

A maioria dos MSPs opera no Windows. A maioria dos clientes utiliza o Windows. Mas o parque de servidores por trás desses clientes está cada vez mais diversificado, com o Linux operando discretamente os servidores web, back-ends de aplicativos, hosts de bancos de dados, plataformas de contêineres e cargas de trabalho nativas da nuvem das quais os clientes do Windows dependem. Quer o MSP queira gerenciar o Linux ou não, o Linux está presente no ambiente.

Os MSPs que acertam nessa questão tratam o Linux como um componente de primeira classe do ambiente de gerenciamento. Eles aplicam a mesma disciplina de atualização, a mesma cobertura de monitoramento, o mesmo reforço de segurança e a mesma estratégia de backup em ambos os sistemas operacionais, a partir do mesmo console, sempre que possível. Os MSPs que não fazem isso direito acabam com servidores Linux gerenciados com base em “conhecimento tribal”, atualizados manualmente quando alguém se lembra, monitorados por quaisquer scripts bash que o último engenheiro tenha escrito e com backups feitos da forma que o proprietário do aplicativo configurou anos atrás.

Este guia aborda o que envolve, na prática, o gerenciamento de servidores Linux, em que aspectos essa disciplina difere do Windows e como os MSPs podem operar ambos os sistemas operacionais a partir de um modelo operacional unificado.

Gerencie terminais Linux e Windows a partir de um único console.

O Kaseya VSA 10 oferece gerenciamento automatizado de patches, monitoramento e gerenciamento remoto para servidores Linux, estendendo o mesmo modelo operacional que abrange os terminais Windows aos ambientes Linux.

Conheça o Kaseya VSA 10

O que é o gerenciamento de servidores Linux?

O gerenciamento de servidores Linux é a disciplina que visa manter os servidores Linux atualizados, monitorados, protegidos, com backups e em bom estado operacional ao longo de toda a sua vida útil. Abrange servidores físicos e virtuais, tanto locais quanto hospedados na nuvem, ambientes com uma única distribuição e ambientes mistos que executam desde o Ubuntu Server até o RHEL, passando pelo Debian e pelo Amazon Linux.

O escopo reflete, em princípio, o gerenciamento de servidores Windows. É preciso aplicar patches. É preciso monitorar os serviços. É preciso analisar os logs. É preciso verificar os backups. É preciso reforçar as configurações. No entanto, a mecânica é diferente, e é aí que os MSPs acostumados a ambientes exclusivamente Windows enfrentam dificuldades.

Em que aspectos o gerenciamento de servidores Linux difere do Windows

Três diferenças são as mais importantes.

O primeiro é o gerenciamento de pacotes. As atualizações do Windows são fornecidas por meio do Windows Update ou do WSUS, um único canal de atualização para o sistema operacional e os aplicativos da Microsoft. As distribuições Linux utilizam gerenciadores de pacotes (apt para Debian e Ubuntu, dnf ou yum para RHEL, CentOS e Fedora, zypper para SUSE) que lidam com atualizações do sistema operacional, atualizações de aplicativos e resolução de dependências a partir de uma única ferramenta. O fluxo de trabalho de aplicação de patches é diferente, os repositórios de pacotes são diferentes e as consequências de uma atualização com falha são diferentes.

O segundo aspecto é a cultura de gerenciamento de configuração. Os ambientes Windows são fortemente orientados por interface gráfica (GUI) e gerenciados por políticas de grupo. Os ambientes Linux são fortemente orientados por arquivos de configuração e, frequentemente, gerenciados por meio do Ansible, Puppet, Chef ou scripts de shell. Um MSP que não possua uma linha de base de configuração documentada para um servidor Linux herda o estado em que o proprietário anterior o deixou, sem um equivalente à Política de Grupo ao qual recorrer.

O terceiro é o silêncio da falha. Um serviço do Windows com comportamento anômalo geralmente se manifesta por meio do Visualizador de Eventos, do SCM ou de um sinal claro na interface do usuário. Um serviço do Linux com comportamento anômalo grava em um arquivo de log, encerra com um código de status diferente de zero e fica em silêncio. Se nada estiver lendo esses logs, ninguém saberá que o serviço parou de funcionar. A disciplina de monitoramento é mais importante no Linux do que no Windows, pois o próprio sistema operacional faz menos para sinalizar um problema.

Gerenciamento de patches no Linux

O gerenciamento de patches no Linux é a parte mais frequente e mais crítica para a segurança dessa disciplina. O Kaseya VSA 10 oferece suporte ao gerenciamento de patches nas principais distribuições Linux, automatizando o fluxo de trabalho de detecção, agendamento, aprovação e implantação que as atualizações manuais de pacotes exigem.

Algumas áreas de correção merecem atenção especial.

As atualizações do kernel exigem reinicializações e devem ser programadas em janelas de manutenção, juntamente com verificações de reinício dos serviços. Opções de aplicação de patches no kernel em tempo real, como o Canonical Livepatch ou o kpatch, podem reduzir a frequência de reinicializações em hosts críticos, mas não substituem as reinicializações planejadas; elas apenas as adiam.

As atualizações do OpenSSL e das bibliotecas criptográficas afetam um grande número de aplicativos dependentes. Uma vulnerabilidade do tipo Heartbleed no OpenSSL afeta todos os serviços que dependem dele, e um patch aplicado sem reiniciar esses serviços deixa a versão antiga da biblioteca carregada na memória. O gerenciamento de patches no Linux significa acompanhar o que está corrigido no disco e o que está realmente em execução.

Servidores web, bancos de dados e outros softwares de aplicativos (Apache, Nginx, MySQL, PostgreSQL, Redis) funcionam sobre o sistema operacional, mas possuem seu próprio ritmo de atualização e seus próprios feeds de CVE. Os gerenciadores de pacotes da distribuição cuidam dos pacotes básicos, mas os ambientes de produção costumam utilizar repositórios fornecidos pelos fornecedores ou imagens de contêineres que precisam ser monitorados separadamente.

Os utilitários do sistema com histórico de vulnerabilidades ativas (sudo, polkit, glibc, systemd) tendem a ser alvos de exploits de escalonamento de privilégios. Eles recebem correções em ciclos normais, mas vale a pena destacá-los no gerenciamento de mudanças, pois uma atualização não aplicada em um CVE do sudo pode transformar um ponto de entrada com privilégios baixos em acesso root total.

Monitoramento e observabilidade do Linux

O monitoramento de servidores Linux abrange quatro áreas: recursos do sistema, disponibilidade dos serviços, atividade dos logs e integridade dos arquivos.

O monitoramento de recursos do sistema acompanha a carga da CPU, a pressão na memória, a utilização do disco (tanto de espaço quanto de E/S), o uso da área de troca e a taxa de transferência da rede. O esgotamento do espaço em disco é a causa mais comum de falha nos serviços do Linux; diretórios de log ou logs de transações de bancos de dados que ocupam todo o espaço do volume raiz podem derrubar todo o sistema no host sem aviso prévio. O alerta por limite na utilização do disco é imprescindível.

O monitoramento da disponibilidade dos serviços confirma se os processos que o servidor deveria estar executando estão, de fato, em execução e respondendo. Um serviço do systemd que aparece como ativo, mas que deixou de responder às solicitações, fica invisível para o comando `systemctl status`; é necessário verificá-lo externamente para detectar a falha. As verificações de HTTP, conexão com banco de dados e porta TCP constituem a base desse monitoramento.

O monitoramento de logs abrange logs do sistema (journald, /var/log/syslog, /var/log/messages), logs de aplicativos (logs de acesso e de erros do servidor web, logs de consultas lentas do banco de dados) e logs de segurança (eventos de autenticação, chamadas do sudo, tentativas de conexão via SSH). Padrões anômalos nesses logs costumam ser o primeiro sinal de uma invasão.

O monitoramento da integridade de arquivos detecta alterações não autorizadas em arquivos críticos do sistema. Ferramentas como o AIDE ou o Tripwire estabelecem uma linha de base do estado esperado dos binários e arquivos de configuração do sistema e alertam quando ocorrem alterações inesperadas. Esse é um controle que distingue operações maduras do Linux de ambientes com monitoramento mínimo.

O Kaseya VSA 10 oferece monitoramento do Linux por meio de sondagens SNMP e verificações baseadas em agentes, com scripts personalizados que podem ser implantados para monitorar indicadores de integridade específicos de aplicativos que o monitoramento genérico não abrange.

Segurança e fortalecimento do Linux

O fortalecimento da segurança do Linux se baseia na aplicação disciplinada de patches. Além de manter os pacotes atualizados, as práticas que reduzem significativamente a superfície de ataque são bem conhecidas e vale a pena aplicá-las como padrão básico.

O SSH deve exigir autenticação baseada em chaves, e não em senhas. A opção PasswordAuthentication deve ser definida como “no” no arquivo sshd_config, a opção PermitRootLogin deve ser definida como “no”, e o login deve ser feito por meio de contas sem privilégios que elevam seus privilégios usando o sudo. A maioria dos ataques de força bruta bem-sucedidos contra servidores Linux ocorre porque a autenticação por senha permanece habilitada no SSH, geralmente na porta padrão 22.

Serviços e portas desnecessários devem ser desativados. Um servidor web não precisa ter um relé de e-mail em execução, um servidor de banco de dados não precisa de um servidor web e um agente de compilação não precisa de nenhum dos dois. Reduzir a área de exposição dos serviços em escuta diminui as vias de acesso que um invasor tem ao servidor.

O acesso ao sudo deve seguir o princípio do privilégio mínimo. Conceder acesso geral ao sudo ao grupo `wheel` a todos os usuários administrativos é conveniente do ponto de vista operacional, mas representa um risco à segurança. As entradas de sudo específicas por comando, registradas pelo `auditd`, permitem visualizar quais comandos com privilégios foram realmente executados e por quem.

O SELinux ou o AppArmor devem ser ativados nos casos em que a distribuição ofereça suporte a eles. Ambos são estruturas de controle de acesso obrigatório que restringem as ações que os processos podem realizar, indo além das permissões tradicionais de arquivos. Sua configuração para aplicativos personalizados não é trivial, mas, para serviços padrão da distribuição, eles aumentam significativamente o custo de uma exploração bem-sucedida.

O Kaseya SIEM capta os dados do syslog dos servidores Linux e correlaciona os eventos de segurança do Linux com a telemetria de terminais, rede e nuvem proveniente de mais de 60 fontes de dados. Falhas de autenticação, eventos de escalonamento de privilégios e execução de processos incomuns em servidores Linux são os sinais que se perdem quando os logs de cada servidor ficam isolados no host. Com a correlação entre superfícies, uma sequência de tentativas de SSH malsucedidas seguida por um login bem-sucedido e, em seguida, por uma conexão de saída para um destino incomum aparece como uma única cadeia de ataque, e não como três eventos não relacionados.

Backup e recuperação de desastres para servidores Linux

Os servidores Linux precisam das mesmas medidas de recuperação que os servidores Windows. Backup em nível de imagem, captura consistente com aplicativos, testes regulares de restauração e uma cópia replicada em local externo ou na nuvem para recuperação de desastres.

O Datto BCDR oferece backup em nível de imagem para máquinas virtuais (VMs) Linux e servidores Linux bare-metal, com a mesma captura consistente com aplicativos e a mesma capacidade de virtualização instantânea que a plataforma oferece para o backup de VMs Windows. O mesmo dispositivo “ SIRIS ” pode abrigar ambientes protegidos tanto no Windows quanto no Linux, o que simplifica as operações de recuperação em ambientes com sistemas operacionais mistos.

Conheça o Datto BCDR para backup de servidores Linux.

Gerenciamento de servidores Linux para MSPs: gerenciamento de ambientes mistos

A maioria dos MSPs não tem a opção de escolher entre Windows e Linux. Eles atendem a um cliente cuja infraestrutura principal é baseada no Windows, mas cuja pilha web voltada para o cliente roda no Ubuntu; ou a um cliente do setor de manufatura cujo backend de ERP está no RHEL; ou a um cliente de desenvolvimento de software cuja infraestrutura de compilação inteira é composta por contêineres Linux.

O que diferencia um MSP não é se ele oferece suporte ao Linux, mas sim se aplica o mesmo rigor operacional a ele. Considere o cenário comum do problema. Um cliente de serviços profissionais com 40 usuários possui duas máquinas virtuais (VMs) Linux que hospedam sua presença na web pública e seu wiki interno. O lado do Windows é totalmente gerenciado pelo serviço padrão do MSP. A parte do Linux está “coberta”, mas recebe patches manualmente sempre que alguém se lembra, sem nenhum monitoramento além de verificações de ping. Uma vulnerabilidade CVE no kernel é divulgada, uma estação de trabalho é comprometida por uma rota não relacionada e o invasor se move lateralmente para a VM Linux sem patch, que se torna o ponto de persistência. A parte do Windows resistiu. A parte do Linux, que o MSP não estava realmente gerenciando, não resistiu.

O trabalho técnico necessário para colocar o Linux no mesmo padrão não é muito extenso. Basta implantar o agente VSA, programar a aplicação de patches, definir limites de monitoramento, importar o syslog para o SIEM e adicionar os hosts à programação de backup. A parte difícil é reconhecer que o servidor Linux semigerenciado é um risco que precisa ser gerenciado adequadamente ou explicitamente excluído do escopo, e não ficar em um meio-termo.

Como o “ Kaseya Intelligence ” muda as operações do Linux

Kaseya Intelligence baseia-se em mais de três exabytes de dados agregados e anônimos e em mais de 17 milhões de terminais gerenciados, possibilitando ações autônomas em toda a plataforma Kaseya 365 . A mudança consiste em passar da simples apresentação de recomendações para a execução e validação de resultados sem intervenção manual.

Em ambientes de servidores Linux, isso é fundamental na aplicação de patches, onde o agendamento manual e a verificação pós-aplicação historicamente tornaram o Linux desproporcionalmente demorado em comparação com o Windows. A implantação automatizada de patches por meio do Kaseya VSA 10, combinada com a validação de fluxos de trabalho orientada por inteligência, elimina essa lacuna. A mesma eficiência operacional que permite que a aplicação de patches no Windows seja escalonada para milhares de terminais começa a se aplicar ao Linux. Explore Kaseya Intelligence.

Um servidor Linux que receba patches, seja monitorado, fortificado e tenha backup de acordo com o mesmo padrão dos servidores Windows ao seu lado não é um projeto de engenharia exótico. Trata-se da mesma disciplina de gerenciamento aplicada a um gerenciador de pacotes diferente. Os MSPs que internalizam isso e operam o Linux como parte integrante do parque de equipamentos são aqueles cujos clientes não são pegos de surpresa por um incidente relacionado ao Linux. Os MSPs que não fazem isso são aqueles que precisam explicar ao cliente, após o fato, por que a máquina da qual eles não tinham conhecimento foi justamente a que permitiu a entrada do invasor.

Pontos principais

• O gerenciamento de patches no Linux utiliza gerenciadores de pacotes específicos de cada distribuição (apt, dnf, yum, zypper). O Kaseya VSA 10 automatiza esse processo nas principais distribuições, juntamente com o gerenciamento de patches do Windows.
• A autenticação baseada em chaves SSH, a exposição mínima dos serviços, o uso do `sudo` com o princípio do privilégio mínimo e o SELinux ou o AppArmor são as práticas de fortalecimento de segurança que reduzem significativamente a superfície de ataque do Linux.
• A captação de syslog do Kaseya SIEM integra eventos de segurança do Linux à camada de correlação, juntamente com dados de terminais, rede e nuvem, eliminando o ponto cego gerado pelo gerenciamento isolado de logs.
• Para os MSPs, o servidor Linux semiautônomo é um risco. É preciso ou alinhá-lo ao mesmo padrão operacional do parque de servidores Windows ou excluí-lo explicitamente do escopo; a posição intermediária é que acaba fracassando.