Aula 34: Segurança Linux em produção — checklist definitivo e melhores práticas

Produção é o ambiente onde erros custam caro, tempo de inatividade gera prejuízo e uma brecha pode expor dados sensíveis. Chegamos à aula final do curso Segurança Linux — Do Zero ao Avançado, e o foco agora é consolidar todo o conhecimento em um checklist prático de Segurança Linux em produção. Ao longo das aulas anteriores, você aprendeu a proteger o sistema de arquivos, configurar firewalls, gerenciar usuários, auditar eventos, implementar criptografia e responder a incidentes. Nesta aula, vamos transformar esse conhecimento em um processo operacional ordenado, aplicável a servidores que estão de fato atendendo requisições, armazenando dados e sustentando negócios.

Esta aula é essencial porque produção não perdoa improvisos. Um servidor em produção exige uma postura metódica: cada alteração deve ser planejada, testada e verificada. O checklist que vamos executar aqui cobre desde a atualização do sistema e o endurecimento do kernel até a implementação de auditoria contínua e a validação final com ferramentas especializadas. Você aprenderá a aplicar as melhores práticas usadas em ambientes corporativos, incluindo aquelas que adotamos diariamente em nossos projetos na JRT Technology Solutions, onde a segurança de servidores Linux é tratada como prioridade absoluta.

O objetivo é que, ao final desta aula, você seja capaz de pegar um servidor recém-instalado — Ubuntu Server 22.04 LTS ou Rocky Linux 9 — e transformá-lo em uma máquina pronta para enfrentar as ameaças de um ambiente real de produção. Vamos executar comandos, configurar arquivos, verificar resultados e entender o porquê de cada etapa. Não se trata apenas de copiar e colar; trata-se de internalizar um fluxo de trabalho que você poderá adaptar a qualquer distribuição Linux e a qualquer cenário.

Para acompanhar esta aula, você precisará de acesso root ou sudo a duas máquinas virtuais: uma com Ubuntu Server 22.04 LTS e outra com Rocky Linux 9. Também será útil ter um segundo terminal para testar acessos e simular tentativas de invasão. Todos os comandos apresentados funcionam nas duas distribuições, com as devidas diferenças de gerenciador de pacotes e ferramentas nativas. Ao final, você terá um servidor endurecido, auditável e pronto para produção, além de um checklist reutilizável para aplicar em qualquer novo deploy.

O que você vai aprender nesta aula

• Compreender os fundamentos de Segurança Linux em produção e a importância da defesa em profundidade.
• Executar um checklist ordenado de hardening em servidores Ubuntu/Debian e Rocky/RHEL.
• Configurar o kernel Linux com parâmetros de segurança via sysctl.
• Proteger o acesso remoto com SSH endurecido e políticas de firewall avançadas.
• Implementar auditoria de arquivos sensíveis com auditd e monitoramento de integridade com AIDE.
• Automatizar atualizações de segurança e configurar logs centralizados.
• Validar a configuração com ferramentas como Lynis e OpenSCAP.
• Diagnosticar e corrigir erros comuns em servidores Linux endurecidos.
• Consolidar todo o aprendizado do curso em um fluxo de trabalho profissional.

Pré-requisitos e Ambiente

Antes de iniciar, verifique se você possui os seguintes recursos e conhecimentos. Em primeiro lugar, você precisa de duas máquinas virtuais ou contêineres com sistema operacional Linux. Recomendamos Ubuntu Server 22.04 LTS e Rocky Linux 9, pois são representantes das duas principais famílias de distribuições: Debian e Red Hat. Ambas devem estar com acesso à internet para instalar pacotes e com pelo menos 2 GB de RAM e 20 GB de disco, o que é confortável para os testes desta aula.

Você também precisa de privilégios administrativos. Todos os comandos desta aula assumem que você está logado como um usuário comum com permissão de sudo. Isso é uma boa prática, pois evita o uso direto da conta root. Se você estiver usando uma instância cloud, pode ser necessário ajustar as regras de segurança do grupo de rede para permitir conexões SSH. Tenha em mãos também um editor de texto como nano ou vim, que já vêm instalados por padrão na maioria das distribuições.

É recomendável que você tenha concluído as aulas anteriores do curso, especialmente aquelas sobre firewalls, SSH, auditoria e gerenciamento de usuários. Se você não teve contato com fail2ban, auditd ou SELinux/AppArmor, não se preocupe: nesta aula vamos revisar os conceitos essenciais e aplicar tudo de forma integrada. O foco não é repetir a teoria, mas sim mostrar como essas ferramentas se encaixam em um fluxo de segurança de produção.

Por fim, prepare-se para trabalhar de forma incremental. A segurança em produção é um ciclo: você endurece, monitora, valida e corrige. Este ciclo é exatamente o que vamos percorrer. Ao final, você terá um roteiro completo que poderá ser adaptado para outros serviços, como servidores web, bancos de dados ou clusters Kubernetes. Em nossos atendimentos na JRT Technology Solutions, utilizamos esse mesmo tipo de checklist como base para implantações seguras em clientes de diversos portes.

Fundamentos de Segurança Linux em Produção

A Segurança Linux em produção não é um produto, mas um processo contínuo baseado em camadas de proteção. O princípio da defesa em profundidade determina que nenhum controle isolado é suficiente; você precisa de múltiplas barreiras que se complementem. Se uma falha for explorada, as camadas seguintes devem conter o impacto. Em um servidor Linux, essas camadas incluem o kernel, os serviços de rede, o sistema de arquivos, os mecanismos de autenticação e os logs de auditoria.

Outro pilar é a redução de superfície de ataque. Isso significa desativar serviços desnecessários, remover pacotes que não são usados, limitar portas abertas e restringir privilégios. Quanto menos componentes ativos, menor a chance de uma vulnerabilidade ser explorada. Essa prática é especialmente crítica em produção, onde cada serviço extra representa um ponto potencial de entrada. Aplicamos essa mentalidade em todos os projetos da JRT, removendo inclusive ferramentas de diagnóstico que não são estritamente necessárias no ambiente final.

O princípio do menor privilégio também é fundamental. Usuários e processos devem ter apenas as permissões necessárias para executar suas funções. Isso se aplica a contas de sistema, contas de serviço e até mesmo a processos do kernel. Ferramentas como SELinux no Rocky Linux e AppArmor no Ubuntu implementam controle de acesso obrigatório, limitando o que cada processo pode fazer mesmo se for comprometido. Integrar essas tecnologias ao seu checklist é um diferencial importante para quem busca um nível avançado de segurança.

Além disso, a auditoria é a capacidade de saber o que aconteceu, quando, e quem fez. Sem logs confiáveis e monitoramento, você pode demorar dias ou semanas para detectar uma invasão. A auditd no Linux permite registrar acessos a arquivos sensíveis, chamadas de sistema e mudanças de configuração. Já ferramentas como AIDE garantem a integridade dos arquivos, alertando sobre modificações não autorizadas. Em produção, auditoria e monitoramento são tão importantes quanto prevenção, porque nem todo ataque pode ser bloqueado na primeira linha.

Por fim, a automação é o que sustenta a consistência. Scripts, ferramentas de gerenciamento de configuração e políticas declarativas reduzem a chance de erro humano e permitem reproduzir o mesmo nível de segurança em dezenas de servidores. No contexto desta aula, vamos executar os passos manualmente para fins didáticos, mas ao final discutiremos como levá-los para um pipeline automatizado com Ansible, por exemplo. Esse é o caminho que seguimos para manter dezenas de servidores seguros e padronizados em nossos projetos na JRT Technology Solutions.

Checklist Definitivo — Estrutura e Ordem de Execução

Antes de colocar a mão na massa, é importante entender a ordem lógica do checklist de Segurança Linux em produção. A sequência importa porque algumas etapas dependem das anteriores. Por exemplo, você não deve configurar o firewall antes de garantir que o SSH permita seu acesso, senão pode se trancar fora do servidor. Também não faz sentido instalar ferramentas de auditoria antes de atualizar o sistema, pois você pode estar auditando binários desatualizados e vulneráveis.

O checklist que vamos seguir está organizado em cinco fases: preparação, endurecimento do sistema, controle de acesso e rede, auditoria e monitoramento, e validação final. Cada fase contém tarefas específicas que serão detalhadas nas próximas seções. A ideia é que você possa imprimir esta estrutura ou transformá-la em um ticket de trabalho para aplicar em qualquer servidor. Em nossa experiência, ter um processo claro e repetível reduz drasticamente as chances de esquecer um passo crítico.

Veja a tabela abaixo com o resumo das fases, objetivos e principais ferramentas. Esta tabela serve como um mapa de navegação para a aula e como referência rápida no seu dia a dia profissional.

Cada fase deve ser executada na ordem apresentada. Não pule etapas, mesmo que esteja com pressa. A segurança em produção é construída em camadas; se a base estiver fraca, as camadas superiores não terão efeito. No decorrer da aula, vamos executar os comandos exatos para cada fase, com as devidas explicações e verificações.

Passo a Passo — Hardening Inicial de um Servidor em Produção

Vamos iniciar a execução do checklist pela Fase 1: Preparação. O objetivo aqui é garantir que o sistema esteja atualizado, criar uma conta de administração segura e configurar o acesso SSH de forma restritiva. Esses três passos são a base de qualquer implantação em produção. Em nossos projetos, sempre começamos por aqui, pois sem controle de acesso adequado, qualquer outra medida pode ser contornada.

1. Atualize o sistema operacional. No Ubuntu, use apt update para atualizar a lista de pacotes e apt upgrade -y para instalar as atualizações. No Rocky, use dnf update -y. Isso garante que você comece com um sistema livre de vulnerabilidades conhecidas. Após a atualização, reinicie se o kernel tiver sido atualizado.
2. Crie um usuário administrativo. Não utilize a conta root diretamente. Crie um usuário chamado deploy com comando useradd -m -s /bin/bash deploy. Em seguida, defina uma senha forte com passwd deploy. Adicione o usuário ao grupo sudo no Ubuntu com usermod -aG sudo deploy, ou ao grupo wheel no Rocky com usermod -aG wheel deploy.
3. Configure o SSH. Edite o arquivo /etc/ssh/sshd_config para desabilitar login root, desabilitar autenticação por senha e restringir quais usuários podem acessar. Essas mudanças exigem que você tenha uma chave SSH configurada para o usuário deploy, o que faremos a seguir.
4. Adicione sua chave pública. Crie o diretório ~/.ssh para o usuário deploy e adicione a chave pública em authorized_keys com as permissões corretas.
5. Reinicie o serviço SSH e teste a conexão em um segundo terminal antes de encerrar a sessão atual.

Vamos executar esses passos no Ubuntu Server 22.04. Os comandos a seguir devem ser executados como um usuário com privilégios de sudo. Observe os comentários em linha para entender cada ação.

# Atualizar a lista de pacotes e instalar atualizações disponíveis
sudo apt update
sudo apt upgrade -y

# Criar o usuário administrativo 'deploy'
sudo useradd -m -s /bin/bash deploy
sudo passwd deploy
sudo usermod -aG sudo deploy

# Criar o diretório .ssh e ajustar as permissões
sudo mkdir -p /home/deploy/.ssh
sudo chmod 700 /home/deploy/.ssh
sudo touch /home/deploy/.ssh/authorized_keys
sudo chmod 600 /home/deploy/.ssh/authorized_keys
sudo chown -R deploy:deploy /home/deploy/.ssh

# Adicionar sua chave pública (substitua pelo conteúdo real da sua chave)
echo "ssh-rsa AAAAB3NzaC1yc2E... seu_comentario" | sudo tee -a /home/deploy/.ssh/authorized_keys

# Fazer backup do arquivo de configuração do SSH antes de editar
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

# Editar o arquivo com nano ou vim (mostraremos o conteúdo completo a seguir)
sudo nano /etc/ssh/sshd_config

# Após editar, validar a sintaxe e reiniciar o serviço SSH
sudo sshd -t
sudo systemctl restart sshd

Agora vamos ver o conteúdo do arquivo /etc/ssh/sshd_config já endurecido. Para fins didáticos, apresentamos uma versão limpa contendo apenas as diretivas relevantes. Em uma instalação real, você pode manter os comentários originais, mas o importante é que estas linhas estejam presentes e com os valores corretos.

# /etc/ssh/sshd_config — Configuração endurecida para produção
# Apenas protocolo SSH versão 2
Protocol 2

# Desabilitar login direto como root
PermitRootLogin no

# Desabilitar autenticação por senha (obriga uso de chave pública)
PasswordAuthentication no
KbdInteractiveAuthentication no

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

# Limitar tentativas de autenticação e definir tempo de sessão
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2

# Restringir acesso a usuários específicos
AllowUsers deploy

# Desabilitar encaminhamento de ambiente e X11
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no

# Registrar logs detalhados
LogLevel VERBOSE

# Usar chaves de host fortes
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key

Cada diretiva tem um papel importante. PermitRootLogin no impede que a conta root faça login remoto, forçando o uso do usuário deploy e depois sudo para tarefas administrativas. PasswordAuthentication no elimina ataques de força bruta baseados em senha. MaxAuthTries 3 reduz a janela para tentativas repetidas. AllowUsers deploy garante que apenas esse usuário possa acessar via SSH, mesmo que outras contas possuam chaves válidas. Essas configurações são essenciais em qualquer servidor de produção.

No Rocky Linux 9, o processo é análogo, mas o gerenciador de pacotes é o dnf e o grupo administrativo é o wheel. Os comandos a seguir mostram o fluxo completo.

# Atualizar o sistema
sudo dnf update -y

# Criar usuário administrativo e adicionar ao grupo wheel
sudo useradd -m -s /bin/bash deploy
sudo passwd deploy
sudo usermod -aG wheel deploy

# Configurar chave SSH para o usuário deploy
sudo mkdir -p /home/deploy/.ssh
sudo chmod 700 /home/deploy/.ssh
sudo touch /home/deploy/.ssh/authorized_keys
sudo chmod 600 /home/deploy/.ssh/authorized_keys
sudo chown -R deploy:deploy /home/deploy/.ssh

# Adicionar chave pública
echo "ssh-rsa AAAAB3NzaC1yc2E... seu_comentario" | sudo tee -a /home/deploy/.ssh/authorized_keys

# Backup e edição do sshd_config (mesmas diretivas do Ubuntu)
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sudo nano /etc/ssh/sshd_config

# Validar e reiniciar
sudo sshd -t
sudo systemctl restart sshd

A saída esperada após a atualização no Ubuntu será semelhante a esta. Ela mostra o progresso da instalação dos pacotes e, ao final, a indicação de que não há mais nada a atualizar.

Hit:1 http://archive.ubuntu.com/ubuntu jammy InRelease
Get:2 http://archive.ubuntu.com/ubuntu jammy-updates InRelease [128 kB]
...
Fetched 45.2 MB in 8s (5.65 MB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.

Após reiniciar o SSH, teste a conexão em um segundo terminal usando o usuário deploy e sua chave privada. O comando ssh deploy@IP_DO_SERVIDOR deve funcionar sem solicitar senha. Se funcionar, você pode encerrar a sessão do usuário anterior e continuar a configuração usando apenas o usuário deploy. Esse passo é crítico: nunca feche a sessão atual antes de confirmar que a nova configuração de SSH está funcionando, pois um erro pode deixá-lo sem acesso ao servidor.

Configuração Detalhada — Parâmetros de Kernel e Segurança do Sistema

Na Fase 2, vamos endurecer o kernel e o sistema de arquivos. O kernel Linux oferece uma série de parâmetros ajustáveis via sysctl que melhoram a segurança, como a proteção contra redirecionamento de ICMP, a restrição de core dumps e a habilitação de ASLR forte. Essas configurações são aplicadas em tempo de execução, mas precisam ser persistidas em arquivos no diretório /etc/sysctl.d/ para sobreviverem a reinicializações.

O arquivo que vamos criar, /etc/sysctl.d/99-security.conf, contém um conjunto abrangente de parâmetros recomendados para servidores de produção. Ele é compatível tanto com Ubuntu quanto com Rocky Linux, pois os parâmetros são do kernel Linux e não dependem da distribuição. A seguir, apresentamos o conteúdo completo do arquivo, com comentários explicando cada parâmetro.

# /etc/sysctl.d/99-security.conf
# Parâmetros de kernel endurecidos para Segurança Linux em produção

# Proteger contra ataques de spoofing de IP e redirecionamento
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0

# Ignorar requisições ICMP de broadcast e limitar respostas
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1

# Habilitar proteção contra SYN flood
net.ipv4.tcp_syncookies = 1

# Restringir a criação de core dumps por processos (proteção contra vazamento de memória)
fs.suid_dumpable = 0
kernel.core_uses_pid = 1

# Habilitar ASLR (Address Space Layout Randomization) no nível máximo
kernel.randomize_va_space = 2

# Impedir que processos sem privilégios acessem dmesg
kernel.dmesg_restrict = 1

# Restringir acesso a kernel pointers em logs e arquivos
kernel.kptr_restrict = 2

# Desabilitar a montagem de sistemas de arquivos incomuns em contêineres
kernel.unprivileged_userns_clone = 0

# Restringir IPC entre processos não relacionados
kernel.shmall = 2097152
kernel.shmmax = 2147483648

# Aumentar a proteção contra caminhos de arquivos em /proc
fs.protected_hardlinks = 1
fs.protected_symlinks = 1

Cada linha tem uma função específica. Por exemplo, rp_filter = 1 ativa a filtragem de pacotes com endereço de origem inválido, prevenindo ataques de IP spoofing. accept_redirects = 0 desabilita o processamento de mensagens ICMP redirect, que podem ser usadas para redirecionar tráfego malicioso. tcp_syncookies = 1 ajuda a mitigar ataques de negação de serviço por SYN flood. randomize_va_space = 2 ativa a aleatorização de endereços de memória, dificultando a exploração de vulnerabilidades de buffer overflow.

Após criar o arquivo, aplique as configurações com o comando sysctl –system. Esse comando lê todos os arquivos em /etc/sysctl.d/ e aplica os parâmetros imediatamente. A saída esperada lista cada parâmetro e seu valor final, confirmando que foram aplicados corretamente. É importante revisar a saída para garantir que não houve erros de sintaxe ou conflitos com outras configurações.

# Aplicar as novas configurações de kernel
sudo sysctl --system

A saída no terminal será extensa, mas deve incluir linhas como as mostradas abaixo, indicando que os parâmetros foram definidos com sucesso. Se algum parâmetro não aparecer ou exibir um valor diferente, revise o arquivo de configuração.

* Applying /etc/sysctl.d/99-security.conf ...
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1
net.ipv4.tcp_syncookies = 1
fs.suid_dumpable = 0
kernel.core_uses_pid = 1
kernel.randomize_va_space = 2
kernel.dmesg_restrict = 1
kernel.kptr_restrict = 2
kernel.unprivileged_userns_clone = 0
kernel.shmall = 2097152
kernel.shmmax = 2147483648
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
* Applying /etc/sysctl.conf ...

Além dos parâmetros de kernel, você deve ajustar as permissões de arquivos sensíveis. O arquivo /etc/shadow deve ter permissão 000 ou 600 e pertencer ao usuário root. O /etc/passwd pode ser lido por todos, mas o /etc/shadow não. Execute chmod 600 /etc/shadow e chown root:root /etc/shadow para garantir. No Ubuntu, o /etc/gshadow também deve ser protegido da mesma forma. Essas medidas impedem que usuários sem privilégios leiam os hashes de senha e tentem quebrá-los offline.

# Proteger arquivos de senha contra leitura não autorizada
sudo chmod 600 /etc/shadow
sudo chown root:root /etc/shadow
sudo chmod 600 /etc/gshadow
sudo chown root:root /etc/gshadow

# Remover permissão de escrita para outros em diretórios críticos
sudo chmod 750 /etc/ssh
sudo chmod 640 /etc/ssh/sshd_config

Essas alterações são simples, mas muitos administradores as negligenciam. Um arquivo /etc/shadow legível por qualquer usuário local é um convite para ataques de quebra de hash. Em servidores de produção, cada permissão excessiva é uma falha em potencial. Em nossos projetos na JRT Technology Solutions, sempre incluímos essa verificação no checklist, pois já encontramos servidores com /etc/shadow acessível a todos.

Configuração de Firewall e Controle de Acesso — Políticas Detalhadas

A Fase 3 do checklist é dedicada ao controle de acesso e rede. O firewall é a primeira linha de defesa contra tráfego não autorizado. No Ubuntu, utilizamos o UFW (Uncomplicated Firewall), que é uma interface amigável para o iptables. No Rocky Linux, utilizamos o firewalld, que gerencia zonas e serviços de forma dinâmica. Ambos devem ser configurados com a política padrão de negação para entrada e permissão para saída.

A regra de ouro é: negue tudo por padrão e libere apenas o que for estritamente necessário. Para um servidor de produção, normalmente isso significa liberar apenas a porta SSH (22), e talvez HTTP/HTTPS se houver um serviço web. Qualquer outra porta deve ser bloqueada. Além disso, podemos aplicar limitação de taxa na porta SSH para reduzir ataques de força bruta. Vejamos os comandos para o Ubuntu com UFW.

# Instalar o UFW (normalmente já vem instalado no Ubuntu Server)
sudo apt install ufw -y

# Definir política padrão: negar entrada e permitir saída
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Liberar SSH com limitação de taxa (máximo 6 conexões por 30 segundos)
sudo ufw limit ssh

# Liberar HTTP e HTTPS se necessário (exemplo)
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Habilitar o firewall (responda 'y' se solicitado)
sudo ufw enable

# Verificar o status detalhado
sudo ufw status verbose

A saída do ufw status verbose deve mostrar as políticas padrão e as regras ativas, como no exemplo abaixo. Observe que a porta 22 aparece com a ação de limite, indicando que a proteção contra força bruta está ativa.

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

To                         Action      From
--                         ------      ----
22/tcp                     LIMIT IN    Anywhere
80/tcp                     ALLOW IN    Anywhere
443/tcp                    ALLOW IN    Anywhere
22/tcp (v6)                LIMIT IN    Anywhere (v6)
80/tcp (v6)                ALLOW IN    Anywhere (v6)
443/tcp (v6)               ALLOW IN    Anywhere (v6)

No Rocky Linux 9, o firewall padrão é o firewalld. Ele trabalha com zonas, sendo a zona drop a mais restritiva, pois descarta todo tráfego sem enviar resposta. A zona public nega entrada e permite saída, mas envia mensagens de rejeição. Para produção, recomendamos a zona drop para a interface externa, liberando apenas os serviços necessários. Vejamos os comandos.

# Instalar o firewalld (geralmente já vem instalado)
sudo dnf install firewalld -y

# Iniciar e habilitar o serviço
sudo systemctl enable --now firewalld

# Definir a zona padrão como drop (política mais restritiva)
sudo firewall-cmd --set-default-zone=drop

# Adicionar o serviço SSH à zona drop (porta 22/tcp)
sudo firewall-cmd --permanent --add-service=ssh

# Adicionar HTTP e HTTPS se necessário
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https

# Aplicar taxa limite ao SSH usando rich rule (6 conexões por 30 segundos)
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" service name="ssh" accept limit value="6/m"'

# Recarregar as regras
sudo firewall-cmd --reload

# Listar todas as configurações ativas
sudo firewall-cmd --list-all

A saída de firewall-cmd –list-all para a zona drop deve indicar os serviços permitidos e a rich rule de limitação. Isso confirma que apenas SSH, HTTP e HTTPS estão liberados, e que o SSH tem proteção contra força bruta.

drop (active)
  target: DROP
  icmp-block-inversion: no
  interfaces: eth0
  sources:
  services: ssh http https
  ports:
  protocols:
  forward: no
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:
	rule family="ipv4" service name="ssh" accept limit value="6/m"

Além do firewall, o fail2ban adiciona uma camada extra de proteção monitorando logs e banindo IPs que apresentam comportamento suspeito. Ele é especialmente útil para proteger o SSH contra ataques de força bruta que podem passar despercebidos pelo limite de taxa do firewall. A instalação e configuração básica são simples e devem fazer parte de qualquer servidor de produção.

# Instalar o fail2ban no Ubuntu
sudo apt install fail2ban -y

# Instalar o fail2ban no Rocky
sudo dnf install fail2ban -y

# Criar arquivo de configuração local (não edite o arquivo principal)
sudo tee /etc/fail2ban/jail.local << 'EOF'
[DEFAULT]
bantime = 3600
findtime = 600
maxretry = 5
destemail = admin@exemplo.com
action = %(action_mw)s

[sshd]
enabled = true
port = 22
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 7200
EOF

# Iniciar e habilitar o fail2ban
sudo systemctl enable --now fail2ban

# Verificar o status do jail SSH
sudo fail2ban-client status sshd

O arquivo /etc/fail2ban/jail.local define que após 3 tentativas falhas em 10 minutos, o IP será banido por 2 horas. Essa configuração é eficaz contra ataques automatizados, reduzindo drasticamente o ruído nos logs e a carga no servidor. A saída do fail2ban-client status sshd mostrará se o jail está ativo e quantos IPs estão banidos atualmente.

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:

Implementando Auditoria e Monitoramento em Segurança Linux em Produção

Chegamos à Fase 4, que trata de auditoria e monitoramento. Em um ambiente de produção, é essencial registrar eventos de segurança para detectar acessos indevidos, alterações em arquivos críticos e comportamentos anômalos. Duas ferramentas são indispensáveis: auditd para auditoria do sistema e AIDE para monitoramento de integridade de arquivos. Além disso, o gerenciamento de logs com rsyslog e logrotate garante que as evidências sejam preservadas de forma organizada.

O auditd é o daemon de auditoria do kernel Linux. Ele permite definir regras para monitorar acessos a arquivos específicos, chamadas de sistema e mudanças de identidade. Por exemplo, podemos registrar toda tentativa de leitura do arquivo /etc/shadow, toda execução do comando sudo e toda modificação em arquivos de configuração do SSH. Essas informações são armazenadas em /var/log/audit/audit.log e podem ser consultadas com ferramentas como ausearch e aureport.

Vamos instalar e configurar o auditd em ambas as distribuições. A instalação é simples: no Ubuntu, apt install auditd; no Rocky, dnf install audit. Após a instalação, criaremos um arquivo de regras em /etc/audit/rules.d/audit.rules com as regras essenciais para produção. O conteúdo completo do arquivo é mostrado abaixo.

# /etc/audit/rules.d/audit.rules

# Regras de auditoria para Segurança Linux em produção

# Remover regras existentes ao carregar

-D
# Aumentar o buffer do kernel para evitar perda de eventos

-b 8192
# Monitorar mudanças em arquivos de senha e grupos

-w /etc/passwd -p wa -k identity

-w /etc/shadow -p wa -k identity

-w /etc/group -p wa -k identity

-w /etc/gshadow -p wa -k identity

Quer aprender na prática com especialistas?
A JRT Technology Solutions oferece treinamentos e implementação de Segurança Linux para equipes corporativas.
  

    

    Falar no WhatsApp