Lista de verificação do reforço do servidor Linux

Uma instalação padrão do Linux não é uma instalação segura do Linux. Configurações incorrectas como acesso SSH de raiz aberta, firewalls fracas e software não corrigido são responsáveis pela maioria das violações. Novos servidores enfrentam varreduras automatizadas poucos minutos depois de ficarem on-line, portanto, o fortalecimento deve acontecer antes de qualquer outra coisa.

Esta lista de verificação abrange os principais passos: bloquear o SSH, configurar firewalls, aplicar patches, reforçar as permissões de ficheiros, ativar controlos de acesso obrigatórios e configurar o registo de auditoria.

Bloquear o SSH

O SSH é o seu principal ponto de acesso e a primeira coisa que os atacantes sondam. A configuração predefinida (autenticação por palavra-passe, início de sessão de raiz, porta 22) é exatamente o que os scanners automatizados procuram.

Gere um par de chaves Ed25519, que oferece melhor segurança e desempenho do que RSA:

ssh-keygen -t ed25519

Assim que o login baseado em chave funcionar, actualize o /etc/ssh/sshd_config:

PasswordAuthentication no
ChallengeResponseAuthentication no
PubkeyAuthentication yes
PermitRootLogin no
AllowUsers yourname
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2

Altere a porta padrão de 22 para algo menos óbvio. Isto não irá impedir um atacante determinado, mas reduz significativamente o ruído das análises automáticas.

Teste sempre as alterações a partir de um segundo terminal antes de fechar a sua sessão atual. Execute sudo sshd -t para verificar se há erros de sintaxe e, em seguida, systemctl reload sshd para aplicar sem deixar cair as conexões ativas.

Adicionar autenticação de dois factores

2FA significa que um atacante precisa tanto da sua chave SSH quanto do acesso físico ao seu dispositivo. Instale o módulo PAM do Google Authenticator:

sudo apt install libpam-google-authenticator   # Debian/Ubuntu
sudo dnf install google-authenticator           # RHEL/Fedora

Execute o google-authenticator para cada utilizador para gerar uma chave secreta e códigos de recuperação. Armazene os códigos de recuperação offline.

Adicione esta linha a /etc/pam.d/sshd:

auth required pam_google_authenticator.so

Em seguida, actualize /etc/ssh/sshd_config:

KbdInteractiveAuthentication yes
UsePAM yes
AuthenticationMethods publickey,keyboard-interactive

Mantenha uma sessão ativa aberta enquanto testa. Os códigos TOTP dependem da hora exacta do sistema, por isso certifique-se que o NTP está a funcionar.

Configurar Firewalls e Fail2Ban

Execute uma firewall baseada no anfitrião, mesmo que o seu servidor se encontre atrás de uma firewall de rede. O princípio é simples: negar todo o tráfego de entrada por padrão e permitir apenas o que for necessário.

Para Ubuntu/Debian (UFW):

ufw default deny incoming
ufw default allow outgoing
ufw limit ssh
ufw enable

Para RHEL/Rocky/AlmaLinux (Firewalld):

firewall-cmd --set-default-zone=public
firewall-cmd --permanent --add-service=ssh
firewall-cmd --permanent --add-service=https
firewall-cmd --reload

Fortaleça a pilha de rede do kernel adicionando isto ao /etc/sysctl.conf:

net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.icmp_echo_ignore_broadcasts = 1

Instalar Fail2Ban

O Fail2Ban monitora tentativas de login e bane IPs após falhas repetidas. Crie o arquivo /etc/fail2ban/jail.local (não edite o jail.conf diretamente, as atualizações irão sobrescrevê-lo) e configure-o para banir IPs por uma hora após três tentativas fracassadas em 10 minutos. Defina o backend correto para seu firewall(banaction = ufw ou banaction = nftables).

Auditar serviços e remover protocolos legados

Verifique o que está a ouvir com ss -tlnp e o que está a correr com systemctl list-units --type=service --state=running. Desactive tudo o que não precisa: Bluetooth, CUPS, avahi-daemon, rpcbind.

Remova protocolos legados que transmitem dados em texto claro:

Em Debian/Ubuntu: sudo apt-get --purge remove xinetd nis tftpd telnetd rsh-server. Em sistemas baseados em RHEL: yum erase xinetd ypserv tftp-server telnet-server rsh-server. Verifique a remoção com ss -tulpn.

Actualizações de patches e automatizadas

Atualizar o seu sistema é a forma mais rápida de colmatar as lacunas de segurança conhecidas. Execute as actualizações imediatamente após o aprovisionamento:

apt update && apt upgrade -y      # Debian/Ubuntu
dnf update -y                      # RHEL/Rocky

Em seguida, automatize os patches de segurança. No Debian/Ubuntu, instale unattended-upgrades e configure-o para aplicar apenas patches de segurança. No RHEL/Rocky, instale o dnf-automatic e defina upgrade_type = security em /etc/dnf/automatic.conf.

Configure notificações de e-mail para resultados de atualização. Desativar os reinícios automáticos nos servidores de produção(Automatic-Reboot = false) para que os reinícios ocorram durante as janelas de manutenção planeadas. Para ambientes de alto tempo de atividade, considere a aplicação de patches ao vivo com o Canonical Livepatch (Ubuntu) ou kpatch (RHEL).

Proteger os sistemas de ficheiros e as permissões

Audite primeiro os binários SUID e SGID. Estes ficheiros são executados com privilégios elevados e são os principais alvos de exploração:

find / -xdev \( -perm -4000 -o -perm -2000 \) -type f -ls

Reforçar as permissões em ficheiros críticos: /etc/shadow deve ser 600, /etc/passwd deve ser 644, /etc/ssh/sshd_config deve ser 600. Defina uma umask global de 027 em /etc/profile para evitar que novos ficheiros sejam legíveis pelo mundo.

Encontre e corrija os ficheiros que podem ser escritos pelo mundo com find / -xdev -type f -perm -0002 -ls. Para diretórios que têm de permanecer legíveis (como /tmp), aplique o sticky bit: chmod 1777 /tmp.

Opções de Montagem Segura

Edite o /etc/fstab para restringir o que pode acontecer em partições críticas:

Teste as alterações com mount -o remount antes de reiniciar para evitar problemas de arranque.

Ativar os controlos de acesso obrigatórios

SELinux e AppArmor adicionam restrições ao nível do kernel sobre o que os processos podem fazer. Utilize o que quer que a sua distribuição inclua: SELinux para RHEL/CentOS/Fedora, AppArmor para Ubuntu/Debian/SUSE. Alternar entre eles causa problemas de compatibilidade.

SELinux: Verificar o estado com getenforce. Inicie em modo permissivo(setenforce 0) por pelo menos duas semanas para capturar o comportamento da carga de trabalho sem quebrar nada. Monitorar violações com ausearch -m avc -ts recent. Use audit2why para diagnosticar bloqueios e audit2allow -M [nome_do_módulo] para criar módulos de política. Uma vez que os logs estejam limpos, mude para enforcing com setenforce 1, então torne-o permanente em /etc/selinux/config.

AppArmor: Verificar perfis activos com aa-status. Instalar apparmor-utils para comandos de gestão. Inicie os perfis em modo complain com aa-complain, depois passe para o modo enforce com aa-enforce quando estiver confiante. Utilize aa-genprof para construir perfis para aplicações personalizadas.

Configurar o registo de auditoria e a monitorização

Sem registo, os incidentes não deixam rasto. Instale o auditd:

sudo apt-get install auditd audispd-plugins

Adicione vigilâncias do sistema de ficheiros para ficheiros críticos:

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

Rastreie toda a execução de comandos no nível de raiz:

-a always,exit -F arch=b64 -S execve -F euid=0 -k root_commands

Carregar regras com augenrules --load e adicionar -e 2 no final do seu ficheiro de regras para tornar a configuração à prova de adulteração (as alterações requerem um reinício).

Monitorização da integridade dos ficheiros com AIDE

AIDE detecta alterações não autorizadas em ficheiros comparando o estado atual com uma linha de base conhecida como boa. Instale-o, inicialize a base de dados com aideinit, e mova o ficheiro resultante para /var/lib/aide/aide.db.gz. Configure um cron job diário para executar aide --check e enviar os resultados por email para os administradores.

Centralizar os registos

Os registos locais são inúteis se um atacante com acesso root os apagar. Encaminhe os logs para um servidor remoto em tempo real usando rsyslog com encriptação TLS. Adicione a /etc/rsyslog.conf:

*.* @@remote-host:514

Defina LogLevel VERBOSE na sua configuração SSH para que os registos incluam impressões digitais de chaves para cada início de sessão bem sucedido. Para ambientes de produção que gerenciam vários servidores, ferramentas como Wazuh ou OSSEC fornecem deteção de intrusão baseada em host com análise centralizada de logs.

Manutenção contínua

A proteção não é uma tarefa única. As configurações variam, surgem novas vulnerabilidades e as mudanças de pessoal deixam contas órfãs.

Semanalmente: Rever os registos Fail2Ban, verificar se existem actualizações falhadas, verificar as cópias de segurança.

Mensalmente: Auditar as contas e permissões dos utilizadores, rever os serviços em execução, executar uma análise completa com o Lynis ou o OpenSCAP.

Trimestralmente: Rodar credenciais, atualizar regras de firewall, testar a recuperação de desastres.

Use ferramentas de infraestrutura como código, como o Ansible, com funções de endurecimento do dev-sec.io para impor configurações consistentes em toda a sua frota e evitar desvios entre as auditorias.

Os servidores dedicados da FDC dão-lhe acesso total à raiz e controlo total sobre a sua pilha de segurança. Explore as opções de servidor dedicado para construir em uma plataforma onde você controla todas as camadas.