Saviez-vous qu’un serveur Ubuntu exposé sur Internet sans configuration de sécurité reçoit en moyenne ses premières tentatives d’intrusion dans les 30 minutes suivant sa mise en ligne ? Au Togo comme partout ailleurs, les cyberattaques ne font pas de discrimination : PME de Lomé, agences de Kara ou entreprises de Sokodé sont toutes des cibles potentielles.

Pourtant, la grande majorité des PME togolaises qui nous contactent après un incident ont un point commun : leur serveur fonctionnait avec la configuration par défaut d’Ubuntu. Mot de passe root actif, SSH ouvert sur le port 22, pas de pare-feu, aucune surveillance. Un profil que les robots d’attaque automatisés repèrent en quelques minutes.

Dans ce guide, vous allez apprendre à sécuriser votre serveur Ubuntu en 10 étapes concrètes et testées, adaptées aux réalités du terrain au Togo : coupures CEET, connexions instables, budgets serrés. À la fin de cet article, votre serveur sera considérablement plus difficile à compromettre, et vous disposerez d’un système de surveillance opérationnel.

Table des Matières

1. Prérequis
2. Étape 1 : Mettre à jour le système
3. Étape 2 : Créer un utilisateur administrateur non-root
4. Étape 3 : Sécuriser SSH
5. Étape 4 : Configurer le pare-feu UFW
6. Étape 5 : Installer et configurer Fail2ban
7. Étape 6 : Activer les mises à jour automatiques de sécurité
8. Étape 7 : Sécuriser le noyau Linux avec Sysctl
9. Étape 8 : Détecter les rootkits avec RKHunter
10. Étape 9 : Mettre en place des sauvegardes automatiques
11. Étape 10 : Surveiller et recevoir des alertes
12. Adaptations pour le contexte local togolais
13. Troubleshooting
14. Ressources Complémentaires

Prérequis

Matériel Nécessaire

Vous pouvez appliquer ce guide sur un serveur physique local ou un VPS (serveur privé virtuel). Les deux options sont valides pour une PME togolaise.

• Serveur physique local : PC reconverti (Core i3/i5, 4 Go RAM minimum) coût 0 FCFA si vous en avez déjà un
• VPS Hetzner CX22 (recommandé pour démarrer) : 6 000 à 10 000 FCFA/mois
• Onduleur 650VA minimum si serveur local (APC/Eaton) : ~45 000 à 65 000 FCFA indispensable face aux coupures CEET

Spécificité Locale : Si votre serveur est hébergé localement à Lomé, un onduleur n’est pas une option, c’est une obligation. Une coupure CEET pendant une opération d’écriture disque peut corrompre votre système de fichiers et rendre le serveur inutilisable.

Logiciels Requis

• Ubuntu Server 22.04 LTS ou 24.04 LTS (versions supportées jusqu’en 2027 et 2029)
• Accès SSH fonctionnel au serveur
• Terminal (Linux/macOS) ou PuTTY (Windows)

Compétences Requises

• Connaissances de base en ligne de commande Linux (navigation, édition de fichiers)
• Savoir se connecter en SSH à un serveur distant
• Avoir des notions de base en réseau (IP, ports)

Accès et Permissions

• Accès root ou sudo au serveur
• Adresse IP du serveur
• Connexion internet stable (fibre YAS TOGO ou 4G MOOV recommandée pour cette session)

Étape 1 : Mettre à jour le système

La première règle de sécurité est la plus simple : un système à jour est un système moins vulnérable. Les mises à jour corrigent des failles de sécurité découvertes chaque semaine dans les logiciels.

Connectez-vous à votre serveur en SSH puis exécutez :

# Mettre à jour la liste des paquets disponibles
sudo apt update

# Appliquer toutes les mises à jour disponibles
sudo apt upgrade -y

# Supprimer les paquets inutiles
sudo apt autoremove -y

# Vider le cache des paquets téléchargés
sudo apt clean

# Mettre à jour la liste des paquets disponibles
sudo apt update

# Appliquer toutes les mises à jour disponibles
sudo apt upgrade -y

# Supprimer les paquets inutiles
sudo apt autoremove -y

# Vider le cache des paquets téléchargés
sudo apt clean

Si le système vous indique qu’un redémarrage est nécessaire (présence du fichier /var/run/reboot-required), redémarrez :

# Vérifier si un redémarrage est nécessaire
cat /var/run/reboot-required 2>/dev/null && echo "Redémarrage requis" || echo "Pas de redémarrage nécessaire"

# Redémarrer si nécessaire
sudo reboot

# Vérifier si un redémarrage est nécessaire
cat /var/run/reboot-required 2>/dev/null && echo "Redémarrage requis" || echo "Pas de redémarrage nécessaire"

# Redémarrer si nécessaire
sudo reboot

⚠️ Attention : Si vous êtes connecté via SSH, la commande reboot va fermer votre connexion. Reconnectez-vous après 1 à 2 minutes.

✅ À ce stade, votre serveur tourne avec les derniers correctifs de sécurité disponibles.

Étape 2 : Créer un utilisateur administrateur non-root

Travailler directement en tant que root est une mauvaise pratique : toute commande mal saisie ou toute intrusion réussie a un impact immédiat sur tout le système. Créez un utilisateur dédié avec des droits sudo.

# Créer un nouvel utilisateur (remplacez "adminpme" par le nom souhaité)
sudo adduser adminpme

# Ajouter cet utilisateur au groupe sudo
sudo usermod -aG sudo adminpme

# Vérifier que l'utilisateur appartient bien au groupe sudo
groups adminpme

# Créer un nouvel utilisateur (remplacez "adminpme" par le nom souhaité)
sudo adduser adminpme

# Ajouter cet utilisateur au groupe sudo
sudo usermod -aG sudo adminpme

# Vérifier que l'utilisateur appartient bien au groupe sudo
groups adminpme

Résultat attendu :

adminpme : adminpme sudo

adminpme : adminpme sudo

Testez immédiatement votre nouvel utilisateur dans une nouvelle fenêtre SSH avant de continuer (ne fermez pas la session root tant que vous n’avez pas vérifié) :

# Dans une NOUVELLE fenêtre SSH, connectez-vous avec le nouvel utilisateur
ssh adminpme@IP_DU_SERVEUR

# Vérifiez que sudo fonctionne
sudo whoami
# Résultat attendu : root

# Dans une NOUVELLE fenêtre SSH, connectez-vous avec le nouvel utilisateur
ssh adminpme@IP_DU_SERVEUR

# Vérifiez que sudo fonctionne
sudo whoami
# Résultat attendu : root

✅ Bonne Pratique : Choisissez un nom d’utilisateur non évident. Évitez « admin », « user », « ubuntu » — ces noms sont testés en premier par les attaquants.

Étape 3 : Sécuriser SSH

SSH (Secure Shell) est la porte d’entrée principale de votre serveur. Sa configuration par défaut comporte plusieurs failles qu’il faut corriger immédiatement.

3a : Générer et déployer une clé SSH (authentification sans mot de passe)

Sur votre machine locale (votre PC, pas le serveur) :

# Générer une paire de clés SSH Ed25519 (plus sécurisée que RSA)
ssh-keygen -t ed25519 -C "admin-pme-togo-$(date +%Y)"

# Copier la clé publique sur le serveur
ssh-copy-id adminpme@IP_DU_SERVEUR

# Générer une paire de clés SSH Ed25519 (plus sécurisée que RSA)
ssh-keygen -t ed25519 -C "admin-pme-togo-$(date +%Y)"

# Copier la clé publique sur le serveur
ssh-copy-id adminpme@IP_DU_SERVEUR

Testez la connexion par clé avant de désactiver les mots de passe :

# Connexion sans mot de passe (ne devrait pas demander de mot de passe)
ssh adminpme@IP_DU_SERVEUR

# Connexion sans mot de passe (ne devrait pas demander de mot de passe)
ssh adminpme@IP_DU_SERVEUR

3b : Durcir la configuration SSH

# Sauvegarder la configuration originale<br>
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup
# Éditer la configuration SSH
sudo nano /etc/ssh/sshd_config

# Sauvegarder la configuration originale<br>
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup
# Éditer la configuration SSH
sudo nano /etc/ssh/sshd_config

Modifiez ou ajoutez ces paramètres :

# Changer le port SSH (évite les scans automatiques sur le port 22)
Port 2222

# Désactiver la connexion root directe
PermitRootLogin no

# Désactiver l'authentification par mot de passe (clé SSH uniquement)
PasswordAuthentication no

# Limiter à 3 tentatives de connexion
MaxAuthTries 3

# Timeout de connexion inactive (5 minutes)
ClientAliveInterval 300
ClientAliveCountMax 2

# Désactiver les fonctionnalités inutiles
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no

# Autoriser uniquement votre utilisateur admin
AllowUsers adminpme

# Changer le port SSH (évite les scans automatiques sur le port 22)
Port 2222

# Désactiver la connexion root directe
PermitRootLogin no

# Désactiver l'authentification par mot de passe (clé SSH uniquement)
PasswordAuthentication no

# Limiter à 3 tentatives de connexion
MaxAuthTries 3

# Timeout de connexion inactive (5 minutes)
ClientAliveInterval 300
ClientAliveCountMax 2

# Désactiver les fonctionnalités inutiles
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no

# Autoriser uniquement votre utilisateur admin
AllowUsers adminpme

Appliquez les changements :

# Vérifier la syntaxe avant de redémarrer
sudo sshd -t

# Redémarrer SSH si aucune erreur
sudo systemctl restart sshd

# Vérifier la syntaxe avant de redémarrer
sudo sshd -t

# Redémarrer SSH si aucune erreur
sudo systemctl restart sshd

⚠️ Attention : Avant de fermer votre session SSH actuelle, ouvrez une nouvelle connexion sur le port 2222 pour vérifier que tout fonctionne : ssh -p 2222 adminpme@IP_DU_SERVEUR. Ne fermez l’ancienne session qu’après avoir confirmé la connexion.

💡 Astuce Locale : Si vous vous connectez depuis une connexion 4G MOOV ou Togocel avec une IP dynamique, évitez de restreindre SSH à une IP fixe , votre adresse change à chaque reconnexion. Restez sur le changement de port et la clé SSH.

Étape 4 : Configurer le pare-feu UFW

UFW (Uncomplicated Firewall) est l’outil de gestion de pare-feu le plus simple pour Ubuntu. Il vous permet de contrôler précisément quels ports sont accessibles depuis Internet.

# Installer UFW si absent
sudo apt install ufw -y

# Politique par défaut : bloquer tout le trafic entrant
sudo ufw default deny incoming

# Politique par défaut : autoriser tout le trafic sortant
sudo ufw default allow outgoing

# Autoriser SSH sur le nouveau port (OBLIGATOIRE avant d'activer UFW !)
sudo ufw allow 2222/tcp comment 'SSH sécurisé'

# Autoriser les services web si nécessaire
sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'

# Activer le pare-feu
sudo ufw enable

# Vérifier l'état
sudo ufw status verbose

# Installer UFW si absent
sudo apt install ufw -y

# Politique par défaut : bloquer tout le trafic entrant
sudo ufw default deny incoming

# Politique par défaut : autoriser tout le trafic sortant
sudo ufw default allow outgoing

# Autoriser SSH sur le nouveau port (OBLIGATOIRE avant d'activer UFW !)
sudo ufw allow 2222/tcp comment 'SSH sécurisé'

# Autoriser les services web si nécessaire
sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'

# Activer le pare-feu
sudo ufw enable

# Vérifier l'état
sudo ufw status verbose

Résultat attendu :

Status: active
To                         Action      From
--                         ------      ----
2222/tcp                   ALLOW IN    Anywhere
80/tcp                     ALLOW IN    Anywhere
443/tcp                    ALLOW IN    Anywhere

Status: active
To                         Action      From
--                         ------      ----
2222/tcp                   ALLOW IN    Anywhere
80/tcp                     ALLOW IN    Anywhere
443/tcp                    ALLOW IN    Anywhere

✅ Bonne Pratique : N’ouvrez que les ports dont vous avez réellement besoin. Chaque port ouvert est une surface d’attaque potentielle. Si vous n’hébergez pas de site web, ne pas ouvrir les ports 80 et 443.

Étape 5 : Installer et configurer Fail2ban

Fail2ban est un système de détection et blocage automatique des tentatives d’intrusion. Il analyse vos fichiers de log et bannit automatiquement les adresses IP qui échouent trop souvent à se connecter.

# Installer Fail2ban
sudo apt install fail2ban -y

# Créer votre fichier de configuration local (ne jamais modifier jail.conf directement)
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

# Éditer la configuration
sudo nano /etc/fail2ban/jail.local

# Installer Fail2ban
sudo apt install fail2ban -y

# Créer votre fichier de configuration local (ne jamais modifier jail.conf directement)
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

# Éditer la configuration
sudo nano /etc/fail2ban/jail.local

Modifiez la section [DEFAULT] :

[DEFAULT]
# Durée de bannissement : 1 heure (3600 secondes)
bantime  = 3600

# Fenêtre d'observation : 10 minutes
findtime  = 600

# Nombre maximum de tentatives avant bannissement
maxretry = 3

# Ignorer localhost
ignoreip = 127.0.0.1/8

[DEFAULT]
# Durée de bannissement : 1 heure (3600 secondes)
bantime  = 3600

# Fenêtre d'observation : 10 minutes
findtime  = 600

# Nombre maximum de tentatives avant bannissement
maxretry = 3

# Ignorer localhost
ignoreip = 127.0.0.1/8

Activez la protection SSH en ajoutant à la fin du fichier :

[sshd]
enabled  = true
port     = 2222
filter   = sshd
logpath  = /var/log/auth.log
maxretry = 3
bantime  = 86400

[sshd]
enabled  = true
port     = 2222
filter   = sshd
logpath  = /var/log/auth.log
maxretry = 3
bantime  = 86400

Démarrez et activez Fail2ban :

# Démarrer le service
sudo systemctl start fail2ban
sudo systemctl enable fail2ban

# Vérifier le statut
sudo fail2ban-client status sshd

# Démarrer le service
sudo systemctl start fail2ban
sudo systemctl enable fail2ban

# Vérifier le statut
sudo fail2ban-client status sshd

Pour consulter les IP bannies :

# Lister les IP actuellement bannies
sudo fail2ban-client status sshd | grep "Banned IP"

# Débannir une IP (si vous vous êtes accidentellement bloqué)
sudo fail2ban-client set sshd unbanip VOTRE_IP

# Lister les IP actuellement bannies
sudo fail2ban-client status sshd | grep "Banned IP"

# Débannir une IP (si vous vous êtes accidentellement bloqué)
sudo fail2ban-client set sshd unbanip VOTRE_IP

Résultat Client : Sur un serveur de PME que nous avons sécurisé à Lomé, Fail2ban a bloqué plus de 1 200 tentatives d’intrusion SSH en une seule semaine, toutes provenant de bots automatisés.

Étape 6 : Activer les mises à jour automatiques de sécurité

Les mises à jour de sécurité doivent être appliquées rapidement, mais vous n’êtes pas toujours disponible pour le faire manuellement. unattended-upgrades automatise ce processus.

# Installer le paquet
sudo apt install unattended-upgrades apt-listchanges -y

# Configurer les mises à jour automatiques
sudo dpkg-reconfigure --priority=low unattended-upgrades

# Installer le paquet
sudo apt install unattended-upgrades apt-listchanges -y

# Configurer les mises à jour automatiques
sudo dpkg-reconfigure --priority=low unattended-upgrades

Répondez Oui à la question posée. Puis affinez la configuration :

sudo nano /etc/apt/apt.conf.d/50unattended-upgrades

sudo nano /etc/apt/apt.conf.d/50unattended-upgrades

Vérifiez que ces lignes sont actives (non commentées) :

Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
};

// Redémarrage automatique si nécessaire (après les mises à jour kernel)
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "03:00";

Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
};

// Redémarrage automatique si nécessaire (après les mises à jour kernel)
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "03:00";

💡 Astuce Locale : Programmez le redémarrage automatique à 3h00 du matin, heure à laquelle les coupures CEET sont moins fréquentes à Lomé et l’activité de votre PME est nulle.

Étape 7 : Sécuriser le noyau Linux avec Sysctl

Le fichier sysctl.conf contrôle des paramètres bas niveau du noyau Linux. Certains réglages permettent de bloquer des types d’attaques réseau courantes (IP spoofing, SYN flood, etc.).

# Éditer la configuration sysctl
sudo nano /etc/sysctl.conf

# Éditer la configuration sysctl
sudo nano /etc/sysctl.conf

Ajoutez ces paramètres à la fin du fichier :

# =============================================
# SÉCURITÉ RÉSEAU — IT-ADMIN.TG
# =============================================

# Désactiver le forwarding IP (serveur, pas routeur)
net.ipv4.ip_forward = 0

# Protection contre le SYN flooding
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_syn_retries = 2
net.ipv4.tcp_synack_retries = 2

# Ignorer les paquets ICMP broadcast (Smurf attacks)
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Ignorer les réponses ICMP incorrectes
net.ipv4.icmp_ignore_bogus_error_responses = 1

# Protection contre l'IP spoofing
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# Désactiver l'acceptation des paquets source-routés
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0

# Désactiver l'acceptation des redirections ICMP
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0

# Ne pas envoyer de redirections ICMP
net.ipv4.conf.all.send_redirects = 0

# Journaliser les paquets avec des adresses source suspectes
net.ipv4.conf.all.log_martians = 1

# =============================================
# SÉCURITÉ RÉSEAU — IT-ADMIN.TG
# =============================================

# Désactiver le forwarding IP (serveur, pas routeur)
net.ipv4.ip_forward = 0

# Protection contre le SYN flooding
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_syn_retries = 2
net.ipv4.tcp_synack_retries = 2

# Ignorer les paquets ICMP broadcast (Smurf attacks)
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Ignorer les réponses ICMP incorrectes
net.ipv4.icmp_ignore_bogus_error_responses = 1

# Protection contre l'IP spoofing
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# Désactiver l'acceptation des paquets source-routés
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0

# Désactiver l'acceptation des redirections ICMP
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0

# Ne pas envoyer de redirections ICMP
net.ipv4.conf.all.send_redirects = 0

# Journaliser les paquets avec des adresses source suspectes
net.ipv4.conf.all.log_martians = 1

Appliquez immédiatement sans redémarrer :

sudo sysctl -p

sudo sysctl -p

Étape 8 : Détecter les rootkits avec RKHunter

Un rootkit est un logiciel malveillant qui se dissimule dans le système pour passer inaperçu. RKHunter (Rootkit Hunter) analyse votre serveur à la recherche de ces menaces.

bash

# Installer RKHunter
sudo apt install rkhunter -y

# Mettre à jour la base de données des rootkits connus
sudo rkhunter --update

# Initialiser la base de données de référence (à faire juste après installation)
sudo rkhunter --propupd

# Lancer une analyse complète
sudo rkhunter --check --sk

# Installer RKHunter
sudo apt install rkhunter -y

# Mettre à jour la base de données des rootkits connus
sudo rkhunter --update

# Initialiser la base de données de référence (à faire juste après installation)
sudo rkhunter --propupd

# Lancer une analyse complète
sudo rkhunter --check --sk

Automatisez l’analyse quotidienne avec un cron :

# Ouvrir le crontab root
sudo crontab -e

# Ouvrir le crontab root
sudo crontab -e

Ajoutez cette ligne pour une analyse chaque nuit à 2h00 avec rapport par email :

# Analyse RKHunter quotidienne à 2h00
0 2 * * * /usr/bin/rkhunter --check --sk --report-warnings-only 2>&1 | mail -s "[SERVEUR PME] Rapport RKHunter $(date +%d/%m/%Y)" votre@email.com

# Analyse RKHunter quotidienne à 2h00
0 2 * * * /usr/bin/rkhunter --check --sk --report-warnings-only 2>&1 | mail -s "[SERVEUR PME] Rapport RKHunter $(date +%d/%m/%Y)" [email protected]

✅ Bonne Pratique : Lancez rkhunter --propupd après chaque mise à jour majeure du système pour éviter les faux positifs. Les mises à jour changent des fichiers systèmes légitimes que RKHunter peut signaler comme suspects.

Étape 9 : Mettre en place des sauvegardes automatiques

La meilleure sécurité du monde ne vous protège pas contre une erreur humaine, une panne matérielle ou un cryptovirus réussi. Les sauvegardes sont votre dernier rempart.

Sauvegarde locale avec Rsync

# Créer un répertoire de sauvegarde
sudo mkdir -p /backup/quotidien
sudo mkdir -p /backup/hebdomadaire

# Script de sauvegarde — créer le fichier
sudo nano /usr/local/bin/backup-pme.sh

# Créer un répertoire de sauvegarde
sudo mkdir -p /backup/quotidien
sudo mkdir -p /backup/hebdomadaire

# Script de sauvegarde — créer le fichier
sudo nano /usr/local/bin/backup-pme.sh

Contenu du script :

#!/bin/bash
# ==============================================
# Script de sauvegarde PME — IT-ADMIN.TG
# ==============================================

DATE=$(date +%Y%m%d_%H%M%S)
BACKUP_DIR="/backup/quotidien"
LOG_FILE="/var/log/backup-pme.log"

echo "[$DATE] Début sauvegarde..." >> $LOG_FILE

# Sauvegarder /etc (configurations système)
rsync -av --delete /etc/ $BACKUP_DIR/etc/ >> $LOG_FILE 2>&1

# Sauvegarder /var/www (sites web si présents)
rsync -av --delete /var/www/ $BACKUP_DIR/www/ >> $LOG_FILE 2>&1

# Sauvegarder les home des utilisateurs
rsync -av --delete /home/ $BACKUP_DIR/home/ >> $LOG_FILE 2>&1

echo "[$DATE] Sauvegarde terminée." >> $LOG_FILE

#!/bin/bash
# ==============================================
# Script de sauvegarde PME — IT-ADMIN.TG
# ==============================================

DATE=$(date +%Y%m%d_%H%M%S)
BACKUP_DIR="/backup/quotidien"
LOG_FILE="/var/log/backup-pme.log"

echo "[$DATE] Début sauvegarde..." >> $LOG_FILE

# Sauvegarder /etc (configurations système)
rsync -av --delete /etc/ $BACKUP_DIR/etc/ >> $LOG_FILE 2>&1

# Sauvegarder /var/www (sites web si présents)
rsync -av --delete /var/www/ $BACKUP_DIR/www/ >> $LOG_FILE 2>&1

# Sauvegarder les home des utilisateurs
rsync -av --delete /home/ $BACKUP_DIR/home/ >> $LOG_FILE 2>&1

echo "[$DATE] Sauvegarde terminée." >> $LOG_FILE

# Rendre le script exécutable
sudo chmod +x /usr/local/bin/backup-pme.sh

# Automatiser via cron (sauvegarde quotidienne à 1h00)
sudo crontab -e

# Rendre le script exécutable
sudo chmod +x /usr/local/bin/backup-pme.sh

# Automatiser via cron (sauvegarde quotidienne à 1h00)
sudo crontab -e

# Sauvegarde quotidienne à 1h00
0 1 * * * /usr/local/bin/backup-pme.sh

# Nettoyage des sauvegardes de plus de 30 jours
0 3 * * 0 find /backup/quotidien -type f -mtime +30 -delete

# Sauvegarde quotidienne à 1h00
0 1 * * * /usr/local/bin/backup-pme.sh

# Nettoyage des sauvegardes de plus de 30 jours
0 3 * * 0 find /backup/quotidien -type f -mtime +30 -delete

💡 Astuce Locale : Pour les PME togolaises avec un serveur local, connectez un disque dur externe USB (25 000 à 35 000 FCFA pour 1 TB) monté automatiquement comme destination de sauvegarde. En cas de panne du serveur principal, vos données sont sur un support physique indépendant.

Étape 10 : Surveiller et recevoir des alertes

Un serveur non surveillé est un serveur dont vous découvrirez les problèmes trop tard. Mettez en place un système d’alertes minimal mais efficace.

Installation de Logwatch (rapport email quotidien)

# Installer Logwatch
sudo apt install logwatch mailutils -y

# Tester un rapport immédiat
sudo logwatch --output stdout --format text --range today --detail low

# Installer Logwatch
sudo apt install logwatch mailutils -y

# Tester un rapport immédiat
sudo logwatch --output stdout --format text --range today --detail low

Configurez l’envoi quotidien :

sudo nano /etc/cron.daily/00logwatch

sudo nano /etc/cron.daily/00logwatch

#!/bin/bash
/usr/sbin/logwatch \
  --output mail \
  --mailto votre@email.com \
  --detail low \
  --range yesterday \
  --service all

#!/bin/bash
/usr/sbin/logwatch \
  --output mail \
  --mailto [email protected] \
  --detail low \
  --range yesterday \
  --service all

Surveillance des ressources avec un script d’alerte

sudo nano /usr/local/bin/alerte-ressources.sh

sudo nano /usr/local/bin/alerte-ressources.sh

#!/bin/bash
# Alerte si CPU > 90% ou disque > 85%
CPU=$(top -bn1 | grep "Cpu(s)" | awk '{print $2}' | cut -d'%' -f1 | cut -d',' -f1)
DISK=$(df / | tail -1 | awk '{print $5}' | cut -d'%' -f1)

if [ "$CPU" -gt 90 ] || [ "$DISK" -gt 85 ]; then
    echo "⚠️ ALERTE SERVEUR PME — $(date)
CPU: ${CPU}%
Disque: ${DISK}%" | mail -s "🚨 Alerte Serveur Critique" votre@email.com
fi

#!/bin/bash
# Alerte si CPU > 90% ou disque > 85%
CPU=$(top -bn1 | grep "Cpu(s)" | awk '{print $2}' | cut -d'%' -f1 | cut -d',' -f1)
DISK=$(df / | tail -1 | awk '{print $5}' | cut -d'%' -f1)

if [ "$CPU" -gt 90 ] || [ "$DISK" -gt 85 ]; then
    echo "⚠️ ALERTE SERVEUR PME — $(date)
CPU: ${CPU}%
Disque: ${DISK}%" | mail -s "🚨 Alerte Serveur Critique" [email protected]
fi

sudo chmod +x /usr/local/bin/alerte-ressources.sh

# Vérification toutes les 15 minutes
sudo crontab -e
# Ajouter :
*/15 * * * * /usr/local/bin/alerte-ressources.sh

sudo chmod +x /usr/local/bin/alerte-ressources.sh

# Vérification toutes les 15 minutes
sudo crontab -e
# Ajouter :
*/15 * * * * /usr/local/bin/alerte-ressources.sh

✅ À ce stade, votre serveur Ubuntu est protégé sur 10 niveaux distincts. Vous recevrez désormais des rapports quotidiens et des alertes critiques directement par email.

Adaptations pour le Contexte Local Togolais

Gestion des Coupures CEET

Pour un serveur physique hébergé localement, les coupures d’électricité sont la première cause de panne et de corruption de données au Togo.

# Installer NUT (Network UPS Tools) pour surveiller votre onduleur
sudo apt install nut -y

# Script de shutdown gracieux en cas de batterie faible
sudo nano /etc/nut/upsmon.conf

# Installer NUT (Network UPS Tools) pour surveiller votre onduleur
sudo apt install nut -y

# Script de shutdown gracieux en cas de batterie faible
sudo nano /etc/nut/upsmon.conf

Ajoutez dans la configuration NUT :

SHUTDOWNCMD "/sbin/shutdown -h +2 'Coupure CEET — arrêt automatique'"
POWERDOWNFLAG /etc/killpower
MINSUPPLIES 1

SHUTDOWNCMD "/sbin/shutdown -h +2 'Coupure CEET — arrêt automatique'"
POWERDOWNFLAG /etc/killpower
MINSUPPLIES 1

Spécificité Locale : Un onduleur 1000VA minimum est recommandé pour un serveur avec disque dur en fonctionnement. Il vous donnera environ 15 à 20 minutes d’autonomie, suffisant pour un arrêt propre. Budget : 70 000 à 100 000 FCFA.

Optimisation pour Bande Passante Limitée

Si votre serveur est géré depuis une connexion 4G, réduisez la consommation de bande passante des mises à jour :

# Configurer APT pour limiter la bande passante des téléchargements
sudo nano /etc/apt/apt.conf.d/99bandwidth

# Configurer APT pour limiter la bande passante des téléchargements
sudo nano /etc/apt/apt.conf.d/99bandwidth

Acquire::http::Dl-Limit "500";  // Limite à 500 KB/s

Acquire::http::Dl-Limit "500";  // Limite à 500 KB/s

VPS vs Serveur Local : Quel Choix pour votre PME ?

Troubleshooting

Problème : SSH ne répond plus après changement de port

Symptôme : Impossible de se connecter après avoir changé le port SSH dans sshd_config.

Cause probable : UFW bloque le nouveau port, ou la syntaxe du port dans sshd_config est incorrecte.

Solution :

# Vérifier que UFW autorise le nouveau port
sudo ufw status | grep 2222

# Si absent, autoriser le port
sudo ufw allow 2222/tcp

# Si accès console disponible, vérifier la config SSH
sudo grep "^Port" /etc/ssh/sshd_config

# Vérifier que UFW autorise le nouveau port
sudo ufw status | grep 2222

# Si absent, autoriser le port
sudo ufw allow 2222/tcp

# Si accès console disponible, vérifier la config SSH
sudo grep "^Port" /etc/ssh/sshd_config

Prévention : Toujours tester la connexion sur le nouveau port avant de fermer la session courante.

Problème : Fail2ban bloque votre propre IP

Symptôme : Connexion SSH refusée après plusieurs tentatives ratées.

Cause probable : Vous avez dépassé le maxretry configuré.

Solution :

# Depuis la console du serveur (ou via l'interface d'urgence du VPS)
sudo fail2ban-client set sshd unbanip VOTRE_IP_PUBLIQUE

# Trouver votre IP publique
curl ifconfig.me

# Depuis la console du serveur (ou via l'interface d'urgence du VPS)
sudo fail2ban-client set sshd unbanip VOTRE_IP_PUBLIQUE

# Trouver votre IP publique
curl ifconfig.me

Prévention : Ajoutez votre IP fixe dans ignoreip de /etc/fail2ban/jail.local.

Problème : UFW activé mais services web inaccessibles

Symptôme : Site web ou application inaccessible depuis l’extérieur après activation d’UFW.

Cause probable : Ports 80 et/ou 443 non ouverts avant l’activation du pare-feu.

Solution :

# Ouvrir les ports web
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Vérifier l'état
sudo ufw status numbered

# Ouvrir les ports web
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Vérifier l'état
sudo ufw status numbered

Problème : RKHunter signale des avertissements après une mise à jour

Symptôme : Rapport RKHunter avec de nombreux « Warning » après apt upgrade.

Cause probable : Les fichiers système ont légitimement changé avec la mise à jour.

Solution :

# Mettre à jour la base de référence après chaque mise à jour système
sudo rkhunter --propupd

# Mettre à jour la base de référence après chaque mise à jour système
sudo rkhunter --propupd

Problème : Disque plein à cause des logs

Symptôme : Serveur lent, messages d’erreur « No space left on device ».

Cause probable : Accumulation de fichiers de log non purgés.

Solution :

# Voir les 10 plus gros dossiers
sudo du -sh /* 2>/dev/null | sort -rh | head -10

# Purger les anciens journaux systemd
sudo journalctl --vacuum-time=30d

# Configurer la rotation automatique des logs
sudo nano /etc/logrotate.conf
# Vérifier que "rotate 4" et "weekly" sont présents

# Voir les 10 plus gros dossiers
sudo du -sh /* 2>/dev/null | sort -rh | head -10

# Purger les anciens journaux systemd
sudo journalctl --vacuum-time=30d

# Configurer la rotation automatique des logs
sudo nano /etc/logrotate.conf
# Vérifier que "rotate 4" et "weekly" sont présents

Problème : Serveur inaccessible après coupure CEET

Symptôme : Impossible de se connecter au serveur local après une coupure de courant.

Cause probable : Corruption du système de fichiers ou service SSH non redémarré automatiquement.

Solution :

# Accès physique requis vérifier les erreurs au démarrage
# Depuis la console locale, lancer une vérification du système de fichiers
sudo fsck -y /dev/sda1

# Vérifier que SSH démarre automatiquement
sudo systemctl enable sshd
sudo systemctl start sshd

# Accès physique requis vérifier les erreurs au démarrage
# Depuis la console locale, lancer une vérification du système de fichiers
sudo fsck -y /dev/sda1

# Vérifier que SSH démarre automatiquement
sudo systemctl enable sshd
sudo systemctl start sshd

Prévention : Onduleur 1000VA + configuration NUT pour shutdown propre automatique.

Vous venez d’appliquer 10 couches de protection à votre serveur Ubuntu :

1. ✅ Système à jour : failles connues corrigées
2. ✅ Utilisateur non-root : principe du moindre privilège
3. ✅ SSH durci : port changé, clé uniquement, root désactivé
4. ✅ Pare-feu UFW : seuls les ports nécessaires sont ouverts
5. ✅ Fail2ban : blocage automatique des attaquants
6. ✅ Mises à jour automatiques : sécurité maintenue sans intervention
7. ✅ Sysctl durci : protection réseau bas niveau
8. ✅ RKHunter : détection de rootkits
9. ✅ Sauvegardes automatiques : récupération en cas d’incident
10. ✅ Surveillance et alertes : vous êtes informé avant qu’il soit trop tard

Votre PME togolaise mérite une infrastructure sécurisée.

Vous n’avez pas le temps d’appliquer ces étapes vous-même, ou vous souhaitez un audit complet de votre infrastructure actuelle ? IT-ADMIN intervient à Lomé et à distance pour sécuriser les serveurs des PME togolaises et ouest-africaines.

Ressources Complémentaires

Documentation Officielle

• Ubuntu Security Guide
• Documentation UFW
• Documentation Fail2ban

Communautés

• Forum Ubuntu Francophone : ubuntuforums.org