Sécurité serveur : audit, durcissement, nettoyage
Un audit en lecture seule des ports, de SSH, du pare-feu, des utilisateurs, des tâches planifiées, de Docker et des fichiers exposés ; un durcissement en option, sauvegardes vérifiées d'abord et chaque changement consigné ; et un nettoyage de crypto-mineur ou de malware avec rapport d'incident et recommandation de reconstruction quand le nettoyage ne suffit pas.
STYD réalise un audit de sécurité en lecture seule des serveurs VPS Linux (ports, pare-feu, SSH, utilisateurs, persistance cron et systemd, Docker, fichiers exposés, bases de données, indices de malware), applique un durcissement de base uniquement sur accord écrit, et nettoie les infections par crypto-mineur ou malware en conservant les preuves, avec rapport d'incident et recommandation de reconstruction si nécessaire.
Le problème
La plupart des serveurs d'entreprise ont été installés une fois, vite, par quelqu'un qui n'est peut-être plus là. Depuis, des ports ont été ouverts pour un test, une base de données écoute sur Internet, un dossier .env ou .git est servi par le serveur web, et root peut encore se connecter par mot de passe. Rien ne semble anormal jusqu'à ce qu'un crypto-mineur comme kinsing, kdevtmpfsi ou xmrig apparaisse, que l'hébergeur envoie un signalement d'abus ou qu'un identifiant fuite. Tuer le processus du mineur suffit rarement : il se réinstalle depuis des tâches cron, des services systemd ou des utilisateurs cachés.
Pour qui
Les entreprises qui font tourner leur propre VPS Linux pour une application web, Odoo, WordPress, Docker, une base de données ou des outils d'automatisation comme n8n : les propriétaires qui ont hérité du serveur et veulent savoir s'il est sûr, et les propriétaires de serveurs qui montrent un CPU élevé, des processus inconnus ou un signalement d'abus de l'hébergeur.
Le résultat
Un serveur dont l'état réel est connu et documenté : expositions dangereuses fermées, SSH et pare-feu sur une base saine, fichiers sensibles plus jamais publics, et une liste claire de ce qui reste. Si le serveur était infecté : l'infection active stoppée, sa persistance retirée, les preuves conservées, et un compte rendu écrit de ce qui a été trouvé, des identifiants à considérer comme exposés, et de la possibilité de garder le serveur en service ou de le reconstruire.
Ce que STYD livre
STYD audite d'abord le serveur en lecture seule : inventaire, ports publics, pare-feu, configuration SSH, utilisateurs et sudoers, persistance cron et systemd, Docker, exposition web des fichiers .env, .git et de sauvegarde, SSL, exposition des bases de données, indices de malware de base, et emplacement des secrets, sans en exposer les valeurs. Chaque constat est noté Critique, Élevé, Moyen, Faible ou OK. Si vous approuvez le durcissement, STYD applique la base : SSH par clé uniquement avec connexion root désactivée quand c'est sûr, pare-feu UFW de base, Fail2ban, mises à jour de sécurité automatiques sans redémarrage automatique, blocage des fichiers sensibles et en-têtes de sécurité sûrs sur Nginx ou Apache, et permissions resserrées sur les fichiers de secrets, le tout validé avant et après. Si le serveur est infecté, STYD capture les preuves avant de toucher à quoi que ce soit, examine processus, écouteurs, cron, systemd, fichiers de démarrage, dossiers temporaires, conteneurs, utilisateurs et clés SSH, ne retire que les éléments confirmés malveillants (les fichiers suspects sont mis en quarantaine, pas détruits ; les utilisateurs de porte dérobée sont supprimés), revérifie le serveur et livre un rapport d'incident avec un plan de rotation des secrets et, quand le nettoyage ne suffit pas, une recommandation de reconstruction.
Questions fréquentes auxquelles ce service répond
- audit sécurité VPS Linux
- sécuriser un VPS Ubuntu SSH pare-feu
- mon VPS est-il sécurisé
- durcissement serveur Linux
- sécuriser un VPS Odoo
- ports Docker exposés serveur
- supprimer un crypto-mineur d'un serveur Linux
- signalement d'abus de l'hébergeur VPS malware
Tarification
Le tarif final est confirmé après un court échange de cadrage.
FAQ
C'est le principal risque d'un durcissement négligent, donc il est verrouillé. Avant de toucher aux règles SSH ou pare-feu, STYD confirme l'accord écrit, une sauvegarde ou un point de restauration vérifié, un instantané chez l'hébergeur si possible, un accès console hors bande, et un utilisateur non root fonctionnel avec une clé SSH.
Le durcissement s'arrête. Sécuriser un serveur peut-être déjà compromis ne fait que cacher le problème, donc le travail passe au volet nettoyage de ce service : les preuves d'abord, puis le retrait des éléments confirmés, puis une revérification.
Vous pouvez, et il revient souvent. Les mineurs se réinstallent depuis des tâches cron, des services systemd, des fichiers de démarrage ou des utilisateurs cachés. Nettoyer, c'est trouver et retirer tout cela, et comprendre par où ils sont entrés.
Un nettoyage manuel ne peut pas garantir qu'un serveur compromis est propre à 100 %. Si une compromission root est suspectée ou si le point d'entrée reste introuvable, la recommandation honnête est une reconstruction sur un serveur neuf, chiffrée séparément.
Audit à partir de $350, audit avec durcissement à partir de $750, nettoyage à partir de $500. Les cas urgents, comme un hébergeur qui menace de suspendre le serveur, sont chiffrés au contact selon le serveur et la situation.
Aucun serveur ne peut être garanti sûr à 100 %. Le travail ferme les expositions courantes et dangereuses, met les accès sur une base saine et dit clairement ce qui reste. Une supervision en option et un plan de suivi mensuel peuvent suivre une fois le serveur stabilisé, sur devis.
La revue du code applicatif, l'investigation à des fins juridiques ou d'assurance et la supervision continue sont à part. Une reconstruction complète sur un serveur neuf est chiffrée séparément quand un serveur ne peut plus être digne de confiance. Ce n'est ni un test d'intrusion ni un audit de conformité certifié.
Services STYD associés
Une revue en lecture seule, fondée sur des preuves, des applications, du code et des automatisations sur lesquels tourne votre entreprise, et une évaluation indépendante d'un système encore en développement : ce qui est exposé, ce qui est sain, et s'il faut continuer à construire.
Une revue concrète de la façon dont votre entreprise tourne sur ses outils : flux de travail, rapports, automatisations, intégrations, hébergement. Elle se termine par une liste priorisée de ce qu'il faut corriger en premier.
Un analyste IA installé sur votre propre serveur Linux, qui répond aux questions à partir de votre Odoo, de vos bases PostgreSQL ou MySQL et de vos documents, en lecture seule. STYD n'héberge rien, et vous choisissez l'IA qui le fait tourner.
Parlez-nous de votre configuration et nous confirmerons l'adéquation, le périmètre et le tarif.