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 usa 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 fazem isso da maneira certa tratam o Linux como um componente de primeira linha 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 informal, atualizados manualmente quando alguém se lembra, monitorados por quaisquer scripts bash que o último engenheiro tenha escrito e com backup feito 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 administrar ambos os sistemas operacionais a partir de um modelo operacional unificado.

O que é o gerenciamento de servidores Linux?

A gestão 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, instalados localmente ou hospedados na nuvem, ambientes com uma única distribuição e infraestruturas mistas 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 registros. É 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 encontram dificuldades.

Em que a gestão de servidores Linux difere da gestão de servidores 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 canal único 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 interfaces gráficas (GUI) e gerenciados por políticas de grupo. Os ambientes Linux são fortemente orientados por arquivos de configuração e, muitas vezes, gerenciados por meio de 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 do fracasso. 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

A gestão de patches no Linux é a parte mais frequente e mais crítica em termos de segurança dessa disciplina. O Kaseya VSA 10 oferece suporte à gestão 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 reinicialização 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 uma ampla gama de aplicativos dependentes. Uma vulnerabilidade do tipo Heartbleed no OpenSSL afeta todos os serviços que utilizam essa biblioteca, e a aplicação de um patch sem reiniciar esses serviços deixa a versão antiga da biblioteca carregada na memória. O gerenciamento de patches no Linux implica 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 ciclo de atualizações 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) costumam ser alvos de exploits de escalonamento de privilégios. Eles recebem correções em ciclos regulares, 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 limitados 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 sobre a 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 banco de dados que ocupam todo o espaço do volume raiz podem derrubar todo o sistema no host sem aviso prévio. A configuração de alertas de limite para a 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 realmente em execução e respondendo. Um serviço do systemd que aparece como ativo, mas que deixou de responder às solicitações, não é detectado pelo comando `systemctl status`; é necessário verificá-lo externamente para identificar a falha. As verificações de HTTP, conexão com o banco de dados e porta TCP constituem a base.

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 SSH). Padrões anômalos nesses logs costumam ser o primeiro sinal de uma violaçã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 Linux maduras 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 implementados 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 baseia-se na aplicação disciplinada de correções. 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 por chave, e não por senha. 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 devido à autenticação por senha ativada 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 servidor de retransmissão 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 superfície de exposição dos serviços em escuta diminui as vias de acesso que um invasor tem ao servidor.

O acesso via sudo deve seguir o princípio do privilégio mínimo. Conceder acesso sudo generalizado 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 saber 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 os suporta. Ambos são estruturas de controle de acesso obrigatório que restringem as ações dos processos além das permissões tradicionais de arquivos. Sua configuração para aplicativos personalizados não é trivial, mas, no caso de serviços padrão da distribuição, aumentam significativamente o custo de uma exploração bem-sucedida.

O Kaseya SIEM capta os registros syslog de servidores Linux e correlaciona eventos de segurança do Linux com dados de telemetria de terminais, redes e nuvem provenientes 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. Isso inclui 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 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 máquinas virtuais Windows. O mesmo SIRIS pode abrigar ambientes protegidos tanto para Windows quanto para 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 é 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 é inteiramente 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 esse sistema. Considere o cenário típico 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. O lado Linux é “coberto”, mas recebe patches manualmente sempre que alguém se lembra, sem nenhum monitoramento além de verificações de ping. Um CVE do kernel é divulgado, 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. O lado Windows resistiu. O lado Linux, que o MSP não estava realmente gerenciando, não resistiu.

O trabalho técnico necessário para colocar o Linux no mesmo nível não é muito complexo. Basta instalar o agente VSA, programar a aplicação de patches, definir limites de monitoramento, integrar o syslog ao SIEM e adicionar os hosts à programação de backup. O difícil é reconhecer que um servidor Linux semigestionado é um risco que precisa ser gerenciado adequadamente ou explicitamente excluído do escopo, e não ficar em uma situação intermediária.

Como Kaseya Intelligence as operações em Linux

Kaseya Intelligence utiliza mais de três exabytes de dados agregados e anônimos e mais de 17 milhões de terminais gerenciados, possibilitando ações autônomas em toda a 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 servidor Linux, isso é fundamental na aplicação de patches, onde o agendamento manual e a verificação pós-aplicação têm, historicamente, tornado 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 a aplicação de patches no Windows em milhares de terminais passa a se aplicar ao Linux. Explore Kaseya Intelligence.

Um servidor Linux que receba patches, seja monitorado, fortificado e tenha backup de acordo com os mesmos padrões 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 executam 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.