Comment sécuriser un VPS Infomaniak
du système livré par l'hébergeur à une base Linux robuste

Infomaniak fournit un système d'exploitation propre sur ses offres VPS, mais la sécurité d'exploitation reste à construire côté client. Pour une PME, le plus important n'est pas de viser une architecture "parfaite", mais de mettre rapidement en place une base de sécurité cohérente, puis de l'opérer dans la durée.

Contexte : VPS Lite vs VPS Cloud

Sur VPS Lite, vous disposez d'une couche pare-feu gérée côté provider depuis le Manager. Sur VPS Cloud, vous êtes face à un système plus brut qui offre plus de flexibilité, mais exige un pilotage sécurité plus strict. Dans les deux cas, l'OS livré est une base technique : il n'inclut pas automatiquement des contrôles comme fail2ban, un modèle d'accès SSH rigoureux ou une journalisation d'audit complète.

Contrôles de base de sécurité

1) SSH via jump host

Éviter les accès SSH directs généralisés et imposer un jump host (bastion) améliore la traçabilité et réduit l'exposition. Concrètement : authentification SSH par clé uniquement, suppression de l'utilisateur par défaut ubuntu pour l'accès humain, création d'un compte nominatif par accès autorisé, droits sudo minimaux et suppression des accès obsolètes.

2) UFW (pare-feu hôte)

UFW permet de verrouiller explicitement les flux entrants et sortants au niveau du serveur. Une base saine consiste à passer en "deny incoming" par défaut, puis à n'autoriser que les ports strictement nécessaires (souvent 22, 80, 443). Cela reste pertinent même si un pare-feu provider existe déjà.

3) Services internes liés à localhost

Liez les composants internes (bases de données, APIs privées, outils d'administration) à 127.0.0.1 ou à un réseau privé, plutôt que de les exposer publiquement.

4) Mises à jour de sécurité automatiques

Activez unattended-upgrades et planifiez des fenêtres de maintenance régulières. L'objectif est de réduire la fenêtre d'exposition entre la publication d'un correctif et son application en production.

5) fail2ban (brute-force et abus)

fail2ban surveille les journaux (notamment SSH) et bloque automatiquement les IP qui enchaînent des tentatives suspectes. C'est un contrôle simple qui réduit fortement le bruit d'attaque quotidien sur les services exposés.

6) auditd + logs externalisés

auditd enregistre les événements sensibles (SSH, sudoers, modifications de fichiers critiques). La bonne pratique est d'externaliser les logs vers une machine distincte (ou un service dédié), pour conserver des traces exploitables même en cas de compromission du VPS principal.

Bonnes pratiques complémentaires

• Sauvegardes testées — la restauration doit être validée en conditions réelles, pas seulement "backup OK".
• Monitoring et alerting — supervision des services, de l'espace disque, des erreurs applicatives et des anomalies réseau.
• MFA sur le compte provider — protégez l'accès au panel d'administration Infomaniak avec MFA obligatoire.
• Runbook d'incident — documentez un protocole court (détection, confinement, restauration, communication) et testez-le périodiquement.
• Hardening SSHD — désactivez le login root SSH, limitez les utilisateurs autorisés et durcissez les timeouts d'inactivité.
• Filtrage sortant (egress) — limitez les flux sortants aux destinations nécessaires pour réduire les risques d'exfiltration.
• Synchronisation de l'heure — imposez NTP/chrony pour des logs corrélables et une meilleure qualité d'investigation.

Checklist par priorité