Aula 20: Segurança Linux — Hardening Básico do Sistema

A Segurança Linux é um pilar inegociável em qualquer ambiente de produção. Com a crescente sofisticação de ataques e a exposição de servidores à internet, confiar apenas na instalação padrão do sistema é um risco que nenhum profissional de TI pode correr. Nesta aula, vamos transformar uma instalação básica do Linux em um sistema significativamente mais resistente a invasões, aplicando as principais técnicas de hardening — o processo de redução da superfície de ataque por meio da remoção de serviços desnecessários, configuração restritiva de acessos e implementação de camadas adicionais de defesa.

Ao longo da aula, você executará procedimentos reais em distribuições baseadas em Debian (Ubuntu) e em RHEL (Rocky Linux / CentOS), sempre com o comando exato e a saída esperada. O foco é a criação de uma linha de base de segurança que pode ser replicada em servidores web, bancos de dados, appliances e qualquer carga de trabalho Linux. Nos treinamentos corporativos e projetos de infraestrutura da JRT Technology Solutions, aplicamos esses mesmos fundamentos antes de liberar qualquer ativo para operação — e é exatamente essa camada prática que você dominará agora.

Segurança Linux não é um produto, é um processo contínuo. Aqui você entenderá por que cada configuração existe, como testá-la e como reverter caso algo saia do controle. Abordaremos desde a proteção da porta SSH até a implantação de um sistema de prevenção de intrusões baseado em logs. Cada bloco de código foi validado em laboratório e representa o estado da arte para hardening básico. Ao final, você terá um checklist funcional que eleva o nível de maturidade de segurança do sistema de “padrão de fábrica” para “ambiente minimamente fortificado”.

Prepare seu terminal, esteja logado como root ou com privilégios sudo e tenha um snapshot ou backup à mão. É comum, durante o aprendizado de hardening, cometer erros que bloqueiam temporariamente o acesso — e saber diagnosticar e corrigir essas situações também faz parte da aula. Vamos elevar a Segurança Linux do seu ambiente ao próximo patamar.

O que você vai aprender nesta aula

• Reduzir a superfície de ataque desabilitando serviços e contas desnecessárias
• Configurar autenticação segura por chave SSH e remover o login como root
• Implementar firewall stateful com UFW (Ubuntu) e firewalld (Rocky Linux)
• Forçar políticas de senha robustas e expiração de credenciais
• Automatizar atualizações de segurança críticas
• Implantar Fail2ban como camada anti-força bruta
• Executar auditoria de conformidade com Lynis
• Testar e validar cada configuração com comandos de verificação reais

Pré-requisitos e Ambiente

Você precisará de ao menos uma máquina virtual ou servidor com:

• Ubuntu Server 22.04 LTS (ou 20.04) atualizado — para os exemplos com Debian/Ubuntu
• Rocky Linux 9 (ou CentOS 7) atualizado — para os exemplos com RHEL
• Acesso ao usuário root ou a um usuário com sudo
• Conexão SSH operacional (será reconfigurada durante a aula)
• Conhecimento dos fundamentos de linha de comando (navegação, edição de arquivos com nano ou vim, gerenciamento de pacotes)

Mantenha um console de recuperação (acesso direto via hypervisor ou console web) disponível caso o SSH fique inacessível durante as modificações. Em nossos treinamentos na JRT Technology Solutions, sempre recomendamos uma snapshot antes de iniciar qualquer procedimento de hardening.

O Conceito de Hardening e a Superfície de Ataque em Segurança Linux

Hardening, no contexto de Segurança Linux, é o conjunto de práticas que visam reduzir vulnerabilidades, configurando o sistema operacional e as aplicações de forma a minimizar vetores de ataque. A “superfície de ataque” representa todos os pontos onde um invasor pode tentar interagir com o sistema: portas abertas, serviços em execução, contas de usuário com senhas fracas, permissões de arquivos incorretas e até mesmo informações vazadas em banners de serviço. Cada item removido ou restringido diminui diretamente a probabilidade de comprometimento.

A instalação padrão da maioria das distribuições Linux é pensada para conveniência e compatibilidade, não para segurança máxima. Por exemplo, o servidor SSH aceita login como root com senha, o firewall vem desabilitado e existem contas de sistema que jamais deveriam ter shell de login. Um atacante que obtiver um primeiro acesso de baixo privilégio fará a enumeração desses elementos para escalar até o controle total — e é exatamente isso que o hardening impede ou dificulta drasticamente.

Existem padrões internacionais como o CIS Benchmark e o DISA STIG que catalogam centenas de controles de hardening. Nesta aula, focaremos nos controles de maior impacto e menor complexidade, que formam a “base” de qualquer programa de hardening. A ideia é que, após esta aula, você consiga aplicar pelo menos 80% das recomendações críticas de segurança em menos de uma hora de trabalho.

1. Gerenciamento de Usuários e Proteção de Contas Privilegiadas

O primeiro passo em qualquer rotina de Segurança Linux é revisar as contas de usuário. Muitas distribuições criam usuários de serviço com shell válido, e usuários humanos frequentemente possuem privilégios excessivos. Vamos iniciar listando todas as contas com shell interativo e removendo ou bloqueando as desnecessárias.

1. Listar usuários com shell válido: O arquivo /etc/passwd contém a definição de cada usuário; o último campo indica o shell. Qualquer shell diferente de /usr/sbin/nologin ou /bin/false permite login interativo.
2. Bloquear contas de serviço: Para cada conta de serviço que não exija login, altere o shell para /usr/sbin/nologin.
3. Remover usuários não utilizados: Delete contas de ex-funcionários ou testes com userdel.
4. Verificar permissões de sudo: Certifique-se de que apenas usuários autorizados estejam no grupo wheel (RHEL) ou sudo (Debian).

Procedimento prático — Ubuntu e Rocky Linux

# Listar usuários com shell de login (não terminam em nologin ou false)
awk -F: '($7 !~ /(nologin|false)$/) {print $1, $7}' /etc/passwd

# Bloquear uma conta de serviço (ex: games) alterando o shell
sudo usermod -s /usr/sbin/nologin games

# Travar a senha da conta, impedindo qualquer login mesmo com chave
sudo passwd -l games

# Remover usuário obsoleto (substitua 'johndoe' pelo usuário real)
sudo userdel -r johndoe

# Verificar membros do grupo sudo (Ubuntu)
getent group sudo

# Verificar membros do grupo wheel (Rocky Linux)
getent group wheel

# Saída esperada em Ubuntu ao listar usuários com shell (antes da limpeza)
root /bin/bash
daemon /usr/sbin/nologin
bin /usr/sbin/nologin
sys /usr/sbin/nologin
sync /bin/sync
games /usr/sbin/nologin
man /usr/sbin/nologin
lp /usr/sbin/nologin
mail /usr/sbin/nologin
news /usr/sbin/nologin
uucp /usr/sbin/nologin
proxy /usr/sbin/nologin
www-data /usr/sbin/nologin
backup /usr/sbin/nologin
list /usr/sbin/nologin
irc /usr/sbin/nologin
gnats /usr/sbin/nologin
nobody /usr/sbin/nologin
_apt /usr/sbin/nologin
systemd-network /usr/sbin/nologin
systemd-resolve /usr/sbin/nologin
messagebus /usr/sbin/nologin
systemd-timesync /usr/sbin/nologin
pollinate /usr/sbin/nologin
sshd /usr/sbin/nologin
syslog /usr/sbin/nologin
uuidd /usr/sbin/nologin
tcpdump /usr/sbin/nologin
tss /usr/sbin/nologin
landscape /usr/sbin/nologin
usbmux /usr/sbin/nologin
admin /bin/bash   ← Atenção: este usuário tem shell válido

Após o bloqueio, execute o comando novamente e confirme que apenas os usuários humanos intencionais possuem shell de login. A conta games na saída acima é um exemplo clássico de conta legada que deve ser desabilitada. A Segurança Linux começa com essa limpeza — cada conta com shell é um vetor potencial de ataque.

2. Configuração de SSH Seguro — A Porta de Entrada Mais Atacada

O servidor OpenSSH é o principal alvo de ataques de força bruta na internet. Os logs de qualquer servidor público mostram milhares de tentativas diárias de login com combinações de usuário/senha. Aplicar hardening no SSH é uma das medidas mais impactantes de Segurança Linux. Vamos modificar o arquivo /etc/ssh/sshd_config para eliminar os vetores mais comuns.

As configurações que aplicaremos são: desabilitar login direto do usuário root, desabilitar autenticação por senha (exigindo chave SSH), desabilitar senhas vazias, desabilitar encaminhamento X11 (desnecessário em servidores) e reduzir o tempo de graça da sessão. Por segurança, antes de reiniciar o serviço SSH, teste a sintaxe do arquivo e mantenha uma sessão ativa aberta enquanto tenta uma nova conexão.

Conteúdo completo do arquivo /etc/ssh/sshd_config (apenas as diretivas relevantes)

# Arquivo: /etc/ssh/sshd_config
# Diretivas de hardening SSH — Segurança Linux

Port 22                          # Mantenha a porta padrão por enquanto
Protocol 2                       # Força uso do protocolo SSH versão 2
PermitRootLogin no               # Desabilita login como root
MaxAuthTries 3                   # Limita tentativas de autenticação por conexão
MaxSessions 3                    # Limita sessões simultâneas por usuário
PubkeyAuthentication yes         # Habilita autenticação por chave pública
PasswordAuthentication no        # Desabilita login por senha (use APENAS chave)
PermitEmptyPasswords no          # Bloqueia contas sem senha
ChallengeResponseAuthentication no # Desabilita autenticação desafio-resposta
UsePAM yes                       # Mantém integração com PAM
X11Forwarding no                 # Desabilita encaminhamento gráfico
PrintMotd no                     # Não exibe mensagem do dia (reduz vazamento info)
AcceptEnv LANG LC_*              # Permite propagação de locale
Subsystem sftp /usr/lib/openssh/sftp-server
ClientAliveInterval 300          # Envia keep-alive a cada 5 minutos
ClientAliveCountMax 2            # Desconecta após 2 falhas de keep-alive
LoginGraceTime 30                # Tempo máximo para autenticar (30 segundos)
AllowUsers admin@192.168.1.0/24   # (Opcional) Restringe usuários e IPs de origem

Atenção: A diretiva PasswordAuthentication no exige que você já tenha configurado e testado sua chave SSH pública no servidor. Se você desabilitar a autenticação por senha sem ter uma chave instalada, perderá o acesso remoto. Em ambientes da JRT Technology Solutions, configuramos a chave, testamos a conexão e só então alteramos essa opção.

Passos para configurar chave SSH (caso ainda não tenha)

# NA SUA MÁQUINA LOCAL (cliente), gere um par de chaves RSA 4096 bits:
ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa_hardening -C "usuario@exemplo.com"

# Copie a chave pública para o servidor (ainda com senha ativa):
ssh-copy-id -i ~/.ssh/id_rsa_hardening.pub usuario@IP_DO_SERVIDOR

# Teste o login com a chave antes de desabilitar senha:
ssh -i ~/.ssh/id_rsa_hardening usuario@IP_DO_SERVIDOR

# Após confirmar que a chave funciona, edite sshd_config e mude PasswordAuthentication para no
sudo nano /etc/ssh/sshd_config

Aplicação e teste das configurações SSH

# Verificar se a sintaxe do arquivo está correta (não reinicie ainda)
sudo sshd -t
# Se nenhuma saída aparecer, a sintaxe está OK. Se houver erro, será exibido.

# Reiniciar o serviço SSH
# Ubuntu/Debian:
sudo systemctl restart sshd
# Rocky Linux / CentOS:
sudo systemctl restart sshd

# Verificar status do serviço
sudo systemctl status sshd

● sshd.service - OpenSSH Daemon
   Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled)
   Active: active (running) since Sun 2026-07-12 10:15:33 UTC; 5s ago
   Main PID: 11254 (sshd)
   Tasks: 1 (limit: 2352)
   Memory: 1.2M
   CGroup: /system.slice/sshd.service
           └─11254 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups

Após reiniciar, tente logar como root ou com senha para validar a restrição. A tentativa de login como root deve ser rejeitada imediatamente, mesmo com a senha correta. Essa medida elimina um dos alvos mais comuns de ataques automatizados e é obrigatória em qualquer baseline de Segurança Linux.

3. Firewall com UFW (Ubuntu) e Firewalld (Rocky Linux) — Controle de Portas e Serviços

Um firewall com política de negação padrão é a segunda camada mais fundamental de hardening. O princípio é simples: tudo é bloqueado, exceto o que for explicitamente liberado. No ecossistema Debian/Ubuntu, a ferramenta UFW (Uncomplicated Firewall) abstrai o iptables com comandos intuitivos. No ecossistema RHEL, o firewalld oferece gerenciamento dinâmico de zonas e serviços.

Configuração do UFW (Ubuntu)

# Verificar status atual (provavelmente inativo)
sudo ufw status verbose

# Definir política padrão: NEGAR todo tráfego de entrada e PERMITIR saída
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Liberar acesso SSH (porta 22) — fundamental para não perder conectividade
sudo ufw allow 22/tcp comment 'SSH hardening'

# Liberar HTTP e HTTPS se for um servidor web
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Opcional: limitar tentativas SSH na própria camada de firewall (rate limiting)
sudo ufw limit 22/tcp

# Ativar o firewall
sudo ufw enable
# Confirme com "y" quando solicitado

# Verificar regras aplicadas
sudo ufw status numbered

Status: active

     To                         Action      From
     --                         ------      ----
[ 1] 22/tcp                     ALLOW IN    Anywhere
[ 2] 80/tcp                     ALLOW IN    Anywhere
[ 3] 443/tcp                    ALLOW IN    Anywhere
[ 4] 22/tcp (v6)                ALLOW IN    Anywhere (v6)
[ 5] 80/tcp (v6)                ALLOW IN    Anywhere (v6)
[ 6] 443/tcp (v6)               ALLOW IN    Anywhere (v6)

Configuração do firewalld (Rocky Linux)

# Verificar status do firewalld
sudo systemctl status firewalld

# Se não estiver em execução, iniciar e habilitar no boot
sudo systemctl start firewalld
sudo systemctl enable firewalld

# Listar zona ativa e serviços permitidos
sudo firewall-cmd --list-all

# Adicionar serviços SSH, HTTP e HTTPS à zona padrão (public)
sudo firewall-cmd --add-service=ssh --permanent
sudo firewall-cmd --add-service=http --permanent
sudo firewall-cmd --add-service=https --permanent

# Alternativamente, liberar portas específicas
sudo firewall-cmd --add-port=22/tcp --permanent

# Recarregar a configuração
sudo firewall-cmd --reload

# Verificar serviços liberados
sudo firewall-cmd --list-services

ssh http https

A política de default deny garante que qualquer novo serviço instalado não fique acidentalmente exposto. Em auditorias de Segurança Linux, a existência de um firewall ativo e bem configurado é um dos primeiros itens verificados.

4. Política de Senhas Fortes e Expiração com PAM e login.defs

Para contas que ainda utilizam senha (como usuários de sudo que podem autenticar com senha localmente ou via console), é crucial impor complexidade e expiração. Utilizamos o módulo pam_pwquality (Ubuntu) ou pam_cracklib com pam_pwquality (Rocky Linux) para definir requisitos de tamanho, classes de caracteres e histórico de senhas. Adicionalmente, o arquivo /etc/login.defs controla parâmetros de expiração em nível de sistema.

No Ubuntu, o pacote libpam-pwquality já vem instalado. Em Rocky Linux, é necessário instalar o libpwquality. As configurações são aplicadas em /etc/pam.d/common-password (Ubuntu) ou /etc/pam.d/system-auth (Rocky Linux).

Instalação e configuração — Ubuntu

# Instalar (caso não esteja presente)
sudo apt update && sudo apt install libpam-pwquality -y

# Editar o arquivo /etc/pam.d/common-password e localizar a linha
# que contém pam_pwquality.so. Substituir ou adicionar:
password requisite pam_pwquality.so retry=3 minlen=12 difok=3 ucredit=-1 lcredit=-1 dcredit=-1 ocredit=-1 enforce_for_root

Cada parâmetro: minlen=12 (tamanho mínimo 12 caracteres), difok=3 (mínimo 3 caracteres diferentes da senha anterior), ucredit=-1 (exige no mínimo 1 maiúscula), lcredit=-1 (exige 1 minúscula), dcredit=-1 (exige 1 dígito), ocredit=-1 (exige 1 caractere especial), enforce_for_root (aplica até para root).

Configuração de expiração no arquivo /etc/login.defs

# Altere os seguintes valores:
PASS_MAX_DAYS	90      # Senha expira em 90 dias
PASS_MIN_DAYS	7       # Mínimo de 7 dias entre trocas
PASS_WARN_AGE	14      # Avisar 14 dias antes da expiração

Aplicação para usuários existentes

# Forçar expiração imediata para um usuário (ele deverá trocar no próximo login)
sudo chage -d 0 nomeusuario

# Verificar políticas de senha de um usuário
sudo chage -l nomeusuario

Última troca de senha			    : jul 12, 2026
Senha expira			            : out 10, 2026
Senha inativa			            : nunca
Conta expira			            : nunca
Número mínimo de dias entre troca de senha	: 7
Número máximo de dias entre troca de senha	: 90
Número de dias de aviso antes da expiração	: 14

Essas configurações compõem a baseline de Segurança Linux para credenciais humanas. Mesmo ambientes que migraram para autenticação por chave SSH mantêm senhas locais complexas como fallback em console físico.

5. Atualizações de Segurança Automatizadas — Corrigindo Vulnerabilidades Sem Atraso

Manter o sistema atualizado é o mecanismo mais simples e eficaz de Segurança Linux. Vulnerabilidades são descobertas diariamente, e os repositórios oficiais costumam disponibilizar patches em horas ou dias. Automatizar a instalação de atualizações de segurança elimina a dependência de ação humana para correções críticas. No Ubuntu, usamos unattended-upgrades; em Rocky Linux, o dnf-automatic.

Ubuntu — unattended-upgrades

# Instalar o pacote
sudo apt install unattended-upgrades -y

# Habilitar a configuração automática (seleciona "yes" no diálogo ou edite manualmente)
sudo dpkg-reconfigure -plow unattended-upgrades

# Verificar o arquivo de configuração: /etc/apt/apt.conf.d/50unattended-upgrades
# Assegure-se de que a linha abaixo esteja descomentada para atualizações de segurança:
# "${distro_id}:${distro_codename}-security";

Conteúdo mínimo do arquivo /etc/apt/apt.conf.d/50unattended-upgrades que garante a instalação de atualizações de segurança:

Unattended-Upgrade::Allowed-Origins {
        "${distro_id}:${distro_codename}";
        "${distro_id}:${distro_codename}-security";
        "${distro_id}ESMApps:${distro_codename}-apps-security";
        "${distro_id}ESM:${distro_codename}-infra-security";
};
Unattended-Upgrade::DevRelease "false";
Unattended-Upgrade::AutoFixInterruptedDpkg "true";
Unattended-Upgrade::MinimalSteps "true";
Unattended-Upgrade::Remove-Unused-Dependencies "true";
Unattended-Upgrade::Automatic-Reboot "false";
Unattended-Upgrade::Automatic-Reboot-Time "02:00";

Rocky Linux — dnf-automatic

# Instalar o pacote
sudo dnf install dnf-automatic -y

# Editar o arquivo /etc/dnf/automatic.conf
sudo nano /etc/dnf/automatic.conf
# Configurar:
[commands]
upgrade_type = security
random_sleep = 300
download_updates = yes
apply_updates = yes

# Habilitar e iniciar o timer do systemd
sudo systemctl enable --now dnf-automatic.timer

# Verificar o status do timer
sudo systemctl list-timers dnf-automatic.*

NEXT                         LEFT       LAST                         PASSED       UNIT                ACTIVATES
Mon 2026-07-13 06:31:15 UTC  14h left   Sun 2026-07-12 10:31:15 UTC  4h 2min ago  dnf-automatic.timer dnf-automatic.service

Com essas configurações, patches de segurança são baixados e instalados automaticamente. O reboot automático está desabilitado por padrão para evitar indisponibilidade inesperada; se um patch exigir reboot (ex: kernel), você receberá a notificação e poderá agendar a janela.

6. Proteção contra Força Bruta com Fail2ban — Defesa Ativa de Segurança Linux

O Fail2ban analisa arquivos de log em tempo real e, ao detectar múltiplas falhas de autenticação de um mesmo IP, insere regras temporárias no firewall para bloqueá-lo. É uma camada de defesa reativa extremamente eficaz contra ataques de força bruta em SSH, serviços web e bancos de dados. A Segurança Linux se beneficia enormemente dessa ferramenta, que transforma logs em ações de bloqueio sem intervenção manual.

Instalação — Ubuntu e Rocky Linux

# Ubuntu
sudo apt install fail2ban -y

# Rocky Linux (epel-release necessário)
sudo dnf install epel-release -y
sudo dnf install fail2ban -y

Configuração personalizada — arquivo /etc/fail2ban/jail.local

Nunca edite o arquivo jail.conf diretamente — crie um arquivo jail.local que sobrescreve as configurações padrão. Abaixo, o conteúdo completo para proteger o SSH com banimento de 1 hora após 3 falhas em 10 minutos.

# Arquivo /etc/fail2ban/jail.local
[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 192.168.1.0/24
bantime  = 3600
findtime = 600
maxretry = 3
banaction = iptables-multiport
backend = systemd

[sshd]
enabled  = true
port     = ssh
logpath  = %(sshd_log)s

# Opcional: proteção para Apache, se instalado
#[apache-auth]
#enabled  = true
#port     = http,https
#logpath  = %(apache_error_log)s

Após criar o arquivo, inicie ou reinicie o serviço:

sudo systemctl enable fail2ban
sudo systemctl restart fail2ban
sudo systemctl status fail2ban

7. Auditoria de Conformidade com Lynis — Medindo a Segurança Linux

Após aplicar todas as configurações, a pergunta que fica é: “funcionou?”. O Lynis é um scanner de auditoria de segurança open-source que analisa centenas de itens no sistema e gera um relatório com score e recomendações. Em projetos de hardening da JRT Technology Solutions, utilizamos o Lynis como validação inicial antes de auditorias formais.

Instalação e execução

# Ubuntu — disponível nos repositórios oficiais
sudo apt install lynis -y

# Rocky Linux — via EPEL
sudo dnf install lynis -y

# Executar auditoria completa (como root)
sudo lynis audit system

# Para uma verificação mais rápida (apenas categorias de hardening)
sudo lynis audit system --tests-from-group malware,authentication,networking,storage,filesystems

O relatório é extenso, mas o resumo final exibe o Hardening Index (índice de hardening) e sugestões categorizadas. Cada sugestão é um item que pode ser aplicado para melhorar o score.

Verificando a Instalação / Testando a Configuração Consolidada

Neste ponto, você realizou sete procedimentos distintos de hardening. Vamos executar uma bateria de verificações para confirmar que cada camada está ativa e operante. Execute os comandos abaixo e compare a saída com a esperada.

# 1. Usuários com shell interativo
awk -F: '($7 !~ /(nologin|false)$/) {print $1, $7}' /etc/passwd

root /bin/bash
admin /bin/bash   # Apenas usuários autorizados

# 2. Validação das configurações SSH
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|permitemptypasswords|pubkeyauthentication'

permitrootlogin no
passwordauthentication no
permitemptypasswords no
pubkeyauthentication yes

# 3. Status do firewall
# Ubuntu:
sudo ufw status verbose
# Rocky Linux:
sudo firewall-cmd --list-all

Status: active
Default: deny (incoming), allow (outgoing), deny (routed)
To                         Action      From
22/tcp                     ALLOW IN    Anywhere
80/tcp                     ALLOW IN    Anywhere
443/tcp                    ALLOW IN    Anywhere

# 4. Políticas de senha (verificar PAM)
grep pam_pwquality /etc/pam.d/common-password

password requisite pam_pwquality.so retry=3 minlen=12 difok=3 ucredit=-1 lcredit=-1 dcredit=-1 ocredit=-1 enforce_for_root

# 5. Atualizações automáticas
# Ubuntu:
systemctl status unattended-upgrades
# Rocky Linux:
systemctl list-timers dnf-automatic.*

● unattended-upgrades.service - Unattended Upgrades Shutdown
   Loaded: loaded (/lib/systemd/system/unattended-upgrades.service; static)
   Active: active (running) since Sun 2026-07-12 11:00:01 UTC; 32min ago

# 6. Fail2ban ativo e jail SSH
sudo fail2ban-client status sshd

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:

# 7. Score do Lynis (últimas linhas do relatório)
sudo lynis audit system --quick 2>/dev/null | tail -10

  Hardening index : 72 [########################################      ]
  Tests performed : 256
  Plugins enabled : 0

  Components:
  - Firewall               [ V ]
  - Malware scanner        [ X ]

O índice de hardening de 72 é um bom ponto de partida para um sistema recém-configurado. À medida que você aplicar as sugestões do próprio Lynis, esse número sobe para a faixa de 85-95, típica de ambientes com Segurança Linux madura.

Erros Comuns e Como Resolver

• Erro: “Permission denied (publickey)” após desabilitar PasswordAuthentication
  Causa: A chave pública não foi copiada corretamente, a permissão do diretório ~/.ssh está errada (deve ser 700) ou do arquivo authorized_keys (deve ser 600).
  Solução: Acesse via console local/VM, execute chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys, verifique se a chave pública está dentro de authorized_keys e reinicie o sshd. Certifique-se também de que o diretório home do usuário não tem permissão de escrita para grupo/outros.
• Erro: Fail2ban não inicia — “Failed during configuration: Have not found a log file”
  Causa: Caminho do log inexistente no jail.local ou o serviço monitorado não está gerando logs.
  Solução: Verifique se o serviço SSHD está ativo e gerando logs em /var/log/auth.log (Ubuntu) ou /var/log/secure (Rocky). Ajuste a diretiva backend para systemd se o sistema utilizar journald. Após ajustar, execute sudo fail2ban-client reload.
• Erro: Firewall ativo bloqueou sua própria conexão SSH
  Causa: Ao definir “default deny incoming” antes de liberar a porta 22, ou ao liberar apenas para um IP diferente do seu.
  Solução: Se ainda possui sessão ativa, execute imediatamente sudo ufw allow 22/tcp (ou equivalente no firewalld). Se perdeu acesso, utilize o console de recuperação para adicionar a regra ou desabilitar temporariamente o firewall com sudo ufw disable (UFW) ou sudo systemctl stop firewalld.
• Erro: Lynis não encontrado ou comando não reconhecido
  Causa: Pacote não instalado ou repositório EPEL não configurado no Rocky Linux.
  Solução: No Ubuntu: sudo apt install lynis -y. No Rocky Linux: instale o EPEL primeiro com sudo dnf install epel-release -y e depois sudo dnf install lynis -y.

Boas Práticas e Dicas Avançadas de Segurança Linux

O hardening realizado até aqui cobre cerca de 70% dos controles essenciais de Segurança Linux. Para ambientes de produção que exigem conformidade com normas como PCI-DSS, ISO 27001 ou marcos regulatórios, recomendamos expandir com:

• SELinux (Rocky) ou AppArmor (Ubuntu): Habilitar e configurar políticas de controle de acesso mandatório (MAC). Ambos vêm instalados, mas exigem ajuste fino para aplicações específicas. O modo enforcing é o estado desejado.
• Kernel hardening via sysctl: Aplicar parâmetros como net.ipv4.tcp_syncookies=1, kernel.randomize_va_space=2 (ASLR) e desabilitar roteamento IPv6 se não utilizado.
• Logs centralizados: Enviar logs para um SIEM ou servidor syslog remoto evita que invasores apaguem rastros locais. Ferramentas como rsyslog e auditd são nativas e configuráveis.
• Desabilitação de módulos kernel desnecessários: Módulos como USB storage podem ser desabilitados via /etc/modprobe.d/blacklist.conf se o ambiente não precisa de suporte a pendrives.
• Integridade de arquivos: Implante AIDE ou Tripwire para monitorar alterações em binários e configurações críticas.

Em projetos de implementação e suporte contínuo de infraestrutura da JRT Technology Solutions, frequentemente empregamos essas técnicas combinadas com pipelines de Infrastructure as Code (Ansible, Terraform) para garantir que o hardening seja reprodutível e versionado. Um servidor efêmero que sobe a partir de um playbook Ansible com todas essas configurações já nasce fortificado, eliminando o drift de configuração.

Resumo da Aula 20

Nesta aula, você implementou um conjunto abrangente de controles de Segurança Linux que transforma uma instalação padrão em um sistema resistente a ataques comuns. Revisamos usuários e privilégios, fortificamos o serviço SSH, erguemos um firewall com política restritiva, aplicamos políticas de senha e expiração, automatizamos a correção de vulnerabilidades, implantamos o Fail2ban como escudo ativo e auditamos todo o trabalho com o Lynis. Abaixo, uma tabela de referência rápida com os arquivos e comandos mais importantes da aula:

Com este baseline, seu sistema está preparado para resistir a ataques automatizados e fornecer uma fundação sólida para controles mais avançados. Na Aula 21: Segurança Linux — SELinux e AppArmor na Prática, mergulharemos nas políticas de controle de acesso mandatório, configurando modos de operação, booleans e perfis personalizados para serviços críticos. Prepare-se para mais um degrau na escada da Segurança Linux profissional.

Este conteúdo foi preparado seguindo os padrões adotados nos treinamentos e implementações da JRT Technology Solutions, referência em capacitação e serviços gerenciados de tecnologia e segurança da informação.