La sécurité informatique est un domaine vaste et en évolution permanente. Décrire un ensembe de règles complètes à suivre pour sécuriser un système dépasse de loin le cadre de ce document, et ne serait surement pas adapté à la plupart des cas concrets. Il existe cependant quelques principes de base qu'il est souvent bon de suivre.
Etablir une politique de sécurité est la première chose à faire quand la décision de sécuriser un système a été prise. Une politique de sécurité doit au moins spécifier ce qui est autorisé et ce qui est interdit. Elle peut également poser des obligations aux utilisateurs.
Si le nombre d'utilisateurs est important (à partir de un utilisateur...), il est intéressant de poser par écrit la politique de sécurité, et de rendre ce document accessible à tous les utilisateurs.
L'un des premiers réflexes classiques quand on commence à s'intéresser à la sécurité est de repérer certaines choses "à risques" (habituellement des services, mais aussi des droits sur des programmes ou des périphériques), et de les interdire.
Cette méthode présente un défaut majeur: elle ne protège (au mieux) que des problèmes connus au moment de la mise en place de la politique.
Il est donc plus fiable de raisonner dans l'autre sens: faites la liste de ce que vous devez autoriser (en étant le plus restrictif possible), et interdisez tout le reste. Si vous avez oublié d'autoriser quelquechose, il sera toujours temps de l'ajouter par la suite.
Si vous supposez que tout va bien se passer, que chaque programme va remplir son rôle sans faillir et que votre système est innattaquable, alors vous avez déjà perdu.
Vous devez toujours vous attendre à ce que quelquechose ne fonctionne pas comme prévu. Plus vous anticiperez, plus vous aurez de chances de vous en sortir assez facilement le jour ou quelquechose posera problème [1].
Voici les principales choses à faire pour se préparer au pire:
Plus une machine a de services à fournir, plus le risque de compromission est grand. Dans la mesure du possible, répartissez les services sur différentes machines, et n'autorisez pas vos utilisateurs à s'en servir comme des postes de travail.
Il est également préférable de mettre les serveurs accessibles au public sur une zone réseau séparée, généralement appelée Zone Démilitarisée.
Les problèmes arriveront probablement quand vous êtes en vacances, mais que votre chef à un besoin urgent que tout fonctionne.
Il peut donc être utile d'avoir une marche à suivre pour ce genre de situations. Cela peut être une possibilité pour vous d'intervenir à distance (voir la section intitulée Administrer à distance dans Chapitre 6), la désignation d'une personne responsable en votre absence, la description d'une action à accomplir (tout débrancher, redémarrer le système, etc...) ou toute autre description que vous jugerez utile.
Si vous pouvez interdire quelquechose à plusieurs endroits, ou de plusieurs facons, faites le. Cela peut paraitre superflu, mais il y a toujours un risque que la première sécurité soit contournée [2], ou qu'une erreur de paramétrage permette de contourner la première protection. Attention cependant à d'éventuels conflits entre différents outils chargés du même rôle sur la même machine !
Dès l'installation, mais surtout dans l'administration quotidienne, être informé rapidement des problèmes de sécurité est primordial, et vous permettra de réagir en conséquence (mise à jour, arrêt temporaire du service concerné, etc...). Des sondages montrent régulièrement que de nombreux serveurs sur internet sont encore vulnérables à des failles de sécurité connues depuis longtemps, et pour lesquelles il existe souvent un patch correctif.
Une personne ayant un accès physique à un ordinateur peut généralement très facilement contourner les verrous logiciels installés sur la machine. Voici quelques méthodes classiques pour contourner la sécurité logicielle, et la façon de s'en protéger.
La méthode la plus facile pour contourner la sécurité mise en place par le système est de ne pas démarrer ce système, mais un autre. Il existe par exemple des disquettes bootables contenant une mini-distributions de GNU/Linux, ou un outil permettant d'accéder aux partitions Linux sous Windows, eplore2fs.
Pour protéger vos données de ce genre d'accès, vous devrez généralement configurer le BIOS de votre machine[3] pour qu'il démarre directement sur le disque dur, sans essayer les lecteurs de disquettes, de CDROMs ou autres.
Pensez à protéger l'outil de configuration du BIOS par un mot de passe, et assurez-vous qu'il ne sera pas trop facile de réinitialiser la configuration du BIOS.
Tous vos efforts de configuration ne serviront à rien si une personne peut prendre votre machine, ou si elle peut l'ouvrir. Cette personne pourrait alors réinitialiser la configuration du BIOS, démarrer un autre système d'exploitation, prendre votre disque dur (et donc vos données) ou insérer un périphérique supplémentaire.
La sécurisation << matérielle >> d'une machine est une chose trop spécifique pour être traitée ici, mais vous pourrez généralement au minimum mettre un cadenas sur votre boitier pour empécher son ouverture à l'aide d'un simple tournevis.
De par son statut privilégié sur le système, l'utilisateur peut assez facilement causer des problèmes de sécurité, volontairement ou non. Il est donc important de limiter les droits de vos utilisateurs à ce qui leur est nécessaire, mais également de les sensibiliser aux problèmes de sécurité. Cela vous permettra de protéger (au moins partiellement) vos utilisateurs de certaines manipulations dangereuses, mais cela vous permettra aussi de leur expliquer pourquoi vous limitez leurs droits sur le système.
Il vous faudra tout particulièrement insufler à vos utilisateurs une certaine dose de méfiance, sans laquelle ils risquent de très facilement exécuter n'importe quel programme envoyé par n'importe qui (voir Se protéger des virus) ou de faciliter sans même s'en appercevoir une attaque par Social Engineering (voir la section intitulée Utilisateurs et mots de passe dans Chapitre 4).
L'obscurité en sécurité informatique est un sujet qui a fait couler beaucoup d'octets, et qui fache encore parfois.
Est généralement qualifiée de "sécurité par l'obscurité" une politique ou une méthode de sécurité qui se base uniquement sur la non divulgation d'une information. On pourra citer par exemple la mise en place d'un serveur (web, ftp, telnet, etc...) sur un port inhabituel et sans authentification. Tout le dispositif de sécurité est basé sur la connaissance du port utilisé: une personne connaissant ce port peut accéder au serveur et donc à ses ressources.
Un autre exemple connu de sécurité par l'obscurité est le célèbre "code de Cesar", utilisé par l'empereur romain pour chiffrer ses correspondances: un décalage de 3 lettres appliqué au texte ("abc" devient "def", et "toto" devient "wrwr"). Toute personne connaissant cette méthode peut alors décoder tous les messages l'utilisant.
La plupart des experts en sécurité informatique s'accordent à dire qu'une politique basée sur l'obscurité est mauvaise et innefficace dès que l'attaquant possède un minimum de compétences et/ou d'outils (dans nos exemples, un scanner de ports ou un programme simple de décryptage).
Devons-nous pour autant nous mettre en permanence en pleine lumière ? Certainement pas ! Si l'obscurité constitue une très mauvaise base pour la sécurité, elle peut en revanche être un ralentisseur très intéressant: si votre serveur est déjà bien protégé et bien sécurisé, le fait de le camoufler peut décourager les attaquants débutants et faire perdre un temps précieux aux attaquants plus expérimentés.
Pensez donc au minimum à modifier les messages par défaut de vos serveurs web, ftp et autres de façon à ce qu'ils n'affichent pas le système d'exploitation utilisé, bloquez tous les services succeptibles de donner des informations sur vos utilisateurs (finger, indent, certaines commandes SMTP, etc...) et bloquez les traceroutes et autres pings vers votre machine si possible.
| [1] | Et ce jour arrivera forcément, et surement plus tôt que vous ne le pensez ! |
| [2] | Récemment encore, le système de filtrage IPFilter, pourtant réputé, a été victime d'un bug qui permettait, dans certaines conditions, de passer outre les règles de filtrage. |
| [3] | Sur des architectures autres que les compatibles PC, la marche à suivre peut être différente. |
| Précédent | Sommaire | Suivant |
| Prérequis | Niveau supérieur | Installation du système |