Scanning Issues

Nessus est une plateforme de scan de vulnérabilités largement reconnue et utilisée. Cependant, il est essentiel de respecter certaines bonnes pratiques avant de lancer un scan. Mal configuré, un scan peut provoquer des faux positifs, une absence de résultats, voire un impact négatif sur le réseau ciblé. Il convient donc de communiquer en amont avec le client ou les parties prenantes internes afin d’identifier les hôtes sensibles ou critiques, qui pourraient nécessiter un traitement à part (exclusion, horaire spécifique, configuration adaptée).

---

🛡️ Mitigation des problèmes courants

Certains pare-feux peuvent générer des résultats de scan incohérents, comme indiquer que tous les ports sont ouverts ou fermés. Une solution consiste à utiliser un scan avancé en désactivant l’option "Ping the remote host". Cela évite à Nessus de s’appuyer sur ICMP pour déterminer si un hôte est actif, contournant ainsi certains pare-feux configurés pour répondre par des messages ICMP trompeurs.

Dans les réseaux sensibles, l’ajustement des options de performance permet de réduire l’impact :

• Limiter le nombre de tests simultanés par hôte (option Max Concurrent Checks Per Host).

• Diminuer le nombre d’hôtes scannés en parallèle.

Des dispositifs anciens (legacy) doivent être exclus du périmètre ou désactivés via le fichier nessusd.rules. De plus, il est recommandé de désactiver le scan des imprimantes et autres équipements fragiles.

🔒 Ne jamais activer les plugins de type Denial of Service sauf si cela est explicitement demandé. Il est conseillé d’activer l’option "Safe Checks" pour limiter les risques d’impact.

Enfin, il est indispensable d’informer les équipes concernées avant un scan et de conserver des logs détaillés en cas d’incident.

---

🌐 Impact réseau

Le scan de vulnérabilités peut fortement impacter un réseau, notamment en cas de bande passante limitée ou de congestion. Il est possible de mesurer cet impact avec l’outil vnstat.

🔍 Exemple sans scan :

sudo vnstat -l -i eth0

rx:       332 bit/s     0 p/s          tx:       332 bit/s     0 p/s

 eth0  /  traffic statistics
  bytes                        572 B  |           392 B
  packets                          8  |               5
  time                    40 seconds

🔍 Exemple pendant un scan Nessus :

sudo vnstat -l -i eth0

rx:   307.92 kbit/s   641 p/s          tx:   380.41 kbit/s   767 p/s

 eth0  /  traffic statistics
  bytes                     1.04 MiB  |        1.34 MiB
  packets                      18252  |           22733
  time                    38 seconds

📊 Ces résultats montrent que le scan génère un trafic important en peu de temps. Il est donc crucial de bien paramétrer les scans pour éviter une surcharge du réseau ou des effets indésirables sur des systèmes en production.

---

✅ Recommandations clés

• 🔕 Désactiver les scans agressifs sur les systèmes critiques.

• 🔁 Informer les parties prenantes et planifier les scans hors heures de production si possible.

• 🔧 Adapter les paramètres de performance en fonction de la robustesse du réseau.

• 📋 Conserver une traçabilité complète de toutes les activités de scan.

---