Sécuriser un nouveau VPS : la checklist de la première heure pour les startups

Un nouveau VPS reçoit sa première tentative de connexion SSH quelques minutes après sa mise en ligne. Des robots balayent en permanence des plages d'adresses IP entières, et un serveur neuf avec sa configuration par défaut est exactement ce qu'ils cherchent.

Cette checklist prend environ une heure sur Ubuntu ou Debian. Faites-la avant de déployer quoi que ce soit.

1. Tout mettre à jour (5 minutes)

sudo apt update && sudo apt full-upgrade -y
sudo reboot

Les images des hébergeurs datent souvent de plusieurs semaines. Partez d'un système à jour.

2. Créer votre propre utilisateur (5 minutes)

Ne travaillez pas en root.

adduser alice
usermod -aG sudo alice

3. Passer aux clés SSH, puis désactiver les mots de passe (10 minutes)

Depuis votre ordinateur :

ssh-copy-id alice@votre-serveur

Vérifiez que la connexion par clé fonctionne dans un second terminal, puis modifiez /etc/ssh/sshd_config :

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no

sudo systemctl restart ssh

Ce seul changement rend les attaques par force brute inutiles : il n'y a plus de mot de passe à deviner.

4. Activer un pare-feu (5 minutes)

N'ouvrez que ce que vous servez réellement.

sudo ufw default deny incoming
sudo ufw allow OpenSSH
sudo ufw allow 80,443/tcp
sudo ufw enable

Bases de données, Redis et interfaces d'administration ne doivent jamais être joignables depuis Internet.

5. Mises à jour de sécurité automatiques (5 minutes)

sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

Cela corrige le système d'exploitation. Cela ne met pas à jour les dépendances de votre application (npm, pip, composer) : elles demandent un suivi à part.

6. Bannir les récidivistes (5 minutes)

Même avec des clés uniquement, des milliers de tentatives échouées remplissent les journaux et masquent les vrais signaux. Bannir automatiquement les IP qui insistent réduit le bruit et bloque les scanners avant qu'ils ne trouvent une autre porte.

7. Connaître les versions exposées (10 minutes)

Listez ce qui tourne sur le serveur et comparez-le aux failles connues (CVE) : serveur web, langage, framework, base de données. Un framework obsolète est la porte d'entrée la plus fréquente sur un serveur pourtant bien configuré.

8. Décider qui regarde le serveur, et quand (10 minutes)

C'est l'étape que la plupart des startups oublient. Tout ce qui précède se fait une fois ; les attaques, elles, ont lieu tous les jours. Quelqu'un doit remarquer le CPU à 100 %, la nouvelle clé SSH, la CVE critique publiée cette nuit.

Choisissez un canal que l'équipe lit déjà (Slack, e-mail) et envoyez-y un court résumé quotidien plutôt qu'un flot d'alertes.

En résumé

Les étapes 6 à 8 sont exactement ce que FounderMode automatise : blocage des intrusions, contrôle des versions vulnérables, surveillance CPU/RAM/disque et intégrité des fichiers, avec un rapport clair chaque matin. Installez-le en une commande juste après l'étape 5. Essai gratuit 14 jours.