Free-EOS v1.2

filtrage IP personnalisé

Personnalisation du firewall (ipchains)


Auteur : Joseph BERAUD (jibe, jibe74)
Sources : IPCHAINS HOWTO , "Introduction aux Templates" du site smeserver.fr, diverses pages web sur Linux, SME et FreeEOS et discussions sur forums
Testé sur FreeEOS version 1.2.2 GPL
Mise a jour : Octobre 2006
Licence : GPL


Permission est donnée de copier, diffuser et/ou modifier le présent document en vertu des conditions de la licence GPL, Version 2 ou toute autre version plus récente publiée par la fondation pour le logiciel ouvert « Free Software Foundation ». Permission accordée pour la production de copies mot à mot sans les textes de couverture et avec maintien des mentions de copyright et des auteurs. Une copie de la licence GFDL est disponible sur le site de la Free Software Foundation à l'adresse http://www.fsf.org/copyleft/fdl.html .

Tous les noms et marques de commerce sont la propriété de leurs titulaires respectifs.


1. But de ce document

1.1. A Propos de ce guide

Les versions 1.2.x de FreeEOS utilisant un noyau 2.2 et donc ipchains, ce guide peut paraitre obsolète étant donné que la version 2, basée sur un noyau 2.4 et iptables est prévue et que le noyau 2.6 fait son apparition. Toutefois, les versions en service de FreeEOS ou SME utilisant ipchains sont encore nombreuses. De fait, c'est pour répondre à une demande d'une entreprise que j'ai effectué cette étude qui pourra probablement servir de base pour les versions futures de FreeEOS ou les versions de SME à partir de la 5.6. Je compte bien, d'ailleurs, continuer cette étude dans le cadre du projet SMERP .

1.2. Le besoin des entreprises et FreeEOS

Les entreprises - particulièrement les PME - ont besoin d'une connection partagée à internet, avec un bon firewall de façon à ce que les différents postes qui y ont accès soient bien protégés des diverses attaques venant de l'extérieur. Souvent, leurs différents postes sont reliés par un réseau local de façon à pouvoir aisément partager les données, voire certaines applications. Intervient alors le problème suivant : comment faire pour que seulement une partie des postes du réseau local aient la possibilité d'accéder à Internet ?

Les raisons de ne pas souhaiter que tous les postes aient un accès sont variées :

  • - Eviter les attaques virales sur les postes qui n'ont aucun besoin d'Internet,
  • - Ne pas tenter certains employés plus enclins à surfer qu'à travailler,
  • - Ne pas transformer l'entreprise en cyber-café par le biais des postes mis à disposition du public pour présenter les produits,
  • - Etc.

Le problème, dans les petites entreprises, est que le budget informatique est généralement très serré. Ceci conduit d'abord à ne pas avoir d'administrateur réseau et donc de n'avoir personne de compétant pour configurer un firewall. La seconde conséquence est aussi que, pour limiter les coûts matériels, on recycle souvent un vieux PC pour faire office de serveur/routeur/passerelle, et que celui-ci n'est pas toujours assez puissant pour qu'on puisse envisager des solutions "gourmandes" en ressources.

FreeEOS et SME offrent une bonne solution, avec un firewall auto-configuré qui ne demande aucune intervention humaine pour remplir assez parfaitement son office. Mais si cette auto-configuration permet de se passer aisément des services d'un administrateur réseau, elle ne permet pas non plus de configurer l'accès poste par poste.

1.3. Les solutions possibles

Certes, les solutions possibles pour réaliser un filtrage poste par poste sont nombreuses. Mais si l'on tient compte des contraintes exposées ci-dessus, la majeure partie ne peut pas convenir.

Si l'on désire ne pas ajouter de matériel, je ne vois qu'une seule solution pour réaliser ce filtrage. Il s'agit d'un rpm créé par Master Sleepy : e-smith-squid-restrict-ip-0.1-1.noarch.rpm . L'essai serait à tenter pour confirmer, mais ce RPM fonctionne probablement très bien sous FreeEOS. Par contre, comme son nom l'indique, il utilise le démon proxy squid pour effectuer le filtrage. Si le serveur est monté sur une machine peu puissante, squid peut amener un ralentissement gênant, lequel ralentissement ne sera même pas compensé par le "cachage" des pages chargées si la connection internet est rapide, ADSL par exemple.

1.4. La solution retenue

Si la solution apportée par Master Sleepy peut être envisagée dans certains cas, mon but était de trouver une solution pour une machine peu puissante sur laquelle il était impossible d'envisager la mise en service de squid. J'ai donc résolu d'employer la méthode la plus naturelle, celle proposée par Linux, à savoir l'utilisation du firewall de base configuré par ipchains.

1.5. Un mot sur DHCP

Certes, la solution proposée ne fonctionne pas si un adressage dynamique des postes clients est effectué via DHCP (sauf astuce ci-dessous). Pour ma part, je n'aime pas beaucoup l'adressage dynamique et n'en vois l'utilité que dans certains cas bien précis, qu'on ne rencontre pas sur les petits réseaux qui nous intéressent ici, et qui comportent souvent des postes clients hétéroclites d'ailleurs. De tous les cas que je connais, aucun ne comporte un grand nombre de postes qu'il est possible de configurer de manière automatique. Le fait d'avoir à paramétrer l'adresse IP statique pour chacun n'est donc pas un handicap, et apporte en revanche une parfaite maitrise du réseau et des possibilités intéressantes.

Pour les adeptes des solutions automatisées et de l'attribution dynamique d'adresses IP, il reste une solution : l'adressage mixte. Il est en effet possible de configurer DHCP pour qu'il attribue des adresses dans une certaine tranche (par exemple au-delà de 192.168.1.127). On laissera en adressage dynamique les postes correspondants à la règle la plus générale, et on passera en adresse statique les autres. Il suffira alors d'établir les règles en conséquence.

2. Mise en oeuvre

2.1. Avertissement

La méthode exposée ici est basée sur iptables. Le lecteur a donc tout intérêt à se documenter sur le sujet, clairement expliqué dans différents documents dont le plus classique est IPCHAINS-HOWTO . Le but de ce document n'est pas d'exposer la théorie d'ipchains ! Le lecteur est donc censé connaitre parfaitement le sujet.

Cette méthode vous est livrée sans aucune garantie. Je l'ai mise en service sur deux serveurs, sur lesquels elle fonctionne apparemment bien. Toutefois, vous la mettez en service à vos risques et périls. Je n'accepte la responsabilité de rien de ce qui pourrait découler, directement ou indirectement, de la mise en service de cette méthode de filtrage. Vous voilà prévenus !

2.2. Elaboration des règles

2.2.1. L'exemple choisi

Pour expliquer cette méthode, nous allons nous baser sur un exemple très simple : un réseau constitué d'un serveur FreeEOS et de quatre postes clients que nous appellerons A, B, C et D. Le serveur a pour IP locale 192.198.1.1. Le poste A (192.168.1.10) a droit à tout Internet, le poste B (192.168.1.20) n'a le droit de visiter que www.free.fr, et le poste C (192.168.1.30) a le droit d'aller partout sauf sur www.free.fr. Enfin, le poste D (192.168.1.40) n'a aucun accès à internet.

Bien qu'ipchains sache faire la résolution de noms en traitant les règles du firewall, nous travaillerons avec des adresses numériques, ce qui évite une recherche DNS pour chaque règle. Une consultation sur dnsreport.com nous apprend que free.fr a pour adresse 213.228.0.42.

Nous pourrions envisager, certes, des cas beaucoup plus complexes. Mais nous nous contenterons d'un cas simple : tout trafic à l'extérieur, quel qu'il soit, est bloqué totalement. S'il était besoin de laisser passer certains services, il suffirait d'établir les règles en conséquence. Elles pourraient alors être beaucoup plus complexes, mais le principe de base exposé ici resterait le même.

2.2.2. Les règles établies par le système

La force de FreeEOS (et de SME) est que le firewall est élaboré automatiquement lors de tout changement de configuration effectué via le menu de console ou le "server-manager" ("e-smith-manager" sur SME). Ceci ne nous arrange guère, car cela implique des règles de base mouvantes auxquelles nous devrons nous adapter.

2.2.3. Où placer les notres

En fait, cela n'a que peu d'importance. En effet, les règles d'accès à l'Internet seront généralement des DENY et peuvent (et même, dans bien des cas, doivent) être placées en tout premier. Reste que nous pourrions (ce sera le cas dans notre exemple) avoir quelques ACCEPT. Nous contournerons le problème en créant une nouvelle chaîne de règles, et en appelant cette chaine en tout premier. Ainsi, les paquets à traiter traverseront d'abord nos règles. Ceux qui sont à éliminer le seront immédiatement et n'iront donc pas plus loin. Quant à ceux qui sont acceptés, ils sortiront de notre nouvelle chaine et reviendront suivre le cours normal, donc traverseront bien les règles de base du système. Il est donc théoriquement impossible de créer ainsi un trou de sécurité.

Voici, replacé dans le schéma d'IPCHAINS-HOWTO, l'ensemble de nos règles :

        ----------------------------------------------------------------------------------------
        |                      ACCEPTER/                               interface lo |
        v                      REDIRIGER                 _________                  |
--> S --> V --> ______ --> ______ --> D --> ~~~~~~~~ -->| Chaîne  |----> _______ -->
    o     a    |notre |   |chaîne|    e    {Décision}   |transfert|     |Chaîne |ACCEPTER
    m     l    |chaîne|   |entrée|    m    {Routage }   |_________| --->|sortie |
    m     i    |______|   |______|    a     ~~~~~~~~         |      | ->|_______|
    e     d       |          |        s        |             |      | |     |
    |     i       |          |        q        |            NON/    | |     |
    |     t       v          v        u        v           REJET    | |     v
    |     é      NON/       NON/      e    Processus                | |    NON/
    |     |     REJET      REJET      r      Local                  | |   REJET
    |     v                           |        ---------------------- |
    v    NON                          \ ------------------------------/
   NON

2.3. Le fichier des règles

Afin d'être plus à l'aise pour l'établir et le modifier par la suite, nous construirons notre fichier de règles dans le répertoire "files" d'un @telier (ibay pour SME). Il pourrait aussi bien être construit directement dans le répertoire /etc/rc.d où il devra se trouver au final.

#--------------------------------------------------------------
# règles de filtrage http de test
#--------------------------------------------------------------
# INPUT
#==============================================================
# On insère une nouvelle chaine au début dans laquelle doivent
# passer tous les paquets
/sbin/ipchains -N jbfilter
/sbin/ipchains -I input 1 -s 0/0 -d 0/0 -j jbfilter
#
# FORWARD
# =============================================================
# Le blocage en input et en output est suffisant...
#
# OUTPUT
#==============================================================
# Par sécurité, on peut insérer ici aussi nos règles au début
/sbin/ipchains -I output 1 -s 0/0 -d 0/0 -j jbfilter
#
# jbfilter
#==============================================================
# Le poste A a droit à tout, donc ne nécessite aucune règle
#
# C n'a pas droit à free.fr
/sbin/ipchains -I jbfilter 1 -s 192.168.1.30 -d 213.228.0.42 -j DENY
#
# B n'a droit qu'à free.fr + LAN
/sbin/ipchains -I jbfilter 1 -s 192.168.1.20 -d ! 213.228.0.42 -j DENY
/sbin/ipchains -I jbfilter 1 -s 192.168.1.20 -d 192.168.1.0/24 -j ACCEPT
#
# D n'a droit à rien d'extérieur
/sbin/ipchains -I jbfilter 1 -s 192.168.1.40 -d ! 192.168.1.0/24 -j DENY

3. Test et mise en service

3.1. Test des règles

Comme indiqué plus haut, ce fichier sera soit mis dans le répertoire "files" d'un @telier (ibay sur SME), ce qui facilite ses modifications, soit directement en place dans le répertoire rc.d. Nommons-le MonFiltreIP . Nous pouvons l'essayer immédiatement, après bien sûr avoir fait un

chmod 777 MonFiltreIP

Lançons.le donc :

./MonFiltreIP

Puis vérifions dans un premier temps que les règles ont bien été prises en compte :

/sbin/ipchains -L -n | less

Nous devrions retrouver nos règles judicieusement placées. Rendons-nous alors sur les différents postes clients pour tenter un petit surf sur internet. Nous devrions pouvoir le faire sans problème pour le poste A, pas du tout sur le poste D, et partiellement sur B et C. Assurons-nous en même temps que tous les accès au LAN se font normalement. Le plus simple est de tenter de lancer le server-manager (e-smith-manager sur SME) ou une quelconque page web située dans un @telier (ibay sur SME). Il est bien sûr possible, même conseillé, de tenter d'autres accès au LAN (ping, mails etc.).

3.2. Mise en place

3.2.1. Les templates

Une des difficultés de la FreeEOS et de la SME dont elle est issue est l'utilisation de "templates". Nous laissons le lecteur se documenter à ce sujet sur le site de contribs.org . Quant à moi, ma page préférée pour bien comprendre les templates est (restons français !) celle de Grand-Pa sur SME-Fr .

Rappelons simplement à ce sujet que les fichiers de personnalisation doivent être mis dans un répertoire particulier et que, périodiquement, le système viendra rechercher ces fichiers de personnalisation pour reconstruire les fichiers de base de Linux. C'est donc dans ces répertoires qu'il faudra organiser nos personnalisation, puis les valider en forçant la reconstruction des fichiers de base. Tout cela explique les diverses manipulations décrites dans le paragraphe suivant.

3.2.2. Quand exécuter notre fichier ?

"Au démarrage, bien sûr !", direz-vous. Oui, mais à quel moment précis lors de la longue procédure de mise en route du système ? Pour le savoir, il faut d'abord bien connaitre les différents "run level" de la FreeEOS :

  • 0 : Arrêt du système
  • 1 : Single User Mode
  • 2 : Multi User Mode, sans réseau
  • 3 : (Full Multi User Mode - démarrage par défaut de la Red Hat, mais pas de la FreeEOS !)
  • 4 : (inutilisé)
  • 5 : (X11 - inutilisé sur FreeEOS)
  • 6 : Reboot
  • 7 : Utilisation normale et démarrage par défaut de la FreeEOS.

Rendons nous donc dans le répertoire /etc/rc.d/rc7.d/ pour étudier l'ordre de mise en route des différents process lors d'un démarrage normal. Dans ce répertoire, nous voyons des fichiers dont le nom commence par un numéro. Chacun correspond à un service, et ils seront utilisés dans l'ordre des numéros en début de nom.

En étudiant les services mis en route, nous voyons que diald et pppoe sont au rang 57 (attention, cela peut dépendre de la version : regardez sur votre serveur ce qu'il en est et adaptez tout ce qui suit en conséquence !). Il faut que notre filtrage soit mis en place avant, sinon des accès pourraient être effectués entre le lancement de la connection internet et la mise en place de notre filtre.

Il n'y a certes aucun risque que quelqu'un tente de surfer entre les deux. Mais la logique l'exige, et tout dépend aussi de ce qu'on veut réaliser. Par exemple, dans mon réseau privé, je veux m'assurer que seuls les postes Linux aient accès à l'internet et que les postes Windows en soient complètement isolés, entre autres au cas où un quelconque cheval de troie tenterait d'envoyer des infos. Dans ce cas, le filtrage doit bien être en place avant toute connection à l'Internet.

Notre fichier de démarrage du filtre devra être mis dans /etc/e-smith/templates-custom/etc/rc.d/init.d/masq/. Rendons-nous dans ce répertoire pour voir si d'autres filtres existent déjà. Nous constatons (cela peut être différent chez vous) qu'il y a déjà deux fichiers, l'un de rang 30 et l'autre de rang 45. Notre filtre doit donc avoir un rang compris entre 45 et 57 en excluant ces deux limites, puisque nous devons le mettre en place en dernier pour être certains que rien ne viendra s'intercaler en amont.

3.2.3. On y va !

Allez, assez bavardé, mettons tout ça en place. Pour commencer, copions notre fichier :

cp /home/e-smith/files/ibays/monibay/files/MonFiltreIP /etc/e-smith/templates-custom/etc/rc.d/init.d/masq/49MonFiltreIP

Régénérons les fichiers de base en intégrant notre nouveau template :

/sbin/e-smith/expand-template /etc/rc.d/init.d/masq

Puis relançons les services :

/sbin/e-smith/signal-event ip-change

4. Conclusion

Voilà, tout est en place et fonctionne bien ! Nous aurions pu affiner les règles, par exemple en gérant les différents services et protocoles. Le principe de ce filtrage étant maintenant connu, il est relativement aisé de l'adapter.

Il devrait être possible de donner la possibilité, dans server-manager, d'adapter les filtres aisément. Ceci permettrait à l'administrateur de les adapter au fur et à mesure de l'évolution des besoins. Les systèmes basés sur ipchains étant appelés à disparaitre peu à peu, cette adaptation ne sera réalisée que la demande le justifie. Par contre, ce principe pouvant probablement être repris et adapté pour iptables, il y aura tout intérêt à faire une extension à server-manager en même temps que le portage.

5. ChangeLog

Octobre 2006 : Correction du lien sur la contrib de Master Sleepy.

Mars 2004 : Version originale.


Alinsunod sa CSS Conformité XHTML 1.1 Alinsunod sa pamantayan Itaas ng pahina TahananInformaticsPagsalinDokumentasyonSari-sari
DokumentasyonFreeEOS/SMECustomized IP Filter