Le dernier Patch Tuesday, Microsoft a publié la mise à jour de sécurité MS12-020 pour fermer deux failles récemment découvertes dans l’implémentation de Microsoft de RDP (Remote Desktop Protocol). L’une d’entre elles, Microsoft la qualifie de « critique » car elle pourrait permettre aux pirates d’obtenir le contrôle du LocalSystem sur une boîte Windows dont le RDP est activé.
Comme vous l’avez probablement entendu maintenant, il s’agit d’une situation à haut risque — qui pourrait entraîner une épidémie aussi grave que celle causée par Code Red, Melissa ou SQL Slammer. Appliquez un correctif ou remédiez à la situation maintenant!
Microsoft vous aidera à faire les deux. Vous pouvez soit installer le patch, soit exécuter un script Fix It en ligne pour atténuer le problème jusqu’à ce que le patch soit appliqué. Le script active l’authentification au niveau du réseau, qui nécessite une authentification avant qu’un système distant puisse se connecter.
Mais j’ai un autre conseil. Comme je le recommande depuis plus d’une décennie, les administrateurs devraient envisager d’exécuter les services connectables à Internet sur des ports non par défaut si possible. Dans ce cas particulier, RDP devrait être exécuté sur un autre port que le port 3389.
Ce conseil s’étend à d’autres domaines. Les sites Web d’administration ne devraient pas être exécutés sur le port 80 ou même 443. SSH ne devrait pas écouter sur le port 22. Les hôtes Telnet ne devraient pas écouter sur le port 23. Le seul service commun répandu que je n’ai pas été en mesure de faire fonctionner de manière fiable sur un port non par défaut est FTP : Il utilise les ports 21 et 22 (en mode passif), et même son mode actif (où vous pouvez indiquer d’autres ports) ne fonctionne pas bien à travers les pare-feu.
Dans le cas de RDP, vous pouvez modifier le port par défaut en suivant ces conseils. Cependant, lorsque vous modifiez le port par défaut, vous devez indiquer le port non par défaut dans la chaîne de connexion (par exemple, mstsc.exe 192.168.1.12:50045).
Ma recommandation de modifier le port d’écoute par défaut sur un service à l’échelle de l’entreprise suscite souvent des critiques. Mon argument central est le suivant : Dans la plupart des cas, une entreprise peut changer le port d’écoute par défaut, ce qui ne cause aucun problème au-delà de l’éducation de l’administrateur et de la reconfiguration unique de certains scripts et outils, et cela diminue considérablement le risque d’attaque militarisée.
Bien que les pirates et les logiciels malveillants puissent utiliser un scanner de port comme Nmap pour trouver le nouveau port, aucun exploit militarisé n’a jamais fait de scan de port, bien qu’ils puissent facilement le faire. Ce seul fait vous donne beaucoup de protection.
Certaines personnes appellent ce genre de recommandation « sécurité par l’obscurité », comme si c’était une mauvaise chose. Si vous me demandez, la sécurité par l’obscurité est l’une des meilleures défenses. Sinon, chaque nation rendrait public l’emplacement de ses missiles et de ses sous-marins nucléaires au lieu de garder l’information secrète.
Pour moi, le ver SQL Slammer est l’un des meilleurs arguments pour mettre les services communs sur des ports non par défaut. Lancé en 2003, il a exploité en 10 minutes la quasi-totalité des serveurs SQL non corrigés et non protégés connectés à Internet. Il s’est déclenché tôt un dimanche matin, et au moment où la plupart des administrateurs s’étaient réveillés, les dommages avaient eu lieu pendant presque une journée de travail complète.
En gros, au moment où nous avons essuyé le sel croûté de nos yeux, c’était fini — puis nous avons passé les 48 heures suivantes (ou plus) à essayer de nettoyer le désordre. C’était un appel au réveil.
Personne qui avait activé SQL sur un port non par défaut (c’est-à-dire un port autre que 1433 et 1434) n’a eu à faire quoi que ce soit — à part regarder calmement tous les autres gérer leurs désastres. Ceux qui ont changé de port n’ont pas eu à nettoyer un énorme gâchis. Ils n’ont pas eu à diffuser des correctifs en urgence. Ils n’avaient pas de serveurs exploités. Un seul changement avec un impact opérationnel minimal et ils ont pu éviter des tonnes de risques.
Certes, d’autres atténuations fonctionnent tout aussi bien, comme exiger une connexion VPN valide avant de se connecter au service, exiger une combinaison de contacts de port préalables avant d’activer le service, ou exiger une authentification réussie avant que le service ne réponde (c’est la solution Fix It de Microsoft), et tout ce qui pourrait vous protéger contre les attaques armées.
Mais je ne peux penser à aucune autre solution de sécurité simple qui diminue le risque aussi efficacement que le changement du port par défaut, lorsque cela est possible. Si vous suivez ce conseil, déplacez le port vers un numéro assez élevé, supérieur à 10 000 ou 12 000, pour éviter d’éventuels conflits de port avec d’autres services existants. Testez tous les équipements de production et mettez à jour les pare-feu ou les proxies nécessaires. Les lecteurs qui ont suivi ce conseil par le passé ne sont pas très pressés cette semaine.