Como Auditar um Linux VPS com vps-audit—e Ler os Resultados Corretamente

Uma Auditoria Rápida de VPS É um Ponto de Partida, Não um Veredicto

Seu website carrega e SSH responde, mas isso não revela atualizações pendentes, configurações SSH permissivas ou listeners inesperados. Uma auditoria de primeira passagem expõe essas questões.

vps-audit é uma checklist Bash para Debian e Ubuntu que transforma sinais de configuração local, manutenção, listener e recursos em um relatório codificado por cores. Como um painel de veículo, aponta áreas que precisam de inspeção sem diagnosticar cada causa.

Este guia executa com segurança vps-audit v0.2.0 fixado, verifica resultados importantes com ferramentas nativas e os transforma em prioridades. O exemplo usa um AlexHost Ubuntu VPS executando Ubuntu 24.04 LTS. Imagens de outros provedores podem diferir, e o SO convidado não gerenciado permanece responsabilidade do operador.

O que vps-audit Verifica—e O Que Não Pode Provar

vps-audit verifica indicadores locais sem examinar nenhuma área de forma exaustiva. Esta tabela mostra o que cada resultado pode—e não pode—lhe dizer.

SUID permite que um programa seja executado com os privilégios efetivos do proprietário do arquivo. Programas de sistema legítimos o usam, portanto investigue um arquivo SUID inesperado em vez de deletá-lo. Fail2ban e CrowdSec podem bloquear tráfego hostil, mas a instalação ou status ativo sozinhos não provam que protegem o serviço pretendido.

O script aplica limites genéricos ao uso de recursos, serviços, logins falhados e listeners. Estes não são scores de risco cientes de carga de trabalho; diferentes funções de VPS podem atingir a mesma cor por razões diferentes.

A ferramenta não inspeciona malware, vulnerabilidades conhecidas, aplicações, containers, firewalls do provedor, conformidade ou tendências. Embora seu README mencione “Active Internet Connections”, v0.2.0 apenas obtém o IP público e inventaria listeners locais. Como precisa de visibilidade privilegiada, primeiro controle qual arquivo recebe acesso sudo.

Antes de Dar sudo a um Script Descarregado

Este fluxo de trabalho Debian/Ubuntu requer acesso SSH, sudo, e as ferramentas padrão utilizadas abaixo. Trabalhe num diretório descartável. Se uma ferramenta estiver em falta, pare em vez de alterar a linha de base instalando-a.

O exemplo utiliza vps-audit v0.2.0, publicado em 10 de Agosto de 2026 e ainda o mais recente quando verificado em 8 de Setembro de 2026.

A sua tag aponta para o commit 57c323d46b48026740f0b35b9bad6cd6127c757b. Fixar evita uma alteração posterior do main mutável.

Crie um diretório dedicado e descarregue esse script exato com tag sobre HTTPS:

mkdir -p "$HOME/vps-audit-test"
cd "$HOME/vps-audit-test"
curl -fL --proto '=https' --tlsv1.2 
  -o vps-audit.sh 
  https://raw.githubusercontent.com/nuver-labs/vps-audit/v0.2.0/vps-audit.sh

Isto guarda vps-audit.sh no novo diretório. A opção -f falha em erros HTTP, enquanto -L segue redirecionamentos.

Depois, registe uma impressão digital SHA-256 local e apresente as definições relevantes para este guia:

sha256sum vps-audit.sh
grep -nE '^(VPS_AUDIT_VERSION|RESOURCE_(WARN|FAIL)|SERVICES_(WARN|FAIL)|LOGINS_(WARN|FAIL)|OPEN_PORTS_(WARN|FAIL)|PASSWORD_MINLEN|DEFAULT_REPORT_DIR|ENABLE_CHOWN)=|api.ipify.org' vps-audit.sh

O resultado apresenta uma impressão digital do ficheiro e mostra o seu caminho de relatório, limiares e pedido para api.ipify.org. O código-fonte completo com tag também lê o estado local, simula apt-get -s upgrade, e procura recursivamente ficheiros SUID. Não é apenas leitura: escreve um relatório, pode criar o seu diretório e contacta um serviço externo. Revise o código-fonte antes de conceder privilégios elevados se conseguir ler código shell.

Os limiares de recursos são 50% para WARN e 80% para FAIL. Os serviços em execução utilizam 20/40, logins falhados 10/50, listeners nominalmente 10/20, e comprimento de palavra-passe 12. A secção de limitações explica por que o estado do listener não segue essas variáveis.

⚠️ Aviso: Fixar, fazer hash, inspeção direcionada e verificação de sintaxe melhoram a reprodutibilidade mas não estabelecem confiança. O commit não está assinado, e o lançamento não fornece ativo de checksum ou assinatura.

Mantenha o hash com as notas de auditoria. Antes de uma execução, compare-o com o ficheiro. Uma correspondência mostra que as cópias contêm os mesmos bytes. Uma diferença pode vir de outro lançamento, uma descarregamento alterado, ou uma edição local. Registar a tag e o hash liga cada relatório ao script que o produziu.

Finalmente, analise o ficheiro sem executar os seus comandos normais, depois adicione permissão de execução apenas se a análise for bem-sucedida:

bash -n vps-audit.sh 
  && chmod +x vps-audit.sh 
  && printf 'Syntax check: PASS; execute permission addedn'

Isto confirma apenas que Bash consegue analisar o ficheiro e que a permissão de execução foi adicionada. O script fixado está agora pronto para uma execução inalterada.

Execute vps-audit e Localize o Relatório

O script imprime detalhes do sistema e status coloridos, depois escreve um relatório em texto simples. Sua busca SUID recursiva torna o tempo de execução variável, então meça-o.

Execute o arquivo fixado uma vez e preserve o status de saída do processo shell:

printf 'Audit started: '
date -u '+%Y-%m-%d %H:%M:%S UTC'
TIMEFORMAT=$'Elapsed real: %3R secondsnUser CPU: %3U secondsnSystem CPU: %3S seconds'
time sudo ./vps-audit.sh
AUDIT_STATUS=$?
printf 'Audit exit status: %sn' "$AUDIT_STATUS"

No VPS testado, a auditoria começou às 13:12:10 UTC em 14 de setembro de 2026 e terminou em 58.412 segundos. Retornou 0 e salvou ./vps-audit-report-20260914_131210.txt.

Elapsed real é o tempo de relógio de parede; os valores de usuário e sistema medem o tempo de CPU. O status de saída 0 significa que o processo foi concluído, não que todas as verificações passaram. v0.2.0 retorna 0 mesmo com resultados FAIL.

Selecione o novo relatório, inspecione seus metadados e extraia contagens e exemplos sem exibir o arquivo sensível na íntegra.

REPORT=$(ls -1t ./vps-audit-report-*.txt 2>/dev/null | head -n 1)
if [ -z "$REPORT" ]; then
    printf 'No vps-audit report found in the current directory.n' >&2
    exit 1
fi
printf 'Report selected: %sn' "$REPORT"
sudo stat --format='Owner: %U:%G | Mode: %A (%a) | Size: %s bytes | Modified: %y' "$REPORT"

for status in PASS WARN FAIL; do
    count=$(sudo grep -c "^\[$status\]" "$REPORT" || true)
    printf '%s: %sn' "$status" "$count"
done

sudo grep -E '^[(PASS|WARN|FAIL)] (Running Services|Disk Usage|Password Policy)' "$REPORT"

O tempo de modificação do relatório às 13:13:08 UTC correspondeu à execução. Continha 17 resultados: seis PASS, três WARN e oito FAIL. Estas são classificações, não uma pontuação de segurança.

Os totais de status são úteis ao comparar execuções da mesma versão, mas sempre inspecione as linhas por trás de uma mudança. Uma contagem FAIL menor pode resultar de entrada diferente ou comportamento do analisador em vez de uma melhoria. Um total inalterado também pode ocultar um problema resolvido e um novo.

O relatório de 2.665 bytes pertencia a root:root com modo 644 (-rw-r--r--), conforme esperado com sudo e ENABLE_CHOWN=false padrão. Usuários de grupo e outros podem ler esse modo se as permissões de diretório permitirem que eles alcancem o arquivo. A propriedade de root sozinha não o torna privado.

❗ Importante: O relatório contém o nome do host, IP público, detalhes do sistema e descobertas. Mantenha-o privado e remova identificadores, prompts e informações de serviço sensíveis antes de compartilhar.

Se uma execução futura não tiver um status, registre essa ausência em vez de reconfigurar o VPS para fabricar uma cor.

Como Ler PASS, WARN e FAIL Sem Exagerar

Os rótulos do dashboard relatam como cada teste correspondeu às regras da v0.2.0:

Separe a observação da recomendação. Em “22 serviços em execução,” a contagem é a observação; “reduzir superfície de ataque” é um conselho baseado em um limite genérico. Confirme a contagem, identifique os serviços e então decida se esse conselho se adequa ao servidor.

Faça três perguntas sobre cada resultado: O valor é preciso? É intencional? Qual é o impacto realista? Comandos nativos verificam o valor; o contexto da carga de trabalho determina o resto.

O WARN da porta SSH é baseado em política: v0.2.0 sinaliza a porta 22. Mover SSH pode reduzir ruído automatizado, mas não pode substituir autenticação forte ou controles de acesso. Um serviço conhecido na porta 22 pode importar menos do que um listener wildcard desconhecido.

Para um FAIL, inspecione a regra antes de propor uma correção. O teste de login raiz aceita apenas PermitRootLogin no, portanto a configuração distinta prohibit-password ainda falha. Verifique OpenSSH diretamente antes de agir.

Um PASS também precisa de contexto. Para unattended-upgrades, o script confirma apenas que o pacote existe—não sua configuração ou histórico de execução.

Verificar Descobertas de Alto Impacto com Comandos Nativos

Use comandos nativos somente leitura para verificar acesso SSH, filtragem de host e listeners locais. Primeiro, pergunte o que OpenSSH realmente resolve após padrões e configuração incluída serem combinados:

sudo sshd -T 
  | grep -E '^(port|listenaddress|permitrootlogin|passwordauthentication|kbdinteractiveauthentication|pubkeyauthentication) '

Ubuntu carrega /etc/ssh/sshd_config.d/*.conf perto do início de sua configuração principal. sshd -T resolve as configurações combinadas, tornando-a evidência mais forte do que grep em um único arquivo.

OpenSSH resolveu porta 22 em endereços IPv4 e IPv6 curinga. Também retornou permitrootlogin yes, passwordauthentication yes, pubkeyauthentication yes, e kbdinteractiveauthentication no. A configuração resolvida confirma as descobertas de login raiz e autenticação por senha do script, embora estado da conta, PAM e regras Match ainda possam afetar um login específico.

Segundo, pergunte o que UFW relata sobre seu estado e política gerenciada:

sudo ufw status verbose

Ubuntu documenta UFW como seu frontend de firewall padrão. Aqui estava ativo com logging de baixo nível e políticas de negação padrão para tráfego de entrada e roteado. Regras permitiram portas de entrada 22, 80, 443 e 37985 sobre IPv4 e IPv6. Isso confirma o estado do UFW, não se cada regra é apropriada.

Terceiro, inventarie listeners TCP e UDP locais, endereços de ligação e processos proprietários:

sudo ss -lntup

As opções selecionam listeners TCP e UDP numéricos e solicitam detalhes do processo. Portas 53, 62789, 8404 e 11111 eram somente loopback; portas 22, 80, 2096, 5678 e 37985 usavam endereços curinga. Nenhum detalhe de processo apareceu, então seus proprietários e propósitos permanecem desconhecidos.

process listener
    → bind address / interface
    → host firewall
    → provider-edge firewall or NAT
    → external network path

Portas 22, 80 e 37985 tinham listeners curinga e regras de permissão UFW. UFW permitiu 443 sem listener, enquanto 2096 e 5678 tinham listeners sem regras de permissão exibidas.

Uma regra de firewall e um listener respondem perguntas diferentes. A regra permite tráfego se um serviço estiver lá para aceitá-lo; o listener mostra um serviço aguardando, mas não se o tráfego de rede pode alcançá-lo. Ler ambos juntos reduz a investigação sem reivindicar exposição externa.

📝 Nota: ss mostra estado de ligação local, e UFW mostra um firewall de host. Nenhum prova acessibilidade da Internet através de firewalls de provedor ou NAT; isso requer testes autorizados de outro sistema.

v0.2.0 no entanto rotula a mesma lista “Total” e “Público” após descartar endereços de ligação, mesmo que quatro de nove portas TCP fossem somente loopback. Seu filtro LISTEN também perde linhas UDP marcadas UNCONN. Leia este resultado como uma contagem de porta TCP local, não exposição pública.

Transformar Descobertas Verificadas numa Fila de Ação Prática

Defina prioridade por confiança, exposição, impacto e intenção. Priority 1 abrange fraquezas confirmadas que necessitam de ação. Priority 2 abrange descobertas importantes que ainda necessitam de investigação, enquanto Priority 3 abrange itens de risco inferior ou orientados por política. Se uma configuração é intencional, documente o motivo, qualquer controlo compensatório e quando revê-la.

A tabela aplica essa abordagem a esta execução; evidência incompleta mantém uma prioridade provisória:

Priority 2 não significa inofensivo; a evidência permanece incompleta. Atribua a cada item não resolvido um proprietário e prazo. Promova-o se a verificação confirmar exposição ou fraqueza. Se é intencional e controlado, registe a decisão claramente.

O rótulo do relatório não define a ordem: verificação e contexto fazem.

⚠️ Aviso: Não altere a autenticação SSH ou regras de firewall remoto a partir desta sequência de comando. Um erro pode bloqueá-lo. Antes da remediação, confirme acesso de chave testado e valide a nova configuração. Mantenha uma segunda sessão aberta e certifique-se de que o acesso à consola ou recuperação funciona.

Trate cada remediação como um fluxo de trabalho separado. Mapeie dependências antes de parar serviços, classifique atualizações antes de agendá-las e verifique propriedade e checksums antes de alterar permissões SUID.

Onde a Visualização do vps-audit Para

vps-audit v0.2.0 é uma checklist Bash de um ponto no tempo. Não pode estabelecer exposição externa, detectar vulnerabilidades ou malware, inspecionar workloads, analisar logs armazenados ou fornecer monitoramento contínuo. Não é um teste de penetração ou avaliação de CIS Benchmark.

O código adiciona ressalvas importantes.

• O status da porta torna-se PASS abaixo de três portas TCP analisadas, WARN em três ou quatro, e FAIL em cinco ou mais—apesar das variáveis nominais 10/20.
• Um PASS de unattended-upgrades verifica apenas o pacote, não sua configuração, timer ou histórico de execução.
• O teste de atualização usa metadados em cache para um apt-get -s upgrade geral, depois chama cada pacote listado de “atualização de segurança”.

O teste de sudo-logging lê apenas /etc/sudoers, perdendo /etc/sudoers.d/ e registros normais de journal ou syslog. Issue #33, aberta quando verificada em 8 de setembro de 2026, documenta este FAIL falso no Ubuntu 20.04 e 24.04. A análise também pode falhar com saída em não-inglês, conforme rastreado na issue #37 aberta. Apesar da redação do README, esta versão não lista conexões estabelecidas.

Amplie a revisão quando necessário. Comportamento suspeito requer análise de log armazenado e workload. Para um VPS importante, confirme backups testados e considere testes externos autorizados. Sistemas críticos ou regulados podem justificar Lynis, o CIS Benchmark do Ubuntu 24.04 ou revisão profissional.

Conclusão: Verificar, Priorizar e Revalidar

Mantenha o relatório original privado e guarde uma cópia redatada. Registe o SHA-256 do script, a tag e o commit juntamente com o tempo de execução, os serviços pretendidos, os resultados da verificação e a fila de ações.

1. Verifique as descobertas de alto impacto com comandos nativos antes de alterar o servidor.
2. Corrija os problemas de alto risco confirmados com segurança, investigue os desconhecidos e documente as exceções intencionais.
3. Reexecute a mesma versão fixada após alterações ou num agendamento, depois compare os relatórios manualmente.

Ao comparar relatórios, concentre-se em alterações de autenticação, regras de firewall, listeners e descobertas resolvidas. Os timestamps e as leituras de recursos mudarão. Anote as alterações deliberadas para que o próximo revisor compreenda por que os resultados diferem.

vps-audit não tem base de dados de referência, agendador, análise de tendências ou motor de comparação. O seu valor vem de um hábito repetível: executar, verificar, priorizar e revalidar.