VPS OVHcloud : sécurité, anti-DDoS, SMTP 25 et bonnes pratiques admin

Table des matières :

1. Modèle de menace d’un VPS OVHcloud : qui protège quoi, et ce que le “core” ne fait pas




2. Anti‑DDoS OVHcloud : ce que fait VAC, et ce que vous devez compléter au niveau L7




3. Durcissement OS : SSH, patching, noyau, et hygiène d’accès (Debian 12 / Ubuntu 24.04)




4. Pare‑feu et segmentation : réduire la surface d’attaque sans casser PrestaShop




5. SMTP 25 sur OVHcloud : politique anti‑abus, déblocage, et alternatives propres pour l’envoi d’emails




6. Bonnes pratiques admin spécifiques e‑commerce : sauvegardes testées, observabilité, et durcissement applicatif PrestaShop




7. Checklist d’exploitation “VPS OVHcloud” orientée prod : ce que vous validez avant et après mise en ligne

Modèle de menace d’un VPS OVHcloud : qui protège quoi, et ce que le “core” ne fait pas

Sur un VPS OVHcloud, la sécurité est un partage de responsabilité classique : OVHcloud gère l’infrastructure (datacenter, réseau, hyperviseur, anti-DDoS en amont), mais l’OS, la pile applicative (Nginx/Apache, PHP-FPM), la base de données, les secrets et la surface d’attaque HTTP restent votre problème. C’est un point souvent mal compris côté e‑commerce : “j’ai pris un VPS, donc c’est sécurisé” est une hypothèse fausse, et elle finit en compromission via un SSH exposé, un panel non patché ou un PrestaShop mal durci.

Pour éviter les malentendus, aidez‑vous d’une matrice simple “qui fait quoi” (utile aussi pour briefer une agence, un freelance, ou votre équipe interne) :

Couche	OVHcloud (core)	Vous (client)	Risque typique si non couvert
Datacenter (électricité, clim, accès)	Oui	Non	Indisponibilité physique
Réseau amont + mitigation DDoS volumétrique	Oui	Non	Saturation lien / flood L3‑L4
Hyperviseur	Oui	Non	Évasion VM (rare, mais critique)
Système (SSH, sudo, users, patch)	Non	Oui	Brute‑force, exploitation CVE OS
Services (Nginx/Apache, PHP‑FPM, DB)	Non	Oui	RCE via service vulnérable / config faible
Applicatif (PrestaShop, modules)	Non	Oui	Back‑office compromis, exfiltration
Données (PII, commandes)	Non	Oui	Incident RGPD, perte de confiance

Concrètement, sur une boutique : vos priorités “admin” doivent être orientées risque. Un exemple très courant : un VPS livré “propre”, mais PasswordAuthentication yes + un compte admin réutilisant un mot de passe déjà compromis (credential stuffing). La VM n’est pas “cassée” par l’hébergeur : elle est cassée par l’exploitation d’un accès qui vous appartient.

Bruce Schneier résume bien la dynamique avec une phrase souvent citée : « Security is a process, not a product. » (Bruce Schneier). Sur un VPS, ça se traduit en runbooks, contrôles continus, et revues régulières (ports exposés, mises à jour, sauvegardes), pas en “tuning une fois” puis oubli.

Enfin, ne mélangez pas tout : anti‑DDoS ≠ WAF ≠ durcissement OS. L’anti‑DDoS réduit l’impact de certains floods réseau, mais ne corrige pas une route Symfony lente, une query MySQL sans index ou un endpoint d’API trop bavard. Pour les sujets applicatifs PrestaShop (auth back‑office, WAF, journalisation), vous avez déjà des bases solides côté site : voir Sécurité PrestaShop : protéger API backoffice, WAF et journalisation SIEM et Sécurité PrestaShop 2026 : risques majeurs et protections professionnelles.

Anti‑DDoS OVHcloud : ce que fait VAC, et ce que vous devez compléter au niveau L7

OVHcloud fournit une mitigation DDoS “en amont”, historiquement basée sur VAC (scrubbing) : en cas d’attaque volumétrique, le trafic est filtré avant d’atteindre votre VM. C’est utile contre des attaques L3/L4 (SYN flood, UDP flood, amplification), mais pas une garantie de disponibilité applicative. En pratique, une attaque HTTP lente, une saturation de workers PHP‑FPM, ou un “cache busting” sur des URLs non cachées peut faire tomber la boutique même sans flood massif.

Techniquement, distinguez bien : L3/L4 (réseau/transport) vs L7 (HTTP/applicatif). Le premier se traite avec scrubbing, rate‑limit conntrack, SYN cookies. Le second se traite avec du cache (Varnish), du shielding (CDN), des règles WAF, et des limites applicatives (timeouts, limitations sur endpoints). Si vous exposez une API ou un front complexe, relisez vos choix de cache : Cache PrestaShop : Varnish, Redis, Memcached et OPcache côté serveur et, pour les patterns de front, TTFB PrestaShop : réduire le Time To First Byte sous 200 ms.

Mini‑scénario “réaliste” e‑commerce : pendant les soldes, votre page catégorie non cachée déclenche des requêtes lourdes (facettes + tri + produits). Un acteur malveillant (ou un bot agressif) “balaye” des combinaisons d’URL uniques (paramètres de tri, pagination, filtres), ce qui évite le cache et pousse PHP‑FPM + MySQL à 100%. Résultat : pas besoin d’un gros DDoS volumétrique pour vous mettre à genoux, juste une pression L7 mal contrôlée. Les mitigations typiques sont simples et cumulatives :

• mettre en cache ce qui doit l’être (Varnish / CDN) ;




• limiter certains endpoints (login/back‑office, API, recherche) ;




• définir des timeouts raisonnables (proxy et upstream) ;




• mesurer (latence par URL, erreurs 5xx, saturation FPM).

Côté reverse‑proxy, vous pouvez par exemple limiter la pression sur un endpoint sensible (à adapter à votre contexte) :

# Exemple minimal : limiter les requêtes sur /api/ et /connexion
limit_req_zone $binary_remote_addr zone=rl_api:10m rate=5r/s;

server {
  location ~ ^/(api|connexion) {
    limit_req zone=rl_api burst=20 nodelay;
    proxy_pass http://php_upstream;
  }
}

Côté VPS, complétez par un contrôle strict des ports. Utilisez le pare‑feu OVHcloud (niveau “réseau” dans le Manager quand disponible) comme première barrière, puis un pare‑feu OS (nftables/ufw) comme seconde barrière. Exemple minimal (Debian 12 / Ubuntu 24.04) : n’autorisez publiquement que 80/443, exposez le port 22 uniquement depuis vos IP d’admin (ou via VPN), et bloquez le reste. Pour les reverse‑proxy/edge, HAProxy reste une option propre : voir HAProxy 3.2 : déploiement systemd, configuration frontend/backend, ACL.

Durcissement OS : SSH, patching, noyau, et hygiène d’accès (Debian 12 / Ubuntu 24.04)

La base, c’est d’arrêter de laisser SSH en “default install”. Sur un VPS OVHcloud, partez du principe que 22/tcp est scanné en continu. Passez sur auth par clés, désactivez les mots de passe, coupez le login root, et imposez des algos modernes. Dans /etc/ssh/sshd_config : PasswordAuthentication no, PermitRootLogin no, PubkeyAuthentication yes. Ajoutez AllowUsers deploy ops et, si possible, un Match Address pour limiter aux IPs d’admin. Redémarrage : systemctl reload ssh (sans vous déconnecter avant d’avoir validé une seconde session).

Deux précisions qui évitent des erreurs fréquentes :

• Changer le port SSH peut réduire le bruit des scans, mais n’est pas une mesure de sécurité suffisante. La vraie sécurité vient de la clé + restriction IP + durcissement.




• Avant de durcir agressivement, vérifiez que vous avez un accès de secours (console/KVM, mode rescue) pour éviter un lock‑out en production.

Le patch management n’est pas optionnel. Côté Linux, mettez en place des mises à jour de sécurité automatiques (avec fenêtre de reboot maîtrisée) : unattended‑upgrades sur Debian/Ubuntu, et un monitoring qui alerte si un reboot est requis. Le NIST insiste, dans NIST SP 800‑40 Rev.3 (2013), Guide to Enterprise Patch Management Planning, sur l’importance d’un processus de gestion des correctifs structuré (inventaire, priorisation, test, déploiement, vérification). Le piège côté e‑commerce, c’est de repousser les updates “par peur de casser” : votre vraie mitigation, c’est un staging et une procédure de rollback, pas l’absence de patch.

Complétez avec des garde‑fous kernel/réseau (sysctl) et une protection brute‑force. Typiquement : activez net.ipv4.tcp_syncookies=1, désactivez le routage source, durcissez les redirects ICMP, et installez Fail2ban pour SSH + endpoints admin exposés (à condition de bien parser vos logs). Pour éviter le “durcissement aveugle”, liez vos mesures à des signaux :

• pics de auth.log (tentatives SSH) ;




• hausse de 401/403 sur /admin ;




• explosion du temps de réponse sur certaines URLs.

Enfin, pour une boutique, le durcissement “accès” ne se limite pas à SSH : traitez aussi les accès applicatifs (back‑office, accès DB, accès panel). Si vous avez des pics (soldes, campagnes), monitorer avant de durcir à l’aveugle : PrestaShop performance : monitoring, tests de charge et runbooks soldes.

Pare‑feu et segmentation : réduire la surface d’attaque sans casser PrestaShop

Un pare‑feu “deny by default” est rarement appliqué sur des VPS e‑commerce, alors que c’est la mesure la plus rentable. La logique : ingress strict, egress contrôlé si vous avez des exigences conformité (ex. limiter les sorties au strict nécessaire : SMTP vers un relay, API paiement, CDN). Pour PrestaShop, l’ingress typique est : 80/443 (public), 22 (restreint), éventuellement 25/587/465 selon stratégie mail, et rien d’autre.

Sur Debian 12, nftables est la voie standard. Exemple conceptuel :

• table inet filter avec input policy drop




• accept ct state established,related




• accept iif lo




• accept tcp dport {80,443}




• accept tcp dport 22 ip saddr {IP_ADMIN/32}




• log rate‑limited puis drop

Le point important n’est pas le snippet, mais la discipline : vous documentez les ports et vous les relisez à chaque ajout de module (ERP, PIM, connecteurs). Sur un VPS OVHcloud, une ouverture “temporaire” finit souvent “permanente” parce que personne ne revient fermer.

Un moyen simple de formaliser (et de détecter les dérives) est de maintenir une petite table “ports autorisés” dans votre doc d’exploitation :

Flux	Source → Destination	Port	Justification	Revue
Web public	Internet → VPS	80/443	Boutique	Trimestrielle
Admin SSH	IP admin → VPS	22	Exploitation	Mensuelle
DB interne	VPS → DB	3306/5432	Si DB séparée	À chaque changement
Mail sortant	VPS → SMTP relay	587/465	Transactionnel	Mensuelle

Segmentez dès que possible : base de données non exposée (bind sur 127.0.0.1 ou réseau privé), Redis uniquement local, et si vous faites du multi‑VM, utilisez des réseaux privés (vRack/équivalent selon offre) plutôt que d’exposer des ports aux quatre vents. Pour la base, pensez aussi performance et sécurité : index, droits SQL, et durcissement MySQL/PostgreSQL. Voir PostgreSQL vs MySQL 2026 : performances, sécurité et cas d’usage et Index MySQL : optimiser WHERE, JOIN et ORDER BY avec EXPLAIN.

SMTP 25 sur OVHcloud : politique anti‑abus, déblocage, et alternatives propres pour l’envoi d’emails

Le sujet “SMTP 25” sur VPS OVHcloud revient en boucle parce que le port 25 sortant est fréquemment restreint (ou soumis à conditions) pour limiter le spam depuis des IPs fraîchement allouées. Ce n’est pas un caprice : les ranges IP “VPS” sont des cibles privilégiées pour les abuse, et le coût réputationnel (blacklists) touche ensuite tout l’écosystème. Donc : partez du principe que vous ne devez pas dépendre du 25 pour les emails transactionnels PrestaShop.

Stratégie propre en 2026 : utilisez un SMTP submission sur 587 (STARTTLS) ou 465 (SMTPS) vers un provider mail/relay (ou votre infra mail), avec authentification et rotation de secrets. Configurez ensuite PrestaShop pour envoyer via SMTP (pas mail()), et surveillez la délivrabilité (SPF/DKIM/DMARC). Exemple “null client” côté serveur : Postfix en mode relais (relayhost = [smtp.provider.tld]:587 + smtp_sasl_auth_enable = yes) ou msmtp si vous voulez minimal. Référence : documentation Postfix et RFC 6409 (Message Submission) qui formalise l’usage de la soumission sur 587.

Un point “terrain” : avant même de débattre port 25 vs 587, validez la chaîne de confiance côté DNS, car c’est elle qui fait la délivrabilité. En pratique, la plupart des pannes “email” en e‑commerce ne sont pas des pannes SMTP, mais des pannes de réputation/alignement (ou des mails qui finissent en spam) — avec un impact direct sur : création de compte, confirmation de commande, réinitialisation de mot de passe, relances panier.

Si vous avez une contrainte spécifique nécessitant le 25 (ex. serveur mail légitime), prévoyez le process OVHcloud : demande de déblocage, justification, et surtout configuration DNS propre. Sans PTR (reverse DNS) cohérent, SPF aligné, DKIM valide et DMARC, vous allez “envoyer” mais pas “délivrer”. Le minimum syndical :

• un enregistrement PTR qui pointe sur un hostname de votre domaine




• un SPF qui autorise l’IP/relay




• DKIM signé (souvent au niveau du provider)




• DMARC en p=none au début, puis durcissement progressif

Progression DMARC raisonnable (pour éviter de couper des flux légitimes le jour 1) :

Étape	Politique DMARC	Objectif
1	p=none	Observer (rapports) sans impacter
2	p=quarantine	Mettre la pression sur les envois non alignés
3	p=reject	Bloquer les usurpations (si tout est propre)

Côté exploitation, traitez l’email comme un service à SLO : mesurez taux de bounce, taux de plainte, délais de queue Postfix, et erreurs TLS. Une boutique qui “n’envoie plus ses emails” se traduit en tickets support, paniers abandonnés, et litiges paiement. Et si vous avez déjà subi des soucis de modifications en prod, vous devriez déjà avoir une checklist de contrôle : Contrôle PrestaShop post‑modification : checklist tunnel de commande et règles panier.

Bonnes pratiques admin spécifiques e‑commerce : sauvegardes testées, observabilité, et durcissement applicatif PrestaShop

Sur un VPS OVHcloud, les “bonnes pratiques admin” se jouent dans l’exécution : sauvegarder n’est pas restaurer. Mettez en place : dump base + fichiers + secrets (hors dépôt), versionnés et chiffrés, avec un test de restauration régulier sur un environnement isolé. Pour PrestaShop 9.x (Symfony 6.4) et PHP 8.2/8.3 (selon votre compatibilité), n’oubliez pas que le cache, les clés, et les jobs cron peuvent être des points de divergence en restauration.

Une stratégie pragmatique (souvent suffisante pour une PME) :

• RPO (perte de données acceptable) : ex. 1 à 4 heures → dumps DB plus fréquents.




• RTO (temps de rétablissement) : ex. < 2 heures → procédures + scripts + accès.




• Règle 3‑2‑1 : 3 copies, 2 supports, 1 hors‑site (au minimum hors VPS).

Checklist “test de restauration” (rapide, mais très révélatrice) :

• restaurer DB + fichiers dans un environnement isolé ;




• vérifier login back‑office ;




• passer une commande en sandbox (paiement/test si possible) ;




• vérifier génération et envoi d’un email transactionnel ;




• vérifier tâches cron (indexation, relances, etc.).

Si vous cherchez un cadre sur la résiliation/migration, même si le contexte est différent, la logique “backup complet + plan” reste valable : résiliation & migration PrestaShop.

L’observabilité doit couvrir à minima : métriques système (CPU steal, I/O, RAM), métriques web (latences, 5xx), métriques PHP‑FPM (busy/idle, slowlog), métriques DB (threads, locks), et logs (auth, web, applicatif). Sans ça, vous administrez “au feeling”, donc trop tard. Une bonne pratique simple : un tableau de bord avec 5 signaux et des seuils d’alerte réalistes :

• disque > 80% (et croissance) ;




• 5xx > X/min ;




• latence p95 > objectif ;




• saturation PHP‑FPM (workers tous occupés) ;




• erreurs DB (timeouts/locks).

Pour le tuning PHP‑FPM/OPcache/MySQL sur une boutique, ne réinventez pas : performance PrestaShop : benchmarks et optimisation.

Enfin, côté durcissement applicatif, assumez les limites du cœur et des modules : PrestaShop n’est pas un WAF, et l’écosystème module est une source récurrente de régressions et de vulnérabilités. Vous devez donc : tenir à jour (core + modules critiques), limiter l’exposition du back‑office (IP allowlist, URL non triviale, MFA si possible), journaliser les actions sensibles, et traiter les vulnérabilités comme des incidents (CVE, patch, validation). Exemple concret : la gestion d’une CVE module doit déclencher une mise à jour + une revue de configuration ; voir CVE‑2025‑61922 pscheckout : mise à jour 5.0.5 et mesures.

Checklist d’exploitation “VPS OVHcloud” orientée prod : ce que vous validez avant et après mise en ligne

Avant mise en prod, validez votre socle : OS à jour, utilisateurs non‑root, SSH par clés, pare‑feu actif, ports minimaux, NTP OK, TLS géré proprement (Let’s Encrypt avec renouvellement), et une stratégie email déjà testée (pas de dépendance à un 25 incertain).

Pour rendre cette checklist “actionnable”, vous pouvez la transformer en contrôles courts (exécutables en 10–15 minutes) :

• Accès




• [ ] Connexion SSH par clé OK, mot de passe SSH désactivé




• [ ] root non accessible en SSH




• [ ] IP allowlist en place (SSH et back‑office si possible)




• Exposition




• [ ] Scan rapide des ports : seuls 80/443 (public) + 22 (restreint) sont ouverts




• [ ] DB non exposée sur Internet (bind local / réseau privé)




• Durabilité




• [ ] Sauvegarde initiale complète + chiffrement + stockage hors VPS




• [ ] Procédure de restauration documentée (même simple)




• Email




• [ ] SMTP en 587/465 validé en réel (envoi + réception + SPF/DKIM/DMARC)




• PrestaShop




• [ ] Back‑office : URL non triviale, protections anti‑bruteforce, modules critiques à jour

Sur TLS, ne bricolez pas : automatisez, surveillez l’expiration, et forcez des suites correctes. Référence utile : Let’s Encrypt et la doc SSL de Mozilla.

Après mise en prod, validez votre capacité de réaction : alerting (latence, 5xx, disque), rotation logs, sauvegardes vérifiées, procédure de rollback déployée, et un test de charge minimal (même un petit k6/wrk) pour vérifier que l’infra tient vos objectifs. Si vous préparez des pics, vous devez avoir un runbook, pas un espoir : runbooks soldes & tests de charge.

Dernier point, souvent négligé : documentez vos exceptions. Chaque règle “temporaire” (ouverture port, IP allowlist élargie, désactivation d’un contrôle) doit avoir une date de fin et un ticket. C’est exactement là que les VPS e‑commerce dérivent : on laisse traîner un accès, on oublie un environnement de test exposé, et l’incident arrive “sans raison”. OWASP résume bien l’objectif avec un principe de fond : réduire la surface d’attaque et traiter la sécurité comme un ensemble de contrôles continus (voir OWASP Top 10).