VPS é segura? O que fica sob seu controle

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. Uma VPS (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 mantém os outros clientes afastados desses 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.

A resposta honesta tem duas partes. O fornecedor é responsável pelo hardware e pelo hypervisor. Você é responsável por tudo o que está 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 compromete um VPS

Um serviço a escutar em todas as interfaces. Bases de dados, caches, filas de mensagens e painéis de administração fazem frequentemente bind a 0.0.0.0 por predefinição, o que significa todas as interfaces de rede, incluindo a interface pública. A pesquisa de endereços na Internet é constante e automatizada, por isso um endereço IP novo recebe a primeira sondagem não solicitada poucos minutos depois de ficar online. 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 as credenciais predefinidas são todos encontrados desta forma, por um scanner que não sabe quem é. Faça bind de 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 da porta de um contentor cria regras de tradução de endereços de rede (NAT) que são avaliadas antes das regras do ufw (uncomplicated firewall), por isso um contentor pode estar acessível a partir da Internet enquanto ufw status indica que essa porta está bloqueada. Isto apanha pessoas que fizeram corretamente tudo o resto. O motivo pelo qual uma porta Docker ignora o ufw merece ser lido antes de publicar uma porta de contentor.

SSH com palavras-passe ativadas. Consulte /var/log/auth.log em qualquer servidor público e 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 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 de que um atacante precisa. Apenas chaves, com o início de sessão de 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 tem custos e limita aquilo a que uma única chave roubada pode dar acesso.

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

Um segredo exposto. As palavras-passe de bases de dados e as chaves de API ficam em ficheiros .env, e esses ficheiros são enviados para um repositório público ou servidos por um servidor Web configurado para apontar para o diretório errado. Tudo o que for colado no contexto de um agente de programação com IA também pode acabar num log, o que é um assunto à parte: manter os segredos fora do alcance de um agente.

Tudo a ser executado como root. Quando a aplicação é executada como root, um único erro nela dá controlo sobre toda a máquina, porque já não existe qualquer limite dentro do servidor que impeça a sua 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 de 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 os guests, por isso as permissões de ficheiros no servidor de um vizinho não têm qualquer significado no seu servidor. Planos baseados em contentores, como OpenVZ e LXC, partilham o kernel do host e oferecem uma fronteira de isolamento mais fraca. Confirme qual é o tipo de virtualização antes de contratar o serviço.

Um VPS é mais seguro do que alojamento partilhado?

Para isolamento, sim. No alojamento partilhado, muitos sites executam no mesmo sistema operativo e a única fronteira são as permissões de ficheiros. Por isso, um erro noutra conta pode, por vezes, expor ficheiros. Num VPS, a fronteira é uma máquina virtual. A contrapartida é que o host aplica as atualizações no alojamento partilhado, enquanto num VPS não gerido é você que 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, e nenhum produto VPS altera esse facto. A imagem do disco fica armazenada no hardware do fornecedor, a consola permite acesso ao ecrã da 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 remove o fornecedor da relação de confiança.

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

Um serviço exposto ou um acesso SSH fraco, com grande diferença. Os scanners automatizados sondam continuamente todos os endereços IP públicos. Por isso, uma base de dados ligada a 0.0.0.0 sem palavra-passe, ou um painel de administração com as credenciais predefinidas, é encontrada em minutos, e não em meses. /var/log/auth.log em qualquer servidor público 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 trabalhos de investigação dirigidos a alvos de elevado valor. Não são a causa dos comprometimentos comuns.