Notes › _DIFFUSION

scripts ou application pour "check" complet serveur debian Pour un check complet d’un serveur Debian, je recommande cette combinaison :

• Lynis : audit général de sécurité et configuration.
• Smartmontools : état S.M.A.R.T. des disques.
• Debsecan : vulnérabilités liées aux paquets installés.
• AIDE : détection de modifications de fichiers.
• auditd : journalisation et audit système.
• sysstat : CPU, mémoire, disque et réseau.
• rkhunter ou chkrootkit : recherche d’éléments suspects, avec résultats à interpréter prudemment.

Installation des outils

sudo apt update
sudo apt install -y \
  lynis \
  needrestart \
  smartmontools \
  curl \
  ca-certificates

Compléments

sudo apt update
sudo apt install -y \
  debsecan \
  aide \
  auditd \
  audispd-plugins \
  sysstat \
  rkhunter \
  chkrootkit

Activez les services utiles :

sudo systemctl enable --now auditd
sudo systemctl enable --now sysstat

needrestart

needrestart inspecte les processus en cours d’exécution et détecte ceux qui utilisent d’anciennes versions de bibliothèques (glibc, OpenSSL, etc.) après une mise à jour. Il peut :

• Lister les daemons à redémarrer (-l)
• Redémarrer automatiquement certains services (-r a ou via configuration)
• S’intégrer avec apt/dpkg pour proposer un redémarrage après mise à jour

Pour redémarrage automatiquement des services concernés, éditer /etc/needrestart/needrestart.conf et activer l’option de redémarrage automatique (par exemple $nrconf{restart} = 'a';)

Une fois installé, on exécute :

sudo needrestart

pour voir quels services doivent être redémarrés après des mises à jour de bibliothèques

Audit principal avec Lynis

sudo lynis audit system

Pour enregistrer le rapport :

sudo lynis audit system \
  --no-colors \
  --quiet \
  > /var/log/lynis-audit.txt

Le rapport détaillé se trouve généralement ici :

/var/log/lynis.log
/var/log/lynis-report.dat

Commencez par corriger les éléments marqués Warning, puis consultez les recommandations :

sudo grep -E "warning|suggestion" /var/log/lynis.log

Vérifications rapides système

hostnamectl
uptime
uname -a
cat /etc/debian_version
systemctl --failed
df -hT
df -ih
free -h
ip -br addr
ss -tulpn

Processus et ressources :

top
ps aux --sort=-%cpu | head -20
ps aux --sort=-%mem | head -20

Paquets et mises à jour :

apt list --upgradable
dpkg --audit
sudo debsecan --suite "$(dpkg --print-architecture)"

Vérifiez aussi les dépôts configurés :

grep -RhvE '^\s*#|^\s*$' /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null

Réseau et services exposés

sudo ss -tulpn
sudo systemctl list-units --type=service --state=running
sudo systemctl --type=service --state=failed

Depuis une autre machine, utilisez éventuellement :

nmap -sV -Pn ADRESSE_IP

Ne lancez pas de scan agressif sur une infrastructure qui ne vous appartient pas.

Disques et stockage

Identifiez les disques :

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS,MODEL

Pour un disque SATA ou NVMe, adaptez le périphérique :

sudo smartctl -a /dev/sda
sudo smartctl -a /dev/nvme0

Test court :

sudo smartctl -t short /dev/sda

Consultez ensuite le résultat :

sudo smartctl -a /dev/sda

Sur une machine virtuelle, S.M.A.R.T. peut ne pas être disponible.

Intégrité et rootkits

Après avoir mis à jour les signatures :

sudo rkhunter --update
sudo rkhunter --propupd
sudo rkhunter --check --skip-keypress --report-warnings-only

Puis :

sudo chkrootkit

Attention : ces outils génèrent régulièrement des faux positifs. Vérifiez chaque alerte avant de supprimer ou modifier quoi que ce soit.

Initialiser AIDE

À faire seulement après avoir vérifié que le serveur est sain :

sudo aideinit
sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db

Contrôle ultérieur :

sudo aide --check

Script de contrôle simple

#!/usr/bin/env bash
set -u

REPORT="/var/log/server-check-$(date +%F-%H%M%S).log"

{
    echo "===== INFORMATIONS SYSTÈME ====="
    date
    hostnamectl
    uptime
    uname -a

    echo
    echo "===== DISQUES ====="
    df -hT
    df -ih
    lsblk

    echo
    echo "===== MÉMOIRE ====="
    free -h

    echo
    echo "===== SERVICES EN ÉCHEC ====="
    systemctl --failed || true

    echo
    echo "===== PORTS EN ÉCOUTE ====="
    ss -tulpn || true

    echo
    echo "===== PROCESSUS CPU ====="
    ps aux --sort=-%cpu | head -15

    echo
    echo "===== PROCESSUS MÉMOIRE ====="
    ps aux --sort=-%mem | head -15

    echo
    echo "===== MISES À JOUR ====="
    apt list --upgradable 2>/dev/null || true

    echo
    echo "===== AUDIT LYNIS ====="
    lynis audit system --no-colors --quiet || true
} 2>&1 | tee "$REPORT"

echo "Rapport enregistré dans : $REPORT"

Enregistrez-le puis exécutez-le :

sudo nano /usr/local/sbin/server-check.sh
sudo chmod 750 /usr/local/sbin/server-check.sh
sudo /usr/local/sbin/server-check.sh

Pour une solution plus professionnelle et centralisée, ajoutez Prometheus + Node Exporter + Grafana pour la supervision continue. Pour un contrôle ponctuel complet, Lynis + Smartmontools + Debsecan + AIDE constitue une très bonne base.

Serveur debian a les ports ouverts 53/tcp (technitium) 443 (ssl/nginx) et 80 (nginx) Utilisation "acme" pour renouvellement certificats du domaine Je souhaite fermer le port 80, possible ou comment identifier qui utilise le port 80? Vous pouvez fermer le port **80**, mais vérifiez d’abord le type de challenge ACME utilisé pour le renouvellement.

• HTTP-01 : nécessite que le port 80/TCP soit accessible depuis Internet.
• TLS-ALPN-01 : utilise le port 443/TCP.
• DNS-01 : utilise un enregistrement TXT DNS et ne nécessite ni le port 80 ni le port 443 pour le challenge.

Si votre client ACME utilise HTTP-01, fermer le port 80 fera échouer les renouvellements, sauf si vous passez à TLS-ALPN-01 ou DNS-01.

Identifier le processus qui utilise le port 80

Sur le serveur :

sudo ss -ltnp 'sport = :80'

ou :

sudo lsof -nP -iTCP:80 -sTCP:LISTEN

ou :

sudo fuser -v 80/tcp

Vous devriez obtenir quelque chose comme :

LISTEN 0 511 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=1234,fd=6))

Pour connaître le service associé au PID :

ps -fp 1234
sudo systemctl status nginx

Vérifiez également les sockets IPv6 :

sudo ss -ltnp | grep -E '(:80[[:space:]]|:80,)'

Vérifier la configuration Nginx

Recherchez toutes les directives utilisant le port 80 :

sudo nginx -T 2>/dev/null | grep -nE 'listen .*80|acme|well-known'

Exemples fréquents :

listen 80;
listen [::]:80;

Le répertoire ACME est souvent exposé ainsi :

location /.well-known/acme-challenge/ {
    root /var/www/html;
}

Si Nginx écoute sur 80 uniquement pour rediriger vers HTTPS, ceci ne ferme pas le port :

return 301 https://$host$request_uri;

Le port reste ouvert tant qu’un bloc contient listen 80.

Fermer le port 80 dans Nginx

Après avoir confirmé que le renouvellement n’utilise pas HTTP-01 :

1. Modifiez les fichiers de configuration :

sudo grep -RInE 'listen .*80|acme-challenge' \
  /etc/nginx/sites-enabled /etc/nginx/conf.d /etc/nginx/nginx.conf

1. Supprimez ou commentez les lignes du type :

listen 80;
listen [::]:80;

1. Testez la configuration :

sudo nginx -t

1. Rechargez Nginx :

sudo systemctl reload nginx

1. Vérifiez :

sudo ss -ltnp | grep ':80'

Aucune sortie ne devrait apparaître.

Fermer uniquement avec le pare-feu

Pour bloquer les connexions entrantes tout en laissant éventuellement Nginx écouter localement :

Avec UFW :

sudo ufw status verbose
sudo ufw delete allow 80/tcp
sudo ufw deny 80/tcp
sudo ufw reload

Avec nftables, exemple :

sudo nft add rule inet filter input tcp dport 80 drop

Cette règle nftables doit être ajoutée à votre configuration persistante, sinon elle peut disparaître au redémarrage.

Vérifiez aussi le pare-feu ou le groupe de sécurité du fournisseur VPS/cloud. Un test externe est utile :

nmap -Pn -p 80,443 votre-domaine.example

Vérifier le mode ACME

Identifiez le client et sa configuration :

systemctl list-timers --all | grep -Ei 'acme|cert|letsencrypt|certbot'

ps aux | grep -Ei 'acme|certbot|letsencrypt' | grep -v grep

Cherchez les configurations :

sudo find /etc -maxdepth 3 -type f \
  \( -iname '*acme*' -o -iname '*certbot*' -o -iname '*letsencrypt*' \) \
  2>/dev/null

Consultez les journaux :

sudo journalctl --since "30 days ago" | \
  grep -Ei 'acme|certbot|letsencrypt|http-01|tls-alpn|dns-01'

Si vous voyez http-01, le port 80 est requis. Si vous voyez dns-01 ou tls-alpn-01, vous pouvez normalement le fermer, après avoir effectué un renouvellement de test.

Pour Certbot, un test ressemble à :

sudo certbot renew --dry-run

Pour un client ACME différent, utilisez son option de simulation équivalente.

La séquence recommandée est donc : identifier le processus → identifier le challenge ACME → effectuer un renouvellement de test → retirer listen 80 de Nginx → bloquer également le port 80 au pare-feu → vérifier depuis l’extérieur.

acme DNS01 Nextcloud nginx 632: location ^~ /.well-known { 633: location = /.well-known/carddav { return 301 /remote.php/dav/; } 634: location = /.well-known/caldav { return 301 /remote.php/dav/; } 635: location /.well-known/acme-challenge { try_files $uri $uri/ =404; } 636: location /.well-known/pki-validation { try_files $uri $uri/ =404; } Avec ACME DNS-01, le renouvellement des certificats ne nécessite pas le port 80. Vous pouvez donc le fermer.

Cependant, ne supprimez pas entièrement le bloc /.well-known : Nextcloud utilise carddav et caldav, qui doivent rester accessibles via HTTPS sur le port 443.

Votre configuration :

location ^~ /.well-known {
    location = /.well-known/carddav {
        return 301 /remote.php/dav/;
    }

    location = /.well-known/caldav {
        return 301 /remote.php/dav/;
    }

    location /.well-known/acme-challenge {
        try_files $uri $uri/ =404;
    }

    location /.well-known/pki-validation {
        try_files $uri $uri/ =404;
    }
}

Avec DNS-01, vous pouvez supprimer les deux locations suivantes si elles ne servent pas à autre chose :

location /.well-known/acme-challenge {
    try_files $uri $uri/ =404;
}

location /.well-known/pki-validation {
    try_files $uri $uri/ =404;
}

Conservez :

location ^~ /.well-known {
    location = /.well-known/carddav {
        return 301 /remote.php/dav/;
    }

    location = /.well-known/caldav {
        return 301 /remote.php/dav/;
    }
}

Avant de modifier, vérifiez dans quel bloc ces lignes se trouvent :

sudo nginx -T 2>/dev/null | nl -ba | sed -n '610,650p'

Puis identifiez tous les listen :

sudo nginx -T 2>/dev/null | grep -nE 'listen .*(:80|80;)'

Si vous trouvez un bloc comme celui-ci :

server {
    listen 80;
    listen [::]:80;

    server_name cloud.example.com;
    ...
}

Vous pouvez soit le supprimer/désactiver, soit retirer ses directives listen 80 et listen [::]:80. Ne retirez pas le bloc HTTPS contenant :

listen 443 ssl;

Après modification :

sudo nginx -t
sudo systemctl reload nginx

Vérifiez ensuite que Nginx n’écoute plus sur 80 :

sudo ss -ltnp | grep ':80'

Puis bloquez également le port au pare-feu. Avec UFW :

sudo ufw status numbered
sudo ufw delete allow 80/tcp
sudo ufw deny 80/tcp
sudo ufw reload

Si vous avez un pare-feu chez votre hébergeur ou une security group cloud, supprimez aussi la règle entrante TCP/80.

Testez que Nextcloud continue à fournir les redirections DAV via HTTPS :

curl -I https://cloud.example.com/.well-known/caldav
curl -I https://cloud.example.com/.well-known/carddav

Vous devez obtenir une redirection vers :

/remote.php/dav/

Enfin, testez le renouvellement ACME :

sudo certbot renew --dry-run

ou utilisez la commande de simulation propre à votre client ACME. Le point important est de confirmer que la configuration utilise bien DNS-01 et non un fallback automatique vers HTTP-01.