inetdoc.net

Une des premières choses à considérer lors de la configuration d'un pare-feu est son emplacement. Un des premiers endroits qui vient à l'esprit est la passerelle entre votre réseau local et l'Internet. C'est un endroit qui devrait être très sécurisé. Ainsi, dans les grands réseaux ce peut-être une bonne idée de séparer différentes divisions entre elles par des pare-feux. Par exemple, pourquoi l'équipe de développement aurait accès au réseau des ressources humaines, ou pourquoi ne pas protéger le département comptabilité des autres ?

Ceci veut dire que vous devriez configurer vos réseaux aussi bien que possible, et les planifier pour qu'ils soient isolés. Spécialement si le réseau est de taille moyenne ou grande (100 stations de travail ou plus, basé sur différents aspects du réseau). Dans les petits réseaux, essayez de configurer les pare-feux pour seulement autoriser le genre de trafic que vous désirez.

Ce peut être aussi une bonne idée de créer une "zone démilitarisée" (DMZ) dans votre réseau dans le cas où vous avez des serveurs qui sont connectés à l'Internet. Une DMZ est un petit réseau physique avec des serveurs, qui est isolé à l'extrême. Ceci réduit le risque que quelqu'un puisse s'introduire dans les machines de la DMZ, et puisse y implanter des chevaux de Troie ou autre depuis l'extérieur. La raison pour laquelle nous l'appelons zone démilitarisée est qu'elle doit être joignable depuis l'intérieur et l'extérieur, et donc être une sorte de zone grise.

Il existe deux moyens pour configurer le comportement d'un pare-feu, et dans cette section nous verrons ce que vous devriez considérer avant d'implémenter votre pare-feu.

Avant de commencer, vous devriez comprendre que la plupart des pare-feux ont des comportements par défaut. Par exemple, si aucune règle n'est spécifiée dans une chaîne, elle peut-être acceptée ou effacée par défaut. Malheureusement, il y a seulement une gestion de règles par chaîne, mais il est souvent facile de les contourner si vous voulez avoir différentes gestions des règles par interface réseau, etc.

Il existe deux stratégies de base que nous utilisons habituellement. Soit nous supprimons (DROP) tout sauf ce que nous spécifions, soit nous acceptons tout excepté ce que nous spécifions comme devant être supprimé. La plupart du temps nous sommes principalement intéressés par la stratégie de suppression, et ensuite accepter ce que nous désirons de façon spécifique. Ceci indique que le pare-feu est plus sécurisé par défaut, mais ça veut aussi dire que nous aurons plus de travail pour simplement obtenir un pare-feu qui fonctionne correctement.

Votre première décision à prendre est de simplement savoir quel type de pare-feu vous allez utiliser. Quel niveau de sécurité ? Quelles sortes d'applications pourront passer à travers le pare-feu ? Certaines applications sont horribles pour les pare-feux pour la simple raison qu'elles négocient les ports à utiliser pour les flux de données dans une session. Ceci rend extrêmement ardu pour le pare-feu de savoir quel port ouvrir. Les applications les plus communes fonctionnent avec Iptables, mais les rares autres ne fonctionnent pas à ce jour, malheureusement.

Note

Il y a aussi quelques applications qui fonctionnent en partie, comme ICQ. L'utilisation normale d'ICQ fonctionne correctement, mais pas les fonctions de chat (discussions) et d'envoi de fichiers, car elles nécessitent un code spécifique pour décrire le protocole. Comme les protocoles ICQ ne sont pas standardisés (ils sont propriétaires et peuvent être modifiés à tout moment) la plupart des filtres ont choisi soit de ne pas le gérer, soit d'utiliser un programme de correction (patch) qui peut être appliqué aux pare-feux. Iptables a choisi de les utiliser comme programmes séparés.

Ce peut être également une bonne idée d'appliquer des mesures de sécurité en couche, ce dont nous avons discuté plus haut. Ce qui veut dire, que vous pourriez utiliser plusieurs mesures de sécurité en même temps, et pas sur un seul concept de sécurité. En prenant ceci comme concept ça décuplera vos mesures de sécurité. Pour un exemple, voir la figure :

Comme vous pouvez le voir, dans cet exemple j'ai choisi de placer un pare-feu Cisco PIX dans le périmètre des trois connexions réseau. Je peux faire du NAT sur le réseau local (LAN), comme sur la DMZ si nécessaire. Il bloquera aussi tout le trafic sortant sauf les retours http ou ftp ou ssh. Il permet également le trafic http entrant depuis le LAN et l'Internet, de même pour le trafic ftp et ssh depuis le LAN. De plus, nous pouvons noter que chaque serveur web est basé sur Linux, avec Iptables et Netfilter sur les machines avec les mêmes stratégies de sécurité. De cette façon, si le Cisco PIX a un problème, vous pouvez toujours relayer sur les pare-feux Netfilter sur chaque machine, et vice-versa. Ce qui est appelé filtrage de sécurité en couche.

En plus de tout ça, nous pouvons ajouter Snort sur chacune des machines. Snort est un excellent système de détection d'intrusion dans un réseau (NDIS) qui vérifie les signatures dans les paquets, il peut soit envoyer un courrier à l'administrateur ou même répondre de façon active à l'attaque en bloquant l'IP expéditeur. Il faut noter que la réponse active ne doit pas être utilisée à la légère, car Snort a un comportement un peu extrême dans le rapport d'attaques (ex. rapport sur une attaque qui n'en est pas réellement une).

Une bonne idée est aussi d'ajouter un proxy en face des serveurs web pour capturer les mauvais paquets, avec la même possibilité pour toutes les connexions web générées localement. Avec un proxy web vous pouvez gérer de façon plus précise le trafic web de vos employés, aussi bien que restreindre leur usage à certaines extensions. Avec un proxy web sur vos propres serveurs, vous pouvez l'utiliser pour bloquer certaines connexions. Un bon proxy qu'il peut être intéressant d'utiliser est Squid.

Une autre précaution qui peut être prise est d'installer Tripwire qui est une excellente ligne de défense en dernier ressort pour ce type d'application. Il effectue une somme de contrôle sur tous les fichiers spécifiés dans le fichier de configuration, et ensuite l'exécute depuis cron pour vérifier s'ils sont identiques, ou n'ont pas changés de façon illégale. Ce programme est capable de savoir si quelqu'un a pénétré dans le système pour le modifer. Une suggestion est de l'exécuter sur tous les serveurs web.

Une dernière chose à noter est qu'il est toujours bon de suivre les standards. Comme vous l'avez déja vu avec ICQ, si vous ne suivez pas les systèmes standardisés, ça peut provoquer de grosses erreurs. Dans votre propre environnement ceci peut être ignoré pour certains domaines, mais si vous êtes sur une large bande ou une baie de modems, ça peut devenir très important. Les personnes qui se connectent doivent toujours pouvoir accéder aux services, et vous ne pouvez pas espérer que ces personnes utilisent le système d'exploitation de votre choix. Certaines personnes travaillent sous Windows, certaines autres sous Linux ou même VMS, etc. Si vous fondez votre sécurité sur des systèmes propriétaires, vous allez au devant de problèmes.

Un bon exemple de ceci est certains services à large bande qui sont apparus en Suède et qui fondent leur sécurité sur des ouvertures de session réseau Microsoft. Ceci peut sembler une bonne idée au départ, mais lorsque vous considerez d'autres systèmes d'exploitation, ce n'est pas une si bonne idée. Comment quelqu'un tournant sous Linux fera-t-il ? Ou VAX/VMS ? Ou HP/UX ? Avec Linux on peut le faire bien sûr, si l'administrateur réseau ne refuse pas à quiconque d'utiliser le service s'ils utilisent Linux. Cependant, ce didacticiel n'est pas une discussion théologique pour savoir qui est le meilleur, c'est simplement un exemple pour vous faire comprendre que c'est une mauvaise idée de ne pas utiliser les standards.