01 - Controla Requisições

O Controle de Requisições do Servidor SSH é o conjunto de mecanismos técnicos que o sshd utiliza para gerenciar o volume, a cadência e a legitimidade das tentativas de conexão que chegam até a infraestrutura. Gerir requisições de forma eficiente é o que garante que o servidor permaneça responsivo para administradores legítimos, mesmo quando submetido a ataques de negação de serviço (DoS) ou scans massivos de botnets. Esta função técnica reside na orquestração entre o soquete de rede e as diretivas de configuração que limitam a exposição do sistema operacional.

1. O Fluxo de Entrada e Aceite de Conexão

Sempre que um novo pacote SYN chega à porta 22 (SSH), o servidor inicia um processo rigoroso de triagem técnica.

Etapas do Ciclo de Aceite

1. Escuta e Aceite (Listen/Accept): O sshd aceita a conexão TCP e, imediatamente, aloca recursos mínimos para o diálogo inicial.
2. Troca de Versão (Version Exchange): As duas pontas trocam strings de identificação do protocolo (ex: SSH-2.0-OpenSSH_8.2p1). Se as versões forem incompatíveis (ex: o cliente solicitar SSH-1 em um servidor moderno), a conexão é encerrada sumariamente.
3. Negociação de Algoritmos: O servidor apresenta sua lista de métodos de troca de chaves (KEX), cifras simétricas e algoritmos de MAC, buscando a maior interseção de segurança suportada por ambos.
4. Troca de Chaves (KEX): Diffie-Hellman efêmero gera a chave de sessão compartilhada.
5. Autenticação: Cliente prova sua identidade (senha, chave pública, Kerberos, certificado).
6. Abertura de Canal: Servidor cria canal de sessão e aloca PTY.

Estados TCP Envolvidos

2. Prevenção de DoS: O Grace Time e Conexões Pendentes

O servidor SSH implementa proteções contra ataques que tentam exaurir seus recursos de rede (como o Slowloris adaptado para SSH, ou ferramentas como pyssh-attack).

Diretiva LoginGraceTime

Define o tempo máximo em segundos que uma conexão pode permanecer aberta sem que o usuário tenha concluído a autenticação com sucesso.

• Default: 120 segundos (2 minutos).
• Recomendado: 30 segundos em ambientes de produção com automação.
• Se o usuário (ou robô) não logar dentro do tempo, o sshd corta a conexão para liberar o slot para outro cliente.
• Também protege contra ataques que abrem conexões e as mantêm paradas para exaurir a tabela de processos do servidor.

Diretiva MaxStartups

Limita o número de conexões "não autenticadas" simultâneas. Isso impede que um atacante abra milhares de conexões em paralelo para travar o daemon de autenticação do servidor.

• Sintaxe: MaxStartups start:rate:full
• Default: 10:30:100 — a partir de 10 conexões não-autenticadas, o servidor começa a recusar 30% das novas; em 100 conexões, todas são recusadas.
• Comportamento: A recusa é aleatória (drop probabilístico), o que mantém o servidor responsivo para conexões legítimas mesmo durante flooding.

Diretiva PerSourcePenalties (OpenSSH 9.8+)

Mecanismo moderno que penaliza IPs que causam repetidas falhas de handshake ou autenticação, aplicando backoff exponencial antes de aceitar nova conexão daquele IP.

3. Gestão de Escala: MaxSessions e MaxAuthTries

Para grandes infraestruturas com múltiplos administradores, o controle de requisições deve ser refinado.

MaxSessions

Define o número máximo de sessões (canais) abertas por cada conexão de rede única. Isso permite que um administrador tenha múltiplos terminais abertos sobre um único túnel seguro, otimizando o tráfego.

• Default: 10
• Cenário: Atingir este limite gera erro channel 0: open failed: resource shortage.
• Ajuste: Em servidores de automação (Ansible), pode ser necessário elevar para 50+.

MaxAuthTries

Define quantas tentativas de senha um usuário pode fazer em uma única conexão. Ao atingir o limite (geralmente 6), o login é recusado e a tentativa é registrada no log de auditoria.

• Default: 6
• Hardening: Reduzir para 3 em ambientes críticos.
• Importante: cada método de autenticação conta como 1 tentativa — se o usuário tenta senha, depois pubkey, depois keyboard-interactive, já consumiu 3.

Isolamento de Soquete (Privilege Separation)

Cada requisição aceita é processada por um "unprivileged worker process" (usuário sshd), garantindo que falhas de rede não permitam a exploração de memória com privilégios de root.

• Diretiva: UsePrivilegeSeparation sandbox (ativado por padrão no OpenSSH moderno).
• Implementa seccomp-bpf para restringir syscalls disponíveis ao processo não-privilegiado.

4. Detecção de Ataques de Brute Force

O sshd pode ser configurado para ser rígido quanto ao número de erros.

Diretivas de Logging

Integração com IPS/IDS

Sistemas de detecção de intrusão externos monitoram o tráfego da porta 22 em busca de assinaturas de scanners de SSH, bloqueando o IP na borda antes que ele atinja o controle de requisições do servidor.

• Fail2Ban: Analisa /var/log/auth.log e injeta regras iptables para IPs que falharam autenticação 5 vezes em 10 minutos.
• Snort/Suricata: Regras para detectar padrões de SSH bruteforce (regra SID 1852 do Emerging Threats).
• ** CrowdSec:** Moderna alternativa ao Fail2Ban com threat intelligence colaborativa.
• sshguard: Leve e eficiente, monitora múltiplos serviços (SSH, vsftpd, sendmail, postfix).

Exemplo de Configuração Fail2Ban

# /etc/fail2ban/jail.local
[sshd]
enabled  = true
port     = ssh
filter   = sshd
logpath  = /var/log/auth.log
maxretry = 5
findtime = 600
bantime  = 3600
banaction = iptables-multiport

5. Auditoria Técnica e Diagnóstico de Requisições

Administradores de sistema utilizam ferramentas de rede para validar o comportamento do daemon sob carga:

# Verificando as configuracoes de limite de conexoes ativas
sudo sshd -T | grep -E "MaxStartups|MaxSessions|MaxAuthTries|LoginGraceTime|ClientAliveInterval"

# Monitorando conexoes SSH em tempo real e identificando o estado (ESTABLISHED vs SYN_RECV)
ss -atn | grep :22 | awk '{print $1}' | sort | uniq -c

# Listando processos sshd filhos (cada conexao autenticada gera um processo)
ps -ef | grep sshd: | grep -v grep

# Contando conexoes por IP de origem (deteccao de flooding)
ss -tn state established '( sport = :22 )' | awk '{print $4}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20

# Analisando tentativas de login falhas no log de autenticacao
sudo journalctl -u ssh -g "Failed password" --since "1 hour ago"

# Testando a resposta do servidor a multiplas requisicoes simultaneas
for i in {1..50}; do
  (timeout 2 ssh -o StrictHostKeyChecking=no -o PasswordAuthentication=no user@localhost 2>&1 &)
done
wait
ss -tn state established '( sport = :22 )' | wc -l

6. Hardening Recomendado do sshd_config

# /etc/ssh/sshd_config (excertos recomendados)

# Limites de conexao e DoS
LoginGraceTime       30
MaxStartups          10:30:60
MaxAuthTries         3
MaxSessions          10
ClientAliveInterval  300
ClientAliveCountMax  2

# Privilegio e isolamento
UsePrivilegeSeparation sandbox
PermitRootLogin       no
AllowUsers            adminuser@(10.0.0.* 192.168.1.*)
DenyUsers            root

# Metodos de autenticacao
PubkeyAuthentication  yes
PasswordAuthentication no
PermitEmptyPasswords  no
KbdInteractiveAuthentication no

# Logging
LogLevel VERBOSE
SyslogFacility AUTHPRIV

# Tunelamento (desabilitar se nao necessario)
AllowTcpForwarding    no
AllowAgentForwarding   no
X11Forwarding         no
PermitTunnel           no

Validação da Configuração

sudo sshd -t -f /etc/ssh/sshd_config       # testa a sintaxe
sudo systemctl reload sshd                  # recarrega sem derrubar conexoes

7. Conclusão

O Controle de Requisições é o filtro que mantém a integridade do servidor SSH em face da hostilidade constante da rede. De sua precisão técnica depende a disponibilidade do acesso remoto e a proteção contra a exaustão de recursos. Configurar adequadamente MaxStartups, LoginGraceTime, MaxAuthTries e o privilege separation é fundamental para manter o servidor SSH operacional mesmo durante tentativas de invasão em larga escala. Combinar essas diretivas nativas com ferramentas externas como Fail2Ban, CrowdSec e IPS de borda cria uma postura de defesa em camadas que reduz drasticamente o risco de comprometimento via brute force ou DoS, garantindo que apenas administradores legítimos obtenham acesso ao shell remoto.