Auditer la sécurité d’un serveur web et d’une boutique

Un serveur Linux peut sembler parfaitement fonctionnel alors qu’il est déjà compromis. Une backdoor discrète, un script injecté ou un compte administrateur frauduleux peuvent rester invisibles pendant des semaines sans provoquer de panne. Les cyberattaques actuelles privilégient la discrétion afin de conserver un accès durable aux systèmes. Réaliser un audit de sécurité régulier permet d’identifier ces anomalies, de renforcer le serveur et de protéger efficacement une boutique en ligne avant qu’un incident ne survienne.

Pourquoi réaliser régulièrement un audit de sécurité

Beaucoup d’administrateurs découvrent une compromission uniquement lorsqu’un client signale un comportement inhabituel ou qu’un moteur de recherche détecte un contenu malveillant. Pourtant, les premiers indices apparaissent souvent plusieurs jours, voire plusieurs semaines auparavant dans les journaux système.

Aujourd’hui, les attaques sont largement automatisées. Des robots analysent Internet en permanence afin d’identifier des serveurs Linux vulnérables, des installations Apache ou Nginx mal configurées, des versions obsolètes de PHP ou encore des boutiques PrestaShop dont certains modules présentent des failles connues.

Une fois la vulnérabilité exploitée, plusieurs scénarios sont possibles :

• installation d’un webshell PHP ;
• création d’un compte administrateur caché ;
• modification de fichiers du site ;
• injection de JavaScript destiné à voler des données bancaires ;
• utilisation du serveur pour envoyer des courriels frauduleux.

Le véritable danger réside dans le fait que ces attaques restent souvent totalement silencieuses. Le site continue de fonctionner normalement tandis que le pirate conserve un accès permanent au serveur.

Un audit sécurité ne consiste donc pas uniquement à rechercher un malware. Il permet de vérifier que le système correspond toujours à son état attendu et qu’aucune modification suspecte n’a été introduite.

Durcir son serveur web

L’audit est indispensable, mais il reste incomplet sans une politique de durcissement du serveur. L’objectif consiste à limiter au maximum les possibilités d’exploitation en supprimant les points faibles les plus courants.

Installer systématiquement les mises à jour

La majorité des compromissions exploite des vulnérabilités déjà corrigées par les éditeurs.

Sur Debian, quelques commandes suffisent pour maintenir le système à jour :

apt update
apt upgrade
apt autoremove

Les mises à jour concernent également Apache, Nginx, PHP, MariaDB, OpenSSL, OpenSSH ainsi que les différents modules installés.

Il est conseillé de planifier cette opération régulièrement et de tester les mises à jour sur une plateforme de préproduction lorsque le serveur héberge une boutique critique.

Désactiver les services inutiles

Au fil des années, un serveur accumule souvent des services devenus inutiles.

Pour connaître les ports ouverts :

ss -tulpn

Pour afficher les services actifs :

systemctl list-units --type=service

Chaque service exposé inutilement augmente la surface d’attaque. Désactiver un démon inutilisé réduit immédiatement les risques.

Renforcer l’accès SSH

L’accès SSH constitue la première cible des attaques automatisées.

Quelques bonnes pratiques permettent déjà d’améliorer fortement la sécurité :

• désactiver la connexion directe de l’utilisateur root ;
• privilégier l’authentification par clé publique ;
• interdire les mots de passe lorsque cela est possible ;
• limiter les utilisateurs autorisés à se connecter.

Une configuration classique ressemble à ceci :

PermitRootLogin no
PasswordAuthentication no
AllowUsers admin

Cette simple modification élimine déjà un grand nombre de tentatives d’intrusion.

Configurer un pare-feu

Un pare-feu correctement configuré limite les connexions aux seuls services nécessaires.

Sous Debian, UFW permet une configuration rapide :

ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

Sur des infrastructures plus complexes, nftables offre davantage de possibilités de filtrage.

Installer Fail2ban

Fail2ban surveille les logs système et bloque automatiquement les adresses IP réalisant plusieurs tentatives d’authentification échouées.

Il protège efficacement :

• SSH ;
• Apache ;
• Nginx ;
• certains services de messagerie.

Dans la pratique, cet outil élimine une grande partie des attaques par force brute sans intervention humaine.

Vérifier les permissions

Des permissions mal configurées facilitent considérablement le travail d’un attaquant.

Quelques contrôles simples permettent de détecter rapidement les erreurs :

find /var/www -perm -777

Les fichiers ne devraient jamais être accessibles en écriture par tous les utilisateurs. Les droits doivent être limités au strict nécessaire.

Sécuriser Apache, Nginx et PHP

Le serveur web mérite également une attention particulière.

Il est recommandé de :

• masquer les versions des logiciels ;
• désactiver les modules inutilisés ;
• interdire l’exécution de scripts dans les répertoires d’upload ;
• limiter les méthodes HTTP acceptées ;
• forcer l’utilisation du protocole HTTPS.

L’installation de ModSecurity constitue un excellent complément en filtrant automatiquement de nombreuses attaques applicatives avant qu’elles n’atteignent le site.

Surveiller les logs et détecter les fichiers modifiés

Les journaux système représentent la meilleure source d’information lors d’un audit.

Ils permettent d’identifier rapidement une tentative d’intrusion ou un comportement inhabituel.

Les principaux fichiers à consulter sont :

• /var/log/auth.log
• /var/log/syslog
• /var/log/apache2/access.log
• /var/log/apache2/error.log
• /var/log/nginx/access.log
• /var/log/nginx/error.log
• les journaux PHP-FPM.

Une simple recherche permet d’identifier les tentatives de connexion SSH échouées :

grep "Failed password" /var/log/auth.log

L’outil journalctl facilite également l’analyse des événements récents :

journalctl -xe

Une augmentation soudaine des erreurs PHP, des requêtes vers des fichiers inconnus ou des connexions provenant de pays inhabituels doivent attirer l’attention.

Contrôler l’intégrité des fichiers

Les attaquants modifient rarement un seul fichier.

Ils ajoutent souvent plusieurs scripts afin de conserver différents moyens d’accès au serveur.

Pour cette raison, il est recommandé de contrôler régulièrement les fichiers sensibles.

Des outils comme :

• AIDE ;
• Tripwire ;
• rkhunter ;
• chkrootkit

permettent de détecter rapidement des modifications inattendues.

Sur une boutique PrestaShop, il est également judicieux de surveiller en priorité :

• le dossier modules ;
• override ;
• upload ;
• cache ;
• les fichiers du thème actif.

Une modification inattendue mérite toujours une vérification.

Vérifier la base de données

Lors d’une compromission, la base de données est souvent modifiée en même temps que les fichiers.

Certaines attaques ajoutent des comptes administrateurs, d’autres injectent directement du code JavaScript dans les pages de paiement.

L’audit doit donc inclure plusieurs contrôles :

• présence de comptes administrateurs inconnus ;
• modules installés récemment ;
• tables modifiées ;
• contenus HTML contenant du JavaScript suspect ;
• redirections ajoutées dans les paramètres.

Il est également recommandé de comparer la structure de la base avec celle d’une installation saine lorsque cela est possible.

Les sauvegardes restent indispensables. Une restauration rapide permet parfois de résoudre un incident beaucoup plus efficacement qu’un nettoyage manuel.

Outils d’audit d’une boutique PrestaShop

L’audit d’une boutique PrestaShop ne se limite pas au système d’exploitation. Il faut également contrôler les fichiers propres au CMS, les modules installés, les comptes administrateurs, les scripts JavaScript chargés sur le front-office et les modifications apportées à la base de données.

Plusieurs méthodes peuvent être combinées :

• comparaison des fichiers avec une version officielle ;
• contrôle des permissions ;
• vérification des modules désactivés mais toujours présents ;
• recherche de webshells ;
• analyse des tâches cron ;
• inspection des journaux Apache, Nginx et PHP.

Pour automatiser une partie de ces vérifications, il est également possible d’utiliser un scanner de sécurité PrestaShop capable d’analyser les fichiers de la boutique, de détecter des scripts suspects, des webshells, des modifications inhabituelles ainsi que plusieurs indicateurs de compromission propres à PrestaShop. Cet outil constitue une aide précieuse pour accélérer un audit, mais il ne remplace jamais l’analyse d’un administrateur système expérimenté.

Mettre en place une routine d’audit

La sécurité n’est pas une opération ponctuelle. Elle repose sur des contrôles réguliers intégrés aux tâches d’administration.

Une routine efficace peut s’organiser de la manière suivante :

L’automatisation permet également de gagner un temps précieux.

Par exemple :

• exécuter AIDE chaque nuit ;
• envoyer une alerte lorsqu’un fichier critique est modifié ;
• contrôler automatiquement l’espace disque ;
• vérifier le bon déroulement des sauvegardes ;
• centraliser les journaux système dans une solution de supervision.

Une surveillance régulière permet de détecter rapidement une anomalie avant qu’elle ne provoque une interruption de service ou une fuite de données.

Conclusion

Auditer un serveur Linux ne consiste pas simplement à vérifier qu’il répond aux requêtes HTTP. Un contrôle sérieux passe par l’analyse des journaux système, le durcissement de Debian, la sécurisation d’Apache ou de Nginx, la vérification des permissions, l’inspection de la base de données et le contrôle de l’intégrité des fichiers.

Pour une boutique PrestaShop, cette démarche doit également inclure l’analyse des modules, des comptes administrateurs et des scripts exécutés côté client. En mettant en place une routine d’audit régulière, associée à des sauvegardes fiables et à une supervision continue, il devient beaucoup plus facile de détecter une compromission avant qu’elle n’affecte les utilisateurs ou les données de la boutique.