Comment auditer un Linux VPS avec vps-audit—et lire correctement les résultats

Un audit VPS rapide est un point de départ, pas un verdict

Votre site web se charge et SSH répond, mais cela ne révèle pas les mises à jour en attente, les paramètres SSH permissifs ou les écouteurs inattendus. Un audit de première passe soulève ces questions.

vps-audit est une liste de contrôle Bash pour Debian et Ubuntu qui transforme les signaux de configuration locale, de maintenance, d’écouteur et de ressources en un rapport en code couleur. Comme un tableau de bord de véhicule, il pointe vers les domaines qui nécessitent une inspection sans diagnostiquer chaque cause.

Ce guide exécute en toute sécurité vps-audit v0.2.0, vérifie les résultats importants avec des outils natifs et les transforme en priorités. L’exemple utilise un VPS Ubuntu AlexHost exécutant Ubuntu 24.04 LTS. D’autres images de fournisseurs peuvent différer, et le système d’exploitation invité non géré reste la responsabilité de l’opérateur.

Ce que vps-audit vérifie—et ce qu’il ne peut pas prouver

vps-audit vérifie les indicateurs locaux sans examiner aucun domaine de manière exhaustive. Ce tableau montre ce que chaque résultat peut—et ne peut pas—vous dire.

SUID permet à un programme de s’exécuter avec les privilèges effectifs du propriétaire du fichier. Les programmes système légitimes l’utilisent, donc enquêtez sur un fichier SUID inattendu plutôt que de le supprimer. Fail2ban et CrowdSec peuvent bloquer le trafic hostile, mais l’installation ou le statut actif seul ne prouve pas qu’ils protègent le service prévu.

Le script applique des seuils génériques à l’utilisation des ressources, aux services, aux connexions échouées et aux écouteurs. Ce ne sont pas des scores de risque conscients de la charge de travail ; différents rôles VPS peuvent atteindre la même couleur pour des raisons différentes.

L’outil n’inspecte pas les malwares, les vulnérabilités connues, les applications, les conteneurs, les pare-feu des fournisseurs, la conformité ou les tendances. Bien que son README mentionne « Connexions Internet actives », la v0.2.0 récupère uniquement l’IP publique et inventorie les écouteurs locaux. Parce qu’il a besoin d’une visibilité privilégiée, contrôlez d’abord quel fichier reçoit l’accès sudo.

Avant de donner sudo à un script téléchargé

Ce flux de travail Debian/Ubuntu nécessite un accès SSH, sudo, et les outils standard utilisés ci-dessous. Travaillez dans un répertoire jetable. Si un outil manque, arrêtez-vous plutôt que de modifier la ligne de base en l’installant.

L’exemple utilise vps-audit v0.2.0, publié le 10 août 2026 et toujours à jour lors de la vérification le 8 septembre 2026.

Son tag pointe vers le commit 57c323d46b48026740f0b35b9bad6cd6127c757b. L’épinglage évite un changement ultérieur de main mutable.

Créez un répertoire dédié et téléchargez ce script tagué exact via 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

Cela enregistre vps-audit.sh dans le nouveau répertoire. L’option -f échoue sur les erreurs HTTP, tandis que -L suit les redirections.

Ensuite, enregistrez une empreinte SHA-256 locale et affichez les paramètres pertinents pour cette procédure :

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

La sortie empreinte le fichier et affiche son chemin de rapport, ses seuils et sa demande à api.ipify.org. La source tagée complète lit également l’état local, simule apt-get -s upgrade, et recherche récursivement les fichiers SUID. Ce n’est pas en lecture seule : il écrit un rapport, peut créer son répertoire et contacte un service externe. Examinez la source avant d’accorder des privilèges élevés si vous pouvez lire le code shell.

Les seuils de ressources sont 50% pour WARN et 80% pour FAIL. Les services en cours d’exécution utilisent 20/40, les connexions échouées 10/50, les écouteurs nominalement 10/20, et la longueur du mot de passe 12. La section limitations explique pourquoi l’état des écouteurs ne suit pas ces variables.

⚠️ Avertissement : L’épinglage, le hachage, l’inspection ciblée et la vérification de la syntaxe améliorent la reproductibilité mais n’établissent pas la confiance. Le commit n’est pas signé, et la version ne fournit aucun actif de somme de contrôle ou de signature.

Conservez le hash avec les notes d’audit. Avant une exécution, comparez-le avec le fichier. Une correspondance montre que les copies contiennent les mêmes octets. Une différence peut provenir d’une autre version, d’un téléchargement modifié ou d’une modification locale. L’enregistrement du tag et du hash lie chaque rapport au script qui l’a produit.

Enfin, analysez le fichier sans exécuter ses commandes normales, puis ajoutez la permission d’exécution uniquement si l’analyse réussit :

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

Cela confirme seulement que Bash peut analyser le fichier et que la permission d’exécution a été ajoutée. Le script épinglé est maintenant prêt pour une exécution inchangée.

Exécuter vps-audit et localiser le rapport

Le script affiche les détails du système et les statuts en couleur, puis écrit un rapport en texte brut. Sa recherche SUID récursive rend le temps d’exécution variable, mesurez-le donc.

Exécutez le fichier épinglé une fois et préservez le statut de sortie du processus 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"

Sur le VPS testé, l’audit a démarré à 13:12:10 UTC le 14 septembre 2026 et s’est terminé en 58.412 secondes. Il a retourné 0 et a enregistré ./vps-audit-report-20260914_131210.txt.

Elapsed real est le temps écoulé; les valeurs user et system mesurent le temps CPU. Le statut de sortie 0 signifie que le processus s’est terminé, non que chaque vérification a réussi. v0.2.0 retourne 0 même avec des résultats FAIL.

Sélectionnez le nouveau rapport, inspectez ses métadonnées, et extrayez les comptages et exemples sans afficher le fichier sensible en intégralité.

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"

L’heure de modification du rapport à 13:13:08 UTC correspondait à l’exécution. Il contenait 17 résultats : six PASS, trois WARN et huit FAIL. Ce sont des classifications, non un score de sécurité.

Les totaux de statut sont utiles lors de la comparaison d’exécutions de la même version, mais inspectez toujours les lignes derrière un changement. Un nombre de FAIL inférieur peut provenir d’une entrée différente ou d’un comportement d’analyseur plutôt que d’une amélioration. Un total inchangé peut aussi masquer un problème résolu et un nouveau.

Le rapport de 2 665 octets appartenait à root:root avec le mode 644 (-rw-r--r--), comme prévu avec sudo et ENABLE_CHOWN=false standard. Les utilisateurs du groupe et autres peuvent lire ce mode si les permissions du répertoire leur permettent d’accéder au fichier. La propriété root seule ne le rend pas privé.

❗ Important : Le rapport contient le nom d’hôte, l’IP publique, les détails du système et les résultats. Gardez-le privé, et masquez les identifiants, invites et informations de service sensibles avant de partager.

Si une exécution future manque un statut, enregistrez cette absence plutôt que de reconfigurer le VPS pour fabriquer une couleur.

Comment lire PASS, WARN et FAIL sans surréagir

Les étiquettes du tableau de bord indiquent comment chaque test correspond aux règles de v0.2.0 :

Séparez l’observation de la recommandation. Dans « 22 services en cours d’exécution », le nombre est l’observation ; « réduire la surface d’attaque » est un conseil basé sur un seuil générique. Confirmez le nombre, identifiez les services, puis décidez si ce conseil convient au serveur.

Posez trois questions sur chaque résultat : La valeur est-elle exacte ? Est-elle intentionnelle ? Quel est l’impact réaliste ? Les commandes natives vérifient la valeur ; le contexte de la charge de travail détermine le reste.

Le WARN du port SSH est basé sur la politique : v0.2.0 signale le port 22. Déplacer SSH peut réduire le bruit automatisé mais ne peut pas remplacer une authentification forte ou des contrôles d’accès. Un service connu sur le port 22 peut importer moins qu’un écouteur wildcard inconnu.

Pour un FAIL, inspectez la règle avant de proposer un correctif. Le test de connexion root accepte uniquement PermitRootLogin no, donc le paramètre distinct prohibit-password échoue toujours. Vérifiez OpenSSH directement avant d’agir.

Un PASS a aussi besoin de contexte. Pour unattended-upgrades, le script confirme uniquement que le paquet existe, pas sa configuration ou son historique d’exécution.

Vérifier les conclusions à fort impact avec des commandes natives

Utilisez des commandes natives en lecture seule pour vérifier l’accès SSH, le filtrage des hôtes et les écouteurs locaux. D’abord, demandez ce qu’OpenSSH résout réellement après que les valeurs par défaut et la configuration incluse soient combinées :

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

Ubuntu charge /etc/ssh/sshd_config.d/*.conf près du début de sa configuration principale. sshd -T résout les paramètres combinés, ce qui en fait une preuve plus solide que de chercher dans un seul fichier.

OpenSSH a résolu le port 22 sur des adresses IPv4 et IPv6 génériques. Il a également retourné permitrootlogin yes, passwordauthentication yes, pubkeyauthentication yes, et kbdinteractiveauthentication no. La configuration résolue confirme les conclusions du script concernant la connexion root et l’authentification par mot de passe, bien que l’état du compte, PAM et les règles Match puissent toujours affecter une connexion spécifique.

Deuxièmement, demandez ce que UFW lui-même rapporte sur son état et sa politique gérée :

sudo ufw status verbose

Ubuntu documente UFW comme son interface de pare-feu par défaut. Ici, il était actif avec une journalisation de bas niveau et des politiques de refus par défaut pour le trafic entrant et routé. Les règles autorisaient les ports entrants 22, 80, 443 et 37985 sur IPv4 et IPv6. Cela confirme l’état d’UFW, non pas si chaque règle est appropriée.

Troisièmement, inventoriez les écouteurs TCP et UDP locaux, les adresses de liaison et les processus propriétaires :

sudo ss -lntup

Les options sélectionnent les écouteurs TCP et UDP numériques et demandent les détails du processus. Les ports 53, 62789, 8404 et 11111 étaient réservés à la boucle locale ; les ports 22, 80, 2096, 5678 et 37985 utilisaient des adresses génériques. Aucun détail de processus n’a été affiché, donc leurs propriétaires et leurs objectifs restent inconnus.

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

Les ports 22, 80 et 37985 avaient à la fois des écouteurs génériques et des règles d’autorisation UFW. UFW a autorisé 443 sans écouteur, tandis que 2096 et 5678 avaient des écouteurs sans règles d’autorisation affichées.

Une règle de pare-feu et un écouteur répondent à des questions différentes. La règle autorise le trafic si un service est là pour l’accepter ; l’écouteur montre un service en attente, mais non pas si le trafic réseau peut le atteindre. Lire les deux ensemble restreint l’investigation sans prétendre à une exposition externe.

📝 Remarque : ss affiche l’état de liaison locale, et UFW affiche un pare-feu hôte. Aucun ne prouve la disponibilité Internet sur les pare-feu du fournisseur ou NAT ; cela nécessite des tests autorisés depuis un autre système.

v0.2.0 étiquette néanmoins la même liste « Total » et « Public » après suppression des adresses de liaison, bien que quatre des neuf ports TCP étaient réservés à la boucle locale. Son filtre LISTEN manque également les lignes UDP marquées UNCONN. Lisez ce résultat comme un décompte de port TCP local, non pas une exposition publique.

Transformer les conclusions vérifiées en file d’attente d’actions pratiques

Définissez la priorité par confiance, exposition, impact et intention. La priorité 1 couvre les faiblesses confirmées qui nécessitent une action. La priorité 2 couvre les conclusions importantes qui nécessitent encore une investigation, tandis que la priorité 3 couvre les éléments à risque plus faible ou pilotés par la politique. Si un paramètre est intentionnel, documentez pourquoi, tout contrôle compensatoire et quand le revoir.

Le tableau applique cette approche à cette exécution ; les preuves incomplètes maintiennent une priorité provisoire :

La priorité 2 ne signifie pas inoffensif ; les preuves restent incomplètes. Donnez à chaque élément non résolu un propriétaire et une date limite. Promouvez-le si la vérification confirme l’exposition ou la faiblesse. S’il est intentionnel et contrôlé, enregistrez la décision clairement.

L’étiquette du rapport ne définit pas l’ordre : la vérification et le contexte le font.

⚠️ Avertissement : Ne modifiez pas l’authentification SSH ou les règles de pare-feu distant à partir de cette séquence de commandes. Une erreur peut vous verrouiller. Avant la correction, confirmez l’accès par clé testé et validez la nouvelle configuration. Gardez une deuxième session ouverte et assurez-vous que l’accès à la console ou de récupération fonctionne.

Traitez chaque correction comme un flux de travail séparé. Mappez les dépendances avant d’arrêter les services, classifiez les mises à jour avant de les planifier, et vérifiez la propriété et les sommes de contrôle avant de modifier les permissions SUID.

Où s’arrête la vue de vps-audit

vps-audit v0.2.0 est une checklist Bash ponctuelle. Il ne peut pas établir l’exposition externe, détecter les vulnérabilités ou les malwares, inspecter les charges de travail, analyser les journaux stockés ou fournir une surveillance continue. Ce n’est pas un test de pénétration ou une évaluation de CIS Benchmark.

Le code ajoute des mises en garde importantes.

• L’état du port devient PASS en dessous de trois ports TCP analysés, WARN à trois ou quatre, et FAIL à cinq ou plus—malgré les variables nominales 10/20.
• Un PASS unattended-upgrades vérifie uniquement la présence du paquet, pas sa configuration, son minuteur ou son historique d’exécution.
• Le test de mise à jour utilise les métadonnées en cache pour un apt-get -s upgrade général, puis appelle chaque paquet listé une « mise à jour de sécurité ».

Le test de journalisation sudo lit uniquement /etc/sudoers, manquant /etc/sudoers.d/ et les enregistrements normaux du journal ou syslog. Le problème #33, ouvert lors de la vérification le 8 septembre 2026, documente ce FAIL faux sur Ubuntu 20.04 et 24.04. L’analyse peut également échouer avec une sortie non-anglaise, comme suivi dans le problème ouvert #37. Malgré le libellé de son README, cette version ne liste pas les connexions établies.

Élargissez l’examen si nécessaire. Un comportement suspect nécessite une analyse des journaux stockés et des charges de travail. Pour un VPS important, confirmez les sauvegardes testées et envisagez des tests externes autorisés. Les systèmes critiques ou réglementés peuvent justifier Lynis, le CIS Benchmark Ubuntu 24.04, ou un examen professionnel.

Conclusion : Vérifier, Prioriser et Revérifier

Conservez le rapport original en privé et maintenez une copie expurgée. Enregistrez le SHA-256 du script, la balise et le commit avec le temps d’exécution, les services prévus, les résultats de vérification et la file d’attente d’actions.

1. Vérifiez les résultats à fort impact avec des commandes natives avant de modifier le serveur.
2. Corrigez les problèmes à haut risque confirmés en toute sécurité, enquêtez sur les inconnues et documentez les exceptions intentionnelles.
3. Réexécutez la même version épinglée après les modifications ou selon un calendrier, puis comparez les rapports manuellement.

Lors de la comparaison des rapports, concentrez-vous sur les modifications d’authentification, les règles de pare-feu, les écouteurs et les résultats résolus. Les horodatages et les lectures de ressources changeront. Notez les modifications délibérées pour que le prochain examinateur comprenne pourquoi les résultats diffèrent.

vps-audit n’a pas de base de données de référence, de planificateur, d’analyse de tendances ou de moteur de comparaison. Sa valeur provient d’une habitude répétable : exécuter, vérifier, prioriser et revérifier.