Lista de verificação para reforço de segurança de servidores Linux

Uma instalação padrão do Linux não é uma instalação segura do Linux. Configurações incorretas, como acesso SSH root aberto, firewalls fracos e software sem patches, são responsáveis pela maioria das violações. Os novos servidores enfrentam análises automatizadas poucos minutos após ficarem online, pelo que o reforço de segurança deve ser feito antes de mais nada.

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

Bloqueie o SSH

O SSH é o seu principal ponto de acesso e a primeira coisa que os atacantes testam. A configuração padrão (autenticação por palavra-passe, login de root, porta 22) é exatamente o que os scanners automatizados procuram.

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

ssh-keygen -t ed25519

Assim que o login baseado em chave funcionar, atualize /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 impedirá um atacante determinado, mas reduz significativamente o ruído das varreduras automatizadas.

Teste sempre as alterações a partir de um segundo terminal antes de encerrar 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 interromper as ligações ativas.

Adicione a autenticação de dois fatores

A autenticação de dois fatores (2FA) significa que um invasor precisa tanto da sua chave SSH quanto de 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 google-authenticator para cada utilizador para gerar uma chave secreta e códigos de recuperação. Guarde os códigos de recuperação offline.

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

auth required pam_google_authenticator.so

Em seguida, atualize /etc/ssh/sshd_config:

KbdInteractiveAuthentication yes
UsePAM yes
AuthenticationMethods publickey,keyboard-interactive

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

Configurar firewalls e o Fail2Ban

Execute uma firewall baseada no host, mesmo que o seu servidor esteja atrás de uma firewall de rede. O princípio é simples: recuse todo o tráfego de entrada por predefinição e, em seguida, permita 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

Reforce a pilha de rede do kernel adicionando estes a /etc/sysctl.conf:

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

Instalar o Fail2Ban

O Fail2Ban monitoriza as tentativas de login e bloqueia IPs após falhas repetidas. Crie /etc/fail2ban/jail.local (não edite jail.conf diretamente, as atualizações irão sobrescrevê-lo) e configure-o para bloquear IPs durante uma hora após três tentativas falhadas num intervalo de 10 minutos. Defina o backend correto para a sua firewall (banaction = ufw ou banaction = nftables).

Serviços de Auditoria e Remover Protocolos Legados

Verifique o que está a escutar com ss -tlnp e o que está a ser executado com systemctl list-units --type=service --state=running. Desative tudo o que não precisar: Bluetooth, CUPS, avahi-daemon, rpcbind.

Remova protocolos legados que transmitem dados em texto simples:

No 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.

Aplicar patches e automatizar atualizações

Atualizar o seu sistema é a forma mais rápida de colmatar falhas de segurança conhecidas. Execute as atualizações imediatamente após a implementação:

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 dnf-automatic e defina upgrade_type = security em /etc/dnf/automatic.conf.

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

Reforçar 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 alvos principais para exploração:

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

Reforce 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 um umask de 027 em /etc/profile para impedir que novos ficheiros sejam legíveis por todos.

Encontre e corrija ficheiros graváveis por todos com find / -xdev -type f -perm -0002 -ls. Para diretórios que devem permanecer graváveis por todos (como /tmp), aplique o bit sticky: chmod 1777 /tmp.

Opções de montagem segura

Edite /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 controlos de acesso obrigatórios

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

SELinux: Verifique o estado com getenforce. Comece no modo permissivo (setenforce 0) durante pelo menos duas semanas para capturar o comportamento da carga de trabalho sem causar falhas. Monitorize as violações com ausearch -m avc -ts recent. Use audit2why para diagnosticar bloqueios e audit2allow -M [module_name] para criar módulos de política. Assim que os registos estiverem limpos, mude para o modo de imposição com setenforce 1, e torne-a permanente no /etc/selinux/config.

AppArmor: Verifique os perfis ativos com aa-status. Instale apparmor-utils para comandos de gestão. Inicie os perfis no modo de aviso com aa-complain, depois mude para o modo de aplicação com aa-enforce assim que estiver confiante. Use aa-genprof para criar perfis para aplicações personalizadas.

Configurar o registo de auditoria e a monitorização

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

sudo apt-get install auditd audispd-plugins

Adicione monitorizações do sistema de ficheiros para ficheiros críticos:

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

Acompanhe toda a execução de comandos ao nível de root:

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

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

Monitorização da integridade de ficheiros com o AIDE

O AIDE deteta alterações não autorizadas nos ficheiros comparando o estado atual com uma linha de base conhecida como válida. Instale-o, inicialize a base de dados com aideinite mova o ficheiro resultante para /var/lib/aide/aide.db.gz. Configure uma tarefa cron diária para executar aide --check e enviar os resultados por e-mail aos administradores.

Centralize os registos

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

*.* @@remote-host:514

Set 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 gerem vários servidores, ferramentas como o Wazuh ou o OSSEC fornecem deteção de intrusões baseada no anfitrião com análise centralizada de registos

Manutenção contínua

O reforço de segurança não é uma tarefa pontual. As configurações sofrem alterações, surgem novas vulnerabilidades e as mudanças de pessoal deixam contas abandonadas.

Semanalmente: analise os registos do Fail2Ban, verifique se há atualizações falhadas e verifique as cópias de segurança.

Mensalmente: Auditar contas de utilizador e permissões, rever serviços em execução, executar uma verificação completa com o Lynis ou o OpenSCAP.

Trimestralmente: Alterne credenciais, atualize regras de firewall, teste a recuperação de desastres.

Utilize ferramentas de infraestrutura como código, como o Ansible com funções de reforço de segurança do dev-sec.io, para impor configurações consistentes em todo o seu parque de servidores e evitar desvios entre auditorias.

Os servidores dedicados da FDC oferecem-lhe acesso root total e controlo completo sobre a sua pilha de segurança. Explore as opções de servidores dedicados para construir numa plataforma onde controla todas as camadas.