Jump Server: Guia de Segurança e Boas Práticas

Jump Server: O Guia para Amplificar sua Segurança — Como Construir, Proteger e Não Transformar Seu Bastion na Porta dos Fundos

Como um servidor pequeno e dedicado pode ser a diferença entre suporte organizado e a próxima manchete sobre ransomware. E como, se mal configurado, pode ser também a porta exata por onde o atacante entra.

Introdução

Se você leu o post anterior sobre acesso remoto seguro, já sabe a regra de ouro: nunca exponha RDP, SSH ou qualquer serviço administrativo diretamente na internet. Mas então surge a pergunta prática: como o time de suporte, os DBAs, os sysadmins e os fornecedores acessam os servidores quando precisam?

A resposta tradicional é o jump server — também chamado de bastion host, stepping stone server, jump box. É um conceito que tem mais de 30 anos e continua relevante porque resolve um problema fundamental: centralizar e controlar todo o acesso administrativo a uma infraestrutura.

Mas aqui está o paradoxo: um jump server mal configurado é pior que não ter jump server nenhum. Por quê? Porque ele cria uma falsa sensação de segurança. Você acha que está protegido porque tem "aquele bastion", quando na verdade ele virou exatamente o que deveria evitar — uma porta única, conhecida, exposta, e cheia de privilégios.

Parte 1: O que é (e o que não é) um jump server

Um jump server é uma máquina dedicada, endurecida (hardened) ao máximo, posicionada como único ponto de passagem entre o mundo externo e os recursos internos críticos.

Em vez de cada servidor expor SSH ou RDP, só o jump server aceita conexões. Quem precisa administrar qualquer coisa, primeiro entra no jump server, e dali alcança os destinos.

A analogia: se sua infraestrutura é um prédio, o jump server é a portaria com catraca. Ninguém entra direto nas salas — todo mundo passa pela portaria, mostra crachá, é registrado.

O que NÃO é jump server:

• Servidor "qualquer" com TeamViewer
• VPN (VPN te coloca na rede; jump te dá acesso a uma máquina específica)
• Servidor de produção
• Substituto pra gestão de identidades
• "Seguro por existir"

Por que existir:

1. Reduz superfície de ataque (1 ponto vs N)
2. Centraliza autenticação e autorização
3. Centraliza logs e auditoria
4. Permite gravação de sessão
5. Aplica políticas uniformes
6. Funciona como ponto de quarentena
7. Suporta fornecedores sem dor
8. Custo baixo

Parte 2: Arquiteturas

2.1 Jump server simples

Internet → [Firewall] → [Jump] → [Servidores]

Pra equipes pequenas. Limitação: ponto único de falha e comprometimento.

2.2 Jump server duplo (chained)

Internet → [FW ext] → [Jump 1 DMZ] → [FW int] → [Jump 2 interno] → [Servidores]

Pra ambientes regulados. Atacante precisa comprometer dois servidores.

2.3 Jump server com broker / PAM

Broker valida tudo, busca credenciais temporárias do cofre, estabelece a sessão sem mostrar a senha. Soluções: CyberArk, BeyondTrust, Delinea, HashiCorp Boundary, Teleport.

2.4 Jump server multi-tenant (MSPs)

Centraliza acesso a múltiplos clientes. Cuidado: vira alvo dos sonhos. Idealmente, cada cliente deveria ter seu próprio jump segregado.

Parte 3: O que precisa ter dentro

3.1 Sistema operacional minimalista

Jump server não é estação de trabalho. Sem Office, sem navegador, sem aplicação, sem nada não-essencial.

# Ubuntu/Debian minimal
sudo apt install --no-install-recommends openssh-server ufw fail2ban auditd rsyslog
sudo apt purge -y telnetd rsh-server xinetd nis ypbind tftp tftpd talk talkd snmpd
sudo apt autoremove -y

sudo ss -tulpn
sudo systemctl list-units --type=service --state=running

Windows: use Server Core sempre que possível.

3.2 Apenas ferramentas necessárias

Linux jump tipicamente tem: OpenSSH, cliente RDP (xfreerdp), mysql/psql client, nmap, dig, traceroute, tcpdump, vim, tmux, ansible.

Windows jump tipicamente tem: mstsc, PuTTY, RSAT, PowerShell modules, SSMS.

O que NÃO deve ter: navegador, e-mail, Office, Adobe Reader, Java client, software pessoal, compiladores.

Regra: se não consegue justificar, não precisa estar ali.

3.3 Rede e segmentação

Entrada:

• Apenas porta de acesso (SSH, RDP ou HTTPS via ZTNA)
• Whitelist de IPs de origem
• Bloqueio geográfico

Saída:

• Apenas portas necessárias pros destinos permitidos
• Bloqueio de saída irrestrita pra internet — crítico

Se atacante comprometer o jump, primeira coisa será baixar ferramentas e conectar em C2. Bloqueando saída, você quebra a cadeia.

3.4 Hardening do SSH

# /etc/ssh/sshd_config

Port 52281
AddressFamily inet
ListenAddress 0.0.0.0

PermitRootLogin no
PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
KbdInteractiveAuthentication no
UsePAM yes
PubkeyAuthentication yes

AllowGroups jump-users

X11Forwarding no
AllowAgentForwarding no
AllowStreamLocalForwarding no
GatewayPorts no
PermitTunnel no
AllowTcpForwarding yes

MaxAuthTries 3
MaxSessions 4
MaxStartups 10:30:60
LoginGraceTime 30
ClientAliveInterval 300
ClientAliveCountMax 2

KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

LogLevel VERBOSE
SyslogFacility AUTH

Banner /etc/ssh/banner.txt

Banner legal:

*****************************************************************
                    ACESSO RESTRITO E MONITORADO

Este sistema é de uso exclusivo de pessoal autorizado.
Todas as atividades são registradas e monitoradas.
O uso não autorizado pode resultar em ações disciplinares
e/ou processo criminal.

Ao continuar, você concorda com essas condições.
*****************************************************************

3.5 Hardening Windows

• Server Core sem GUI
• NLA habilitado
• SMB v1 desabilitado
• Defender + Credential Guard + Device Guard
• AppLocker ou WDAC pra whitelist de execução
• LAPS pra rotação automática da senha local
• Audit Policies completas com forwarding pro SIEM
• PowerShell v2 desabilitado
• PowerShell Constrained Language Mode
• CIS Benchmark aplicado via GPO

Parte 4: Autenticação e autorização

4.1 MFA obrigatório

Sem exceção. Pra todo mundo. Sempre.

Linux com Google Authenticator:

sudo apt install libpam-google-authenticator
google-authenticator

# /etc/pam.d/sshd
auth required pam_google_authenticator.so

# /etc/ssh/sshd_config
ChallengeResponseAuthentication yes
KbdInteractiveAuthentication yes
UsePAM yes
AuthenticationMethods publickey,keyboard-interactive

A diretiva AuthenticationMethods publickey,keyboard-interactive força chave e TOTP.

Hardware tokens FIDO2 (mais seguro):

ssh-keygen -t ed25519-sk -f ~/.ssh/id_ed25519_sk

A chave privada fica dentro do token físico (YubiKey). Mesmo malware na máquina não consegue extrair.

4.2 Princípio do menor privilégio

• Grupos por função (dba-mysql, sysadmin-linux, support-tier1, vendor-acme)
• Sudo granular, nunca ALL
• Shell restrito quando possível (rbash, lshell)
• ACLs de filesystem

Exemplo /etc/sudoers.d/dba-mysql:

%dba-mysql ALL=(root) NOPASSWD: /bin/systemctl restart mysql
%dba-mysql ALL=(root) NOPASSWD: /bin/systemctl status mysql
%dba-mysql ALL=(root) NOPASSWD: /bin/journalctl -u mysql *
%dba-mysql ALL=(mysql) /usr/bin/mysql

4.3 Autenticação centralizada

Não use contas locais. Integre com AD/LDAP/Azure AD/Okta/Google Workspace.

Vantagens:

• Demitiu? Desativa no AD, acesso ao jump cai junto
• MFA centralizado
• Logs centralizados
• Sem contas órfãs

# Linux com AD via SSSD
sudo apt install sssd realmd adcli krb5-user samba-common-bin
sudo realm join dominio.empresa.local --user=admin

4.4 Acesso just-in-time (JIT)

Usuário não tem acesso permanente. Solicita, justifica, é aprovado, expira.

Soluções: CyberArk, Teleport, HashiCorp Boundary + Vault, Azure PIM, AWS Session Manager.

Versão simples com script:

#!/bin/bash
USER=$1
HOURS=$2

usermod -a -G jump-users $USER
echo "gpasswd -d $USER jump-users" | at now + $HOURS hours

Parte 5: Logs, gravação de sessão e auditoria

5.1 Logs detalhados

Linux com auditd:

sudo apt install auditd audispd-plugins

# /etc/audit/rules.d/jump-server.rules
-w /etc/passwd -p wa -k passwd_changes
-w /etc/shadow -p wa -k shadow_changes
-w /etc/sudoers -p wa -k sudoers_changes
-w /etc/sudoers.d/ -p wa -k sudoers_changes
-w /etc/ssh/sshd_config -p wa -k sshd_config

-a always,exit -F arch=b64 -S execve -F euid=0 -F auid>=1000 -F auid!=4294967295 -k privileged_exec
-a always,exit -F arch=b64 -S connect -k network_connect
-a always,exit -F arch=b64 -S execve -k command_exec

sudo systemctl enable auditd
sudo systemctl start auditd

Centralize tudo num SIEM (Wazuh, Graylog, ELK, Splunk). Logs locais não servem se atacante deletar.

5.2 Gravação de sessão

Feature mais poderosa de jump server bem feito. Gravar tudo que cada admin faz.

Por que é poderoso:

• Investigação forense: você assiste, não adivinha
• Compliance: PCI-DSS, ISO 27001, SOX, LGPD
• Treinamento: revisar más práticas
• Dissuasão: admins agem com mais cuidado quando sabem que estão sendo gravados
• Resolução de disputas: "eu não fiz isso" deixa de funcionar

tlog (Red Hat, open-source):

sudo apt install tlog

# /etc/tlog/tlog-rec-session.conf
{
    "shell": "/bin/bash",
    "notice": "\nATENÇÃO: Esta sessão está sendo gravada para auditoria.\n",
    "writer": "journal",
    "log": {
        "input": true,
        "output": true,
        "window": true
    }
}

sudo usermod -s /usr/bin/tlog-rec-session usuario

Reproduz com:

tlog-play -r journal -M TLOG_USER=usuario

Outras ferramentas:

• auditd com ttyaudit
• asciinema (cenários informais)
• CyberArk PAM (comercial)
• BeyondTrust
• Teleport (open-source com features comerciais)
• Apache Guacamole (gateway HTML5 com gravação em vídeo)

Importante:

1. Avise os usuários (banner explícito; em alguns países gravar sem aviso é ilegal)
2. Proteja as gravações (acesso restrito, criptografia)
3. Defina retenção (PCI-DSS pede 1 ano mínimo)
4. Cuidado com dados sensíveis nas gravações

5.3 Centralização de logs

Logs locais são logs descartáveis. Atacante apaga primeiro.

# /etc/rsyslog.d/forward.conf
*.* @@siem.empresa.local:6514  # TCP com TLS

Forward em tempo real, não em batch.

Parte 6: Patches e ciclo de vida

• Patches críticos: até 48 horas
• Patches normais: ciclo semanal/quinzenal
• Reboot: quando necessário
• Snapshot/backup: sempre antes
• Imagem dourada: mantenha hardened, reconstrua periodicamente

Reconstrução periódica: a cada 3-12 meses, destrua e reconstrua do zero via Ansible/Terraform/Packer. Elimina drift, lixo acumulado, qualquer backdoor não detectada. É como trocar a fechadura da porta da frente periodicamente.

Parte 7: Monitoramento e resposta

7.1 O que monitorar

• Múltiplas tentativas de login falhas
• Login em horário atípico
• Login de IP geográfico atípico
• Login de usuário que não usa o jump normalmente
• wget ou curl (tentativa de baixar payload)
• Execução em /tmp, /var/tmp, /dev/shm
• Modificação de /etc/passwd, /etc/shadow, /etc/ssh/sshd_config
• Criação de novos usuários
• Mudanças em sudoers
• Conexões de saída inesperadas
• Aumento súbito de tráfego
• Processos rodando como root sem motivo
• Escalada de privilégio sem aprovação

7.2 Alertas em tempo real

Notificação imediata (pager, SMS) pros eventos críticos. Não relatório no dia seguinte.

7.3 Resposta a incidentes

Runbook pronto para "jump server foi comprometido":

1. Isolamento imediato (derrubar da rede em 30 segundos)
2. Preservação de evidências (snapshot, dump de memória, cópia de logs)
3. Comunicação (quem avisar, em que ordem)
4. Investigação (quem, com quais ferramentas)
5. Recuperação (reconstruir do zero — NUNCA limpar in-place)
6. Postmortem e lições aprendidas

Parte 8: Alternativas modernas

8.1 ZTNA

Cloudflare One, Tailscale, Twingate, Teleport substituem jump server tradicional. Sem porta exposta, acesso por aplicação, controles centralizados.

8.2 PAM completo

CyberArk, BeyondTrust, Delinea, HashiCorp Boundary + Vault. Vão além: gerenciam senhas, rotacionam credenciais, just-in-time, gravam sessões, SIEM, dashboards de compliance.

8.3 Cloud-native

• AWS Systems Manager Session Manager
• Azure Bastion
• Google Cloud IAP

Cloud provider mantém o bastion por você.

8.4 Quando ainda usar jump tradicional

• On-premise sem cloud
• Soberania/compliance que exige sem dependência SaaS
• Budget zero
• Equipamentos legados
• Controle total da pilha exigido

Parte 9: Erros comuns

1. Jump com saída irrestrita pra internet — atacante baixa ferramentas e exfiltra
2. Mesmo jump pra "tudo" — suporte, DBA, dev, fornecedor compartilhando
3. Sem MFA porque "atrapalha o trabalho"
4. Compartilhamento de credenciais — quando der ruim, ninguém sabe quem foi
5. Patches atrasados — "tá funcionando, não vou mexer"
6. Logs locais sem centralização
7. Sem monitoramento ativo — logs centralizados mas ninguém olha
8. Jump em rede plana — comprometeu o jump, comprometeu tudo
9. Sem rotação de credenciais — senha que não muda há 5 anos
10. Sem revisão periódica — estagiário que saiu há 2 anos ainda no grupo

Checklist final

SISTEMA OPERACIONAL
[ ] Instalação minimal
[ ] Apenas ferramentas estritamente necessárias
[ ] Patches em dia
[ ] Snapshot/backup antes de alterações
[ ] Imagem dourada documentada
[ ] Reconstrução periódica programada

REDE
[ ] Segmento dedicado
[ ] Whitelist de IPs de origem
[ ] Bloqueio geográfico
[ ] Saída pra internet bloqueada
[ ] Saída pra interna restrita
[ ] DNS interno confiável

SSH
[ ] Porta não-padrão
[ ] PermitRootLogin no
[ ] PasswordAuthentication no
[ ] Chaves ED25519 ou FIDO2
[ ] AuthenticationMethods publickey,keyboard-interactive
[ ] AllowGroups restritivo
[ ] X11/Agent forwarding desabilitados
[ ] Limites configurados
[ ] Algoritmos modernos
[ ] Banner legal
[ ] fail2ban ativo

WINDOWS
[ ] Server Core
[ ] NLA habilitado
[ ] SMB v1 desabilitado
[ ] Defender + Credential Guard + Device Guard
[ ] AppLocker / WDAC
[ ] LAPS
[ ] PowerShell Constrained Language Mode
[ ] CIS Benchmark via GPO

AUTENTICAÇÃO
[ ] MFA obrigatório
[ ] Identity provider central
[ ] Sem contas locais (exceto break-glass)
[ ] Menor privilégio
[ ] Sudo granular
[ ] Just-in-time onde possível
[ ] Revisão trimestral

LOGS E AUDITORIA
[ ] auditd / Audit Policy
[ ] Forward em tempo real pro SIEM
[ ] Gravação de sessão
[ ] Retenção definida (≥1 ano)
[ ] Logs criptografados em trânsito
[ ] Acesso restrito

MONITORAMENTO
[ ] SIEM recebendo eventos
[ ] Regras de alerta
[ ] Notificação imediata
[ ] Dashboard de health
[ ] Drift detection

RESPOSTA A INCIDENTES
[ ] Runbook documentado
[ ] Procedimento de isolamento testado
[ ] Plano de reconstrução
[ ] Comunicação definida
[ ] Postmortem após incidente

GOVERNANÇA
[ ] Documentação atualizada
[ ] Inventário de quem tem acesso
[ ] Política aprovada formalmente
[ ] Revisões periódicas agendadas
[ ] Treinamento dos administradores

Considerações finais

Jump server parece simples até você começar a fazer direito. A versão "rápida" — VM com SSH aberto que todo mundo usa — leva meia hora. A versão "certa" — hardening completo, MFA, gravação de sessão, SIEM, segmentação, JIT — leva semanas e exige processos contínuos.

Mas a versão certa é a única que efetivamente protege. A versão rápida é só mais um servidor exposto com privilégios elevados.

Comece pelo essencial: hardening básico, MFA, logs centralizados, segmentação. Vá evoluindo. Cada controle reduz a superfície de ataque um pouco mais.

E monitore continuamente. O jump configurado perfeitamente hoje pode ter regressões amanhã quando alguém "só pra resolver um problema rápido" reabre uma porta. Sem monitoramento contínuo, hardening é foto, não filme.

O SentinelHub varre exatamente isso: monitora seus IPs públicos, identifica portas e serviços expostos (incluindo o jump server), alerta quando algo novo aparece, identifica versões vulneráveis, em português. Se seu jump reaparece com porta 22 padrão amanhã porque alguém esqueceu, você fica sabendo.

Achou útil? Compartilha com seu time de infra. Especialmente com aquele cara que falou "ah, jump server é firula".