Aula 30: Linux em produção — boas práticas para servidores corporativos

Chegamos à aula final do curso Linux — Do Zero ao Avançado. Ao longo das 29 aulas anteriores, você construiu uma base sólida que vai desde os primeiros comandos no terminal até o gerenciamento de serviços, permissões, redes, scripts e containers. Agora, o objetivo é consolidar todo esse conhecimento em um contexto real: preparar, proteger, monitorar e manter servidores rodando Linux em produção. Nesta aula, você não vai apenas instalar pacotes ou editar arquivos de configuração — você vai aplicar um conjunto de boas práticas corporativas que separam um ambiente de teste funcional de uma infraestrutura estável, segura e auditável.

Gerenciar Linux em produção é muito diferente de administrar uma máquina de laboratório. Em um servidor corporativo, cada minuto de indisponibilidade pode representar prejuízo financeiro, perda de contratos ou exposição de dados sensíveis. Por isso, a abordagem precisa ser preventiva e padronizada: hardening de acesso, firewall, atualizações automáticas, monitoramento contínuo, auditoria de logs e backups confiáveis são requisitos obrigatórios. Em nossos projetos na JRT Technology Solutions, nossos especialistas utilizam diariamente exatamente as práticas que você verá aqui para manter ambientes críticos de clientes dos setores financeiro, saúde e varejo funcionando com alta disponibilidade.

Ao final desta aula, você será capaz de transformar uma instalação Linux recém-provisionada — seja em um datacenter físico, em uma VM ou em um provedor de nuvem como AWS, Azure ou Google Cloud — em um servidor de produção corporativo. Você vai executar um processo completo de endurecimento (hardening), configurar um firewall com regras mínimas, ativar proteção contra ataques de força bruta com Fail2ban, automatizar atualizações de segurança, monitorar métricas essenciais, auditar eventos críticos e implementar uma rotina de backup verificável. Tudo isso seguindo um passo a passo rigoroso, com comandos reais e saídas esperadas.

Os pré-requisitos para esta aula são os conhecimentos das aulas anteriores, especialmente sobre systemd, SSH, firewall, gerenciamento de pacotes e permissões. Você precisará de acesso root ou sudo a duas máquinas virtuais — uma rodando Ubuntu Server 22.04/24.04 (Debian/Ubuntu) e outra rodando Rocky Linux 9 ou CentOS Stream 9 (RHEL) — com pelo menos 2 GB de RAM, 2 vCPUs e 20 GB de disco. Todos os procedimentos serão mostrados para ambas as famílias de distribuições, com as diferenças devidamente destacadas.

O que você vai aprender nesta aula

• Compreender os pilares de confiabilidade, segurança e observabilidade no gerenciamento de Linux em produção.
• Executar o hardening inicial de um servidor Linux, incluindo criação de usuário administrativo, configuração segura de SSH e ajustes de kernel.
• Configurar firewall com regras de política padrão restritiva em Ubuntu/Debian com UFW e em RHEL/Rocky com firewalld.
• Instalar e configurar o Fail2ban para bloquear tentativas de intrusão por força bruta.
• Automatizar atualizações de segurança usando unattended-upgrades no Ubuntu e dnf-automatic no Rocky Linux.
• Implantar o Node Exporter do Prometheus para expor métricas e configurar o sysstat para coleta histórica de desempenho.
• Configurar auditoria com auditd e boas práticas de rotação de logs com logrotate.
• Criar e agendar um script de backup com tar e rsync, incluindo testes de restauração.
• Verificar a configuração final e solucionar os erros mais comuns que ocorrem nesse tipo de ambiente.

Pré-requisitos e Ambiente

Para acompanhar esta aula sem interrupções, prepare duas máquinas virtuais limpas, preferencialmente com imagens oficiais minimizadas. Na JRT Technology Solutions, padronizamos o uso de imagens oficiais e repositórios atualizados para evitar surpresas com pacotes obsoletos ou backports mal configurados. As duas distribuições de referência desta aula serão:

• Ubuntu Server 22.04 LTS ou 24.04 LTS — família Debian, gerenciador de pacotes apt, firewall UFW, serviço de atualização unattended-upgrades.
• Rocky Linux 9 ou CentOS Stream 9 — família RHEL, gerenciador de pacotes dnf, firewall firewalld, serviço de atualização dnf-automatic.

Além disso, você deve ter acesso SSH funcional com usuário root ou um usuário com privilégios sudo. Recomendamos fortemente o uso de snapshots ou backups da VM antes de iniciar qualquer procedimento de hardening, pois algumas alterações — como desabilitar autenticação por senha no SSH — podem bloquear seu acesso se executadas incorretamente. Por fim, certifique-se de que o relógio do servidor esteja sincronizado via NTP (Network Time Protocol), pois logs, fail2ban e auditoria dependem de timestamps confiáveis.

A tabela a seguir resume os principais componentes que serão utilizados em cada distribuição ao longo da aula:

O que significa gerenciar Linux em produção

Antes de executar qualquer comando, é fundamental entender o que diferencia um servidor Linux em produção de uma máquina de desenvolvimento. Em produção, o servidor precisa estar disponível de forma contínua, responder de maneira previsível a picos de carga e resistir a ataques constantes da internet. Isso exige que você adote uma mentalidade de engenharia de confiabilidade: toda alteração deve ser planejada, testada e reversível. Nada pode ser feito “de qualquer jeito” — um simples erro de digitação em um arquivo de configuração pode derrubar o acesso de todos os administradores ou expor uma porta não autorizada.

Os quatro pilares que guiam o gerenciamento de Linux em produção são: segurança, confiabilidade, observabilidade e recuperabilidade. Segurança envolve reduzir a superfície de ataque, aplicar o princípio do menor privilégio e manter o sistema sempre atualizado. Confiabilidade significa garantir que os serviços críticos permaneçam disponíveis mesmo diante de falhas parciais, utilizando redundância e limites adequados de recursos. Observabilidade é a capacidade de saber o que está acontecendo no servidor em tempo real por meio de métricas, logs e alertas. Recuperabilidade é a certeza de que, se algo der errado, você poderá restaurar o estado anterior rapidamente a partir de backups íntegros.

Em nossos projetos na JRT Technology Solutions, padronizamos a adoção de Infrastructure as Code (IaC) para provisionar servidores Linux em produção de forma idempotente. Ferramentas como Ansible, Terraform e cloud-init permitem que a configuração de um servidor seja versionada, revisada e replicada em minutos. Embora nesta aula você execute os passos manualmente para entender cada detalhe, o ideal é automatizar tudo o que for repetitivo. A intenção aqui é formar um profissional capaz de entender o que cada camada faz e, posteriormente, transformar esse conhecimento em código.

Outra característica essencial de um servidor corporativo é a padronização. Nada de instalar pacotes manualmente sem registro, nada de configurar serviços fora do systemd, nada de depender de scripts não versionados. Toda alteração deve ser documentada, preferencialmente em um repositório Git, e acompanhada de justificativa. Isso permite auditorias, reprodução de ambientes e respostas rápidas a incidentes. Ao longo desta aula, você verá que cada procedimento segue um fluxo claro: instalar, configurar, habilitar, iniciar e verificar. Esse fluxo é a espinha dorsal do trabalho com Linux em produção.

Hardening inicial do Linux em produção

O primeiro passo para colocar um servidor Linux em produção é reduzir sua superfície de ataque e estabelecer uma base segura. Vamos começar atualizando o sistema, criando um usuário administrativo não-root, configurando autenticação por chave SSH e desabilitando métodos de acesso inseguros. Esse procedimento é essencial porque a maioria dos ataques automatizados tenta explorar senhas fracas no SSH ou vulnerabilidades conhecidas de pacotes desatualizados. Executar o hardening logo após o provisionamento evita que problemas sejam levados para o ambiente produtivo.

No Ubuntu/Debian, execute os seguintes comandos para atualizar todos os pacotes e instalar ferramentas básicas de administração segura:

# Atualiza a lista de pacotes disponíveis e aplica todas as atualizações pendentes
sudo apt update && sudo apt upgrade -y

# Instala pacotes essenciais para administração, segurança e monitoramento básico
sudo apt install -y openssh-server ufw fail2ban unattended-upgrades auditd sysstat rsync curl wget gnupg2 ca-certificates

# Remove pacotes desnecessários e limpa o cache local
sudo apt autoremove -y && sudo apt clean

No Rocky Linux / CentOS Stream, o procedimento equivalente utiliza o dnf. O comando dnf update -y atualiza todos os pacotes, e o dnf install instala as mesmas ferramentas, com exceção do ufw, que é substituído pelo firewalld:

# Atualiza todos os pacotes do sistema para as versões mais recentes
sudo dnf update -y

# Instala pacotes essenciais, incluindo firewalld no lugar de UFW
sudo dnf install -y openssh-server firewalld fail2ban dnf-automatic auditd sysstat rsync curl wget gnupg2 ca-certificates

# Habilita o serviço de firewall e remove pacotes órfãos
sudo systemctl enable --now firewalld
sudo dnf autoremove -y

Após a atualização, crie um usuário administrativo dedicado. Nunca utilize o usuário root diretamente para tarefas rotineiras. No Ubuntu, o comando adduser cria o usuário, o diretório home e solicita a definição de senha de forma interativa. Em seguida, adicione o usuário ao grupo sudo para conceder privilégios administrativos. No Rocky Linux, use useradd com as opções -m (criar home), -G wheel (adicionar ao grupo wheel, equivalente ao sudo) e -s /bin/bash (definir shell padrão):

# Ubuntu/Debian: cria o usuário 'admin' e o adiciona ao grupo sudo
sudo adduser admin
sudo usermod -aG sudo admin

# Rocky/RHEL: cria o usuário 'admin', com home, shell bash e grupo wheel
sudo useradd -m -G wheel -s /bin/bash admin
sudo passwd admin

Agora precisamos adicionar sua chave pública SSH ao novo usuário para permitir login sem senha. Se você ainda não possui um par de chaves, gere com ssh-keygen -t ed25519 na sua máquina local. Depois, copie a chave pública com ssh-copy-id ou manualmente. No servidor, crie o diretório ~/.ssh com permissão 700 e o arquivo authorized_keys com permissão 600:

# Execute na sua máquina local para copiar a chave pública para o servidor (substitua o IP)
ssh-copy-id admin@192.168.1.100

# No servidor, se preferir fazer manualmente:
mkdir -p /home/admin/.ssh
chmod 700 /home/admin/.ssh
echo "ssh-ed25519 AAAAC3... sua_chave_pública" > /home/admin/.ssh/authorized_keys
chown -R admin:admin /home/admin/.ssh
chmod 600 /home/admin/.ssh/authorized_keys

Com a chave instalada, teste o acesso SSH como admin antes de desabilitar a autenticação por senha e o login root. Abra um novo terminal e conecte-se usando ssh admin@IP. Se funcionar, prossiga para a configuração segura do SSH. Vamos criar um arquivo de configuração drop-in no diretório /etc/ssh/sshd_config.d/ para não alterar o arquivo principal. O conteúdo completo do arquivo 99-hardening.conf deve ser:

# /etc/ssh/sshd_config.d/99-hardening.conf
# Configuração segura para servidores Linux em produção

# Desabilita login direto do usuário root
PermitRootLogin no

# Exige autenticação por chave pública
PubkeyAuthentication yes

# Desabilita autenticação por senha (use chaves SSH)
PasswordAuthentication no

# Desabilita autenticação por senha vazia e respostas a desafios
PermitEmptyPasswords no
KbdInteractiveAuthentication no

# Limita tentativas de autenticação e sessões não autenticadas
MaxAuthTries 3
MaxSessions 10

# Encerra conexões ociosas após 5 minutos (300 segundos) de inatividade
ClientAliveInterval 300
ClientAliveCountMax 2

# Desabilita encaminhamento X11 e agente SSH para reduzir riscos
X11Forwarding no
AllowAgentForwarding no

# Define um banner de aviso legal (opcional)
Banner /etc/issue.net

Cada diretiva desse arquivo tem um propósito específico. PermitRootLogin no impede que o usuário root faça login via SSH, forçando o uso de um usuário comum com sudo. PasswordAuthentication no exige que toda autenticação seja feita por chave pública, eliminando ataques de força bruta contra senhas. PubkeyAuthentication yes habilita a autenticação por chave. MaxAuthTries 3 limita o número de tentativas antes de encerrar a conexão. ClientAliveInterval e ClientAliveCountMax juntos encerram sessões ociosas após 10 minutos (300s × 2), evitando conexões esquecidas. Por fim, X11Forwarding no e AllowAgentForwarding no reduzem vetores de ataque comuns em ambientes corporativos.

Após criar o arquivo, valide a sintaxe com sshd -t e reinicie o serviço. Em ambos os sistemas, o serviço é chamado ssh no Ubuntu e sshd no Rocky. Use systemctl restart e verifique o status:

# Verifica a sintaxe do arquivo de configuração SSH
sudo sshd -t

# Recarrega a configuração sem derrubar conexões ativas (Debian/Ubuntu)
sudo systemctl reload ssh

# No Rocky/RHEL, o serviço é chamado sshd
sudo systemctl reload sshd

Também é importante ajustar parâmetros de kernel para proteger contra ataques de rede e fortalecer a pilha TCP/IP. Crie o arquivo /etc/sysctl.d/99-hardening.conf com o seguinte conteúdo completo:

# /etc/sysctl.d/99-hardening.conf
# Ajustes de kernel para servidores Linux em produção

# Ignora pacotes ICMP de broadcast (evita amplificação)
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Ativa proteção contra IP spoofing em todas as interfaces
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# Não aceita redirecionamentos ICMP (prevenção de ataques MITM)
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0

# Ignora pacotes ICMP de redirecionamento enviados por roteadores
net.ipv4.conf.all.secure_redirects = 0

# Habilita proteção contra SYN floods
net.ipv4.tcp_syncookies = 1

# Não registra pacotes com endereço de origem inválido
net.ipv4.conf.all.log_martians = 1
net.ipv4.conf.default.log_martians = 1

Para aplicar as configurações imediatamente, execute sudo sysctl –system. Esse comando carrega todos os arquivos /etc/sysctl.d/*.conf e também o /etc/sysctl.conf. A saída mostrará cada parâmetro com o valor aplicado, confirmando que as alterações foram aceitas pelo kernel.

Configurando Firewall e Fail2ban para Linux em produção

Um servidor Linux em produção deve bloquear todo tráfego que não seja explicitamente permitido. A política padrão de um firewall corporativo é negar todo o tráfego de entrada e permitir apenas as portas necessárias para os serviços em execução. No Ubuntu, utilizamos o UFW (Uncomplicated Firewall), uma interface amigável para o iptables. No Rocky Linux, empregamos o firewalld, que gerencia zonas e serviços de forma dinâmica. Ambos têm o mesmo objetivo: minimizar a exposição da máquina à rede.

No Ubuntu/Debian, os comandos a seguir definem a política padrão e liberam apenas SSH (porta 22) e, posteriormente, a porta do Node Exporter (9100). O ufw default deny incoming bloqueia todas as conexões de entrada não autorizadas. O ufw default allow outgoing permite todo o tráfego de saída, o que é seguro e necessário para atualizações e monitoramento. O ufw allow OpenSSH utiliza o perfil de aplicativo pré-definido para a porta 22. O ufw allow 9100/tcp libera a porta do Node Exporter. Por fim, ufw enable ativa o firewall e ufw status verbose mostra as regras aplicadas:

# Define política restritiva de entrada e permissiva de saída
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Libera SSH (perfil OpenSSH) e porta do Node Exporter
sudo ufw allow OpenSSH
sudo ufw allow 9100/tcp

# Ativa o firewall e exibe as regras
sudo ufw enable
sudo ufw status verbose

A saída esperada após a ativação do UFW deve ser semelhante a esta:

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp (OpenSSH)           ALLOW IN    Anywhere
9100/tcp                   ALLOW IN    Anywhere
22/tcp (OpenSSH (v6))      ALLOW IN    Anywhere (v6)
9100/tcp (v6)              ALLOW IN    Anywhere (v6)

No Rocky Linux / RHEL, o firewalld trabalha com zonas. A zona padrão geralmente é a public, que já bloqueia conexões de entrada não solicitadas. Os comandos firewall-cmd –permanent –add-service=ssh e –add-port=9100/tcp adicionam as regras de forma permanente. Como o firewalld não aplica automaticamente as alterações permanentes, é necessário executar firewall-cmd –reload para recarregar as regras:

# Verifica a zona ativa e adiciona as regras permanentes
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --permanent --add-port=9100/tcp

# Recarrega as regras e exibe tudo o que está permitido
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

Com o firewall ativo, precisamos de uma camada adicional contra ataques de força bruta. O Fail2ban monitora os logs de serviços como SSH e, após um número configurável de tentativas falhas, bloqueia temporariamente o endereço IP do atacante no firewall. No Ubuntu, instale com apt install fail2ban; no Rocky, use dnf install fail2ban (já instalado anteriormente). A configuração do Fail2ban é feita em arquivos no diretório /etc/fail2ban/, e o arquivo principal de personalização é o jail.local, que sobrescreve as definições padrão do jail.conf sem ser sobrescrito em atualizações.

Crie o arquivo /etc/fail2ban/jail.local com o conteúdo completo abaixo. Esse arquivo define o backend, o tempo de banimento, o número máximo de tentativas e os filtros para SSH. A diretiva enabled = true ativa a jail. bantime = 3600 bloqueia o IP por 1 hora. findtime = 600 considera uma janela de 10 minutos para contar as tentativas. maxretry = 3 permite no máximo 3 falhas antes do banimento. O ignoreip lista endereços que nunca devem ser bloqueados, como o IP do administrador ou a rede interna:

# /etc/fail2ban/jail.local
# Configuração personalizada para servidores Linux em produção

[DEFAULT]
# Define o backend como systemd para leitura de logs no journal
backend = systemd

# Ignora IPs confiáveis (rede interna e IP do administrador)
ignoreip = 127.0.0.1/8 192.168.1.0/24

# Tempo de banimento em segundos (3600 = 1 hora)
bantime = 3600

# Janela de tempo para contar tentativas (600 = 10 minutos)
findtime = 600

# Número máximo de tentativas antes do banimento
maxretry = 3

# Ação padrão: usar firewallcmd ou ufw conforme a distro
# Deixe comentado para usar auto-detecção; descomente se necessário
# banaction = iptables-multiport

[sshd]
# Ativa a jail para o serviço SSH
enabled = true

# Filtro de log para SSH (já incluso no fail2ban)
filter = sshd

# Porta monitorada
port = ssh

# Logpath padrão para systemd
logpath = %(sshd_log)s

Após criar o arquivo, habilite e inicie o serviço fail2ban em ambos os sistemas. No Ubuntu, o nome do serviço é fail2ban; no Rocky, também é fail2ban. Use systemctl enable –now fail2ban para habilitar e iniciar de uma só vez. Em seguida, verifique se a jail do SSH está ativa com fail2ban-client status sshd:

# Habilita e inicia o fail2ban
sudo systemctl enable --now fail2ban

# Verifica se a jail sshd está ativa e lista IPs banidos
sudo fail2ban-client status sshd

A saída esperada deve mostrar que a jail está ativa e com zero IPs banidos se ainda não houver ataques:

Status for the jail: sshd
|- Filter
|  |- Currently failed: 0
|  |- Total failed: 0
|  `- File list: /var/log/auth.log
`- Actions
   |- Currently banned: 0
   |- Total banned: 0
   `- Banned IP list:

Atualizações automáticas e agendadas no Linux em produção

Manter o sistema atualizado é uma das práticas mais importantes para a segurança de um Linux em produção. Vulnerabilidades são descobertas diariamente, e atrasar a aplicação de patches expõe o servidor a exploits conhecidos. Por isso, configuramos atualizações automáticas de segurança para garantir que correções críticas sejam aplicadas sem intervenção manual. No Ubuntu/Debian, usamos o unattended-upgrades; no Rocky/RHEL, o dnf-automatic. Em ambos os casos, a atualização automática deve ser limitada a pacotes de segurança, para evitar mudanças inesperadas em versões de software que possam quebrar aplicações.

No Ubuntu, após instalar o pacote unattended-upgrades, precisamos habilitar a atualização automática criando o arquivo /etc/apt/apt.conf.d/20auto-upgrades. O conteúdo completo deve conter duas linhas: APT::Periodic::Update-Package-Lists “1”; para atualizar a lista de pacotes diariamente, e APT::Periodic::Unattended-Upgrade “1”; para executar as atualizações automáticas diariamente:

# Cria o arquivo de configuração para atualizações automáticas
sudo tee /etc/apt/apt.conf.d/20auto-upgrades <<'EOF'
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
EOF

O arquivo principal de configuração /etc/apt/apt.conf.d/50unattended-upgrades já vem com valores padrão adequados. Porém, recomendamos verificar se a linha Unattended-Upgrade::Allowed-Origins está restrita a atualizações de segurança. Em servidores corporativos, a política ideal é permitir apenas ${distro_id}:${distro_codename}-security e, opcionalmente, ${distro_id}ESMApps se você utiliza Ubuntu Pro. Para testar o funcionamento, execute sudo unattended-upgrades –dry-run –debug. A saída mostrará quais pacotes seriam atualizados sem aplicar as mudanças.

No Rocky Linux / RHEL, o pacote dnf-automatic fornece um serviço systemd com timers. O arquivo de configuração fica em /etc/dnf/automatic.conf. Edite-o para que as atualizações sejam baixadas e aplicadas automaticamente, mas apenas para pacotes de segurança. O conteúdo completo relevante do arquivo deve ser ajustado para:

# /etc/dnf/automatic.conf
# Configuração para atualizações automáticas em servidores Linux em produção

[commands]
upgrade_type = security
random_sleep = 30

[emitters]
emit_via = stdio

[email]
email_from = root@localhost
email_to = admin@example.com
email_host = localhost

[base]
debuglevel = 1

A diretiva upgrade_type = security restringe as atualizações a pacotes com correções de segurança. random_sleep = 30 adiciona um atraso aleatório de até 30 segundos para evitar que todos os servidores acessem o repositório ao mesmo tempo. Na seção [emitters], emit_via = stdio envia a saída para o log do systemd; em produção, você pode configurar emit_via = email e preencher os campos de e-mail para receber notificações. Após editar o arquivo, habilite e inicie o timer dnf-automatic.timer:

# Habilita e inicia o timer de atualizações automáticas
sudo systemctl enable --now dnf-automatic.timer

# Verifica o status e a próxima execução
sudo systemctl status dnf-automatic.timer
sudo systemctl list-timers dnf-*

Em ambos os sistemas, é essencial verificar periodicamente se as atualizações automáticas estão realmente funcionando. No Ubuntu, utilize systemctl list-timers apt-daily-upgrade.timer para ver a próxima execução. No Rocky, systemctl list-timers dnf-automatic.timer. Também monitore os logs: tail -f /var/log/unattended-upgrades/unattended-upgrades.log no Ubuntu, e journalctl -u dnf-automatic no Rocky.

Monitoramento essencial para Linux em produção

Sem monitoramento, você está operando às cegas. Um servidor Linux em produção precisa expor métricas de CPU, memória, disco, rede e processos para que a equipe de operações possa identificar gargalos, prever capacidade e responder a incidentes antes que os usuários percebam. Vamos instalar duas ferramentas complementares: o sysstat para coleta histórica de métricas do sistema e o Node Exporter do Prometheus para expor métricas em tempo real no formato padrão de monitoramento.

O sysstat fornece os comandos sar, iostat,

Quer aprender na prática com especialistas?