VPS sem logs: configure um servidor VPN que nada registra

O que de facto fica registado num servidor

O apelo de ter o seu proprio VPN e simples: nenhuma empresa fica entre voce e a internet a anotar o que voce faz. Mas um servidor Linux comum continua a manter os seus proprios registos e, se quer uma configuracao genuinamente sem logs, precisa de saber quais sao:

• O proprio WireGuard nao mantem nenhum log de trafego. Por padrao, nao escreve nada sobre as suas ligacoes no disco. Mantem apenas na memoria a hora do ultimo handshake e o seu endpoint atual, que voce ve com wg show - e isso e apagado ao reiniciar. Portanto, a camada VPN ja esta limpa.
• O sistema operativo e a parte barulhenta. O journal do systemd (journald) regista eventos de servicos. Se o rsyslog estiver instalado, tambem escreve ficheiros em texto simples como /var/log/syslog e /var/log/auth.log - e o auth.log regista cada login SSH. Ficheiros separados (wtmp, btmp, lastlog) rastreiam quem fez login e quando, e a sua shell mantem um ~/.bash_history.
• E alguns caminhos mais silenciosos ate ao disco. Se o servidor tiver swap ligado, o kernel pode despejar paginas de RAM - incluindo chaves - para o disco. Um programa que rebenta pode deixar um core dump da sua memoria. E o gestor de pacotes escreve logs de atualizacao em /var/log/apt. Uma configuracao cuidadosa tambem fecha estes.

O limite honesto: o que o sem-logs pode e nao pode fazer

Antes de tocar em nada, seja claro sobre o que esta realmente a comprar. Desligar os logs impede o seu proprio servidor de manter registos - portanto, se o disco alguma vez for apreendido, copiado ou lido por alguem que entre, ha muito menos para encontrar. Isso e um ganho real e valioso.

O que ele nao faz e esconde-lo da empresa que lhe aluga o servidor. O seu fornecedor de VPS sempre sabe que existe uma maquina naquele IP, pode ver quanta largura de banda ela movimenta e poderia, em principio, observar o trafego ao nivel da rede ou do hypervisor - nenhuma definicao dentro do seu servidor muda isso. O sem-logs trata de minimizar a sua propria pegada, nao de se tornar invisivel para o anfitriao. Escolha um fornecedor com o qual se sinta confortavel e trate os passos abaixo como uma reducao de risco, nao como uma eliminacao dele.

Sem-logs nao e uma garantia de anonimato. Dois limites que nenhuma definicao do servidor pode mudar:

• O seu fornecedor ve os IPs que se ligam. O conteudo esta encriptado, mas eles conseguem ver que o IP da sua casa alcancou a porta do WireGuard, e quando.
• O seu fornecedor pode capturar a RAM. Um VPS e uma maquina virtual; o anfitriao controla o hypervisor e pode capturar a memoria em tempo real (as chaves ativas do WireGuard e os peers ligados) e pode ser obrigado a entrega-la a policia mediante um pedido legal valido.

Conclusao: voce e dono do software, nao da maquina. O sem-logs reduz o seu risco, nao o elimina.

Passo 1: Mover o journal do systemd para a RAM

Primeiro, diga ao journald para manter o seu journal apenas na memoria, para que nunca chegue ao disco e desapareca a cada reinicio. Abra a sua configuracao:

nano /etc/systemd/journald.conf

Na seccao [Journal], defina estas duas linhas (remova o # inicial se estiver presente):

[Journal]
Storage=volatile
RuntimeMaxUse=16M

Aplique e o journal passa a viver em /run (RAM), limitado a 16 MB e apagado ao reiniciar:

systemctl restart systemd-journald

Passo 2: Colocar todo o /var/log na RAM

O journal ja esta na memoria, mas varias ferramentas continuam a largar ficheiros em texto simples em /var/log - o rsyslog, o auth.log que regista os logins SSH, os logs de atualizacao do apt e os registos de login wtmp/btmp/lastlog (que continuam a ser reescritos a cada login, por isso simplesmente apaga-los nao adianta nada). A solucao limpa e abrangente e montar todo o diretorio /var/log como um tmpfs - um sistema de ficheiros assente em RAM que e apagado a cada reinicio. Adicione uma linha ao /etc/fstab:

echo "tmpfs /var/log tmpfs defaults,noatime,nosuid,nodev,mode=0755,size=50M 0 0" >> /etc/fstab

Agora tudo em /var/log vive na memoria e esvazia-se a cada reinicio. Reinicie uma vez para que os servicos em execucao reabram os seus ficheiros de log dentro do novo disco em RAM:

reboot

Passo 3: Desligar o swap

Se o servidor tiver o swap ativado, o kernel pode empurrar paginas de RAM - possivelmente incluindo chaves ativas - para o disco quando a memoria fica escassa. Numa maquina sem-logs, voce quer que a memoria fique na memoria. Desligue o swap agora e mantenha-o desligado entre reinicios:

swapoff -a
sed -i.bak '/\sswap\s/s/^/#/' /etc/fstab

Muitos VPS pequenos vem sem nenhum swap - nesse caso, o swapoff -a simplesmente nao faz nada, o que esta bem.

Passo 4: Desligar os core dumps

Se um programa rebentar, o systemd-coredump pode escrever um core dump - um instantaneo da memoria desse programa - no disco, em /var/lib/systemd/coredump/. Desligue-o:

mkdir -p /etc/systemd/coredump.conf.d
printf '[Coredump]Storage=none' > /etc/systemd/coredump.conf.d/99-nolog.conf
systemctl daemon-reload

Passo 5: Desligar o historico da shell e do editor

A sua shell guarda cada comando em ~/.bash_history, e os editores deixam os seus proprios rastos (~/.viminfo, ~/.lesshst). Aponte-os todos para /dev/null para que nada seja escrito. Para o utilizador atual:

ln -sf /dev/null ~/.bash_history
ln -sf /dev/null ~/.viminfo
ln -sf /dev/null ~/.lesshst

Depois, impeca o bash de manter um ficheiro de historico para cada login shell no sistema, de modo que outras contas fiquem tambem cobertas:

printf 'unset HISTFILEexport HISTSIZE=0' > /etc/profile.d/00-nohistory.sh

Se tiver outras contas de utilizador, repita as tres linhas ln -sf tambem para cada uma das suas pastas pessoais.

Passo 6: Manter a protecao contra intrusoes - voce nao esta cego

Um mito comum e que desligar os logs o deixa indefeso. Nao tem de ser assim. O fail2ban - a ferramenta que bane um IP apos varias tentativas de login falhadas - pode ler diretamente do journal do systemd, que agora vive na RAM. Assim, voce mantem a protecao automatica contra forca bruta sem escrever nada no disco. Instale-o:

apt install fail2ban -y

Aponte-o para o journal criando o /etc/fail2ban/jail.local com:

[DEFAULT]
backend = systemd

Depois, reinicie-o e, para alem disso, feche as portas obvias:

systemctl restart fail2ban

• Apenas chaves SSH. Desative o login por password em /etc/ssh/sshd_config (PasswordAuthentication no) e reinicie o ssh. Uma chave nao pode ser adivinhada como uma password.
• Firewall fechada por padrao. Mantenha o ufw a permitir apenas o SSH e a sua porta do WireGuard (51820/udp), com todo o resto negado.
• Atualizacoes de seguranca automaticas. Instale o unattended-upgrades; os seus logs vivem agora no /var/log assente em RAM, portanto tambem desaparecem ao reiniciar.

Passo 7: Verificar que nada persiste

Reinicie mais uma vez, faca login de novo e verifique as quatro coisas que alterou:

mount | grep /var/log
swapon --show
journalctl --no-pager | wc -l
ls -lh /var/log

Deve ver /var/log montado como tmpfs, nenhum swap ativo, um journal quase vazio e um /var/log novo e quase vazio. A partir daqui, o servidor nao mantem essencialmente nada no disco sobre o que passa por ele.

Quando pode querer manter alguns logs

O sem-logs nao e automaticamente o certo para toda a gente. Se o servidor fizer mais do que correr o seu VPN pessoal - alojar um site, tratar do trafego de outras pessoas - pode querer um pouco de historico para detetar problemas. Boa noticia: a configuracao acima ja mantem logs de curto prazo na RAM (no journal e no tmpfs /var/log), portanto voce tem visibilidade dentro da mesma sessao sem escrever nada permanente no disco. Se precisar de mais, aumente o RuntimeMaxUse no Passo 1 ou o size do tmpfs no Passo 2. Ajuste a agressividade a forma como realmente usa a maquina.