VPS é seguro? O que você realmente controla

A hospedagem em VPS é segura? A resposta curta

Sim. A hospedagem em VPS é segura para o trabalho para o qual a maioria das pessoas a contrata e representa uma melhoria real em relação à hospedagem partilhada. Um VPS KVM (servidor privado virtual) é uma máquina virtual com o seu próprio kernel, a sua própria memória, o seu próprio disco e as suas próprias contas de utilizador. O hypervisor que a executa impede os outros clientes de acederem a esses quatro recursos. A pessoa que aluga o servidor ao lado do seu na mesma máquina física não consegue ler os seus ficheiros, listar os seus processos, iniciar sessão no seu servidor nem ver o seu tráfego de rede. Os planos baseados em contentores oferecem um isolamento mais fraco, explicado abaixo.

A resposta completa tem duas partes. O fornecedor é responsável pelo hardware e pelo hypervisor. Você é responsável por tudo dentro da sua máquina virtual, e é aí que começa quase todos os incidentes reais. Os servidores são normalmente comprometidos através de uma porta aberta, de uma palavra-passe SSH fraca, de um pacote que ninguém atualizou ou de um segredo num ficheiro que foi publicado. Muito raramente são comprometidos através do hypervisor.

O que o hipervisor realmente separa

Um hipervisor é o software que executa máquinas virtuais num único host físico. Num VPS KVM (KVM significa kernel based virtual machine, o padrão em hosts Linux), o seu servidor é uma máquina virtual completa. Arranca com o seu próprio kernel. O host atribui-lhe uma região fixa da memória física, e a unidade de gestão de memória do processador recusa qualquer acesso fora dessa região. Por isso, o código executado noutro guest não consegue endereçar a sua RAM. Não existe um sistema de ficheiros partilhado nem uma tabela de utilizadores partilhada. Por isso, as permissões de ficheiros no servidor de outro cliente não têm qualquer efeito no seu.

O alojamento partilhado funciona de forma diferente. Muitos sites ficam no mesmo sistema operativo, sob o mesmo servidor web e a mesma instalação do PHP, como contas de utilizador comuns. A única fronteira são as permissões de ficheiros. Um erro de permissões ou um plugin vulnerável executado por um utilizador que pode ler dados em excesso pode, por isso, aceder aos ficheiros de outra conta. É esta lacuna que a migração do alojamento partilhado para um VPS elimina.

Confirme o que está a comprar, porque nem todos os planos vendidos como VPS são máquinas virtuais. Os planos baseados em contentores (OpenVZ, LXC, Virtuozzo) partilham o kernel do host e separam os clientes com namespaces e cgroups, em vez de usarem virtualização de hardware. Essa fronteira é mais fraca, porque um erro no kernel do host também é um erro no kernel do seu servidor. Também não pode carregar módulos do kernel nesses planos, o que impede a utilização de alguns softwares. KVM é a opção predefinida mais segura. Pergunte qual vai receber antes de pagar.

O que um vizinho ruidoso pode fazer consigo

Partilhar um host físico reduz a velocidade, e esse é o único custo. Os guests na mesma máquina partilham o CPU físico e os discos. Quando o CPU está ocupado com outro cliente, o seu CPU virtual espera. O Linux regista essa espera como tempo de steal: o campo %st em top e vmstat. Um tempo de steal acima de alguns por cento durante várias horas indica que o host está sobrealocado. Isso não significa que alguém esteja a ler os seus dados. A solução é escolher outro plano ou outro fornecedor. Antes de decidir, pode medir o CPU e o disco que realmente recebeu.

Há um efeito entre clientes que vale a pena conhecer, mas não é uma falha de segurança. Se enviar email a partir do seu VPS, o seu endereço IP fica num intervalo que também é usado por outros clientes. Um vizinho que envie spam pode fazer com que parte desse intervalo seja incluída numa blocklist. Como resultado, o seu email pode chegar às pastas de spam por uma razão que não causou. Os fornecedores que controlam o abuso mantêm intervalos mais limpos. Pergunte sobre isso se o email for importante para si.

O que um vizinho hostil não pode fazer e o caso raro em que pode

Um cliente no mesmo host não tem acesso aos seus ficheiros. Não pode ver os seus processos, montar o seu disco nem abrir uma shell no seu servidor, porque nada disso existe dentro da máquina virtual desse cliente. Há uma exceção importante: trate qualquer rede privada do fornecedor como uma rede partilhada com desconhecidos e encripte o que passar por ela, em vez de assumir que está invisível.

As fugas do hypervisor são reais. Um erro na camada de virtualização pode permitir que código dentro de um guest aceda ao host e, a partir do host, a todos os guests nele alojados. Estes erros são encontrados, publicados com um identificador CVE (common vulnerabilities and exposures) e corrigidos. Os fornecedores de alojamento aplicam estas correções rapidamente, porque todo o negócio depende dessa camada. Para explorar uma fuga, é necessário um exploit funcional para uma versão específica do hypervisor. É dispendioso gastar esse recurso numa conta de alojamento pequena.

Os ataques por canais laterais entre guests também são reais. Incluem a família Spectre e Meltdown e exploram caches partilhadas do processador para inferir pequenas quantidades de dados através de uma fronteira. As atualizações de microcode e do kernel reduzem este risco, e as taxas de fuga descritas nos trabalhos publicados são muito baixas. Os casos publicados são demonstrações de investigação, não ataques em massa. O risco não é zero. Simplesmente não está perto do topo da lista de problemas que o irão afetar.

Onde termina o trabalho do provedor e começa o seu

O provedor é responsável pelo edifício, pelo hardware do host, pelo hypervisor e pelo kernel do host, pela rede física e pelo painel de controlo que pode iniciar, parar, reconstruir e criar snapshots do seu servidor. Se algum desses componentes falhar, cabe ao provedor corrigir a falha.

Você é responsável por tudo a partir do sistema operativo. Isso inclui os pacotes que instala, as portas que deixa abertas, as contas e chaves que podem iniciar sessão, as atualizações que aplica, as suas cópias de segurança e o seu próprio código de aplicação. A maioria dos planos VPS não é gerida, o que significa que ninguém aplica patches no seu servidor por si e que nenhum pedido de suporte fará isso. Vale a pena ler A divisão entre serviços geridos e não geridos antes de comprar, porque essa decisão determina quanto dessa lista ficará sob a sua responsabilidade.

Uma parte da sua responsabilidade é fácil de esquecer: o próprio painel de controlo do alojamento. Quem tiver acesso a essa conta pode reconstruir o seu servidor ou ligar o seu disco a um sistema de recuperação, sem nunca conhecer uma palavra-passe do interior do servidor. Ative a autenticação de dois fatores (2FA) na conta de alojamento e não reutilize essa palavra-passe em nenhum outro local.

O seu provedor de hospedagem consegue ver os seus dados?

Sim, em princípio. Este é o limite real do que um VPS oferece. A imagem do seu disco fica no armazenamento do provedor. O console dele permite acesso ao nível do ecrã da sua máquina virtual. O modo de recuperação pode iniciar outro sistema com o seu disco anexado. Um VPS protege-o contra outros clientes, mas o provedor fica fora desse compromisso.

Se tiver dados que devam permanecer ilegíveis para o host, cifre-os na aplicação antes de os gravar. A cifragem completa do disco dentro do sistema convidado ajuda contra uma imagem copiada enquanto está armazenada, mas a chave tem de permanecer na memória enquanto o servidor está em execução. Por isso, o provedor continua a fazer parte do modelo de confiança. A mesma confiança aplica-se a um servidor dedicado que aluga só para si, com menos uma camada partilhada.

O que realmente permite invadir uma VPS

Um serviço a escutar em todas as interfaces. Bases de dados, caches, filas de mensagens e painéis de administração ligam-se frequentemente a 0.0.0.0 por predefinição. Isto significa todas as interfaces de rede, incluindo a interface pública. O varrimento de toda a Internet IPv4 é constante e automatizado. Por isso, um endereço IPv4 novo recebe a primeira sondagem não solicitada poucos minutos depois de ficar online. O espaço IPv6 é demasiado grande para ser varrido endereço a endereço. Ainda assim, um endereço IPv6 pode ser encontrado através de registos DNS e de outras fugas. Não o trate como oculto. Um Redis sem palavra-passe, um nó Elasticsearch sem autenticação, uma API Docker aberta na porta 2375 e um painel de administração que ainda usa o início de sessão predefinido são todos encontrados desta forma, por um scanner que não sabe quem é. Ligue um serviço a 127.0.0.1 quando apenas a máquina local precisar dele e bloqueie o restante na firewall.

O Docker a contornar a firewall. A publicação de uma porta de contentor cria regras de tradução de endereços de rede (NAT) que são avaliadas antes das regras do ufw (uncomplicated firewall). Assim, um contentor pode ficar acessível a partir da Internet enquanto ufw status indica que essa porta está bloqueada. Isto apanha pessoas que fizeram corretamente tudo o resto. A razão pela qual uma porta Docker ignora o ufw vale a pena ler antes de publicar uma porta de contentor.

SSH com palavras-passe ativadas. Leia o log SSH em qualquer servidor com um endereço IPv4 público (/var/log/auth.log no Ubuntu, /var/log/secure no Rocky Linux e noutros sistemas da família RHEL, ou journalctl -u ssh e journalctl -u sshd quando não é mantido nenhum ficheiro de log). Encontrará linhas como Failed password for root from 203.0.113.10 port 54312 ssh2, aos milhares, dia e noite. Os bots testam nomes de utilizador comuns e palavras-passe comuns. O início de sessão por palavra-passe, juntamente com uma conta root que aceita inícios de sessão, é tudo o que um atacante precisa. Apenas chaves, com o início de sessão root desativado, transforma esse tráfego em ruído que pode ignorar.

Uma única chave privada usada em todo o lado. Uma única chave copiada para todos os portáteis e servidores significa que um portátil roubado desbloqueia tudo. Além disso, as chaves SSH não expiram. Por isso, uma chave entregue a um prestador de serviços há dois anos continua a funcionar hoje. Uma chave por pessoa e por máquina não custa nada e limita o alcance de uma única chave roubada.

Pacotes que ninguém atualizou. Um CVE publicado contra o seu servidor Web ou a sua framework de aplicação é um conjunto público de instruções. Os scanners começam a testá-lo no prazo de alguns dias. As atualizações de segurança são a defesa mais barata disponível e podem ser executadas automaticamente: consulte atualizações de segurança automáticas no Ubuntu.

Um segredo exposto. As palavras-passe de bases de dados e as chaves de API ficam em ficheiros .env. Esses ficheiros podem ser enviados para um repositório público ou servidos por um servidor Web apontado para o diretório errado. Qualquer conteúdo colado no contexto de um agente de programação com IA também pode acabar num log. Esse é um tema próprio: manter os segredos fora do alcance de um agente.

Tudo a correr como root. Quando a aplicação corre como root, um único erro nela passa a controlar toda a máquina, porque já não existe nenhum limite dentro do servidor que impeça a propagação.

A sua parte do trabalho

Nada do que se segue é trabalho de hipervisor. Tudo fica do seu lado da linha, e é esse lado que determina se o seu VPS está seguro.

• Faça corretamente a primeira hora: os primeiros dez minutos num VPS novo abrangem um utilizador não root e uma firewall.
• Proteja o acesso remoto: proteção do SSH num VPS.
• Feche as portas que não utiliza: fundamentos da firewall ufw.
• Dê a cada serviço apenas o acesso de que precisa: utilizadores com privilégio mínimo num VPS.
• Atrase as tentativas de início de sessão por força bruta: fail2ban no Ubuntu 24.04.
• Mantenha uma cópia de segurança que tenha restaurado pelo menos uma vez: cópias de segurança restic para um VPS.

A parte do fornecedor já está concluída quando o seu servidor arranca. A sua parte demora cerca de uma hora no primeiro dia e alguns minutos por mês depois disso. Se ainda estiver a comparar opções, o que é realmente um VPS explica os fundamentos de tudo isto.

FAQ

Outro cliente no mesmo servidor físico pode ler os meus ficheiros?

Não, num VPS KVM. O seu servidor é uma máquina virtual com o seu próprio kernel e o seu próprio disco virtual, além de uma região da memória física que o host lhe atribui. O processador bloqueia qualquer acesso fora dessa região. Não existe um sistema de ficheiros partilhado entre guests, por isso as permissões de ficheiros no servidor de outro cliente não têm significado no seu. Planos baseados em contentores, como OpenVZ e LXC, partilham o kernel do host e oferecem uma separação mais fraca. Confirme qual é o tipo de virtualização antes de contratar.

Um VPS é mais seguro do que alojamento partilhado?

Para isolamento, sim. No alojamento partilhado, muitos sites executam no mesmo sistema operativo e a única separação são as permissões de ficheiros. Por isso, um erro noutra conta pode, por vezes, expor ficheiros. Num VPS, a separação é feita por uma máquina virtual. A contrapartida é que o host aplica as atualizações no alojamento partilhado, enquanto num VPS não gerido é você quem as aplica. Um VPS só é mais seguro se instalar efetivamente as atualizações e fechar as portas.

O meu fornecedor de alojamento pode ler os meus dados?

Em princípio, sim. Nenhum produto VPS altera esse facto. A imagem do disco fica armazenada no hardware do fornecedor, a consola permite acesso ao nível do ecrã à máquina em execução e o modo de recuperação pode arrancar outro sistema com o seu disco ligado. Se alguns dados tiverem de permanecer ilegíveis para o host, cifre-os na aplicação antes de os gravar. A cifragem do disco dentro do guest continua a manter a chave na memória enquanto o servidor está em execução. Por isso, não elimina o fornecedor do modelo de confiança.

Qual é a forma mais comum de um VPS ser comprometido?

Um serviço exposto ou um login SSH fraco, de longe. Scanners automatizados sondam continuamente todos os endereços IPv4 públicos. Por isso, uma base de dados ligada a 0.0.0.0 sem palavra-passe, ou um painel de administração deixado com as credenciais predefinidas, é encontrado em minutos, não em meses. O log SSH de qualquer servidor com um endereço IPv4 público (/var/log/auth.log no Ubuntu, /var/log/secure no Rocky Linux) mostra a parte relacionada com SSH: linhas Failed password for root repetidas, provenientes de endereços de todo o mundo. Existem escapes do hypervisor, mas são ataques de nível de investigação dirigidos a alvos de elevado valor. Não são a causa dos comprometimentos comuns.