Proxmox blindado com MFA
📋 Índice
- Usuários, realms e RBAC
- MFA: o jeito nativo do Proxmox
- Firewall em três camadas
- Habilitando o firewall
- Regras no Datacenter
- Security Groups: regras reutilizáveis
- Firewall na VM: isolamento de workloads
- Let's Encrypt: HTTPS de verdade
- SSH: fora do básico
- Atualizações e patches
- Logs de auditoria
- Isolamento de rede de gerenciamento
- Revisão rápida: checklist de hardening
- Conclusão
Uma instalação padrão do Proxmox fica acessível na porta 8006 com certificado autoassinado, autenticação só por senha, e root com acesso total. Funciona para homelab isolado, mas qualquer coisa exposta para a internet ou com mais de uma pessoa usando precisa de atenção.
A boa notícia: o Proxmox tem uma stack de segurança bastante completa já embutida. MFA via UI, firewall em três camadas, Let's Encrypt nativo, RBAC com roles granulares. Não precisa de nada externo para a maioria dos cenários.
💡 Esse post assume que você já tem o Proxmox instalado e, se tiver cluster, que ele está configurado conforme o Quando um nó não é suficiente.
Usuários, realms e RBAC
O Proxmox tem um sistema de controle de acesso próprio com quatro conceitos principais: usuários, realms (fontes de autenticação), roles e permissões.
Realms de autenticação
Por padrão o Proxmox tem dois:
pve — usuários locais gerenciados pelo próprio Proxmox. O root@pam é especial: usa o PAM do Linux (mesma senha do root do sistema). Os outros usuários @pve têm autenticação gerenciada internamente.
pam — qualquer usuário Unix do sistema pode logar com usuario@pam. Útil para integrar com usuários existentes no SO.
Você pode adicionar outros realms:
# Integrar com Active Directory / LDAP
pveum realm add minha-empresa \
--type ldap \
--server ldap.empresa.com \
--base-dn "dc=empresa,dc=com" \
--user-attr sAMAccountName \
--port 389
# Ou com OpenLDAP
pveum realm add openldap \
--type ldap \
--server ldap.interno \
--base-dn "ou=users,dc=lab,dc=local" \
--user-attr uid
Criando usuários
# Criar usuário local
pveum user add joao@pve --comment "João da equipe de infra" --email joao@empresa.com
# Definir senha
pveum passwd joao@pve
# Listar usuários
pveum user list
Via UI: Datacenter → Permissions → Users → Add.
Roles disponíveis
O Proxmox vem com roles pré-definidas. As mais usadas:
| Role | O que pode fazer |
|---|---|
Administrator |
Tudo, exceto gerenciar permissões de outros admins |
PVEAdmin |
Gerenciar VMs, storage e rede, sem configurações de sistema |
PVEVMAdmin |
Criar, modificar e deletar VMs |
PVEVMUser |
Iniciar, parar e acessar console de VMs existentes |
PVEAuditor |
Visualizar tudo, sem modificar nada |
PVEDatastoreAdmin |
Gerenciar storage e backups |
NoAccess |
Nenhum acesso (útil para revogar acesso sem deletar o usuário) |
# Criar role customizada
pveum roleadd OperadorNOC \
--privs "VM.PowerMgmt,VM.Console,VM.Monitor"
# Listar privilégios disponíveis
pveum role list --privs
Atribuindo permissões
Permissões no Proxmox são atribuídas em paths da árvore de recursos:
# Dar acesso de admin ao joao em tudo
pveum aclmod / --user joao@pve --role Administrator
# Acesso só em VMs específicas (pelo ID)
pveum aclmod /vms/100 --user joao@pve --role PVEVMAdmin
pveum aclmod /vms/101 --user joao@pve --role PVEVMAdmin
# Acesso a um pool inteiro
pveum aclmod /pool/producao --user joao@pve --role PVEVMUser
# Acesso a um nó específico
pveum aclmod /nodes/pve2 --user joao@pve --role PVEAdmin
# Ver permissões atuais
pveum acl list
💡 Permissões são herdadas: dar acesso em
/vale para tudo abaixo. Dar em/vmsvale só para VMs. Use o menor escopo possível para cada usuário.
MFA: o jeito nativo do Proxmox
Muitos tutoriais ensinam a instalar libpam-google-authenticator e editar /etc/pam.d/common-auth. Isso funciona, mas é a abordagem manual do Linux. O Proxmox tem MFA embutido na UI, gerenciado por ele mesmo, sem tocar no PAM.
Dois métodos suportados:
TOTP (Time-based One-Time Password) — o QR code que você escaneia no Google Authenticator, Aegis, Bitwarden, etc. Gera um código de 6 dígitos que muda a cada 30 segundos.
WebAuthn — chaves de hardware (YubiKey, token FIDO2) ou biometria via browser (Face ID, Windows Hello). Mais seguro que TOTP porque não tem código para interceptar.
Configurando TOTP
# Habilitar TOTP para um usuário via CLI
pveum user token add joao@pve totp \
--expire 0 \
--privsep 0
# Mas é mais prático fazer pela UI:
# Datacenter → Permissions → Users → joao@pve → Edit → TOTP
Via UI é mais simples: Datacenter → Permissions → Two Factor (ou no perfil do usuário). O Proxmox gera o QR code para escanear no autenticador.
Para forçar MFA para todos os usuários de um realm:
# Tornar MFA obrigatório no realm
pveum realm modify pve --tfa type=totp
# Para um usuário específico obrigatório
pveum user modify joao@pve --tfa type=totp
Configurando WebAuthn
WebAuthn requer que o Proxmox tenha um domínio configurado (não funciona só com IP):
# Configurar o relying party (domínio do Proxmox)
# Datacenter → Options → WebAuthn Settings
pvesh set /cluster/options \
--webauthn-rp-id proxmox.empresa.com \
--webauthn-origin https://proxmox.empresa.com:8006
# O usuário cadastra o token na UI:
# User → Two Factor → Add WebAuthn
⚠️ Não perca acesso ao root. Se configurar MFA obrigatório e perder o dispositivo autenticador, você vai precisar de acesso físico ao servidor para recuperar. Mantenha um método de recovery (chave de backup TOTP, segundo dispositivo WebAuthn, ou acesso via console físico documentado).
Firewall em três camadas
O Proxmox tem um firewall com três níveis independentes: Datacenter, Nó e VM/Container. As regras são aplicadas de fora para dentro: Datacenter define o baseline, nó pode restringir mais, VM pode restringir ainda mais.
Habilitando o firewall
# Habilitar no Datacenter (aplica para todos os nós)
pvesh set /cluster/firewall/options --enable 1
# Habilitar em um nó específico
pvesh set /nodes/pve/firewall/options --enable 1
# Habilitar em uma VM
pvesh set /nodes/pve/qemu/100/firewall/options --enable 1
Via UI: Datacenter → Firewall → Options → Enable.
Regras no Datacenter
# Listar regras existentes
pvesh get /cluster/firewall/rules
# Adicionar regra: permitir SSH só de IPs internos
pvesh create /cluster/firewall/rules \
--action ACCEPT \
--type in \
--proto tcp \
--dport 22 \
--source 192.168.1.0/24 \
--comment "SSH somente da rede interna"
# Bloquear acesso à UI de IPs externos
pvesh create /cluster/firewall/rules \
--action DROP \
--type in \
--proto tcp \
--dport 8006 \
--source "!192.168.0.0/16" \
--comment "Bloquear UI de fora da rede"
Security Groups: regras reutilizáveis
Em vez de repetir as mesmas regras em várias VMs, crie um security group:
# Criar security group para servidores web
pvesh create /cluster/firewall/groups \
--group web-servers \
--comment "Regras para servidores web"
# Adicionar regras ao grupo
pvesh create /cluster/firewall/groups/web-servers \
--action ACCEPT --type in --proto tcp --dport 80
pvesh create /cluster/firewall/groups/web-servers \
--action ACCEPT --type in --proto tcp --dport 443
# Aplicar o grupo numa VM
pvesh create /nodes/pve/qemu/100/firewall/rules \
--action GROUP \
--type in \
--macro web-servers
Firewall na VM: isolamento de workloads
Para VMs que precisam de isolamento maior:
# Habilitar firewall na interface de rede da VM
# qm set 100 --net0 virtio,bridge=vmbr0,firewall=1
# Regras específicas da VM (port 5432 postgres, só da rede de app)
pvesh create /nodes/pve/qemu/100/firewall/rules \
--action ACCEPT \
--type in \
--proto tcp \
--dport 5432 \
--source 10.10.1.0/24
# Bloquear todo o resto (política padrão)
pvesh set /nodes/pve/qemu/100/firewall/options \
--policy-in DROP
Let's Encrypt: HTTPS de verdade
O certificado autoassinado padrão faz o browser reclamar em todo acesso. O Proxmox tem integração nativa com Let's Encrypt via ACME:
Domínio público com DNS challenge
# Configurar conta ACME (uma vez por cluster)
pvesh create /cluster/acme/account/default \
--contact email@empresa.com \
--tos-url https://letsencrypt.org/documents/LE-SA-v1.3-September-21-2022.pdf
# Configurar plugin DNS (exemplo com Cloudflare)
pvesh create /cluster/acme/plugins \
--id cloudflare \
--api cf \
--data "CF_Token=seu-token-aqui"
# Adicionar domínio ao nó
pvesh create /nodes/pve/acme/domains \
--domain proxmox.empresa.com \
--plugin cloudflare
# Emitir o certificado
pvesh create /nodes/pve/acme/certificate
# Renovação automática já está configurada pelo Proxmox
Rede interna com validação HTTP
Para homelabs onde o Proxmox está acessível externamente via HTTP:
# Plugin standalone (Proxmox expõe porta 80 temporariamente para validação)
pvesh create /cluster/acme/plugins \
--id standalone \
--api standalone
pvesh create /nodes/pve/acme/domains \
--domain proxmox.meudominio.com \
--plugin standalone
pvesh create /nodes/pve/acme/certificate
⚠️ Para validação HTTP o Proxmox precisa estar acessível na porta 80 a partir dos servidores do Let's Encrypt. Se estiver atrás de NAT, configure port forward temporário ou use DNS challenge.
SSH: fora do básico
O SSH do host Proxmox merece atenção separada porque é o acesso mais direto ao sistema:
# /etc/ssh/sshd_config.d/proxmox-hardening.conf
# Desabilitar login por senha (só chave)
PasswordAuthentication no
ChallengeResponseAuthentication no
# Desabilitar root via SSH (usa pvesh ou sudo)
PermitRootLogin no
# Limitar a usuários específicos
AllowUsers joao@192.168.1.0/24 maria
# Porta não padrão (obscuridade não é segurança, mas reduz ruído nos logs)
Port 2222
# Timeout de sessão inativa
ClientAliveInterval 300
ClientAliveCountMax 2
# Recarregar
systemctl reload sshd
# Adicionar chave pública para o usuário
mkdir -p /home/joao/.ssh
echo "ssh-ed25519 AAAA... joao@empresa" >> /home/joao/.ssh/authorized_keys
chmod 700 /home/joao/.ssh
chmod 600 /home/joao/.ssh/authorized_keys
chown -R joao:joao /home/joao/.ssh
fail2ban para SSH e UI
apt install fail2ban
# /etc/fail2ban/jail.d/proxmox.conf
cat > /etc/fail2ban/jail.d/proxmox.conf << 'EOF'
[proxmox-web]
enabled = true
port = 8006
filter = proxmox
logpath = /var/log/daemon.log
maxretry = 5
bantime = 3600
findtime = 600
[sshd]
enabled = true
maxretry = 3
bantime = 86400
findtime = 600
EOF
# Filtro para a UI do Proxmox
cat > /etc/fail2ban/filter.d/proxmox.conf << 'EOF'
[Definition]
failregex = pvedaemon\[.*\]: authentication failure; rhost=<HOST> user=.* msg=.*
ignoreregex =
EOF
systemctl enable --now fail2ban
fail2ban-client status proxmox-web
Atualizações e patches
O maior vetor de ataque em qualquer sistema é software desatualizado. No Proxmox:
# Atualizar o sistema
apt update && apt dist-upgrade
# Ver quais pacotes têm atualizações de segurança pendentes
apt list --upgradable 2>/dev/null | grep -i security
# Configurar notificação de atualizações disponíveis
# (Proxmox 8.1+) Datacenter → Notifications → Add Target → Email
Para ambientes com subscrição enterprise, o repositório enterprise recebe atualizações mais testadas antes do repositório community:
# /etc/apt/sources.list.d/pve-enterprise.list
deb https://enterprise.proxmox.com/debian/pve bookworm pve-enterprise
# Autenticar com a chave de subscrição (gerada no portal Proxmox)
💡 Rotina de manutenção: atualizar semanalmente é razoável para homelab. Para produção, aplicar patches de segurança críticos em até 72h e atualizações regulares mensalmente, com janela de manutenção definida e backup antes.
Logs de auditoria
# Logs da UI e autenticação
journalctl -u pvedaemon --since "24 hours ago" | grep -i "auth\|login\|fail"
# Todos os eventos do cluster
journalctl -u pve-cluster -f
# Tarefas executadas (backup, migration, etc.) ficam visíveis na UI
# Datacenter → Tasks (ou Node → Tasks)
# Via CLI
pvesh get /nodes/pve/tasks --limit 50
# Log de uma tarefa específica
pvesh get /nodes/pve/tasks/UPID:pve:...:vzdump:/tasklog
Para enviar logs para um SIEM ou servidor centralizado:
# /etc/rsyslog.d/proxmox-remote.conf
*.* action(type="omfwd" target="siem.empresa.com" port="514" protocol="tcp")
systemctl restart rsyslog
Isolamento de rede de gerenciamento
Uma prática que faz diferença real: isolar a interface de gerenciamento do Proxmox do restante da rede:
# /etc/network/interfaces
# Interface de gerenciamento (só para acesso à UI e SSH)
auto eth0
iface eth0 inet static
address 10.0.0.10/24
gateway 10.0.0.1
# Interface para tráfego de VMs
auto vmbr0
iface vmbr0 inet manual
bridge-ports eth1
bridge-stp off
bridge-fd 0
Com essa separação, comprometer uma VM não dá acesso direto à interface de gerenciamento do Proxmox. Acesso à UI e SSH só é possível pela rede de management (que pode ter ACLs no switch).
Revisão rápida: checklist de hardening
Antes de expor qualquer instalação Proxmox para uso real:
- MFA habilitado para todos os usuários com acesso à UI
- Usuários com roles mínimas necessárias (sem
Administratorpara quem não precisa) - Firewall habilitado com política padrão
DROPpara entrada - Acesso à porta 8006 restrito por IP ou VPN
- Certificado Let's Encrypt configurado
- Login por senha desabilitado no SSH
- fail2ban rodando para SSH e UI
- Repositório de updates configurado e sistema atualizado
- Backups configurados e testados (PBS ou vzdump)
- Interface de gerenciamento isolada da rede de VMs
Conclusão
Segurança no Proxmox não precisa de ferramentas externas para o básico. MFA, firewall multicamada, RBAC e Let's Encrypt estão todos disponíveis de fábrica e bem integrados. O que precisa é de atenção na configurção inicial, porque os padrões de instalação são conservadores por compatibilidade, não por segurança máxima.
Com isso, a série de posts sobre KVM e Proxmox está completa: da fundação em KVM mora no seu kernel até cluster com alta disponibilidade em Quando um nó não é suficiente, passando por tudo no meio.