Project-Id-Version: Trac 0.12
Report-Msgid-Bugs-To: trac-dev@googlegroups.com
POT-Creation-Date: 2013-01-27 11:21+0900
PO-Revision-Date: 2010-07-19 23:05+0200
Last-Translator: Jeroen Ruigrok van der Werven <asmodai@in-nomine.org>
Language-Team: en_US <trac-dev@googlegroups.com>
Plural-Forms: nplurals=2; plural=(n != 1)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Generated-By: Babel 0.9.6

Configuration/Firewall – Trac ResEl
wiki:Configuration/Firewall

Le Firewall ResEl Brest

Auteur : Milton Yates milton.yates@… (known as BinaryK)

Date : 6 septembre 2004

Note : pour ipp2p : voir Configuration/Firewall/IpP2P

Disclaimer

Une bonne connaissance des protocoles IP, TCP (notamment), de Iptables et éventuellement de Perl seront nécessaires. Cette documentation n'a pas pour but de vous apprendre le fonctionnement d'Iptables. Les règles Iptables sont assez lisibles de par leur syntaxe, cependant je vous conseille vivement de lire les HOWTO officiels qui sont très clairs : http://netfilter.org/documentation/index.html#documentation-howto .

Un firewall pour le ResEl 2

Dans la perspective d'une (éventuelle) future indépendance du ResEl vis-à-vis de Renater, l'élaboration d'un firewall semblait inévitable. La mise en place de ResEl 2 et de sa -pseudo- DMZ a également mis à jour le besoin de NAT. La solution choisie est logique : Système Linux 2.4 => Iptables :o)

Dans un deuxième temps, ce même firewall s'est vu ajouter un système de filtrage des IP/MAC du réseau interne, synchronisé (régulièrement) avec la base LDAP. Afin de garder un tout cohérent, le script a été traduit entièrement en Perl.

Enfin, dans notre lutte éternelle contre les p2p : le firewall a été doté du module stringmatch (ipt_string) afin de supprimer purement et simplement (ya pas plus bourrin) les paquets dont le payload match avec une certaine chaîne.

À partir de mars 2011, nous avons réécrit une partie du firewall car l'interconnexion entre la l'école et le ResEl a été changé. La DISI nous offrant une meilleur bande passante, nous avons décidé aussi de changer le système de coupure en le remplaçant par un système de shaping. Le ResEl maintenant à disposition 6 ips publiques. Une ip pour le trafique propre (192.108.116.129), une pour le flux sale (192.108.116.130), une pour les services du ResEl (192.108.116.131), une pour les sites des clubs sur golf (192.108.116.132), une ip pour l'admin ResEl (192.108.116.133).

Les fonctionnalités

Gestion des paramètres de lancement du script

  • Efface toutes les règles/chaînes, vide les files, puis relance le firewall statique + ajout des règles IP/MAC. C'est la commande à lancer pour (re)démarrer le firewall :
 # firewall start
  • Efface toutes les règles/chaînes et désactive le forwarding de paquet : ATTENTION cela changera la passerelle en une simple machine et coupera supprimera tous les flux non directement destinés à la passerelle :
 # firewall stop
  • Affiche l'aide :
 # firewall help
  • Supprime les règles IP/MAC courantes, puis relance l'ajout des règles IP/MAC :
 # firewall

Mise à jour automatique des règles IP/MAC

  • La ligne suivante a été ajoutée au Crontab root :
*/30 * * * *   /etc/init.d/firewall 1>/dev/null
  • Lors d'une inscription au ResEl, cette mise à jour s'effectue à nouveau par l'appel à firewall sans paramètre.

La méthode choisie : le script d'inscription se log sur loli en tant qu'utilisateur updatefirewall à l'aide d'une clé ssh RSA sans passphrase. Au lieu de lancer un shell, updatefirewall lance /home/updatefirewall/sudoinitfirewall.sh. On notera que ce script va lancer le firewall à l'aide d'une commande sudo.

Stateful Firewall !

Iptables supporte les états de connexion, et notre firewall aussi :)

Cette fonctionnalités d'Iptables est vraiment TRES pratique, c'est elle qui fait presque tout le boulot du firewall ! Elle permet de laisser passer les paquets faisant partie de connexions déjà établies. Si c'est pas beau ça !! Celà nous permet de concentrer notre attention sur tous les paquets d'initialisation de connexion.

C'est un firewall stateful ou connection aware ou encore taquet power etc

Segmentation du flux

Le flux de données à traiter a été segmenté suivant la provenance et la destination du paquet, ce qui simplifie grandement la recherche et l'ajout de règles, tout en facilitant la lecture du script.

Principe de la DMZ

Il existe tout plein de sortes de DMZ, cependant le but reste le même pour toutes : protéger le réseau interne en mettant les machines exposées aux attaques dans une zone à part nommée zone démilitarisée (DMZ :p). Les droits d'accès de la DMZ vers l'intérieur doivent être les mêmes que les droits d'accès de l'extérieur vers l'intérieur, c'est à dire : RIEN sauf les connexions déjà établies (connexions qui ont donc été établies depuis l'intérieur bien évidemment). Vu de l'intérieur, on doit pouvoir accéder à la DMZ de la même manière qu'à l'extérieur.

On place dans la DMZ tous les services qui ont besoin d'être accessibles de l'extérieur, et on part du principe que cette zone n'est pas sûre. Si un service tombe et une machine se fait rooter, alors le danger devrait être contenu dans la DMZ et ne pas pouvoir se propager au réseau interne.

Au ResEl, à ce jour, l'accès DMZ -> réseau interne est toujours grand ouvert, car quelques services en ont encore besoin. Il semble pourtant possible de contourner ce besoin...

Parcours détaillé du script

L'ordre des sections suivantes est inspiré de l'ordre d'écriture du firewall.

Paramètres/Variables? du firewall

  • Nommage des interfaces, des IPs du système et de la DMZ.
  • Liste des réseaux de l'école et des ranges ResEl qui auront accès à l'extérieur.
  • Configuration du passage des ICMP (explications plus loin).
  • Listes des ports forwardés dans la DMZ depuis l'intérieur/l'extérieur en TCP/UDP vers chacun des serveur de la DMZ.
  • Liste des ports de destination rejetés lors du passage par la chaîne DoNotSendOutside (anti-p2p).

Préparation du noyau

  • Chargement des modules nécessaires. Normalement Iptables le fait tout seul, si vous avez osé compilé ça en module ;) cependant, il arrive qu'il ne charge pas tout tout seul, aussi mieux vaut être préventif. Si le noyau est monolithique, ne pas tenir compte des erreurs de modprobe rencontrées au démarrage.

Préparation des chaînes Iptables

  • Mise en place de la cible par défaut (DROP) pour les 3 Chaînes de base (INPUT/OUTPUT/FORWARD) de la table filter. On DROP tout par défaut, et on n'autorise que les paquets que l'on veut : c'est la base de la sécurité. Vidange des règles et chaînes courantes.
  • Création des chaînes standards.
  • Création des chaînes supplémentaires dans la table filter.
    • La passerelle peut être vue comme un carrefour. Il est possible à une voiture qui arrive d'une rue, d'aller dans une autre rue. Seulement voilà, chaque rue est à double sens, et il y a 3 rues (DMZ/Intérieur/Extérieur). Afin de ne pas nous perdre (eh, on est le gendarme qui fait la circulation quand-même ;) ) on va créer une chaîne par sens (un sens est une rue à sens unique :) ). On aura par exemple: int_to_ext, int_to_dmz, int_to_int, ...
      • Exemple: un paquet qui fait un aller retour d'une machine du ResEl A vers google.fr. Le chemin (grossier) du paquet est : A ->int_to_ext->...Internet...->ext_to_int-> A
  • Création de la Chaîne Dropit. Cette chaîne est utilisée en lieu et place de DROP quand on souhaite faire croire que le port est fermé, et non que le paquet envoyé a été bêtement supprimé. On utilise pour celà la cible REJECT avec l'option: --reject-with tcp-reset pour une connexion TCP et icmp-port-unreachable pour un paquet UDP, le reste est envoyé sur DROP.
    • NOTE: cette chaîne ne fonctionnera que pour des règles de la table filter.

Tuning du noyau avec les sysctl

Les sysctl sont des contrôles qui permettent de changer des paramètres du noyau en temps réel. Sur les systèmes munis de /proc, on peut les atteindre directement dans /proc/sys. Pour la plupart, ce sont de simples flag qui prennent 0 ou 1 comme valeur.

Exemple :

 echo "1" > /proc/sys/net/ipv4/ip_forward

Cette commande active le forwarding de paquets (option INDISPENSABLE).

Le script firewall se sert des sysctl afin de forcer l'état de certaines options noyau :

  • Activer le forwarding de paquets.
  • Activer les TCP SYNcookies qui permettent d'éviter le SYN flooding (ne protège que la passerelle).
  • Activer la protection anti-spoof sur toutes les interfaces.
  • Ne pas répondre aux pings broadcast
  • Rendre insensible aux icmp redirects
  • Désactiver le source routing (paquets spécifiants eux-même leur routage)

Filtre StringMatch Anti-P2P

La chaîne StringMatchsDrop contient les règles anti-p2p qui DROP les paquets contenant les chaînes données en paramètres. La recherche de la chaîne prend en compte sa casse ! Exemple:

 $IPTABLES -A !StringMatchsDrops -m string --string 'X-Kazaa' -j Dropit

Ces règles permettait de bloquer notamment Kazaa, donc une partie des p2p basés sur FastTrack et BitTorrent. Aujourd'hui, elles ne sont plus utilisées.

Filtre de ports

La chaîne DoNotSendOutside contient une liste de paquets que l'on ne veut absolument pas voir traverser notre passerelle et sortir sur le net. Par exemple, les paquets NetBios, et plein de ports fixes utilisés par nos amis les P2P.

Filtre ICMP

Cette chaîne, FilterICMP, nous a posé quelques problèmes, et a été victime d'attaque type icmp flood de la part de PCs d'élèves infectés. Aussi, cette chaîne a été segmenté en 3 niveaux.

  1. Les ICMP non limités: ces types de paquets ICMP sont simplement acceptés par le firewall. Ils sont listés dans la variable @ICMP_NOT_LIMITED.
  2. Les ICMP limités au niveau 1: ces types de paquets ICMP sont limités à $ICMP_LIMITED_V1_LIMIT paquets par seconde. Ils sont listés dans la variable @ICMP_LIMITED_V1.
  3. Les ICMP limités au niveau 2: ces types de paquets ICMP sont limités à $ICMP_LIMITED_V2_LIMIT paquets par seconde. Ils sont listés dans la variable @ICMP_LIMITED_V2.

Les limites choisies et le placement des types de paquets ICMP dans l'une des 3 listes ont été établis de manière empiriques. On notera que certains types de paquets ICMP sont absents des 3 listes, ce n'est pas un oublie. La plupart de ces paquets ICMP sont de type ICMP-Redirect, or nous ne voulons pas laisser passer ce genre d'ICMP (je t'assure que non).

Certains paquets ICMP sont logués dans syslog : tous les paquets de type ICMP-Redirect.

Enfin, tous les paquets ICMP qui ne sont pas encore passé sont logués avec une limite de 20/heure, puis DROPé.

Détection du spoof (basic)

On se sert de quelques règles dans PREROUTING afin de vérifier qu'aucun paquet n'est honteusement en train de spoofer un réseau, ou une interface de la passerelle. Les spoofs des IPs de la passerelle sont logués. Une partie de ces règles est probablement inutile, car réalisée dans le noyau par le sysctl rp_filter (vérification des sources)... à voir.

MASQUERADING (SNAT)

Le masquerading permet de modifier la source d'un paquet. Pour Iptables il existe la cible MASQUERADING et la cible SNAT (Source Network Address Translation). MASQUERADING est adapté pour les interfaces qui pourraient changer dynamiquement d'IP (exemple ADSL), comme ce n'est pas notre cas : nous utiliserons SNAT qui permet de spécifier la nouvelle IP source du paquet.

L'application du SNAT se fait dans la chaîne POSTROUTING et uniquement pour les paquets :

  1. Qui viennent de ranges ResEl (@RESEL) et sortent vers l'extérieur.
    • On attribue alors en fonction du type de port utilisé l'IP publique du flux Propre du !ResEL ou l'IP publique du flux sale du ResEl comme IP source
  2. Qui viennent de la DMZ et sortent vers l'extérieur.
    • On attribue alors l'IP publique des services du ResEl comme IP source
  3. Qui viennent de la DMZ et sortent vers l'intérieur.
    • On attribue alors l'IP interne de la passerelle ($IP_INT) comme IP source

Comme son nom l'indique, le paquet arrivant dans la chaîne POSTROUTING a déjà été filtré puis routé, il est maintenant sur la dernière case du jeu de l'oie avant de s'envoyer en l'air. Comme le paquet a déja été routé et filtré, nous pouvons changer son IP source sans nous inquiéter : cela ne changera rien au devenir du paquet.

Ah si ! Ca va changer son IP source, ça oui :) L'intérêt ? Simplement que la personne (extérieure) qui recevra ce paquet pourra y répondre car, l'IP source est une IP routable sur Internet, ce qui n'est pas le cas des adresses locales comme celles utilisées au ResEl. La même chose pour le cas 3. : le réseau 10.0.0.0 n'est pas sensé être vu pour l'utilisateur, il ne doit voir que la passerelle, donc on lui fait croire que c'est la passerelle qui envoie le paquet (ce qui en un sens est vrai ;) ).

Forwarding de ports (DNAT)

Pour les paquets qui sont effectivement pour la passerelle, il faut distinguer, suivant le port de destination et l'interface d'arrivée du paquet, s'il faut l'envoyer vers une machine particulière de la DMZ, le laisser à la passerelle, ou le supprimer.

On va utiliser les listes suivantes:

  • @TCP_EXT_DMZ, @TCP_EXT_DMZ_VENUS, @UDP_EXT_DMZ : pour les paquets provenant de l'extérieur vers la dmz.
  • @TCP_INT_DMZ, @TCP_INT_DMZ_VENUS, @UDP_INT_DMZ, @UDP_INT_DMZ_VENUS : pour les paquets provenant des réseaux de l'école (sur l'interface extérieure) et de l'intérieur.

Règles supplémentaires :

  1. L'adresse resel.enst-bretagne.fr pointe vers l'IP de l'interface extérieure des services, aussi une machine de l'intérieur qui fera une requête sur cette IP va tomber dans les règles anti-spoof. Aussi faut-il faire une exception : dès qu'on reçoit le paquet (chaîne PREROUTING), si il vient de l'interface intérieure et que la requête pointe vers $IP_EXT sur les ports 80 ou 443, alors il faut remplacer l'IP de destination du paquet directement par l'IP du serveur web dans la DMZ. Cette belle phrase se traduit par :
     $IPTABLES -t nat -A PREROUTING -i $ETH_INT -p tcp -d $IP_FLUX_SERVICE --dport 80 -j DNAT --to-destination $IP_SERVEUR_DMZ
     $IPTABLES -t nat -A PREROUTING -i $ETH_INT -p tcp -d $IP_FLUX_SERVICE --dport 443 -j DNAT --to-destination $IP_SERVEUR_DMZ
    
    C'est un 'hack' pas super beau, mais il reste efficace donc ça va :)
  2. Les requêtes sur le port 80 (quelque soit leur destination) en provenance d'IP dans 172.16.22.0/24 seront automatiquement redirigées sur le serveur web du ResEl. Le but premier était d'y mettre un lien ou une redirection vers la page d'inscription. Et c'est toujours mieux que de ne rien avoir :) (rappelez-vous, les adresses en 172.16.22 ne passent pas le MASQUERADING.
  3. Ensuite on trouve une bête suite de règles UDP, ce sont les ports nécessaires pour eyeball chat je crois bien. Ca marche ça ?!

Séparation des flux dans les chaînes

C'est ici que l'on va diviser le flux principal et remplir les chaînes int_to_ext (...) de paquets. La séparation s'effectue en fonction de la provenance et de la destination du paquet. On notera que le routage a déja été effectué, sinon nous ne pourrions pas savoir où partirait le paquet. Exemples :

 $IPTABLES -t filter -A INPUT -i $ETH_INT -j int_to_gw
 $IPTABLES -t filter -A OUTPUT -o $ETH_INT -j gw_to_int
 $IPTABLES -t filter -A FORWARD -i $ETH_INT -o $ETH_EXT -j int_to_ext

Dans la suite, nous allons spécifier le comportement de chacune de nos chaînes.

Extérieur -> Gateway (ext_to_gw)

  1. On accepte les connexions qui sont déjà initialisées
     $IPTABLES -t filter -A ext_to_gw -m state --state ESTABLISHED,RELATED -j ACCEPT
    
  2. On rejette les paquets mal formés
     $IPTABLES -t filter -A ext_to_gw -m state --state INVALID -j DROP
    
  3. On envoie les ICMP sur la chaîne FilterICMP
     $IPTABLES -t filter -A ext_to_gw -p icmp -j FilterICMP
    
  4. On ouvre le port tcp/113 pour oidentd
  5. On rejette le reste avec Dropit

DMZ -> Gateway (dmz_to_gw)

  1. On accepte les connexions qui sont déjà initialisées
  2. On rejette les paquets mal formés
  3. On envoie les ICMP sur la chaîne FilterICMP
  4. On accepte les demandes de connexion au serveur ssh tcp/2222
  5. On accepte les demandes de connexion au serveur DNS de la passerelle (tcp/53 et udp/53)
  6. On laisse passer le tunnel de log de saturne vers la passerelle
  7. On rejette le reste avec Dropit

Intérieur -> Gateway (int_to_gw)

  1. On DROP les paquets à destination de 10.0.0.0/8 (parano inside)
  2. On envoie les ICMP sur la chaîne FilterICMP
  3. On accepte les connexions qui sont déjà initialisées
  4. On rejette les paquets mal formés
  5. On accepte les demandes de connexion au serveur ssh tcp/2222
  6. On accepte les demandes de connexion à darkstat tcp/6789
  7. On accepte les demandes de connexion au serveur DNS de la passerelle (tcp/53 et udp/53)
  8. On rejette le reste avec Dropit

Gateway -> Extérieur (gw_to_ext)

Ici, on considère que tout le traffic en provenance de la passerelle elle-même peut passer. On filtre qd même avec DoNotSendOutside et FilterICMP qui doivent filtrer tous les paquets sortants.

  1. Tout ce qui n'est pas ICMP est envoyé à DoNotSendOutside (qui DROP ce qui ne doit pas sortir sur le net).
  2. On envoie les ICMP sur la chaîne FilterICMP
  3. On accepte ce qui reste

Gateway -> DMZ (gw_to_dmz)

  1. On accepte tout

Gateway -> Intérieur (gw_to_int)

  1. On accepte tout

Extérieur -> Extérieur (ext_to_ext)

Ce traffic n'a pas lieu d'être (spoof ? ...)

  1. On DROP sauvagement

Extérieur -> DMZ (ext_to_dmz)

  1. On accepte les connexions qui sont déjà initialisées
  2. On rejette les paquets mal formés
  3. On envoie les ICMP sur la chaîne FilterICMP
  4. On accepte les demandes de connexion dans une limite de 20 paquets par seconde sur les ports listés dans @TCP_EXT_DMZ, @TCP_EXT_DMZ_VENUS pour tous et @TCP_INT_DMZ, @TCP_INT_DMZ_VENUS uniquement pour les paquets en provenance d'un des réseaux de l'école
  5. On accepte les demandes de connexion dans une limite de 20 paquets par seconde sur les ports IMAP et IMAPS depuis les réseaux de l'école uniquement
  6. On accepte les paquets UDP dont le port de destination est listé dans @UDP_EXT_DMZ
  7. On rejette le reste avec Dropit

Extérieur -> Intérieur (ext_to_int)

Ici est un bon endroit pour DROPer les IPs externes que l'on veut bannir.

  1. On accepte les connexions qui sont déjà initialisées
  2. On rejette les paquets mal formés
  3. On envoie les ICMP sur la chaîne FilterICMP
  4. On rejette le reste avec Dropit

DMZ -> DMZ (dmz_to_dmz)

Ce traffic n'a pas lieu d'être.

  1. On DROP sauvagement

DMZ -> Extérieur (dmz_to_ext)

On accepte tout ce qui va vers l'extérieur, sauf DoNotSendOutside bien sûr

  1. Tout ce qui n'est pas ICMP est envoyé à DoNotSendOutside (qui DROP ce qui ne doit pas sortir sur le net).
  2. On accepte ce qui reste

DMZ -> Intérieur (dmz_to_int)

Le principe de la DMZ voudrait que l'on ne laisse passer que les connexions déjà initialisées (même règles que pour ext_to_int), cependant il reste encore quelques services qui ont besoin d'initialiser une connexion DMZ->Intérieur... en attendant qu'un jour on referme cette porte ouverte dans l'architecture... :\

  1. On accepte tous les paquets valides d'état NEW, ESTABLISHED ou RELATED
    • Une vraie DMZ proposerait la même règle sans le 'NEW'.
  2. On rejette le reste avec Dropit

Intérieur -> Intérieur

Ce traffic n'a pas lieu d'être... sauf dans le cas d'une connexion à l'école par le fameux icmp redirect.

  1. On DROP les paquets à destination du ResEl, car ce chemin n'est pas normal.
  2. Pour les ranges ResEl (@RESEL), on autorise les paquets qui ne sont pas à destination du ResEl:
     foreach $source (@RESEL){
      system("$IPTABLES -t filter -A int_to_int -s $source -d ! 172.16.0.0/16 -j ACCEPT");
     }
    
  3. On rejette le reste avec Dropit

Intérieur -> DMZ (int_to_dmz)

  1. On rejette les paquets en provenance de l'école sur l'interface interne. C'est la solution la plus simple pour résoudre notre problème de routage. L'école doit absolument utiliser resel.enst-bretagne.fr ($IP_EXT donc) pour se connecter aux services ResEl.
     foreach $source (@ECOLE) {
      system("$IPTABLES -t filter -A int_to_dmz -i $ETH_INT -s $source -d $IP_INT -j REJECT --reject-with icmp-host-prohibited");
     }
    
  2. On envoie les ICMP sur la chaîne FilterICMP
  3. On accepte les connexions qui sont déjà initialisées
  4. On accepte les initialisations de connexion sur les ports listés dans @TCP_INT_DMZ, @TCP_INT_DMZ_VENUS, @UDP_INT_DMZ, @UDP_INT_DMZ_VENUS
  5. On rejette le reste avec Dropit

Intérieur -> Extérieur (int_to_ext)

Ici est un bon endroit pour couper les IPs de machines ResEl pour les empêcher d'aller sur le net.

  1. On envoie les ICMP sur la chaîne FilterICMP
  2. On envoie les paquets qui ne sont pas ICMP vers la chaîne DoNotSendOutside
  3. On envoie les paquets qui ne sont pas ICMP vers la chaîne StringMatchsDrops
  4. On crée une chaîne par range de @RESEL nommée int_to_ext_$trange
  5. Les chaînes ainsi créées laissent tout passer. On insèrera dans celles-ci les règles IP/MAC correspondantes à leur range respective : ce qui fait gagner BEAUCOUP en temps de transit du paquet. En effet, au lieu d'essayer le paquet sur 600 règles IP/MAC, on ne l'essaiera que sur au plus 254.
  6. On envoie les paquets de chaque range de @RESEL dans sa chaîne respective
  7. Pour les paquets qui ne sont pas partis dans une chaine de range, c'est que leur adresse n'est pas attribuée : on rejette avec un icmp-net-prohibited.

Ajout des règles IP/MAC

Pour chaque range de @RESEL, on se place dans la chaîne associée à la range:

  1. Suppression des règles de la chaîne
  2. On accepte les connexions qui sont déjà initialisées
  3. On parcourt toutes les IP de la base LDAP, si l'IP est dans la range, alors on ajoute la règle :
     IPTABLES -t filter -A int_to_ext_$trange -s $ip -m state --state NEW -m mac --mac-source $mac -j ACCEPT
    
  4. On termine avec une règle qui log les paquets refusés à 1 paquet par minute Note: Ces logs sont intéressants : ils mettent en valeur des couples IP/MAC non valides. La personne a une IP ResEl valide (puisqu'elle arrive jusque dans cette chaîne spécifique à une range ResEl), mais si la personne n'a pas trouvé sa MAC dans la liste des règles, c'est : soit qu'elle prend une IP pour laquelle elle n'est pas enregistrée (PAS BIEN!), soit son IP n'est pas associée à la bonne MAC dans LDAP.
  5. On le rejette avec un icmp-net-prohibited
  6. On DROP ce qu'il reste (normalement rien)

On va prendre une bière :)

Améliorations possibles

  • Il est possible d'utiliser le module psd pour détecter et Loguer/DROPer les scans de ports. A tester.
  • Il existe plein de patchs pour ajouter des modules à iptables, ils ne sont pas tous très stables, alors avant d'en mettre un en production testez/lisez le, et soyez attentifs aux retours utilisateurs sur le module en question.
  • Je suis intéressé par les nouvelles idées que vous implanterez :)

Dépendances

Voici les ressources nécessaires à la mise en place de ce firewall :

Noyau Linux 2.4

  • Patché pour le support du StringMatch. Le patch est trouvable dans le pack patch-o-matic correspondant à la version d'Iptables utilisée (http://netfilter.org/downloads.html)
  • Compilé avec toutes les options de routage (au moins la section IP: advanced router) et tout IP: Netfilter Configuration (vérifier la présence du module Iptables String match support)
  • Compilé avec les TCP syncookies
  • Je conseille de réaliser un noyau monolithique

Système

  • Perl >= 5.6
  • Module Perl/LDAP: Net::LDAP (paquet Debian libnet-ldap-perl 0.25-2)
  • Iptables >= 1.2.8
  • /etc/init.d/firewall

Pour la mise à jour des règles IP/MAC à distance

  • Ajout d'un utilisateur updatefirewall avec une clé ssh RSA sans passphrase.
  • Dans /etc/password :
    updatefirewall:*:1006:1006:chargement du firewall à distance:/home/updatefirewall:/home/updatefirewall/sudoinitfirewall.sh
    
    Note: (1006:1006) = (uid:gid)
  • Script /home/updatefirewall/sudoinitfirewall.sh avec droits restreints
    # ls -l /home/updatefirewall
    total 4
    -rwx------    1 updatefi updatefi       36 Dec  8  2003 sudoinitfirewall.sh
    
  • Entrée dans /etc/sudoers pour le script ci-dessus :
    updatefirewall ALL=NOPASSWD: /etc/init.d/firewall
    

Page créée par jcorbier et modifiée par srecher le 08/01/2013 15:40:21

Last modified 6 years ago Last modified on Jan 8, 2013, 3:40:21 PM