Pourquoi un scan authentifié, ou « authenticated scan » en anglais, avec Qualys avec un clé ssh ? Un scan réseau Qualys est souvent trop limité en scannant uniquement les ports TCP/UDP pour construire une vue complète sur l’ensemble des vulnérabilités d’un serveur.

Entre les applications non exposées sur le réseau, les seveurs à multiples interfaces réseau, les services exposés partiellement (par exemple avec un filtre ip) ou les authentifications web de type SAML et openidconnect, il est difficile d’avoir une vue d’ensemble exhaustive sur les vulnérabilités présentes sur le serveur. Tout bon CISO ou expert en sécurité doit avoir une vue exhaustive afin d’être en mesure les risques et faire les bons choix.

Le scanning authentifié SSH résout ce problème, encore faut-il pouvoir l’implémenter correctement. De nombreuses organisations se limitent à définir le même login et mot de passe sur chaque serveur et configurer l’accès dans la console Qualys. Bien que l’approche semble facile à mettre en place, on peut se poser des questions sur de telles pratiques.

Création d’un compte technique du scanneur de vulnérabilités Qualys SSH

Le compte SSH a besoin des droits « root » (ou « sudo » – « root equivalent ») afin de pouvoir réaliser un inventaire complet des vulnérabilités. Nous aurions aimé que Qualys publie une liste mise à jour des commandes requises. Cette approche permettrait de mettre en place une politique de « least privileges ». Nous évitons d’éventuels abus liés au compte technique utilisé par le scanner Qualys.

Qualys indique clairement sur son site qu’ils ne publient pas ces informations et qu’ils n’ont pas l’intention de le faire: « Customers should be strongly discouraged from placing granular controls around the Qualys service account because of the reasons stated above.« 

Stratégie de protection du compte SSH (qualys)

Afin d’éviter les abus d’utilisation du compte technique Qualys, nous recommandons la stratégie suivante

• Authentication sur base d’une clé SSH et protégée par une passphrase
• Procédure pour la génération de la clé SSH, la passphrase et l’import dans Qualys pour garantir l’intégrité de la clé et éviter de maldadroites copies (ou l’envoi de la clé par via un canal non insécurisé ou non approprié)
• Forcer l’utilisation de la clé SSH pour le compte Qualys (et donc interdire l’utilisation d’un mot de passe). Dans certains cas, il se pourrait que le compte nécessite une clé SSH et un mot de passe, en fonction des règles existantes définies sur le serveur
• Limiter les connexions à l’ip du serveur Qualys (souvent une ip fixe et whitelisté dans les firewalls)
• Automatiser le déploiement sur les serveurs via le « configuration management tool » préféré (ansible, puppet, chef,..): création de l’utilisateur, déploiement de la clé publique, déploiement sudo

Déploiement sudo (compte qualys)

Nous recommandons la configuration suivante pour le fichier sudoers

sudoers file

# Cmnd alias specification Cmnd_Alias SU=/bin/su # User privilege specification qualysuser ALL= NOPASSWD:SU

qualysuser désigne ici l’utilisateur technique Qualys utilisé par le scanner.

NOPASSWD signique que le compte n’a pas besoin de mot passe pour devenir « root equivalent ». Ceci est nécessaire si aucun mot de passe n’est configuré et que l’authentication est uniquement basée sur la clé SSH.

Limiter la source ip au scanner Qualys

Pour limiter l’ip source, nous configurons le filtrage suivant sur le fichier /home/qualysuser/.ssh/authorized_keys.

ssh file

from="<ip scanner>" ssh-rsa AAAAB3N....................U7= qualyuser@qualysscanner

Configuration /etc/ssh/sshd_config

Match User qualysuser    PasswordAuthentication no Match Address 1.2.3.4 PasswordAuthentication no

Conclusion

Nous avons vu comment il est possible de facilement déployer une configuration à grande échelle permettant à Qualys d’avoir une meilleure vue sur les vulnérabilités.

L’article porte sur Qualys mais la configuration est très probablement identique pour un produit concurrent comme Tenable Nessus.

Il est possible d’aller encore plus loin, par exemple:

• Protéger la clé SSH dans un Vault
• Intégrer les logs avec un SIEM pour détecter tout abus lié au compte
  • par exemple tentative de login depuis une autre ip,
  • ou une authentication via un mot de passe,
  • une authentication échouée..
• Désactiver les comptes techniques sur les serveurs Linux lorsque le scanner n’est pas en fonction si les scans sont réalisés de manière sporadique
• Mettre en place une procédure pour changer la clé SSH à interval régulier (par exemple annuellement). Du côté des machines Linux, il faut simplement modifier la clé publique, tâche assez facilement réalisable avec un configuration management tool.