J'ai scanné mon serveur avec un outil de scan de vulnérabilités — les failles trouvées sont-elles un vrai risque ?

Les vulnérabilités liées aux versions de paquets viennent souvent des correctifs rétroportés (backport). Les distributions Linux appliquent les patchs de sécurité sans changer le numéro de version principale du paquet, mais comme le scanner se contente de lire la bannière, il croit qu'il y a une faille. Vérifiez le changelog de votre gestionnaire de paquets pour confirmer si le bulletin concerné a bien été corrigé.

La première chose à faire, c'est de durcir les règles de votre pare-feu. Sur le serveur, seuls les ports 80 et 443 doivent rester ouverts vers l'extérieur. Si vous restreignez tous les services d'administration, y compris SSH, au réseau local ou à l'IP fixe de votre bureau, au moins la moitié des alertes du rapport disparaîtront en une heure.

Sur notre plateforme, le premier scan avait sorti 62 failles, on s'est enfermés deux jours avec notre dev pour tout éplucher. Sur les 6 failles critiques, 5 n'étaient que des faux positifs basés sur la détection de version. La seule vraie faille critique restante, c'était un port de base de données de test laissé ouvert sur l'extérieur. Une fois fermé, le score est redevenu propre direct.

Vous avez lancé le scan avec authentification ou simplement depuis l'IP externe ? Si vous avez scanné de l'extérieur sans fournir d'identifiants et que l'outil a quand même pu lister les versions de vos paquets internes, c'est que vos bannières de service divulguent trop d'informations ; commencez par masquer ces en-têtes.

Les scanners automatiques sont la méthode préférée des boîtes de conseil pour gonfler leurs rapports. Ils sortent des pages entières de graphiques colorés pour faire peur. Un vrai attaquant ne s'attaque pas à tout ce que pointe un outil automatique ; il cherche les failles de contrôle d'accès et la logique métier des API. Pas de panique.

Ne vous prenez pas la tête, n'importe quel serveur sort ce genre de tableau au premier scan. Commencez par mettre à jour vos suites de chiffrement avec des outils de test SSL en ligne gratuits pour sécuriser la config de votre serveur web. Redémarrez ensuite le système et relancez le scan vous serez vite rassuré en voyant le résultat.

on a eu la meme panique chez nous mais on a cherché les cve une par une pour voir si un exploit etait vraiment dispo. la plupart demandaient un acces local donc fallait deja etre infiltré sur le serveur. fermez les ports de base et faites le reste tranquillement.

Ne vous fiez pas aveuglément au score CVSS pour prioriser les résultats. Votre priorité absolue doit toujours être les failles exploitables à distance sans authentification. Si une vulnérabilité nécessite un compte utilisateur local sur le serveur ou si le port n'est pas exposé sur Internet, même si elle est classée critique, sa priorité opérationnelle reste faible.

Ce qui est écrit correspond exactement à ce que nous avons vécu. du coup les environnements de test oubliés sont plus souvent des portes d'entrée que les systèmes de production.

Si vous obtenez trois réponses différentes sur un sujet, la question est mal posée. bref à votre place j'irais par cette voie.

Absolument. Si j'ajoute quelque chose : L'erreur commise du côté de outil de scan de vulnérabilités est généralement réversible, mais coûteuse.

Une modification des coordonnées bancaires n'est jamais confirmée par le canal d'origine.

La discussion part dans tous les sens, je recentre. Aucun processus sans suivi ne s'améliore, car vous ne savez pas quoi corriger.

Je suis aussi curieux de savoir si d'autres font autrement.

je suis dans la même situation c'est pourquoi je pose la question et du coup les envirnonements de test oubliés sont plus souvent des portes d'entrée que les systèmes de production.

la plupart des pertes de temps s'accumulent sur les tâches en attente de validation. c'est confirmé par l'expérience.

Je me permets une petite mise en garde. Le temps que vous mettez à détecter un problème détermine directement son coût.

exact.

Je suis intéressé. Aucun processus sans suivi ne s'améliore, car vous ne savez pas quoi corriger.

Voilà, désolé si je me suis étendu.

Chez nous aussi.

Beau travail. Tous ceux qui se pressent sur outil de scan de vulnérabilités se heurtent au même obstacle.

La sécurité n'est pas absolue ; c'est rendre l'attaque trop coûteuse pour valoir l'effort. Bon courage.

Je vais essayer.