On remarquera que sous Windows la plupart des failles touchent directement l'utilisateur dans un contexte desktop, autrement dit nous
. Je trouve regrettable que des failles Outlook ou IE figurent à ce tableau, parce que parser et afficher de l'HTML ne devrait pas avoir d'incidence sur le système ...
Pour Unix, bah Bind a toujours été un logiciel critique, et sa version 9, ptrès "usine à gaz", ne fait pas l'unnanimité. Les failles RPC c'est bien plus chiant ... mais utiliser RPC est un choix, il faut donc savoir sécuriser son infrastructure en conséquence. Apache, très exposé, est bien sur sujet à certaines failles de sécurité, mais elles sont corrigées très rapidement, et la série 1.x n'accepte désormais plus que des bugfixes et est plutôt fiable. Le point 4 vient des administrateurs qui laissent des comptes avec mots de passes triviaux ... sans commentaire. De même pour les échanges de données non cryptée, qui peuvent parfaitement l'être avec un bon tunelling ssh ou IPSec. Pour Sendmail, le même constat que pour Bind est applicable : les applications obèses contiennent une plétorde de bugs et sont très difficiles à auditer. Ceci dit, qmail existe et est un peu plus propre que Sendmail. Ensuite, pour SNMP je ne pourrais pas vous éclairer parce que je n'ai jamais eu à l'utiliser. Pour SSH, là c'est vraiment critique parce qu'il est activé sur de nombreux serveurs : il doit être configuré de manière très restrictive, mais n'est, malgrès sa bonne conception, pas à l'abri de bugs. Le point 9 est encore dû aux négligences des administrateurs.
Bref, il faut garder à l'esprit qu'une box bien configurée limite grandement les dégats dans tous les cas. N'activer que les services nécessaires, préparer ses défenses log/firewall/restrictions d'accès et mettre à jour régulièrement les applications "critiques" (SSH, Bind, Apache, ...), si possible en s'abonnant aux mailing lists "announce" de ces logiciels. Une technique élémentaire consiste à partir de rien pour arriver au strict nécessaire, et reconsidérer tout les composants à intégrer, évaluer leur utilité et leur potentiel en terme de sécurité. De même, il est possible de limiter les risques à la compilation en utilisant
Pax,
stack-smashing protector,
RSBAC ...
Si cette politique prévaut pour les serveurs, les workstations en proffiteront aussi ... reste qu'une workstation seule ne peut faire face à toutes les attaques, elle est bien trop vulnérable de part le nombre incalculable de paramètres qui peuvent compromettre sa sécurité. Une workstation a donc besoin d'un serveur/routeur pour la protéger, de manière à n'être pas la cible directe en cas d'attaque frontale.
Du reste, il ne faut pas non plus céder à la paranoïa, automatisez au maximum les tâches de maintenance telles que la sauvegarde ou la mise à jour, et gardez un oeil ouvert si quelque chose d'anormal se produit. Documentez-vous : rien n'est pire que de suivre les rumeurs en matière de sécurité. Un administrateur bien documenté vaut mieux que tous les logiciels de protection configurés à la va-vite, et qui ne donnent finalement qu'une impression trompeuse de sécurité.
Une bonne idée du SANS, qui nous a réalisé un excellent article que je vous conseille de lire en intégralité, vous pouvez comparer un petit scan de port sur votre machine à la liste de ports communs contenus dans "Appendix A Common Vulnerable Ports" à la fin de l'article. Il convient également de faire le ménage dans ses scripts de démarrage et ses services, et de configurer une fois pour toutes correctement son firewall.