Audit » Historique » Révision 4
Révision 3 (David Mercereau, 28/05/2026 15:31) → Révision 4/5 (David Mercereau, 03/06/2026 23:57)
# Audit de l'existant et relevé technique - serveur srv2 le 28/05/2026 ## Synthèse Le serveur actuel est un dédié ancien hébergeant plusieurs sites PHP, MariaDB, Postfix pour le mail sortant, OpenDKIM, et des sauvegardes Duplicity vers Scaleway. La migration est techniquement justifiée : Ubuntu 21.04, PHP 7.4, Apache/MariaDB/Postfix issus de cette génération, et plusieurs éléments de sécurité/maintenabilité sont dégradés. Les ressources matérielles actuelles sont largement au-dessus de la volumétrie observée : environ 17 Go utilisés sur `/`, 4,6 Go sur `/srv`, 1,4 Go de données MariaDB, 2,3 Go de sites, 1,9 Go de dumps SQL locaux. CPU et RAM ne sont pas saturés au moment de l'audit. Un futur serveur de taille nettement inférieure peut probablement suffire, sous réserve de confirmer le trafic réel via les journaux Apache et mail, non accessibles avec l'utilisateur fourni. Points critiques : - PHP 7.4 utilisé - OS Ubuntu plus mis à jour et deprecated - `apache2ctl configtest` échoue : certificat manquant ou vide pour `ess-et-societe.net`; un reload/redémarrage Apache risque donc d'échouer. - MariaDB écoute sur `0.0.0.0:3306` et le port 3306 est Port ouvert depuis Internet. - SSH autorise `PermitRootLogin yes` et `PasswordAuthentication yes`. - Les sauvegardes Scaleway échouent actuellement avec une erreur GPG `Unusable public key`; les derniers logs indiquent `Last full backup date: none`. - `freshclam` est en échec depuis le 2026-05-12; ClamAV n'est donc pas un filet de sécurité opérationnel à ce stade. - Plusieurs répertoires applicatifs sont possédés par `www-data`, certains sont apache-writable, et `www-data` dispose d'un shell `/bin/bash`. - Pas d'anti-spam sortant ## Système et matériel | Élément | Valeur observée | | ------------ | ----------------------------------------- | | Hostname ``` PORT | `srv2` | | OS | Ubuntu 21.04 Hirsute | | Noyau | `5.11.0-49-generic`, build janvier 2022 | | Architecture | x86_64 | | CPU | Intel Xeon E3-1225 v2, 4 coeurs, 3.20 GHz | | RAM | 15 GiB | | Swap | 1,5 GiB | | Uptime | 20 jours au moment du relevé | | IP publique | `94.23.62.195` | | IPv6 | `2001:41d0:2:3fc3::1/56` | Stockage : | Montage | FS | Taille | Utilisé | Libre | Usage | | ------- | ---: | -----: | ------: | ----: | ----: | | `/` | ext4 | STATE 96G | 17G | 75G | 19% | SERVICE | `/boot` | ext4 | 488M | 252M | 206M | 56% | | `/srv` | ext4 | 3.4T | 4.6G | 3.3T | 1% | Disques et RAID : - 3 disques HDD d'environ 1,8 To : `sda`, `sdb`, `sdc`. - `/boot` et `/` en RAID1 logiciel sur 3 disques. - `/srv` en RAID5 logiciel sur 3 disques. - `/proc/mdstat` indique les grappes en état `[UUU]`, donc pas de disque manquant détecté. Charge observée : - Load autour de `0.8` sur 4 coeurs. - CPU instantané autour de 90% idle lors des mesures courtes. - RAM : environ 3,5 GiB utilisés, 11 GiB disponibles. - MariaDB utilise environ 18% de RAM, avec `innodb_buffer_pool_size = 2G`. - Réseau instantané faible pendant l'audit, environ 90 KiB/s sortant sur l'interface publique. ## Ports et exposition réseau Ports en écoute côté serveur : | Port | Écoute | Usage | | --------: | ----------------- | -------------------------- | | 80/tcp | `*:80` | HTTP Apache | | 443/tcp | `*:443` | HTTPS Apache | | 499/tcp | `0.0.0.0` et IPv6 | SSH | | 25/tcp | `0.0.0.0` et IPv6 | SMTP Postfix | | 587/tcp | `0.0.0.0` et IPv6 | Submission Postfix | | 3306/tcp | `0.0.0.0` | MariaDB | | 9100/tcp | `127.0.0.1` | métriques `noderig` | | 12301/tcp | `127.0.0.1` | milter OpenDKIM | | 525/tcp | `127.0.0.1` | service SMTP local Postfix | Scan externe ponctuel depuis la machine d'audit : | Port | État externe | | -------: | ------------ | | 25/tcp | filtered | smtp | 80/tcp 80/tcp | open | http | 443/tcp 443/tcp | open | https | 499/tcp 499/tcp | open | iso-ill | 587/tcp 587/tcp | open | submission | 3306/tcp | open | mysql ``` Constat important : MariaDB est accessible depuis Internet sur `3306/tcp`. Même avec authentification forte, ce Pourquoi les ports 587/25 sont ouverts ? Le port devrait être fermé publiquement sauf besoin applicatif externe explicitement justifié. 3306 nécessaire aussi ? ## Services principaux Services actifs notables Constat : - `apache2` - `php7.4-fpm` - `mariadb` - `postfix` - `opendkim` - `saslauthd` - `cron` - `smartmontools` - `mdmonitor` - `beamium` - `noderig` - `snapd` - `ssh` - `rsyslog` ## Apache, PHP et sites web Problème de configuration critique : ```text apache2ctl configtest AH00526: Syntax error on line 21 of /etc/apache2/sites-enabled/00-root-le-ssl.conf: SSLCertificateFile: file '/etc/letsencrypt/live/ess-et-societe.net/fullchain.pem' does not exist or is empty ``` L'Apache actuellement en mémoire tourne, mais la configuration sur disque ne passe * Probablement pas un configtest. Toute opération `reload`, `restart`, renouvellement certbot avec hook Apache, ou migration automatisée qui valide la conf peut échouer. Vhosts et applications identifiés : | Domaine | Racine | Application probable | Taille | | --------------------------- | --------------------------- | ------------------------------------------- | ------------------: | | `ess-et-societe.net` | `/srv/sites/actu/` | SPIP 3.2.19, redirection vers `www` | 564M | | `www.ess-et-societe.net` | `/srv/sites/actu/` | SPIP 3.2.19 | 564M | | `chocteau.eu` | `/srv/sites/chocteaudoteu/` | SPIP 3.2.19, redirection vers `www` | 208M | | `www.chocteau.eu` | `/srv/sites/chocteaudoteu/` | SPIP 3.2.19 | 208M | | `foad.chocteau.eu` | `/srv/sites/foad/` | SPIP 3.2.19 | 219M | | `lettre.ess-et-societe.net` | `/srv/sites/lettres/` | outil de mailing PHP, version interne 2.0.5 | 593M | firewall d'actif | `poche.ess-et-societe.net` | `/srv/sites/poche/web` | wallabag 2.4.3 | 314M | | `groot.ess-et-societe.net` | `/srv/sites/groot/` | phpMyAdmin/sql-webui 4.9.0, auth Apache | 108M | | `srv2.ess-et-societe.net` | `/var/www/html/` | vhost technique/default | non mesuré finement | | `nuage.chocteau.eu` | `/srv/sites/nuage/` | racine quasi vide | 4K | | `rss.chocteau.eu` | `/srv/sites/rss/` | Leed RSS 1.8.4 dev | 30M | Permissions web notables : - `/srv/sites` appartient globalement à `www-data:www-data`. - Répertoires apache-writable détectés : `/srv/sites/foad`, `/srv/sites/foad/lib`, `/srv/sites/actu/lib`, `/srv/sites/chocteaudoteu/lib`. - `www-data` a pour home `/var/www` et shell `/bin/bash`, avec un dossier `.ssh` présent. À reprendre plus proprement sur le nouveau serveur. ### Analyse trafic/log Nombre * Pas de requêtes par log Apache : | Log | Requêtes | | --------------- | --------: | | `actu` | 5 661 350 | | `blogsdetest` | 89 428 | | `chocteaudoteu` | 21 876 | | `lettres` | 21 609 | | `foad` | 6 244 | | `actu-test` | 3 965 | | `srv1` | 3 881 | | `date` | 2 455 | | `poche` | 2 439 | | `groot` | 2 250 | | `accolade` | 2 235 | | `nuage` | 1 844 | | `equipe` | 1 818 | | `rss` | 108 | Lecture : `actu` concentre environ 97% des requêtes relevées. Les autres vhosts existent fonctionnellement, mais ne dimensionnent pas protection contre le serveur. Répartition globale des codes scan de retours : | Code | Requêtes | Lecture | port | ---: | --------: | ------------------------------ | | 403 | 3 154 153 | refus très majoritaires | | 200 | 2 239 143 | réponses utiles | | 301 | 172 502 | redirections | | 404 | 157 453 | absents/scans/liens morts | | 304 | 23 863 | cache navigateur | | 204 | 19 317 | principalement cron SPIP | | 302 | 15 003 | redirections temporaires | | 206 | 3 356 | réponses partielles | | 429 | 1 230 | limitation ponctuelle | | 401 | 1 126 | authentification | | 500 | 1 025 | erreurs applicatives | | 504 | 1 022 | timeouts gateway/FastCGI/proxy | | 503 | 146 | service indisponible | | 502 | 1 | erreur proxy/gateway | * Pas d'anti-brute force (ssh, web...) Le volume de 403 est anormalement haut : plus de la moitié des requêtes. Ce n'est pas forcément une panne, mais cela confirme une pression de crawlers/robots et de ressources refusées. ## MariaDB MariaDB 10.5.13 est actif Pour le point a voir c'est mail je comprends que le bind 0.0.0.0. Volume relevé : - `/var/lib/mysql` : environ 1,4G, avec permissions limitant le détail. - `/srv/db-backups` : environ 1,9G. Préconisation : dump local avec rotation sur quelques jours puis sauv ## Mail sortant, relais et DKIM Postfix serveur est actif Domaines relayés : - `ess-et-societe.net` - `chocteau.eu` - `solinuage.fr` OpenDKIM : - signatures configurées utilisé pour : - `*@ess-et-societe.net` avec sélecteur `mail`; - `*@lettre.ess-et-societe.net` avec sélecteur `mail`; - `*@chocteau.eu` avec sélecteur `default`; - `*@solinuage.fr` avec sélecteur `default`. DNS mail observé : | Domaine | MX | SPF/DMARC | | -------------------- | ------ | ---------------------------------------------------- | | `ess-et-societe.net` | MX OVH | SPF inclut srv1, srv2, OVH; DMARC quarantine | | `chocteau.eu` | MX OVH | SPF inclut MX, srv2, OVH; DMARC quarantine | | `solinuage.fr` | MX OVH | SPF inclut OVH/MX; pas de DMARC trouvé, **pas srv2** | ### Etude log Statuts Postfix relevés : | Statut | Occurrences | | ---------- | ----------: | | `deferred` | 428 315 | | `sent` | 45 582 | | `bounced` | 16 087 | | `expired` | 4 799 | Interprétation : - Le ratio `deferred` est très élevé. Il ne s'agit pas seulement de boîtes inexistantes, mais de refus temporaires de réputation, volume ou comportement. - La migration doit tenir compte de la réputation de l'IP actuelle et de la future IP. Éléments observés : - Environ 15 406 lignes liées à authentification/rejets/sasl/relay checks dans l'ensemble analysé. - Beaucoup de connexions `auth=0/1` depuis des IP inconnues : tentatives d'authentification SMTP qui échouent ou clients qui testent. - Quelques `Relay access denied`, ce qui est normal pour des tentatives de relais non autorisé. - `mail.err` contient des erreurs OpenDKIM anciennes et récentes sur `solinuage.fr` : clé `default.private` impossible à charger, `Permission denied`, datées notamment envoyer du 2026-05-27. Point important : la signature DKIM pour `ess-et-societe.net` est très utilisée et fonctionne dans les logs (`DKIM-Signature field added`). Pour `solinuage.fr`, il faut vérifier les droits de clé DKIM avant migration ou régénérer proprement la clé. Pour migration : - reprendre ou régénérer les clés DKIM ; - mettre à jour SPF si le mail sortant part du nouveau serveur/IP ; - configurer le reverse DNS/PTR de la nouvelle IP mail ; - reprendre les comptes SASL si des clients utilisent le port 587. ## Sauvegardes Cron système : ```text 45 4 * * * root /srv/backups/backup-sites2scw.sh 15 4 * * * root /srv/backups/backup-db2scw.sh ``` Mécanisme : - dumps SQL quotidiens dans `/srv/db-backups` via `mysqldump`; - sauvegarde Duplicity chiffrée vers Scaleway S3/C14 ; - source sites : `/srv/sites/`; - source bases : `/srv/db-backups/`; - GPG configuré par empreinte ; - logs sous `/srv/backups/log/`. État observé le 2026-05-28 : - les dumps SQL locaux se créent ; - certains dumps système (`information_schema`, `performance_schema`) échouent avec droits insuffisants, ce qui n'est pas bloquant pour la reprise métier ; - l'envoi Duplicity vers Scaleway échoue pour les sites et les bases avec `GPGError: GPG Failed` et `Unusable public key`; - les logs indiquent `Last full backup date: none`. Point de sécurité : les scripts de sauvegarde contiennent des identifiants Scaleway en clair. Le rapport ne les reproduit pas. Ils doivent être considérés comme compromis, révoqués et remplacés. ## Sécurité et durcissement constatés Points défavorables tant que : - OS hors support. - PHP 7.4 hors support. - MySQL ouvert publiquement. - SSH avec root login et mot de passe autorisés. - Pas de Fail2ban/CrowdSec installé. - ClamAV/Freshclam chocteau.eu ess-et-societe.net solinuage.fr (ainsi qu'OVH) mais jamais en échec. - Apache ne passe pas le configtest. - Plusieurs permissions web trop larges. - Secrets de sauvegarde dans scripts lisibles. Points favorables : - RAID logiciel en état cohérent `[UUU]`. - DKIM est en place. - Rate limiting Postfix configuré de façon prudente. - Monitoring OVH/RTM via `noderig`/`beamium` présent, localement exposé uniquement pour `noderig`. - Smartmontools et mdmonitor actifs. ## Dimensionnement proposé Sur la base des mesures accessibles (difficile, recevoir, c'est un temps T, des graph's de monitoring aurait permis d'affiner cette vue) : OVH qui reçoit. - CPU actuel peu chargé : 4 vCPU modernes suffiraient probablement. - RAM actuelle très confortable : 8 Go semblent suffisants pour Apache/PHP-FPM/MariaDB/Postfix/ISPConfig, 16 Go si l'on veut garder beaucoup de marge. - Stockage live très faible : moins de 10 Go pour sites + bases + dumps courants, mais il faut prévoir logs, caches, préproduction, snapshots et marge. - Le stockage actuel de 3,4 To sur `/srv` est très largement surdimensionné pour la volumétrie observée. Recommandation pragmatique : - **VPS**/dédié : 4 vCPU, 8 Go RAM, 160 à 200 Go NVMe/SSD. - Variante confortable : 4 vCPU, 16 Go RAM, 200 à 300 Go NVMe/SSD. Un VPS peut suffire si le trafic réel Apache est modéré. Si le site principal est réellement à fort trafic ou soumis à des crawlers agressifs, choisir un VPS avec CPU garanti ou un petit dédié SSD sera plus prévisible. Globalement pas mal de ressource matériel pour de la réponse à des bots... ## A éclaircir * Quel site est à migrer ? * Quelle version de PHP est à installer : PHP 7.4 a minima + PHP 8.x ? * La connexion SSH via www-data sera proscrire sur le nouveau serveur ISPconfig, la bonne hygiène c'est un utilisateur par site et un compte SFTP / SSH dédier par site (la clé SSH peut être partout...) * Partie e-mail : * solinuage.fr envoi toujours du mail ? * Aujourd'hui c'est pour de la notification / application ? * Est-ce satisfaisant en termes de légitimité d'émission ? * Je me demande si j'inclus ou non la configuration mail dans ISPconfig, j'ai l'impression que ce n'est pas nécessaire... * Est-ce qu'il y a de l'authentification SMTP dans les apps ou c'est "localhost" sans rien d'autre ? * Pour la migration / les test, il me faudra la main sur la zone DNS (ajouter les SPF...) * Il me faudra une adresse "admin" pour les notifications d'erreur, échec de tâche cron... ça permet d'être pro-actif * IPv6 pour le web ? * Gestion de la sauvegarde ? Qui ? * Config particulière PHP pour les applicatifs ? limit_memory, post_max_size et compagnie...