Boas práticas
Segurança não é só "evitar invasão": é evitar grief, reduzir abuso, prevenir perda de mundo e garantir recuperação rápida. Use este checklist como padrão.
1) Identidade e autenticação do servidor
✅ online-mode
Recomendado: online-mode=true. Isso força validação de conta pela Mojang/Microsoft, reduzindo spoof de nick e várias formas de abuso.
Atenção: online-mode=false só deveria existir em cenários bem específicos (ex.: redes offline/lan, ambientes controlados) e aumenta muito o risco.
2) Acesso administrativo (OP, console e permissões)
✅ OP e permissões mínimas
Regra de ouro: dê o mínimo necessário. Evite OP permanente em contas pessoais.
Prefira permissões por grupo (ex.: staff/moderador/admin) e logs do que cada um "com OP".
✅ Whitelist e controle de entrada
- Servidores privados: use whitelist=true.
- Servidores públicos: considere whitelist apenas em fases iniciais (beta), eventos ou comunidade fechada.
✅ Acesso ao painel/host
- Proteja painel com senha forte e 2FA.
- Use usuários separados por função.
3) Proteção contra grief e abuso
✅ Anti-grief (servidores públicos)
- Proteção de terreno/claims (para evitar que qualquer um quebre tudo).
- Rollback / log de blocos (para reverter desastres rápido).
- Limites e regras para TNT, fogo, lava, explosões.
- Proteção de spawn e áreas públicas.
- Rate limit / anti-spam (chat, comandos, conexões).
✅ Anti-cheat (se aplicável)
- Use anti-cheat confiável e mantenha atualizado.
- Combine com verificação manual (staff), logs e alertas.
- Punições graduais (warn → mute → ban).
- Evite depender de "um plugin mágico": ajuste e monitore.
4) Backups e restauração (o que separa amador de profissional)
✅ Política de backup (mínimo recomendado)
- Automático (sem depender de alguém lembrar).
- Frequente: a cada 6h/12h (ou mais em servidores grandes).
- Retenção: 7–30 dias (depende do tamanho).
- Off-site: pelo menos uma cópia fora do servidor (S3, outro host, drive, etc.).
✅ Teste de restauração
Backup que nunca foi testado não é backup.
- Restaurar mundo em um ambiente de staging.
- Verificar spawn, regiões, inventários, plugins essenciais.
- Documentar o procedimento de restauração passo a passo.
✅ Boas práticas extras
- Backup do mundo + configs + plugins + permissões + banco de dados (se existir).
- Se usar MySQL/MariaDB: inclua dump consistente (e não só "copiar pasta").
5) Contas, senhas
✅ Senhas
- Senha forte e única por serviço (painel, host, banco, etc.).
✅ Contas separadas
Não use "conta compartilhada" tipo admin/admin. Cada pessoa com seu login.
6) Atualizações e cadeia de supply (plugins/mods)
✅ Atualize com critério
- Mantenha servidor e plugins atualizados, mas teste antes em ambiente de staging.
- Leia changelogs em updates críticos.
- Plugins abandonados e desatualizados são um risco recorrente.
✅ Fonte confiável
- Baixe plugins/mods de fontes oficiais/conhecidas.
- Evite builds "reupados" e links aleatórios.
- Mantenha uma lista de plugins permitidos e versão aprovada.
7) Rede e proteção contra ataques (DDoS / firewall)
✅ Firewall e portas
- Exponha só o necessário (porta do servidor e painel com restrição).
- Painel, banco de dados e backends não devem ficar abertos para o mundo.
✅ DDoS
- Considere proteção DDoS do provedor.
- Use proxy/rede com mitigação quando a exposição for alta (servidor público).
Servidor público vs privado (o que muda)
✅ Servidor privado (amigos / comunidade fechada)
- whitelist=true
- permissões simples e poucos admins
- backups automáticos
- menos necessidade de anti-cheat, mas rollback/log de blocos ajuda
- regras claras e combinadas
Foco: estabilidade e recuperação rápida.
✅ Servidor público (aberto / divulgação / muitos jogadores)
- online-mode=true
- controle forte de permissões (nada de OP "por conveniência")
- claims/proteção de terreno + rollback
- anti-spam / rate limit / moderação ativa
- logs e auditoria de ações staff
- mitigação DDoS e proteção de painel/infra
Foco: reduzir abuso e responder rápido a incidentes.