VPS/VDS a partir de 0,36 €
RU EN DE TR ES PT

Primeiros 10 passos depois de comprar uma VPS: segurança

Tentativas de adivinhar a senha de um servidor novo começam poucos minutos depois que ele ganha um IP público. Abaixo estão dez passos que, em uma hora, fecham as brechas mais comuns: comandos para Ubuntu e Debian, as diferenças para AlmaLinux e Rocky Linux e as verificações sem as quais é fácil perder o acesso ao seu próprio servidor.

Atualizado 31.10.2026 · Encontre um VPS sob medida →

O servidor que você acabou de pagar já está visível para toda a internet. Bots varrem endereços em sequência e tentam entrar por SSH como root com senhas populares, então as primeiras tentativas alheias aparecem no log já na primeira hora. A boa notícia é que contra ataques em massa bastam medidas simples: login só por chave, portas desnecessárias fechadas e atualizações em dia. Tudo o que está abaixo se faz uma vez, em cerca de uma hora, de preferência antes de o site e os dados irem para o servidor.

Os comandos são para Ubuntu e Debian; as diferenças para AlmaLinux e Rocky Linux estão indicadas à parte. Execute-os como root ou via sudo.

Antes de começar: um acesso de reserva

Encontre no painel do provedor o console do servidor: ele se chama VNC, console KVM ou console de emergência e abre a tela do servidor direto no navegador. Por ele dá para entrar mesmo quando o SSH já não deixa. Enquanto você altera as configurações de login, mantenha aberta a sessão SSH atual e teste cada mudança numa segunda janela. Assim, um erro de configuração custa alguns minutos, e não uma reinstalação do sistema.

1. Atualize o sistema

Os provedores preparam as imagens de sistema com antecedência, e na hora da instalação muitas vezes já há uma dezena de correções de segurança pendentes.

apt update && apt full-upgrade -y     # Ubuntu, Debian
dnf upgrade -y                         # AlmaLinux, Rocky Linux

Se o kernel foi atualizado, reinicie o servidor. No Ubuntu e no Debian, quem avisa é o arquivo /var/run/reboot-required: se ele existe, é preciso reiniciar.

2. Crie um usuário separado

Trabalhar o tempo todo como root é incômodo e perigoso: qualquer erro de digitação é executado com plenos poderes, e o nome root todos os bots conhecem. Crie seu próprio usuário e dê a ele direito ao sudo:

adduser deploy
usermod -aG sudo deploy      # Ubuntu, Debian
usermod -aG wheel deploy     # AlmaLinux, Rocky Linux

No AlmaLinux e no Rocky Linux, o comando adduser não pergunta nada, e a senha é definida à parte: passwd deploy. Escolha qualquer nome, menos os óbvios admin e user.

3. Entre com uma chave SSH

Ao contrário de uma senha, uma chave não pode ser descoberta por tentativa e erro. Crie o par de chaves no seu computador, não no servidor, e copie a parte pública para o servidor:

ssh-keygen -t ed25519 -C "laptop"
ssh-copy-id deploy@IP_DO_SERVIDOR

No Windows 10 e 11, o cliente OpenSSH vem embutido, mas o ssh-copy-id não. Nesse caso, abra o arquivo .pub e cole a linha dele no servidor em /home/deploy/.ssh/authorized_keys; a pasta .ssh deve ter permissões 700, o arquivo 600, e o dono deve ser o próprio usuário. Muitos provedores permitem adicionar a chave já no pedido, e então ela já está no root.

Confirme numa nova janela que o login funciona sem senha e que o sudo está disponível: ssh deploy@IP_DO_SERVIDOR, depois sudo -v. Só então passe para o próximo passo.

4. Proíba o login por senha e como root

O mais prático é não editar o arquivo principal, e sim colocar suas configurações num arquivo separado em /etc/ssh/sshd_config.d/. Um detalhe importante: para cada parâmetro, o sshd usa o primeiro valor encontrado, e os arquivos dessa pasta são lidos em ordem alfabética. Nas imagens de nuvem do Ubuntu às vezes existe ali um arquivo 50-cloud-init.conf com a linha PasswordAuthentication yes, por isso dê ao seu arquivo um número menor que 50, por exemplo /etc/ssh/sshd_config.d/10-hardening.conf:

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no

Verifique a sintaxe e quais valores o servidor vai aplicar de fato, depois recarregue as configurações:

sshd -t && sshd -T | grep -Ei 'permitrootlogin|passwordauthentication'
systemctl reload ssh       # Ubuntu, Debian
systemctl reload sshd      # AlmaLinux, Rocky Linux

Não feche a sessão antiga até conseguir entrar, numa segunda janela, com seu usuário e a chave. A tentativa de entrar como root deve ser recusada.

Mudar a porta do SSH de 22 para outra não é obrigatório. Isso tira do log quase todas as tentativas automáticas de login, mas quem protege é a chave, não o número da porta. Se mesmo assim for mudar, abra primeiro a nova porta no firewall. No Ubuntu 22.10 e posteriores, o SSH é iniciado por um socket do systemd, e depois de alterar Port é preciso executar systemctl daemon-reload e systemctl restart ssh.socket; caso contrário, o servidor continua escutando na 22.

5. Ative o firewall

A regra é simples: todas as conexões de entrada são bloqueadas, exceto as que vão para os serviços que precisam ser visíveis de fora. Para um site, isso significa SSH, 80 e 443. No Ubuntu, o ufw é prático; no Debian, é preciso instalá-lo com apt install ufw:

ufw default deny incoming
ufw default allow outgoing
ufw allow OpenSSH
ufw allow 80,443/tcp
ufw enable
ufw status verbose

A ordem importa: primeiro libere o SSH, depois ative. No AlmaLinux e no Rocky Linux, o firewalld já está rodando e o SSH vem liberado por padrão; as portas web se abrem assim:

firewall-cmd --permanent --add-service=http --add-service=https
firewall-cmd --reload
firewall-cmd --list-all

Se o servidor for rodar Docker, leve em conta uma particularidade: ele escreve as próprias regras de iptables, e uma porta de contêiner publicada, por exemplo -p 3306:3306, fica acessível pela internet mesmo que não esteja liberada no ufw. Publique portas de serviço apenas no endereço local: -p 127.0.0.1:3306:3306. Planos para contêineres estão reunidos na seleção VPS para Docker.

Muitos provedores também oferecem no painel um firewall de rede na frente do servidor. Ele não substitui o do sistema, mas é útil como segunda camada. A proteção contra DDoS é um serviço à parte, no nível da rede do provedor; planos com ela estão na seleção VPS com proteção contra DDoS.

6. Instale o fail2ban

O fail2ban lê os logs e bloqueia por um tempo os endereços que erram o login repetidamente. Com login só por chave, ele serve principalmente para aliviar o log, mas também é útil para outros serviços: painel de controle, e-mail, página de login do site.

apt install fail2ban python3-systemd

Escreva suas configurações em /etc/fail2ban/jail.local, e não em jail.conf, que é sobrescrito nas atualizações:

[sshd]
enabled = true
backend = systemd
maxretry = 5
bantime = 1h

A linha backend = systemd é necessária no Debian 12 e posteriores: ali, por padrão, não existe o arquivo /var/log/auth.log, o registro de logins fica no journald, e sem essa linha o fail2ban não encontra o que ler. Sem configurações próprias, ele bloqueia o endereço por 10 minutos após 5 tentativas falhas em 10 minutos. Depois de editar, execute systemctl restart fail2ban e confira: fail2ban-client status sshd. No AlmaLinux e no Rocky Linux, o pacote vem do repositório EPEL: dnf install epel-release, depois dnf install fail2ban e systemctl enable --now fail2ban.

7. Ative as atualizações automáticas de segurança

A maioria das invasões de servidores explora vulnerabilidades para as quais a correção já saiu, só que não foi instalada. No Ubuntu, o pacote unattended-upgrades vem instalado e ativado por padrão; confira com o comando systemctl status unattended-upgrades. No Debian, ele é instalado e ativado assim:

apt install unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades

Por padrão, ele instala apenas atualizações de segurança. O kernel não é atualizado sem reinicialização: ou você reinicia o servidor por conta própria, pelo sinal do passo 1, ou ativa a reinicialização automática no período noturno com os parâmetros Unattended-Upgrade::Automatic-Reboot e Automatic-Reboot-Time em /etc/apt/apt.conf.d/50unattended-upgrades.

No AlmaLinux e no Rocky Linux, quem faz isso é o dnf-automatic. Instale o pacote com dnf install dnf-automatic, defina em /etc/dnf/automatic.conf upgrade_type = security e apply_updates = yes (sem isso, as atualizações só são baixadas) e ative o timer: systemctl enable --now dnf-automatic.timer.

8. Veja o que o servidor está escutando

As imagens dos provedores e os painéis de controle às vezes iniciam serviços que você não pediu. Veja todas as portas abertas:

ss -tulpn

Tudo o que escuta em 0.0.0.0 ou [::] fica acessível de fora, se o firewall deixar passar. Além do SSH e do servidor web, não deve haver serviços assim. Os bancos de dados MySQL, MariaDB, PostgreSQL e Redis devem escutar apenas em 127.0.0.1: nos pacotes do Debian e do Ubuntu isso já é o padrão, mas depois de uma instalação via Docker ou por um script de terceiros vale conferir. Pare os serviços desnecessários e tire-os da inicialização: systemctl disable --now nome_do_servico. Para ver o servidor com os olhos de um estranho, rode de outro computador: nmap -Pn IP_DO_SERVIDOR.

9. Horário, logs e monitoramento

Confira com o comando timedatectl se o relógio está sincronizado (linha System clock synchronized: yes). Um horário errado quebra a verificação de certificados, os códigos de uso único e a análise dos logs. Quem entrou no servidor e quando, mostram last -a | head e journalctl -u ssh --since today (no AlmaLinux o serviço se chama sshd).

Ligue um monitoramento externo de disponibilidade: há muitos serviços gratuitos que abrem o site a cada minuto e avisam você em caso de erro. Configure à parte um alerta de disco cheio: disco lotado é uma causa frequente de o site e o banco de dados pararem de funcionar durante a noite.

10. Crie um ponto de restauração e proteja o painel do provedor

Com o servidor configurado, tire um snapshot do disco no painel do provedor, se houver essa função: será possível voltar ao sistema limpo e configurado em minutos. O snapshot não substitui backups, porque fica guardado no mesmo provedor. Como montar backups de verdade fora do servidor está explicado no artigo Backups de VPS: estratégias e ferramentas.

Ative o login em dois fatores na área do cliente do provedor. Pela área do cliente dá para reinstalar o servidor, redefinir a senha do root ou abrir o console, e um SSH bem protegido não adianta nada se a conta for aberta com uma senha roubada. Guarde a chave SSH privada apenas nos seus dispositivos e proteja-a com uma frase-senha.

O que não fazer

  • Não desative o SELinux no AlmaLinux e no Rocky Linux no primeiro erro de acesso. Quase sempre basta o rótulo correto na pasta do site ou uma única permissão via setsebool.
  • Não use permissões 777 nas pastas do site. O dono dos arquivos deve ser o usuário do servidor web ou um usuário próprio do site; pastas com 755, arquivos com 644.
  • Não rode aplicações como root. Um bot, um site ou uma fila de tarefas se viram bem com um usuário próprio sem sudo.
  • Não deixe o painel de controle e o phpMyAdmin em endereços padrão abertos para todos. Permita o acesso a eles só a partir do seu IP ou por um túnel SSH.

O sistema para o novo servidor é fácil de escolher pelas seleções VPS com Ubuntu, VPS com Debian e VPS com AlmaLinux. Se o servidor é para um site que está numa hospedagem, o próximo passo está descrito no artigo Como migrar um site da hospedagem para uma VPS, e o que observar na escolha do próprio plano, no artigo Como escolher uma VPS: os 7 parâmetros que decidem.

Perguntas frequentes

É preciso mudar a porta do SSH para uma não padrão?

Não é obrigatório. Outra porta tira do log quase todas as tentativas automáticas de login, mas quem protege o servidor é o login por chave com senhas proibidas. Se for mudar a porta, abra-a primeiro no firewall e, no Ubuntu 22.10 e posteriores, depois da mudança execute systemctl daemon-reload e systemctl restart ssh.socket.

O que fazer se perdi o acesso ao servidor depois de configurar o SSH?

Abra o console do servidor no painel do provedor (VNC ou console de emergência), entre com a senha e corrija o arquivo em /etc/ssh/sshd_config.d/. Se não houver senha definida, a maioria dos provedores oferece um modo de recuperação, no qual o disco do servidor pode ser montado e corrigido.

O fail2ban basta se eu mantiver o login por senha?

Não. O fail2ban desacelera as tentativas vindas de um endereço, mas os bots chegam de milhares de endereços. A proteção confiável é o login por chave com PasswordAuthentication no; o fail2ban é uma camada extra.

Preciso de firewall no sistema se o provedor tem um de rede?

Sim. O firewall de rede do provedor é configurado no painel e nem todos oferecem, enquanto o ufw ou o firewalld do sistema roda no próprio servidor e vai junto com ele. O melhor é usar os dois.

Com que frequência atualizar uma VPS?

As atualizações de segurança devem ser instaladas automaticamente todos os dias, via unattended-upgrades ou dnf-automatic. As atualizações que mudam versões de programas e a reinicialização para um novo kernel são mais práticas de fazer à mão a cada uma ou duas semanas, depois de um backup recente.

Preciso de antivírus num servidor Linux?

Para o servidor em si, importam mais as atualizações, o login por chave e as portas fechadas. Um scanner como o ClamAV faz sentido se os usuários enviam ao site arquivos que depois outras pessoas baixam.

Planos sobre o tema

VPS com Rocky LinuxRanking de hospedagem VPS 2026

Mais no guia

  • Docker em VPS: por onde começarCom o Docker, você roda no servidor um bot, um site, um banco de dados e o monitoramento sem que um atrapalhe o outro, e mudar para outra VPS se resume a copiar alguns arquivos e os dados. A instalação leva cinco minutos; os problemas de verdade aparecem depois: portas do banco abertas para a internet, logs de dezenas de gigabytes e dados que sumiram junto com o contêiner. Veja como evitá-los desde o início.
  • Como migrar um site da hospedagem para uma VPSA migração em si leva umas duas horas, e os erros costumam acontecer em volta dela: uma tarefa do cron esquecida, regras do .htaccess que o nginx não lê, um registro AAAA com o endereço antigo ou um e-mail que sumiu junto com a troca de IP. Abaixo, a ordem dos passos com comandos e verificações para um site em PHP e MySQL.
  • Painéis de controle de servidor: ISPmanager, FASTPANEL, aaPanelO painel transforma a VPS em algo parecido com o painel da hospedagem compartilhada: sites, bancos de dados, e-mail e certificados são criados com o mouse, e não editando arquivos de configuração. Os três painéis mais instalados em servidores russos e em servidores baratos no exterior são o ISPmanager, o FASTPANEL e o aaPanel. Eles diferem no preço, na memória que exigem e no quanto tomam conta do servidor.
  • VPS Windows para 1CUm servidor alugado para o 1C livra a empresa daquele computador debaixo da mesa do escritório que ninguém atualiza nem copia. Mas o 1C em VPS tem particularidades: a licença de software fica vinculada aos parâmetros da máquina virtual, os usuários precisam de licenças tanto do 1C quanto do Windows, e a frequência dos núcleos importa mais que a quantidade. Veja como montar um servidor para o 1C numa empresa pequena.
  • VPS Windows: licenciamento, RDP e acesso seguroUm servidor Windows custa mais que um Linux não só por causa da memória: o preço inclui uma licença, e a forma como ela é contratada define se o uso está regular e quantas pessoas podem se conectar. Uma porta RDP exposta também é o caminho mais comum para invadir esses servidores. Veja os dois temas.
  • Quando migrar da hospedagem compartilhada para uma VPSUma VPS não deixa o site mais rápido por si só: ela dá recursos e liberdade e, junto com eles, o trabalho de administrar um servidor. Veja como saber que a hospedagem ficou pequena, quando o problema se resolve sem mudança e como migrar um site sem que os visitantes percebam.
  • Backups de VPS: estratégias e ferramentasNuma VPS, os backups são responsabilidade sua, mesmo que o plano diga «backups incluídos». Vamos ver o que exatamente copiar, por que o snapshot do provedor não basta, como configurar o restic ou o BorgBackup em meia hora e como ter certeza de que dá mesmo para restaurar a partir da cópia.
  • Como escolher o país do servidorColoque o servidor onde estão os seus visitantes. Para um público no Brasil, São Paulo dá o menor ping; Miami e a costa leste dos EUA são a alternativa comum, e a Europa fica bem mais longe. A LGPD não obriga a manter os dados no Brasil, mas a transferência para fora precisa de base legal. O preço quase não decide: no mesmo provedor, Europa e EUA costumam custar o mesmo, e só Ásia e Austrália saem bem mais caras.
  • Cobrança por hora: quando ela compensaA cobrança por hora compensa se você precisa do servidor menos de três semanas por mês: para um teste, um build, uma tarefa pesada pontual. Na maioria dos provedores, a hora custa exatamente o preço mensal dividido por 730 horas, então num mês cheio você quase não paga a mais. O custo extra está em outro lugar: os planos com cobrança por hora são, em média, mais caros, e para um servidor que roda o ano inteiro o plano mensal ou anual costuma sair mais barato.
  • Quanta memória e quantos núcleos um site precisaA maioria dos sites roda bem com 2 GB de memória e um ou dois núcleos; uma loja com milhares de produtos precisa de 4 GB e dois núcleos. Memória importa mais que núcleos: quando ela falta, o site fica lento ou cai, e um núcleo a mais sem memória quase não ajuda. Abaixo mostro como calcular a memória para o seu site e como descobrir quanto ele gasta de verdade.
  • KVM ou OpenVZ: o que escolherEm 2026 quase sempre vale escolher KVM: ele custa no máximo uns dois dólares por mês a mais que o OpenVZ, mas nele tudo funciona, do Docker ao Windows. O OpenVZ só se justifica num caso estreito, e abaixo você vê qual; no final estão os comandos para conferir o seu servidor em um minuto.
  • NVMe ou SSD: faz diferença para um site?Para um site pequeno, a diferença entre NVMe e SSD é quase imperceptível: as páginas saem da memória, não do disco. Ela aparece em lojas virtuais e sites com banco de dados grande. E no mesmo provedor o NVMe custa só uns US$ 0,50–1 por mês a mais, às vezes até menos que o SSD, então o que decide normalmente não é o tipo de disco, e sim o tamanho e como o provedor o limitou.
  • O que é VPS, explicado de forma simplesUma VPS é um pedaço de um servidor físico potente que você aluga e que se comporta como um computador independente: com sistema próprio, endereço IP próprio e acesso total. Veja como ela se diferencia da hospedagem, para quem serve, quanto custa e o que conferir logo depois da contratação.
  • VPS para bot do Telegram: do que o bot precisa e como escolher o planoUm bot com menu e alguns comandos roda bem no servidor mais barato, enquanto um bot com disparos, arquivos e banco de dados esbarra em limites totalmente diferentes. Veja o que um bot realmente consome, quais limites do Telegram definem a escolha do servidor e como não pagar a mais.
  • Como testar ping e velocidade de uma VPS antes de pagarOs números de um plano não dizem qual será a latência até seus usuários nem a velocidade real do disco. Quase tudo pode ser medido antes de pagar, e o resto na primeira hora depois de ligar o servidor. Veja as ferramentas e como interpretar os resultados.
  • Rede corporativa em VPS: acesso remoto ao escritórioUm servidor alugado pode virar o centro da rede privada de uma empresa: funcionários remotos e filiais se conectam por ele ao ERP, ao servidor de arquivos, ao CRM e ao Git. Veja os esquemas mais comuns, os protocolos, os requisitos do servidor e o básico de segurança.
  • Como escolher uma VPS: os 7 parâmetros que decidemDois planos com os mesmos «2 núcleos, 4 GB, 50 GB» podem ter velocidade várias vezes diferente e custar o dobro um ano depois. Veja o que existe por trás de cada linha de um plano VPS e o que conferir antes de pagar.
  • VPS ou VDS: existe diferença e o que realmente importaNa maioria dos mercados, VPS e VDS significam a mesma coisa: um servidor virtual. A diferença que de fato afeta o seu trabalho não está no nome, e sim no tipo de virtualização e em os recursos serem garantidos ou não.