Les 10 commandes Linux indispensables pour auditer la sécurité d’un serveur

Ce que vous saurez faire à la fin

1. Exécuter 10 commandes d’audit indispensables en moins de 5 minutes
2. Détecter tentatives SSH, processus suspects, fichiers modifiés
3. Comparer l’état actuel du système à une baseline saine
4. Générer un rapport d’audit automatique quotidien
5. Alerter en temps réel sur les anomalies

Durée : 45 minutes. Pré-requis : serveur Linux Ubuntu/Debian/CentOS, accès root ou sudo.

1. Détecter les connexions sortantes suspectes

ss -tunp state established | awk 'NR>1 {print $5}' | sort -u

# Cross-check avec les processus
sudo lsof -i -n -P | grep ESTABLISHED

1. Comparez les IPs distantes aux plages connues (AWS, OVH, vos CDN).
2. Une IP résidentielle inconnue = à investiguer immédiatement.

2. Identifier les processus qui écoutent

sudo ss -tulpn | grep LISTEN

# Format: Netid  State  Recv-Q  Send-Q  Local-Addr:Port  Peer-Addr:Port  users:(("process",pid=1234,fd=3))

# Vérifier les services actifs
systemctl list-units --type=service --state=running | head -30

1. Chaque port en écoute = surface d’attaque. Seuls les services attendus doivent apparaître (SSH 22, HTTPS 443, etc.).
2. Un port inattendu (ex: 31337) = alerte haute.

3. Vérifier les dernières connexions SSH

# Connexions réussies avec IP
last -i | head -30

# Tentatives échouées
sudo lastb -i | head -30

# Top IPs qui ont échoué (7 derniers jours)
sudo journalctl -u ssh --since "7 days ago" \
  | grep -oP '(?<=Failed password for ).*from \K[0-9.]+' \
  | sort | uniq -c | sort -rn | head -20

1. IPs avec > 100 tentatives d’échec : bloquer via fail2ban ou firewall.

4. Chercher les fichiers SUID/SGID suspects

# Liste complète des SUID root
sudo find / -perm -4000 -type f -printf '%M %u %p\n' 2>/dev/null

# Nouveaux SUID apparus ces 30 derniers jours
sudo find / -perm -4000 -type f -mtime -30 2>/dev/null

# SGID
sudo find / -perm -2000 -type f -mtime -30 2>/dev/null

1. Les binaires SUID permettent de s’exécuter en tant que le propriétaire. Un SUID récent inattendu = backdoor potentielle.
2. Baseline saine : liste à comparer, stockée hors ligne.

5. Fichiers modifiés récemment dans /etc

sudo find /etc -type f -mtime -7 -printf '%TY-%Tm-%Td %p\n' | sort

# Diff avec la version précédente (si git init fait)
sudo git -C /etc diff HEAD~1 -- passwd shadow sudoers

Astuce pro : au premier audit, initialisez /etc en dépôt git :

sudo git -C /etc init
sudo git -C /etc add -A
sudo git -C /etc commit -m "baseline initiale"

# Chaque semaine, automatiquement:
sudo git -C /etc diff
sudo git -C /etc add -A && sudo git -C /etc commit -m "hebdo $(date +%F)"

6. Contrôler les crontabs de TOUS les utilisateurs

for u in $(cut -f1 -d: /etc/passwd); do
  crontab_u=$(sudo crontab -u "$u" -l 2>/dev/null)
  if [ -n "$crontab_u" ]; then
    echo "=== $u ==="
    echo "$crontab_u"
  fi
done

# Crontabs système
ls -la /etc/cron.d/ /etc/cron.daily/ /etc/cron.hourly/ /etc/cron.weekly/
cat /etc/cron.d/*

1. Cron est un vecteur classique de persistance. Tout cron non documenté = à investiguer.

7. Inspecter les utilisateurs privilégiés (UID 0)

awk -F: '$3==0 {print $1}' /etc/passwd

# Doit retourner UNIQUEMENT: root
# Tout autre utilisateur UID 0 = backdoor confirmée

8. Journal des commandes sudo

sudo journalctl -u sudo --since "30 days ago" | grep -v "session opened\|session closed"
sudo grep sudo /var/log/auth.log | tail -50

# Qui a utilisé sudo et pour quelle commande ?
sudo grep "COMMAND=" /var/log/auth.log | awk -F'TTY=' '{print $2}' | head -30

9. Détecter les rootkits

sudo apt install -y rkhunter chkrootkit

# RKHunter
sudo rkhunter --update
sudo rkhunter --check --skip-keypress --report-warnings-only

# Chkrootkit
sudo chkrootkit -q

1. Exécutez 1x/semaine. Toute alerte non identifiée = investigation manuelle.
2. Ne garantit pas une détection 100 % (les rootkits récents échappent), mais écarte 90 % des variantes connues.

10. Intégrité des binaires système (debsums)

sudo apt install -y debsums

# Vérifie les hash de tous les binaires installés par paquets
sudo debsums -c 2>/dev/null

1. Affiche uniquement les fichiers dont le hash ne correspond PAS au .deb d’origine.
2. Peut indiquer une modification légitime (compilation custom) ou une compromission.

Script d’audit quotidien automatisé

#!/usr/bin/env bash
# /usr/local/bin/audit-quotidien.sh
set -euo pipefail

RAPPORT=/var/log/audit-$(date +%F).txt

{
echo "=== Audit sécurité $(hostname) - $(date) ==="
echo
echo "== Connexions SSH échouées (24h) =="
sudo journalctl -u ssh --since "1 day ago" | grep -c "Failed password" || true

echo
echo "== Nouveaux SUID (24h) =="
sudo find / -perm -4000 -type f -mtime -1 2>/dev/null || true

echo
echo "== Processus écoutant =="
sudo ss -tulpn | grep LISTEN

echo
echo "== Utilisateurs UID 0 =="
awk -F: '$3==0 {print $1}' /etc/passwd

echo
echo "== Espace disque =="
df -h | awk '$5+0 > 85 {print "ALERT saturated:", $0}'

echo
echo "== Charge système =="
uptime
} > "$RAPPORT" 2>&1

# Envoi email si anomalie
if grep -qE "ALERT|backdoor|RKH" "$RAPPORT"; then
  mail -s "[ALERTE] Audit $(hostname)" secu@example.sn < "$RAPPORT"
fi

# Rendre exécutable et planifier
sudo chmod +x /usr/local/bin/audit-quotidien.sh
echo "0 6 * * * root /usr/local/bin/audit-quotidien.sh" | sudo tee /etc/cron.d/audit

Alerting en temps réel avec auditd

sudo apt install -y auditd
sudo systemctl enable --now auditd

# Règles de surveillance critique
sudo tee /etc/audit/rules.d/itsc.rules <<'EOF'
-w /etc/passwd -p wa -k passwd_changes
-w /etc/shadow -p wa -k shadow_changes
-w /etc/sudoers -p wa -k sudoers_changes
-w /etc/ssh/sshd_config -p wa -k ssh_config
-a always,exit -F arch=b64 -S execve -F euid=0 -k root_exec
EOF

sudo augenrules --load
sudo systemctl restart auditd

# Consulter les événements
sudo ausearch -k sudoers_changes
sudo ausearch -k root_exec --start today

Checklist hebdomadaire

✓ Commandes 1-10 exécutées et logs archivés
✓ Aucun nouvel UID 0
✓ SUID list comparée à baseline
✓ /etc diff inspecté avec git
✓ rkhunter + chkrootkit sans alerte
✓ IPs brute-force bloquées (fail2ban)
✓ Mises à jour sécurité appliquées (unattended-upgrades)
✓ Baselines à jour dans le wiki interne

Étape 1 : préparer l’environnement d’audit

Avant de lancer la moindre commande sur un serveur de production basé à Dakar, Abidjan ou Lomé, ouvrez une session SSH avec un utilisateur sudo et créez un répertoire dédié aux logs d’audit. Tous les outputs seront archivés pour la traçabilité.

# Préparer le dossier d'audit horodaté
sudo mkdir -p /root/audit/$(date +%Y-%m-%d)
cd /root/audit/$(date +%Y-%m-%d)
# Vérifier la version OS
cat /etc/os-release | grep PRETTY_NAME

La sortie attendue affiche Ubuntu 24.04 LTS, Debian 12, ou AlmaLinux 9. Si l’OS est en fin de vie (Ubuntu 18.04, CentOS 7), considérez la migration comme priorité avant tout audit — un système non patché reste vulnérable.

Étape 2 : commande 1 — auditer les utilisateurs et sessions actives

Le premier réflexe consiste à identifier qui est connecté et qui peut se connecter. Une session inattendue à 03h00 GMT est un signal d’alerte fort, surtout sur un serveur exposé en Afrique de l’Ouest.

# Sessions actives et historique
who -a
last -F | head -30
# Comptes avec un shell de connexion
awk -F: '$7 !~ /(nologin|false)/ {print $1}' /etc/passwd

Une ligne still logged in sur un compte que vous ne reconnaissez pas justifie un blocage immédiat avec sudo passwd -l user. La liste des shells valides ne devrait contenir que root et vos administrateurs identifiés.

Étape 3 : commande 2 — vérifier les sudoers et privilèges escaladés

Une mauvaise configuration sudoers est la cause numéro un d’élévation de privilèges en production. Auditez le fichier principal et les drop-ins dans /etc/sudoers.d/.

# Lister tous les sudoers actifs
sudo cat /etc/sudoers /etc/sudoers.d/*
# Vérifier la syntaxe avant toute modification
sudo visudo -c

Repérez les lignes NOPASSWD: ALL qui sont rarement justifiées. Sur un serveur web public, seul un utilisateur de déploiement CI peut éventuellement avoir un sudo passwordless, et uniquement sur une commande précise.

Étape 4 : commande 3 — détecter les processus suspects

Un cryptominer ou un reverse shell se cache souvent derrière un nom de processus innocent comme kworker ou systemd-helper. Croisez la consommation CPU avec le binaire réel.

# Top 10 des processus par CPU
ps aux --sort=-%cpu | head -11
# Vérifier le binaire d'un PID suspect
sudo ls -la /proc/PID/exe
sudo ls -la /proc/PID/cwd

Un processus dont le binaire pointe vers /tmp, /dev/shm ou /var/tmp est presque toujours malveillant. Tuez-le avec sudo kill -9 puis investiguez la chaîne d’infection avant de redémarrer le service légitime.

Étape 5 : commande 4 — auditer les ports ouverts et services exposés

Tout port ouvert vers Internet doit être justifié. Sur un serveur applicatif derrière un reverse proxy Nginx, seuls 22, 80 et 443 devraient être accessibles publiquement.

# Sockets en écoute (TCP/UDP)
sudo ss -tulnp
# Vérifier le pare-feu UFW
sudo ufw status verbose
# Vérifier nftables / iptables
sudo nft list ruleset | head -50

Un Redis exposé sur 0.0.0.0:6379 est un cas classique de fuite — passez-le sur 127.0.0.1 ou activez l’authentification. Un PostgreSQL ou MySQL en écoute publique doit être immédiatement réservé au localhost ou à un VPN WireGuard.

Étape 6 : commande 5 — analyser les logs d’authentification SSH

Les tentatives de bruteforce SSH représentent 80 % du bruit en production. Identifiez les IP attaquantes et les comptes ciblés pour ajuster fail2ban ou bannir les pays inutiles.

# Échecs de connexion SSH (Debian/Ubuntu)
sudo grep "Failed password" /var/log/auth.log | tail -50
# Top 10 IP attaquantes
sudo grep "Failed password" /var/log/auth.log \
  | awk '{print $11}' | sort | uniq -c | sort -nr | head

Si une IP cumule plus de 100 échecs, ajoutez-la définitivement à votre pare-feu. Pour un serveur ne servant que l’Afrique de l’Ouest, bloquer les ranges asiatiques connus pour leur activité offensive réduit le bruit de 90 %.

Étape 7 : commande 6 — vérifier l’intégrité des fichiers critiques

Un attaquant persiste souvent en modifiant /etc/passwd, /etc/shadow, ou les binaires /bin/ls et /usr/sbin/sshd. Comparez les hashes avec ceux du paquet officiel.

# Vérifier l'intégrité des paquets installés (Debian/Ubuntu)
sudo apt install debsums
sudo debsums -c
# RHEL / AlmaLinux
sudo rpm -Va | grep -v "^.{8}c"

Toute différence sur un binaire système exige une investigation immédiate. Une modification légitime arrive uniquement après apt upgrade et est tracée dans /var/log/dpkg.log. Sinon, c’est un rootkit potentiel.

Étape 8 : commande 7 — auditer les tâches cron et systemd timers

La persistance malveillante passe souvent par un cron caché ou un timer systemd. Listez exhaustivement toutes les planifications utilisateur et système.

# Crons utilisateur (tous les utilisateurs)
for u in $(cut -f1 -d: /etc/passwd); do
  sudo crontab -u $u -l 2>/dev/null && echo "user: $u"
done
# Timers systemd actifs
systemctl list-timers --all

Un cron qui télécharge un script depuis raw.githubusercontent.com ou pastebin.com à intervalle régulier est typiquement un downloader de malware. Supprimez-le et investiguez le compte utilisateur compromis.

Étape 9 : commande 8 — détecter les binaires SUID/SGID suspects

Les binaires avec bit SUID s’exécutent avec les privilèges de leur propriétaire. Un nouveau SUID sur le système est souvent une porte dérobée.

# Lister tous les SUID/SGID
sudo find / -type f \( -perm -4000 -o -perm -2000 \) \
  -exec ls -la {} \; 2>/dev/null > suid-actuels.txt
# Comparer à un baseline antérieur
diff suid-baseline.txt suid-actuels.txt

Conservez un baseline de référence après installation propre. Toute apparition de /tmp/.x ou /usr/local/bin/inconnu avec SUID root est un signal d’alarme rouge — isolez immédiatement le serveur du réseau.

Étape 10 : commande 9 — vérifier les paquets non patchés

Une vulnérabilité non patchée comme une CVE Linux kernel récente offre une élévation locale immédiate. Auditez régulièrement les paquets en retard de mise à jour.

# Debian/Ubuntu : lister les paquets de sécurité disponibles
sudo apt update
sudo apt list --upgradable 2>/dev/null | grep -i security
# RHEL/AlmaLinux
sudo dnf updateinfo list security

Sur un serveur de production, planifiez les apt upgrade de sécurité hebdomadairement. Un délai de patch supérieur à 30 jours expose à des exploits publics largement diffusés sur Telegram et les forums underground.

Étape 11 : commande 10 — auditer les modules kernel et rootkits

Un rootkit kernel moderne se cache des outils utilisateur classiques. Utilisez chkrootkit et rkhunter en complément de vos audits manuels.

# Installer et lancer rkhunter
sudo apt install rkhunter chkrootkit
sudo rkhunter --update
sudo rkhunter --check --skip-keypress
sudo chkrootkit | grep -v "not found\|nothing detected"

Une détection positive ne signifie pas toujours infection (faux positifs fréquents), mais doit toujours être investiguée manuellement. En cas de doute sérieux, redémarrez depuis un live USB et montez le disque en lecture seule pour analyse forensique.

Étape 12 : automatiser l’audit avec un script hebdomadaire

Pour un parc de plusieurs serveurs, automatisez l’exécution des 10 commandes et envoyez le rapport par email ou dans un canal Slack dédié.

# /usr/local/bin/audit-weekly.sh
#!/bin/bash
LOG=/var/log/audit-$(date +%Y%m%d).log
{
  echo "=== Sessions ==="; who -a
  echo "=== Sudoers ==="; cat /etc/sudoers.d/*
  echo "=== Top CPU ==="; ps aux --sort=-%cpu | head -5
  echo "=== Ports ==="; ss -tulnp
  echo "=== SSH fails ==="; grep "Failed" /var/log/auth.log | wc -l
} > $LOG
mail -s "Audit hebdo" admin@exemple.io < $LOG

Planifiez ce script via cron chaque lundi à 06h00 GMT. Le rapport arrive avant la prise de poste à Dakar et permet une revue rapide en moins de 10 minutes.

Pour approfondir, consultez notre guide pour durcir SSH en production et le tutoriel configurer fail2ban sur Ubuntu et Debian.