Installer un serveur VPN n'est que la première étape. Sans ces mesures de base, ce même serveur devient une porte d'entrée exposée sur Internet plutôt qu'une protection.
L'accès administrateur à votre serveur se fait presque toujours via SSH. Désactiver l'authentification par mot de passe au profit d'une paire de clés cryptographiques élimine d'un coup la quasi-totalité des tentatives de connexion automatisées par force brute, qui essaient des mots de passe courants en boucle 24h/24. C'est la mesure la plus efficace pour l'effort le plus faible.
Le pare-feu du serveur (ufw, nftables ou iptables selon votre distribution) ne devrait laisser passer que le port SSH et le port utilisé par votre serveur VPN - rien d'autre. Chaque port ouvert inutilement est une surface d'attaque supplémentaire, même sur un service que vous pensez ne jamais utiliser.
Fail2ban surveille les journaux de connexion et bannit temporairement (ou définitivement) les adresses IP qui multiplient les tentatives d'authentification échouées. Combiné à l'authentification par clé SSH, il réduit à presque rien le bruit des scans automatisés qui parcourent en permanence les serveurs exposés sur Internet.
Une vulnérabilité découverte dans le noyau, le logiciel VPN ou une bibliothèque système reste exploitable jusqu'à ce que le correctif soit appliqué - pas seulement jusqu'à ce qu'il soit publié. Activer les mises à jour de sécurité automatiques (unattended-upgrades sur Debian/Ubuntu, ou l'équivalent de votre distribution) réduit cette fenêtre d'exposition sans demander d'intervention manuelle régulière.
Effectuer les opérations courantes avec un compte utilisateur standard disposant de droits sudo ponctuels, plutôt que d'être connecté en permanence en tant que root, limite les conséquences d'une erreur de manipulation ou d'une commande malveillante exécutée par erreur.
Au-delà des snapshots de la machine entière, conservez une copie de vos fichiers de configuration VPN (clés, certificats, règles de pare-feu) dans un endroit distinct et chiffré. Cela vous évite de devoir régénérer l'ensemble des configurations clients en cas de perte du serveur.
Si vous utilisez OpenVPN, la sécurité de l'ensemble du système repose sur la protection de la clé privée de votre autorité de certification (CA). Gardez cette clé racine hors ligne autant que possible - ne la laissez pas en permanence sur le serveur VPN lui-même - et générez des certificats individuels par appareil client plutôt qu'un certificat unique partagé, afin de pouvoir révoquer l'accès d'un seul appareil perdu ou compromis sans invalider tous les autres.
Un mécanisme de révocation de certificat (CRL) fonctionnel est aussi important que sa génération initiale. Si un téléphone ou un ordinateur portable configuré avec un certificat client est perdu ou volé, vous devez pouvoir révoquer son accès immédiatement sans avoir à régénérer l'ensemble de l'infrastructure de clés. Testez cette procédure de révocation avant d'en avoir réellement besoin, pas le jour où l'urgence se présente.
Au-delà du pare-feu, quelques réglages système (sysctl sous Linux) réduisent la surface d'attaque réseau : désactiver le renvoi de paquets ICMP redirect, désactiver le routage source, activer la protection SYN cookies contre les attaques par inondation de connexions. Ce sont des réglages ponctuels, appliqués une fois, qui renforcent la résistance du serveur à des classes entières d'attaques réseau basiques.
Fail2ban et un pare-feu bien configuré ne remplacent pas une vérification humaine occasionnelle des journaux de connexion. Une revue rapide et régulière (connexions VPN à des horaires inhabituels, tentatives d'authentification depuis des pays inattendus) permet de repérer une anomalie que les automatismes n'auraient pas bloquée. Un outil simple d'agrégation de logs suffit pour un serveur personnel - inutile de déployer une solution de supervision d'entreprise.