From a71ee682bfba66c84cd8f964862c9e80cbbe2ae3 Mon Sep 17 00:00:00 2001 From: gmarcenac Date: Sat, 7 Jan 2006 19:20:38 +0000 Subject: [PATCH] Initial French release git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@3250 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb --- Shorewall-docs2/FAQ_fr.xml | 2089 ++++++++++++++++++++++++++++++++++++ 1 file changed, 2089 insertions(+) create mode 100644 Shorewall-docs2/FAQ_fr.xml diff --git a/Shorewall-docs2/FAQ_fr.xml b/Shorewall-docs2/FAQ_fr.xml new file mode 100644 index 000000000..d3409793f --- /dev/null +++ b/Shorewall-docs2/FAQ_fr.xml @@ -0,0 +1,2089 @@ + + +
+ + + + FAQ Shorewall + + Version Française de Shorewall + FAQs + + + Shorewall Community + + + Tom + + Eastep + + + + Guy + + Marcenac + + Adaptation française + + + + 2005-12-07 + + + 2001-2006 + + Thomas M. Eastep + + Guy Marcenac + + + + Permission est accordée de copier, distribuer et/ou modifier ce + document selon les termes de la Licence de Documentation Libre GNU (GNU + Free Documentation License), version 1.2 ou toute version ultérieure + publiée par la Free Software Foundation ; sans section Invariables, sans + première de Couverture, et sans texte de quatrième de couverture. Une + copie de la présente Licence est incluse dans la section intitulée. Une + traduction française de la licence se trouve dans la section + Licence de + Documentation Libre GNU. Ce paragraphe est une + traduction française pour aider à votre compréhension. Seul le texte + original en anglais présenté ci-dessous fixe les conditions + d'utilisation de cette documentation. + + Permission is granted to copy, distribute and/or modify this + document under the terms of the GNU Free Documentation License, Version + 1.2 or any later version published by the Free Software Foundation; with + no Invariant Sections, with no Front-Cover, and with no Back-Cover + Texts. A copy of the license is included in the section entitled + GNU Free Documentation License + . + + + + + Notes du traducteur : Si vous + trouvez des erreurs ou si vous avez des améliorations à apporter à cette + documentation vous pouvez me + contacter. + + + + Cet article s'applique à Shorewall 3.0 et à + ses versions ultérieures. Si vous utilisez une version plus ancienne de + Shorewall, référez-vous à la documentation s'appliquant à votre + version. + + +
+ Installation de Shorewall + +
+ Où puis-je trouver des instructions d'installation et de + configuration pas à pas ? + + Réponse: Allez voir les guides de démarrage + rapide. +
+ +
+ (FAQ 37) Je viens d'installer Shorewall sur Debian et le + répertoire /etc/shorewall est vide!!! + + + Après avoir installé le paquetage .deb, avant de commencer à + configurer Shorewall, vous devriez prendre connaissance de ce conseil + de Lorenzo Martignoni, le mainteneur Debian de Shorewall: + + Pour plus d'information quant à l'utilisation de + Shorewall sur un système Debian vous devriez aller voir le fichier + /usr/share/doc/shorewall/README.Debian distribué avec le paquetage + Debian de Shorewall. + + + Si vous vous servez du .deb pour installer, vous vous rendrez + compte que votre répertoire /etc/shorewall est + vide. Ceci est voulu. Les squelettes des fichiers de configuration se + trouvent sur votre système dans le répertoire /usr/share/doc/shorewall/default-config. + Copiez simplement les fichiers dont vous avez besoin depuis ce + répertoire dans /etc/shorewall, + puis modifiez ces copies. + + Remarquez que vous devez copier + /usr/share/doc/shorewall/default-config/shorewall.conf + et /usr/share/doc/shorewall/default-config/modules + dans /etc/shorewall même si + vous ne modifiez pas ces fichiers. +
+ +
+ (FAQ 44) Je n'arrive pas à installer ou mettre à jour le RPM - + J'ai le message d'erreur "error: failed dependencies:iproute is + needed..." + + Réponse: Lisez les Instructions d'installation! +
+ +
+ (FAQ 50) Quand j'installe ou que je mets à jour, j'obtiens de + multiples instances du message suivant "warning: user teastep does not + exist - using root" + + Réponse: Vous pouvez sans aucun + risque ignorer ce message. Il était dû à une erreur mineure de paquetage + qui a été corrigée depuis. Cela ne change rien dans l'utilisation de + Shorewall. +
+
+ +
+ Transfert de port (Redirection de Port) + +
+ (FAQ 1) Je veux rediriger le port UDP 7777 vers mon PC personnel + qui a l'adresse 192.1683.1.5. J'ai cherché partout et je ne trouve pas + comment faire. + + Réponse: Le premier exemple de la + documentation du fichier + rules vous indique comment faire du transfert de port avec + Shorewall. Le format d'une règle de redirection de port vers un système + local se présente comme suit: + + #ACTION SOURCE DEST PROTO DEST PORT +DNAT net loc:<adresse IP locale>[:<port local>] <protocole> <n° port> + + Ainsi pour rediriger le port UDP 7777 vers le système interne + 192.168.1.5, la règle est: + + #ACTION SOURCE DEST PROTO DEST PORT +DNAT net loc:192.168.1.5 udp 7777 + + Si vous voulez rediriger vers un système interne les requêtes + envoyées à une adresse donnée (<IP externe>) + sur votre firewall: + + #ACTION SOURCE DEST PROTO DEST PORT SOURCE ORIGINAL +# PORT DEST. +DNAT net loc:<adresse IP locale>[:<port local>]<protocole> <n° port> - <IP externe> + + Enfin, si vous avez besoin de rediriger une plage de ports, + spécifiez la plage de ports <premier port>:<dernier port> + dans la colonne DEST PORT. + +
+ (FAQ 1a) D'accord -- j'ai suivi toutes ces instruction, mais + cela ne marche toujours pas. + + Réponse: Ceci se produit + généralement lorsque: + + + + Vous tentez de tester depuis l'intérieur de votre firewall + (non, cela ne marchera pas -- allez voir la ). + + + + Vous avez un problème plus élémentaire de configuration de + votre système local (celui vers lequel vous tentez de rediriger + les paquets), une mauvaise passerelle par défaut par exemple (elle + devrait être configurée avec l'adresse IP de l'interface interne + de votre firewall). + + + + Votre FAI bloque le trafic entrant sur ce port + particulier. + + + + Vous utilisez une version de Mandriva antérieure à la 10.0 + final et vous avez configuré le partage de connexion internet. Si + c'est le cas, le nom de votre zone locale n'est pas 'loc' mais + 'masq' (dans vos règles changez toutes les instances de 'loc' pour + 'masq'). Vous pouvez envisager de ré-installer Shorewall avec une + configuration conforme à la documentation de Shorewall. Voir le + guide Firewall à deux + interfaces pour plus de détails. + + +
+ +
+ (FAQ 1b) J'ai malgré tout encore des problèmes avec la + redirection de port + + Réponse: pour aller plus avant + dans le diagnostic du problème: + + + + En tant que root, tapez iptables -t nat + -Z . Ceci remet à zéro les compteurs Netfilter + de la table nat. + + + + Essayez de vous connecter au port redirigé depuis un hôte + externe. + + + + En tant que root, tapez shorewall show + nat + + + + Repérez la règle DNAT appropriée. Elle sera dans une chaîne + nommée <zone source>_dnat + (net_dnat dans les exemples ci-dessus). + + + + Est-ce que le décompte de paquets dans la première colonne + est supérieur à zéro ? Si cela est le cas, la requête de connexion + atteint le firewall et est bien redirigée vers le serveur. Dans ce + cas, le problème vient en général de l'absence de paramétrage ou + d'un paramétrage erroné de la passerelle par défaut sur le système + local (celui vers lequel vous essayez de transférer les paquets -- + sa passerelle par défaut devrait être l'adresse IP de l'interface + du firewall connectée à ce système local). + + + + Si le décompte de paquets est égal à zéro: + + + + La requête de connexion n'arrive pas jusqu'à votre + serveur (il est possible que votre FAI bloque ce port) + + + + Vous essayez de vous connecter à une adresse IP + secondaire sur votre firewall et votre règle ne redirige que + l'adresse IP primaire (dans votre règle DNAT vous devez + spécifier l'adresse IP secondaire dans la colonne ORIG. + DEST.) + + + + Pour d'autres raisons, votre règle DNAT ne correspond + pas à la requête de connexion. Dans ce cas, pour aller plus + loin dans le diagnostic, vous pourrez avoir à vous servir d'un + sniffer de paquets comme tcpdump ou + ethereal. + + + + +
+ +
+ (FAQ 1c) Je voudrais que lorsque je me connecte depuis internet + au port 1022 de mon firewall, cette connexion soit redirigée vers le + port 22 de mon système local 192.168.1.3. Comment faire ? + + Dan le fichier /etc/shorewall/rules: + + #ACTION SOURCE DEST PROTO DEST PORT +DNAT net loc:192.168.1.3:22 tcp 1022 +
+ +
+ (FAQ 1d) J'ai un serveur web dans man DMZ et j'utilise le + transfert de port pour rendre ce serveur accessible depuis internet. + Cela fonctionne très bien sauf lorsque mes utilisateurs locaux + essayent de se connecter au serveur en utilisant l'adresse IP externe + du firewall. + + Réponse: Supposons que: + + + + L'adresse IP externe est 206.124.146.176 sur eth0. + + + + L'adresse IP du serveur est 192.168.2.4 + + + + Vous pouvez activer l'accès au serveur depuis votre réseau local + en utilisant l'adresse IP externe du firewall. Pour cela, vous pouvez + ajouter cette règle: + + #ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL +# PORT DEST +DNAT loc dmz:192.168.2.4 tcp 80 - 206.124.146.176 + + Si votre adresse IP externe est dynamique, vous devez faire + comme suit: + + Dans /etc/shorewall/params: + + ETH0_IP=`find_interface_address eth0` + + Pour les utilisateurs de 2.1.0 et des versions + ultérieures: + + ETH0_IP=`find_first_interface_address eth0` + + Et votre règle DNAT deviendra: + + #ACTION SOURCE DEST PROTO DEST PORT SOURCE ORIGINAL +# PORT DEST. +DNAT loc dmz:192.168.2.4 tcp 80 - $ETH0_IP +
+ +
+ (FAQ 1e) Dans le but de décourager les attaques en force brute, + je voudrais rediriger toutes les connexions internet arrivant sur un + port non standard (4104) vers le port 22 du firewall/routeur. J'ai + remarqué que lorsque je paramètre une règle REDIRECT sur le firewall, + il ouvre sur internet les deux ports 4104 et 22 . Est-il possible de + rediriger seulement le port 4104 vers le port 22 de localhost et que + toutes les tentatives de connexion depuis internet au port 22 soient + ignorées ? + + Réponse: avec l'aimable + autorisation de Ryan: en supposant que l'adresse de l'interface locale + de votre firewall soit 192.168.1.1, en ajoutant la règle suivante, le + port 4104 sera en écoute sur internet et le port 22 sera en écoute sur + votre LAN. + + #ACTION SOURCE DEST PROTO DEST PORT(S) +DNAT net fw:192.168.1.1:22 tcp 4104 +
+
+ +
+ (FAQ 30) Quand doit-on utiliser des règles DNAT et quand doit-on + utiliser des règles ACCEPT ? + + Je vous suggère de revenir au guides de démarrage rapide + adapté à votre configuration. Ces guides couvrent ce sujet sous un angle + didactique. Vous devriez utiliser des règles DNAT pour les connexions + qui doivent aller dans le sens inverse de celles en provenance de la + SNAT/Masquerade. Ainsi, si vous utilisez la SNAT ou Masquerade depuis + votre réseau local vers internet, vous aurez besoin d'utiliser des + règles DNAT pour autoriser les connexions d'internet vers votre réseau + local. Si vous avez besoin d'intercepter des connexions lorsqu'elles + arrivent sur le firewall et que vous voulez les traiter sur le firewall + lui-même, vous utiliserez une règle REDIRECT.Dans tous les autres cas, + vous utiliserez ACCEPT. +
+ +
+ (FAQ 38) Où trouver plus d'information sur la DNAT? + + Ian Allen a écrit cet article au sujet de la DNAT et Linux. +
+ +
+ (FAQ 48) Comment configurer un proxy transparent avec + Shorewall? + + Réponse: Vous pouvez voir Shorewall et Squid. +
+
+ +
+ DNS et Transfert de Port/Traduction d'Adresses Réseau NAT + +
+ (FAQ 2) Je transfère (port forward) toutes les requêtes web + soumises à www.mondomaine.com (IP 130.151.100.69) vers le système + 192.168.1.5 de mon réseau local. Les clients externes peuvent accéder à + http://www.mondomaine.com mais les clients internes ne le peuvent + pas. + + Réponse: j'ai deux objections à + cette configuration. + + + + Avoir un serveur sur votre réseau local accessible depuis + internet est comme élever des loups à coté de votre poulailler. Si + le serveur est compromis, il n'y a rien entre ce serveur et vos + autres systèmes locaux. Pour le prix d'un adaptateur ethernet et + d'un câble croisé, vous pouvez mettre votre serveur en DMZ de telle + façon qu'il soit isolé de vos systèmes locaux - en supposant que le + serveur puisse être installé à coté de votre firewall, bien entendu + :-) + + + + La meilleure solutions pour l'accessibilité à votre serveur + est d'utiliser les vues de Bind Version 9 (ou bien + d'utiliser un serveur DNS séparé pour les clients locaux) afin que + www.mondomaine.com soit résolu en 130.141.100.69 pour les clients + externes et en 192.168.1.5 pour les clients internes. C'est ce que + je fait ici à shorewall.net pour mes systèmes locaux qui utilisent + la NAT un-à-un (one-to-one NAT). + + + + Supposons que votre interface externe soit eth0, que votre + interface interne soit eth1 et que eth1 ait l'adresse 192.168.1.254 sur + le sous-réseau 192.168.1.0/24: + tout le trafic redirigé par cette bidouille sera vu par le + serveur comme provenant du firewall (192.168.1.254) au lieu de venir + du client d'origine! + + + + + Dans /etc/shorewall/interfaces: + + #ZONE INTERFACE BROADCAST OPTIONS +loc eth1 detect routeback + + + + Dans /etc/shorewall/masq: + + #INTERFACE SUBNET ADDRESS PROTO PORT(S) +eth1:192.168.1.5 eth1 192.168.1.254 tcp www + + + + Dans /etc/shorewall/rules: + + #ACTION SOURCE DEST PROTO DEST PORT SOURCE ORIGINAL +# PORT DEST. +DNAT loc loc:192.168.1.5 tcp www - 130.151.100.69 + + Bien entendu, cette règle ne fonctionnera que si vous avez une + adresse IP externe statique. Si vous avez une adresse dynamique vous + devez inclure ceci dans + /etc/shorewall/params: + + ETH0_IP=`find_first_interface_address eth0` + + et votre règle DNAT deviendra: + + #ACTION SOURCE DEST PROTO DEST PORT SOURCE ORIGINAL +# PORT DEST. +DNAT loc loc:192.168.1.5 tcp www - $ETH0_IP + + Lorsque vous utilisez cette technique, il vous faudra + configurer votre client DHCP/PPPoE de façon à ce qu'il relance + shorewall chaque fois qu'il obtient une nouvelle adresse IP. + + + +
+ (FAQ 2a) J'ai une zone <quote>Z</quote> avec un sous-réseau RFC + 1918 et j'utilise la NAT un-à-un (one-to-one NAT) pour assigner des + adresses non-RFC1918 aux hôtes de la zone <quote>Z</quote>. Les hôtes + dans la zone <quote>Z</quote> ne peuvent pas communiquer entre eux en + utilisant leur adresse externe (adresses non-FRC1918) et donc ils ne + peuvent pas communiquer en utilisant leurs noms DNS. + + + Si la colonne ALL INTERFACES dans le fichier + /etc/shorewall/nat est vide ou contient Yes, vous + verrez aussi dans votre journal des messages comme celui-ci à chaque + fois que vous tenterez d'accéder à un hôte de la zone Z depuis un + autre hôte de la zone Z en utilisant son adresse publique: + + Oct 4 10:26:40 netgw kernel: + Shorewall:FORWARD:REJECT:IN=eth1 OUT=eth1 SRC=192.168.118.200 + DST=192.168.118.210 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=1342 DF + PROTO=TCP SPT=1494 DPT=1491 WINDOW=17472 RES=0x00 ACK SYN URGP=0 + + + Réponse: C'est encore un + problème très bien résolu par l'utilisation des vues de + Bind Version 9. Les + clients internes comme les clients externes peuvent alors accéder aux + hôtes NATés en utilisant leur nom réseau. + + Une autre bonne façon d'approcher le problème est d'abandonner + la NAT un-à-un au profit du Proxy ARP. De cette façon, les machines + dans Z ont des adresses non-RFC1918 et on peut y accéder aussi bien + depuis l'intérieur que depuis l'extérieur en utilisant la même + adresse. + + Si vous n'aimez pas ces solutions et que vous préférez bêtement + router tout le trafic de Z vers Z par votre firewall: + + + + Activez l'option routeback sur l'interface vers Z. + + + + Mettez Yes dans la colonne ALL INTERFACES du + fichier nat. + + + + + Exemple: + + Zone: dmz Interface: eth2 Ssous-réseau: 192.168.2.0/24 Addresse: 192.168.2.254 + + Dans le fichier + /etc/shorewall/interfaces: + + #ZONE INTERFACE BROADCAST OPTIONS +dmz eth2 192.168.2.255 routeback + + Dans le fichier /etc/shorewall/nat, + assurez-vous d'avoir Yes dans la colonne ALL + INTERFACES. + + Dans le fichier + /etc/shorewall/masq: + + #INTERFACE SUBNETS ADDRESS +eth2 eth2 192.168.2.254 + + Tout comme dans la bidouille présentée dans la FAQ2 ci-dessus, + le trafic de la dmz vers la dmz semblera provenir du firewall et non + du véritable hôte source. + +
+ +
+ (FAQ 2b) J'ai un serveur web dans ma DMZ et je me sers du + transfert de port pour le rendre accessible sur internet en tant que + www.mondomaine.com. Cela marche très bien sauf pour mes utilisateurs + locaux lorsqu'ils tentent de se connecter à + www.mondomaine.com. + + Réponse: Supposons que: + + + + L'adresse externe IP soit 206.124.146.176 sur eth0 (www.mondomaine.com). + + + + L'adresse IP du serveur soit 192.168.2.4 + + + + Vous pouvez autoriser les machines du réseau local à accéder à + votre serveur en utilisant l'adresse IP externe du firewall. Il suffit + d'ajouter cette règle: + + #ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL +# PORT DEST +DNAT loc dmz:192.168.2.4 tcp 80 - 206.124.146.176 + + Si votre adresse IP externe vous est allouée dynamiquement, vous + devez faire comme suit: + + Dans le fichier + /etc/shorewall/params: + + ETH0_IP=`find_first_interface_address eth0` + + Et votre règle DNAT deviendra: + + #ACTION SOURCE DEST PROTO DEST PORT SOURCE ORIGINAL +# PORT DEST. +DNAT loc dmz:192.168.2.4 tcp 80 - $ETH0_IP +
+
+
+ +
+ Netmeeting/MSN + +
+ (FAQ 3) Je veux utiliser Netmeeting ou la messagerie instantanée + MSN avec Shorewall. Que faire ? + + Réponse: Il existe un module de + suivi de connexion H.323 qui est d'un grand secours avec + Netmeeting. Prenez cependant en compte cet article récent d'un des + développeurs de Netfilter: + +
+ > Je sais que PoM -ng va traiter ce problème, mais en attendant qu'il soit prêt, +> et que tous les extras y soient portés, existe-t-il un moyen d'utiliser le patch +> noyau pour le module de suivi de connexion H.323 avec un noyau 2.6 ? +> j'utilise un noyau 2.6.1 et le noyau 2.4 n'est pas installé sur le système, c'est +> pourquoi je ne peux pas envisager de revenir en 2.4 ... et le module n'a pas +> encore été porté en 2.6, dommage. +> Quelles options ai-je à part d'installer une application gatekeeper (qui ne +> fonctionne pas dans mon réseau) ou un proxy (ce que je préférerais éviter) ? + +Je suggère à tous de configurer un proxy (gatekeeper): le module est vraiment +nul et ne mérite pas d'exister. Ça a été un très bon outil de développement et +de deboguage de l'interface newnat. +
+ + Vous pouvez aller voir ici une + solution pour la messagerie instantanée MSN. Vous devez avoir conscience + que cette solution comporte des risques de sécurité significatifs. Vous + pouvez également vérifier auprès de la liste de diffusion de Netfilter à + http://www.netfilter.org. +
+
+ +
+ Ports ouverts + +
+ (FAQ 4) Je viens juste d'utiliser un scanner de port en ligne + pour vérifier le paramètrage de mon firewall et certains ports + apparaissent <quote>fermés</quote> (closed) alors que d'autres sont + <quote>bloqués</quote> (blocked). Pourquoi ? + + Réponse: La configuration par + défaut de Shorewall invoque l'action Drop avant de mettre en oeuvre une politique + DROP, et la politique par défaut d'internet vers toutes les zones est + DROP. L'action Drop est définie dans le fichier + /usr/share/shorewall/action.Drop qui invoque + lui-même l'action RejectAuth (définie + dans le fichier + /usr/share/shorewall/action.RejectAuth). Cela est + nécessaire pour éviter les problèmes de connexion sortante à des + services qui utilisent le mécanisme Auth pour identifier + les utilisateurs. C'est le seul service configuré par défaut pour + rejeter (REJECT) les paquets. + + Si vous voyez d'autres ports TCP fermés autres que le port 113 + (auth) c'est que vous avez ajouté des règles REJECT pour ces ports ou + bien qu'un routeur à l'extérieur de votre firewall répond aux requêtes + de connexion sur ce port. + +
+ (FAQ 4a) Je viens d'exécuter un scan UDP de mon firewall avec + nmap et il trouve des centaines de ports ouverts!!!! + + Réponse: Respirez à fond et + lisez la section man de nmap au sujet des scans UDP. Si nmap n'a + aucun retour de votre firewall, il + donnera ce port comme étant ouvert. Si vous voulez voir quels sont les + ports UDP réellement ouverts, modifiez temporairement votre politique + net->all pour REJECT, relancez Shorewall et refaites le scan UDP + nmap. +
+ +
+ (FAQ 4b) Quoi que je change dans mes règles, Il y a un port que + je n'arrive pas à fermer. + + J'avais une règle qui autorisait telnet de mon réseau local vers + mon firewall. Je l'ai enlevée et j'ai relancé Shorewall mais ma + session telnet fonctionne encore!!! + + Réponse: Les règles traitent de + l'établissement de nouvelles connexions. Lorsqu'une connexion est + établie par le firewall, elle restera utilisable jusqu'à la + déconnexion tcp ou jusqu'au time out pour les autres protocoles. Si + vous fermez votre session telnet et que vous essayez d'établir un + nouvelle session, votre firewall bloquera cette tentative. +
+ +
+ (FAQ 4c) Comment utiliser Shorewall avec PortSentry? + + Vous + trouverez ici la description d'une bonne intégration de + Shorewall et PortSentry. +
+
+ +
+ (FAQ 51) Comment <quote>ouvrir un port</quote> avec Shorewall + ? + + Réponse: Ça dépend + … + + Si l'application qui sert ce port tourne sur le même système que + Shorewall, ajoutez cette règle: + + #ACTION SOURCE DEST PROTO DEST PORT(S) +ACCEPT net $FW <protocole> <numéro de port> + + Où <protocole> est tcp ou + udp et <numéro de port> est le port que vous + voulez ouvrir. + + Si l'application qui sert ce port tourne sur un autre système sur + votre réseau local, voyez la FAQ 1 + SVP. +
+
+ +
+ Problèmes de connexion + +
+ (FAQ 5) J'ai installé Shorewall et je ne peux plus + <quote>pinger</quote> à travers le firewall + + Réponse: Pour une description + complète de la gestion du ping par Shorewall, voyez + cette page. +
+ +
+ (FAQ 15) Mes systèmes locaux ne peuvent rien voir sur + internet + + Réponse: Chaque fois que je lis + mes systèmes ne peuvent rien voir sur internet, je me + demande où l'auteur a bien pu acheter des ordinateurs avec des yeux et + ce que ces ordinateurs peuvent bien voir lorsque tout + fonctionne convenablement. Ceci mis à part, les causes habituelles à ce + type de problèmes sont: + + + + L'adresse de la passerelle par défaut n'est pas configurée à + l'adresse de l'interface locale du firewall sur chacun des systèmes + locaux. + + + + L'entré pour le réseau local dans le fichier + /etc/shorewall/masq est erronée ou + manquante. + + + + La configuration du DNS sur les systèmes locaux est mauvaise + ou bien l'utilisateur fait tourner un serveur DNS sur le firewall et + il n'a pas autorisé le port 53 UDP et TCP de son firewall vers + internet. + + + + Le forwarding n'est pas activé (ceci est souvent le cas pour + les utilisateurs Debian). Exécutez cette commande: + + cat /proc/sys/net/ipv4/ip_forward + + Si la valeur est 0 (zéro) mettez IP_FORWARDING=On dans le fichier + /etc/shorewall/shorewall.conf et relancez + Shorewall. + + +
+ +
+ (FAQ 29) FTP ne fonctionne pas + + Voir la page Shorewall et + FTP. +
+ +
+ (FAQ 33) Depuis mes clients derrière le firewall les connexions + vers certains sites échouent. Les connexions vers les mêmes sites, mais + depuis le firewall fonctionnent. Qu'est-ce qui ne va pas ? + + Réponse: Très probablement, il + vous faudra mettre CLAMPMSS=Yes dans le fichier /etc/shorewall/shorewall.conf. +
+ +
+ (FAQ 35) J'ai deux interfaces ethernet vers mon réseau local que + j'ai montées en pont (bridge). Quand Shorewall est démarré, je n'arrive + pas à faire passer le trafic à travers le pont. J'ai défini l'interface + pont (br0) comme interface locale dans /etc/shorewall/interfaces. Les + interfaces ethernet <quote>pontées</quote> ne sont pas définies pour + Shorewall. Comment demander à Shorewall d'autoriser le trafic à travers + le pont ? + + Réponse: ajouter l'option + routeback à l'interface br0 dans le fichier /etc/shorewall/interfaces. + + Pour plus d'information sur ce type de configuration, voir la + documentation pour un pont simple avec + Shorewall. +
+
+ +
+ Journalisation + +
+ (FAQ 6) Où sont enregistrés les messages de journalisation et + comment modifier leur destination ? + + Réponse: NetFilter utilise + l'équivalent noyau de syslog (voir man syslog) pour + journaliser les messages. Il utilise toujours le dispositif LOG_KERN + (voir man openlog) et vous devez choisir le niveau de + journalisation (log level, voir man syslog) dans vos + politiques et dans vos + règles. La destination des + messages journalisés par syslog est contrôlée avec + /etc/syslog.conf (voir man + syslog.conf). Lorsque vous avez modifié + /etc/syslog.conf, assurez-vous de redémarrer + syslogd (sur un système RedHat, service syslog + restart). + + Par défaut, les versions plus anciennes de Shorewall limitaient le + taux de journalisation des messages grâce à des paramètres du fichier + /etc/shorewall/shorewall.conf -- Si vous voulez + journaliser tous les messages, positionnez ces paramètres comme + suit: + + LOGLIMIT="" +LOGBURST="" + + On peut également paramétrer + Shorewall pour qu'il enregistre les messages de journalisation dans un + fichier séparé. + +
+ (FAQ 6a) Existe-t-il des analyseur de journal qui fonctionnent + avec Shorewall? + + Réponse: Voilà plusieurs liens + qui peuvent vous aider: + + + http://www.shorewall.net/pub/shorewall/parsefw/ + http://www.fireparse.com + http://cert.uni-stuttgart.de/projects/fwlogwatch + http://www.logwatch.org + http://gege.org/iptables + http://home.regit.org/ulogd-php.html + + + Personnellement, j'utilise Logwatch. Il m'envoie chaque jour par + courriel un rapport pour chacun de mes différents systèmes. Chaque + rapport résume l'activité journalisée sur le système + correspondant. +
+ +
+ (FAQ 6b) Mes journaux sont inondés de messages DROP pour des + requêtes de connections sur le port 10619. Puis-je exclure + temporairement de la journalisation Shorewall les messages d'erreur + pour ce port ? + + Ajoutez temporairement la règle suivante: + + DROP net fw udp 10619 +
+ +
+ (FAQ 6d) Pourquoi l'adresse MAC dans les messages de + journalisation Shorewall est-elle si longue ? Je pensais que l'adresse + MAC ne faisait que 6 octets. + + Ce qui est labelisé comme adresse MAC dans les messages de + journalisation Shorewall est en fait l'entête de la trame ethernet. + Elle contient: + + + + l'adresse MAC de destination (6 octets) + + + + l'adresse MAC source (6 octets) + + + + le type de trame ethernet (2 octets) + + + + + Exemple + + MAC=00:04:4c:dc:e2:28:00:b0:8e:cf:3c:4c:08:00 + + + adresse MAC de destination = 00:04:4c:dc:e2:28 + + + + adresse MAC source = 00:b0:8e:cf:3c:4c + + + + type de trame ethernet = 08:00 (IP Version 4) + + + +
+
+ +
+ (FAQ 16) Shorewall écrit ses messages de journalisation + directement sur ma console et la rend inutilisable! + + Réponse: + + + + Trouvez où klogd est démarré (ce sera depuis un des fichiers + du répertoire /etc/init.d -- + sysklogd, klogd, ...). Modifiez ce fichier ou le fichier de + configuration approprié de telle manière que klogd soit démarré avec + -c <n> avec + <n> étant un niveau de journalisation + inférieur ou égal à 5; ou alors + + + + Voir la page man de dmesg (man + dmesg). Vous devez ajouter une commande dmesg + adaptée dans vos scripts de démarrage ou la placer dans le fichier + /etc/shorewall/start. + + + + + Sous RedHat et Mandriva, le niveau de journalisation maximum + envoyé à la console est spécifié par la variable LOGLEVEL du fichier + /etc/sysconfig/init. Positionnez + LOGLEVEL=5 pour éliminer de la console les messages de + niveau info. + + + + Sous Debian, vous pouvez mettre KLOGD=-c 5 dans + le fichier /etc/init.d/klogd afin d'éliminer de + la console les messages de niveau info (log level 6). + + + + Sous SUSE, ajoutez -c 5 à KLOGD_PARAMS dans le + fichier /etc/sysconfig/syslog fin d'éliminer de + la console les messages de niveau info (log level 6). + +
+ +
+ (FAQ 17) Pourquoi ces paquets sont-ils ignorés/rejetés + (dropped/rejected)? Comment décode-t-on les messages de journalisation + Shorewall? + + Réponse: Avec Shorewall, les + paquets ignorés/rejetés peuvent avoir été journalisés en sortie d'un + certain nombre de chaînes (comme indiqué dans le message): + + + + man1918 or logdrop + + + L'adresse destination est listée dans le fichier + /usr/share/shorewall/rfc1918 avec une cible + logdrop -- voir /usr/share/shorewall/rfc1918. + + + + + rfc1918 or logdrop + + + L'adresse source ou destination est listée dans le fichier + /usr/share/shorewall/rfc1918 avec un cible + logdrop -- voir /usr/share/shorewall/rfc1918. + + + Si vous voyez des paquets rejetés par la chaîne rfc1918 et + que ni l'adresse IP source ni l'adresse IP de destination ne + sont réservées par la RFC 1918, cela provient la plupart du + temps d'un ancien fichier rfc1918 dans + /etc/shorewall (ceci + arrive le plus fréquemment lorsque vous utilisez une Debian ou + un de ses dérivés). Le fichier rfc1918 + incluait aussi bien les bogons que les + trois plages réservées par la RFC 1918. Il était installé dans + le répertoire /etc/shorewall. Maintenant le + fichier ne contient que les trois plages d'adresse de la RFC + 1918 et il est installé dans le répertoire /usr/share/shorewall. Retirez le + fichier rfc1918 périmé de votre répertoire /etc/shorewall. + + + + + + all2<zone>, <zone>2all or all2all + + + Vous avez une politique qui spécifie un + niveau de journalisation et ce paquet a été journalisé par cette + politique. Si vous voulez autoriser (ACCEPT) ce trafic, il vous + faudra une règle à + cette fin. + + + + + <zone1>2<zone2> + + + Ou bien vous avez une politique pour le trafic de + la <zone1> vers la + <zone2> qui spécifie un + niveau de journalisation et ce paquet a été journalisé par cette + politique ou alors ce paquet correspond à une règle incluant un niveau de + journalisation. + + + + + @<source>2<dest> + + + Vous avez une politique pour le trafic de <source> vers <dest> dans laquelle vous avez spécifié + un taux de limitation des connexions TCP (les valeurs dans la + colonne LIMIT:BURST). Les paquet journalisé dépassait cette limite + et a été ignoré (DROP). Il faut noter que ces messages au journal + sont eux-même sévèrement limités afin qu'une inondation SYN + (syn-flood) ne provoque pas un déni de service (DOS) secondaire + par un nombre excessif de messages de journalisation. Ces messages + ont été introduits dans Shorewall 2.2.0 Beta 7. + + + + + <interface>_mac + + + Ce paquet a été journalisé par l'option d'interface + maclist . + + + + + logpkt + + + Ce paquet a été journalisé par l'option d'interface + logunclean. + + + + + badpkt + + + Ce paquet a été journalisé par l'option d'interface + dropunclean tel que spécifié dans + le paramètre LOGUNCLEAN du + fichier + /etc/shorewall/shorewall.conf + . + + + + + blacklst + + + Ce paquet a été journalisé parce que l'adresse IP source est + inscrite dans la liste noire /etc/shorewall/blacklist. + + + + + INPUT or FORWARD + + + Ce paquet a une adresse IP source qui n'est définie dans + aucune de vos zones (shorewall check et regardez + les définitions de zones) ou alors la chaîne est FORWARD et + l'adresse IP de destination ne figure dans aucune de vos zones + définies. Si la chaîne est FORWARD et les interfaces IN et OUT + sont identiques, vous avez sans doute besoin de l'option routeback sur cette interface dans le + fichier /etc/shorewall/interfaces + ou bien vous avez besoin de l'option routeback pour l'entrée adéquate dans le + fichier /etc/shorewall/hosts + . + + + + + OUTPUT + + + Ce paquet a une adresse IP destination qui n'est définie + dans aucune de vos zones (shorewall check et + regardez les définitions de zones). + + + + + logflags + + + Ce paquet a été journalisé parce qu'il a échoué aux + contrôles mis en oeuvre par l'option d'interface + tcpflags. + + + + + + Exemple: + + Jun 27 15:37:56 gateway kernel: + Shorewall:all2all:REJECT:IN=eth2 + OUT=eth1 + SRC=192.168.2.2 + DST=192.168.1.3 LEN=67 TOS=0x00 PREC=0x00 TTL=63 ID=5805 DF PROTO=UDP + SPT=1803 DPT=53 LEN=47 + + Examinons les partie importantes de ce message: + + + + all2all:REJECT + + + Ce paquet a été rejeté (REJECT) par la chaîne all2all -- le paquet a été rejeté par la + politique all->all REJECT (voir + all2all ci-dessus). + + + + + IN=eth2 + + + Le paquet est arrivé dans le firewall par eth2. Lorsque + vous voyez IN= sans aucun nom d'interface, c'est + que le paquet provient du firewall lui-même. + + + + + OUT=eth1 + + + Si il avait été autorisé, ce paquet aurait été transmis à + eth1. Lorsque vous voyez OUT= sans aucun nom + d'interface, c'est que le paquet aurait été traité par le + firewall lui-même. + + + Lorsqu'une règle DNAT est journalisée, on n'a jamais de + OUT= parce que le paquet est journalisé avant d'être routé. + Par ailleurs, la journalisation DNAT donnera l'adresse IP + destination et le numéro de port destination + d'origine. + + + + + + SRC=192.168.2.2 + + + Ce paquet a été envoyé par 192.168.2.2 + + + + + DST=192.168.1.3 + + + Ce paquet a pour destination 192.168.1.3 + + + + + PROTO=UDP + + + Le protocole est UDP + + + + + DPT=53 + + + Le port de destination est le port 53 (DNS) + + + + + Pour plus d'informations concernant les messages de + journalisation, voir http://logi.cc/linux/netfilter-log-format.php3. + + Dans ce cas, 192.168.2.2 était dans la zone dmz + et 192.168.1.3 était dans la zone loc. Il me manquait + la règle suivante: + + ACCEPT dmz loc udp 53 + +
+ +
+ (FAQ 21) Je vois occasionnellement ces étranges messages dans mon + journal. De quoi s'agit-il? + + Nov 25 18:58:52 linux kernel: + Shorewall:net2all:DROP:IN=eth1 OUT= + MAC=00:60:1d:f0:a6:f9:00:60:1d:f6:35:50:08:00 SRC=206.124.146.179 + DST=192.0.2.3 LEN=56 TOS=0x00 PREC=0x00 TTL=110 ID=18558 PROTO=ICMP + TYPE=3 CODE=3 [SRC=192.0.2.3 DST=172.16.1.10 LEN=128 TOS=0x00 PREC=0x00 + TTL=47 ID=0 DF PROTO=UDP SPT=53 DPT=2857 LEN=108 ] + + 192.0.2.3 est externe à mon firewall... mon réseau local est + 172.16.0.0/24 + + Réponse: Bien que la plupart des + gens associent ICMP (Internet Control Message Protocol) à + ping, ICMP est une pièce clé d'internet. ICMP sert à + informer l'expéditeur d'un paquet des problèmes rencontrés. C'est ce qui + se produit ici. Malheureusement, de nombreuses implémentations ne + fonctionnent pas dès lors que la traduction d'adresses est impliquée (y + compris SNAT, DNAT et Masquerade). C'est ce que vous voyez avec à + travers ces messages. Quand Netfilter renvoie ces messages, la partie + précédent le "[" décrit le paquet ICMP, et la partie entre "[" et "]" + décrit le paquet pour lequel ICMP répond. + + Voici mon interprétation de ce qui se passe -- pour confirmer + l'analyse, il faudrait avoir un sniffeur de paquets à + chacune des extrémités de la connexion. + + L'hôte 172.16.1.10 placé derrière la passerelle NAT + 206.124.146.179 a envoyé une requête DNS UDP à 192.0.2.3 et votre + serveur DNS a tenté d'envoyer un réponse (l'information en réponse est + entre les crochets -- remarquez le port source 53 qui indique qu'il + s'agit d'une réponse DNS). Quand la réponse a été envoyée à + 206.124.146.179, le firewall a réécrit l'adresse IP destination à + 172.16.1.10 puis a fait suivre le paquet à 172.16.1.10 qui n'avait plus + de connexion UDP sur le port 2857. Ceci provoque la génération d'un + message ICMP port unreachable (type 3, code 3) en retour vers 192.0.2.3. + Ce paquet est renvoyé par 206.124.146.179 qui change correctement + l'adresse source dans le paquet pour 206.124.146.179 mais ne modifie pas + de la même façon l'IP destination dans la réponse DNS d'origine. Lorsque + le paquet ICMP atteint votre firewall (192.0.2.3), celui-ci n'a aucun + enregistrement lui indiquant qu'il a envoyé une réponse DNS à + 172.16.1.10 et par conséquent ce paquet ICMP semble n'être associé à + rien de ce qui a été envoyé. Le résultat est que ce paquet est + journalisé et ignoré (DROP) par la chaîne all2all. J'ai également vu des + cas dans lesquels la source IP dans le paquet ICMP lui-même n'est pas + ré-écrite à l'adresse externe de la passerelle NAT distante. Dans ce cas + votre firewall va journaliser et ignorer (DROP) le paquet par la chaîne + rfc1918 cas son IP source est réservée par la RFC 1918. +
+
+ +
+ Routage + +
+ (FAQ 32) J'ai deux connexions internet avec deux FAI différents + sur mon firewall. Comment le configurer avec Shorewall? + + Réponse: voir cet article sur + Shorewall et le routage. +
+ +
+ (FAQ 49) Quand je démarre Shorewall, ma table de routage est + détruite. Pourquoi Shorewall fait-il cela? + + Réponse: Ceci est en général la + conséquence d'une bêtise dans la configuration du NAT un-à-un + (one-to-one NAT): + + + + Vous spécifiez l'adresse IP primaire d'une interface dans la + colonne EXTERNAL du fichier /etc/shorewall/nat + alors que la documentation et les commentaires dans le fichier vous + mettent en garde contre une telle configuration. + + + + Vous spécifiez ADD_IP_ALIASES=Yes et RETAIN_ALIASES=No dans le + fichier /etc/shorewall/shorewall.conf. + + + + Cette combinaison fait détruire par Shorewall l'adresse primaire + de l'interface réseau spécifiée dans la colonne INTERFACE, ce qui a en + général pour conséquence de détruire routes les routes sortantes de + cette interface. La solution est de ne pas + spécifier l'adresse primaire d'une interface dans la colonne + EXTERNAL. +
+
+ +
+ Démarrer et arrêter Shorewall + +
+ (FAQ 7) Quand j'arrête Shorewall avec la commande + <quote>shorewall stop</quote>, je ne peux plus me connecter à quoi que + ce soit. Pourquoi cette commande ne fonctionne-t-elle pas? + + La commande stop est prévue + pour mettre votre firewall dans un état de sécurité où seuls les hôtes + listés dans le fichier /etc/shorewall/routestopped + sont activés. Si vous voulez ouvrir complètement votre firewall, il vous + faut utiliser la commande shorewall + clear. +
+ +
+ (FAQ 8) Quand je tente de lancer Shorewall sur RedHat, je reçois + des messages d'erreur insmod -- qu'est-ce qui ne va pas? + + Réponse: La sortie que vous avez + ressemble à ceci: + + /lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: init_module: Device or resource busy +Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters +/lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: insmod +/lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o failed +/lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: insmod ip_tables failed +iptables v1.2.3: can't initialize iptables table `nat': iptables who? (do you need to insmod?) +Perhaps iptables or your kernel needs to be upgraded. + + En général, ce problème est corrigé par la séquence de commandes + qui suit: + + service ipchains stop +chkconfig --delete ipchains +rmmod ipchains + + Par ailleurs, assurez-vous d'avoir vérifié dans l'errata que vous n'avez pas de problèmes lié à + la version d'iptables (v1.2.3) distribuée avec RH7.2. + +
+ (FAQ 8a) Quand je tente de lancer Shorewall sur une RedHat, je + reçois un message qui me renvoie à la FAQ #8 + + Réponse: Ceci se traite en + général avec la séquence de commandes présentée ci-dessus dans la + . +
+
+ +
+ (FAQ 9) Pourquoi Shorewall ne réussit-il pas à détecter + convenablement mes interfaces au démarrage? + + Je viens d'installer Shorewall et quand je lance la commande + start, voilà ce qui se passe : + + Processing /etc/shorewall/params ... +Processing /etc/shorewall/shorewall.conf ... +Starting Shorewall... +Loading Modules... +Initializing... +Determining Zones... + Zones: net loc +Validating interfaces file... +Validating hosts file... +Determining Hosts in Zones... + Net Zone: eth0:0.0.0.0/0 + Local Zone: eth1:0.0.0.0/0 +Deleting user chains... +Creating input Chains... +... + + Pourquoi est-ce que Shorewall ne détecte-t-il pas correctement mes + interfaces? + + Réponse: La sortie ci-dessus est + parfaitement normale. La zone Net est définie comme étant composée de + toutes les machines connectées à eth0 et la zone Local est définie comme + étant composée de toutes celles connectées à eth1. Si vous utilisez + Shorewall 1.4.10 ou une version plus récente, vous pouvez envisager de + paramétrer l'option + d'interface detectnet pour + votre interface locale (eth1 dans l'exemple ce-dessus). Ceci forcera + Shorewall à restreindre la zone locale aux seuls réseaux routés par + cette interface. +
+ +
+ (FAQ 22) Je voudrais exécuter certaines commandes iptables au + démarrage de Shorewall. Dans quel fichier les mettre? + + Vous pouvez placer ces commandes dans une des Scripts d'Extension + Shorewall. Assurez-vous de bien examiner le contenu des chaînes + que vos commandes vont modifier afin d'être certain que ces commandes + feront bien ce qu'elles sont censées faire. De nombreuses commandes + publiées dans des guides (HOWTOs) ainsi que dans d'autres modes + opératoires font usage de la commande -A qui ajoute les règles en fin de + chaîne. La plupart des chaînes construites par Shorewall se terminent + par une règle inconditionnelle DROP, ACCEPT ou REJECT et donc toute + règle que vous pourriez ajouter après serait ignorée. Consultez + man iptables et prenez connaissance de la commande -I + (--insert). +
+ +
+ (FAQ 34) Comment accélérer le démarrage (start/restart)? + + L'utilisation d'un shell léger tel que ash peut + diminuer de façon très significative le temps nécessaire pour démarrer + (start/restart) Shorewall. Voyez la variable + SHOREWALL_SHELL dans le fichier shorewall.conf . + + Utilisez un émulateur de terminal rapide -- en particulier la + console KDE défile beaucoup plus vite que le terminal Gnome. Vous pouvez + également utiliser l'option '-q' si vous redémarrez à distance ou depuis + un terminal lent (ou rediriger la sortie vers un fichier comme dans + shorewall restart > /dev/null). + + Shorewall offre également une fonction de démarrage rapide. Pour + l'utiliser: + + + + Avec Shorewall dans l'état démarré, + exécutez shorewall save. Cela va créer le script + /var/lib/shorewall/restore. + + + + Utilisez l'option -f avec la + commande start (par exemple, shorewall -f start). + Ceci forcera Shorewall à chercher le script + /var/lib/shorewall/restore et à l'exécuter si + il existe. Exécuter /var/lib/shorewall/restore + prend beaucoup moins de temps que d'exécuter un shorewall + start complet. + + + + Le script /etc/init.d/shorewall exécuté + au démarrage du système utilise l'option -f. + + + + Le script /var/lib/shorewall/restore peut + être exécuté à tout moment pour restaurer le firewall. Il peut être + invoqué directement ou bien indirectement en utilisant la commande + shorewall restore. + + + + Si vous modifiez votre configuration de Shorewall, vous devez + exécuter un shorewall start (sans + -f) ou un shorewall + restart avant de refaire un shorewall save. + La commande shorewall save sauvegarde la + configuration qui tournait au moment où elle a été exécutée et non celle + que représentent les fichiers de configuration que vous avez + modifiés. + + De même, si vous modifiez votre configuration Shorewall et que + vous êtes satisfait du résultat, vous devez exécuter une commande + shorewall save, sans quoi vous reviendriez à + l'ancienne configuration enregistrée dans + /var/lib/shorewall/restore lors du prochain + démarrage de votre système. +
+ +
+ (FAQ 43) Je viens d'installer le RPM Shorewall et Shorewall ne + démarre pas au lancement du système (boot). + + Réponse: Quand vous installez + avec la commande "rpm -U", Shorewall n'exécute pas les outils de votre + distribution qui configurent le démarrage de Shorewall. Vous devrez + exécuter cet outils vous-même (insserv, chkconfig, run-level editor, + …) pour que Shorewall démarre aux niveaux d'exécutions + (run-level) auxquels vous voulez l'utiliser. +
+ +
+ (FAQ 45) Pourquoi est-ce que "shorewall start" échoue lorsque je + tente de mettre en place SNAT/Masquerade? + + shorewall start produit la sortie + suivante: + + … +Processing /etc/shorewall/policy... + Policy ACCEPT for fw to net using chain fw2net + Policy ACCEPT for loc0 to net using chain loc02net + Policy ACCEPT for loc1 to net using chain loc12net + Policy ACCEPT for wlan to net using chain wlan2net +Masqueraded Networks and Hosts: +iptables: Invalid argument + ERROR: Command "/sbin/iptables -t nat -A …" Failed + + Réponse: Dans 99.999% des cas, + cette erreur provient d'un problème de comptabilité des versions + d'iptables et du noyau. + + + + Votre iptables doit être compilé en utilisant un arbre de + sources du noyau qui soit compatible au niveau Netfilter avec le + noyau que vous exécutez sur votre système. + + + + Si vous recompilez iptables avec les paramètres par défaut + puis que vous l'installez, il sera installé dans + /usr/local/sbin/iptables. Comme on peut le voir + ci-dessus, votre variable IPTABLES est configurée à + /sbin/iptables dans votre fichier + shorewall.conf. + + +
+
+ +
+ Au sujet de Shorewall + +
+ (FAQ 10) Sur quelles distributions tourne-t-il? + + Shorewall fonctionnera sur n'importe quelle distribution GNU/Linux + distribution réunissant les pré-requis Shorewall indiqués + dans ce document. +
+ +
+ (FAQ 11) Quelles sont ses caractéristiques? + + Réponse: voir la liste des caractéristiques de + Shorewall. +
+ +
+ (FAQ 12) Existe-t-il une interface graphique? + + Réponse: Oui. Webmin offre le + support de Shorewall à partir de la version 1.060. Voir http://www.webmin.com +
+ +
+ (FAQ 13) Pourquoi l'avez-vous appelé + <quote>Shorewall</quote>? + + Réponse: Shorewall est le + résultat de la concaténation de + Shoreline (la ville où je vis) et de + Firewall . En fait le nom complet du + produit est Shoreline Firewall mais on utilise plus + communément Shorewall. +
+ +
+ (FAQ 23) Pourquoi utilisez-vous des polices de caractères aussi + affreuses sur votre site web? + + Le site web de Shorewall est presque entièrement neutre en ce qui + concerne les polices (à l'exception de quelques pages il ne spécifie + explicitement aucune police). Les polices que vous voyez sont largement + celles configurées par défaut dans votre navigateur. Si vous ne les + aimez pas reconfigurez votre navigateur. +
+ +
+ (FAQ 25) Comment savoir quelle version de Shorewall + j'utilise? + + A l'invite du système, tapez: + + /sbin/shorewall version +
+ +
+ (FAQ 31) Est-ce que Shorewall fournit une protection + contre.... + + + + IP Spoofing: envoyer des paquets par l'interface WAN en se + servant d'adresses IP du réseau local comme adresse source? + + + Réponse: Oui. + + + + + Tear Drop: Envoyer des paquets contenant des fragments qui se + recouvrent ? + + + Réponse: Ceci est de la responsabilité de la pile IP, ce + n'est pas celle d'un firewall basé sur Netfilter car le + ré-assemblage des fragments est fait avant que le filtre de + paquets ne voie chaque paquet. + + + + + Smurf and Fraggle: Envoyer des paquets qui utilisent comme + adresse source l'adresse de diffusion (broadcast) du WAN ou du + LAN? + + + Réponse: On peut configurer Shorewall pour le faire avec sa + fonction de liste noire + (blacklist). A partir de la version 2.0.0, Shorewall + filtre ces paquets avec l'option d'interface + nosmurfs dans le fichier /etc/shorewall/interfaces. + + + + + Land Attack: Envoyer des paquets utilisant la même adresse + comme source et comme destination? + + + Réponse: Oui lorsque l'option d'interface + routefilter est sélectionnée. + + + + + DOS: Déni de Service SYN Dos - ICMP Dos - protection DOS par + hôte + + + Réponse: Shorewall offre la possibilité de limiter les + paquets SYN les paquets ICMP. Netfilter tel qu'il est inclus dans + les noyaux Linux standard ne supporte pas la mise en oeuvre de + limitations par hôte distant sauf en utilisant une règle explicite + qui spécifie l'adresse IP de l'hôte. Cette forme de limitation est + supportée par Shorewall. + + + +
+ +
+ (FAQ 36) Est-ce que Shorewall tourne sur le noyau Linux + 2.6? + + Shorewall fonctionne avec les noyaux 2.6 avec les deux + restrictions suivantes: + + + + Dans les noyaux 2.6 Netfilter/iptables n'offre pas un support + complet d'IPSEC -- il existe des patch pour le noyau et pour + iptables. Vous trouverez des détails à la page Shorewall IPSEC-2.6. + + + + Les noyaux 2.6 n'offrent pas le support des options logunclean + et dropunclean du fichier + /etc/shorewall/interfaces. Le support de ces + options a également été retiré de Shorewall dans la version + 2.0.0. + + +
+
+ +
+ RFC 1918 + +
+ (FAQ 14) Je suis connecté avec un modem câble qui a son propre + serveur web interne utilisé pour le paramétrage et la supervision. Mais + bien entendu, si j'active le blocage des adresse de la RFC 1918 sur mon + interface internet eth0, le serveur web du modem est bloqué lui + aussi. + + Est-il possible de rajouter une règle avant la règle de blocage + rfc1918 de façon à autoriser tout le trafic en provenance et à + destination de 192.168.100.1, adresse de mon modem, tout en continuant à + filtrer les autres adresses rfc1918? + + Réponse: Si vous utilisez une + version de Shorewall antérieure à la 1.3.1, créez un fichier + /etc/shorewall/start et mettez-y la commande + suivante: + + run_iptables -I rfc1918 -s 192.168.100.1 -j ACCEPT + + Si vous utilisez la version 1.3.1 ou une version plus récente, + ajoutez ce qui suit dans le fichier /etc/shorewall/rfc1918 + (Remarque: Si vous utilisez 2.0.0 ou une version ultérieure, il est + possible que ayez à préalablement à copier le fichier + /usr/share/shorewall/rfc1918 vers + /etc/shorewall/rfc1918): + + Assurez-vous d'ajouter l'entrée AU-DESSUS de l'entrée pour + 192.168.0.0/16. + + #SUBNET TARGET +192.168.100.1 RETURN + + + Si vous ajoutez une seconde adresse IP à l'interface externe de + votre firewall qui corresponde à l'adresse du modem, vous devez + ajouter une entrée pour cette adresse dans le fichier + /etc/shorewall/rfc1918. Par exemple, si vous + configurez l'adresse 192.168.100.2 sur votre firewall, vous devrez + ajouter les deux entrées suivantes dans le fichier + /etc/shorewall/rfc1918: + + #SUBNET TARGET +192.168.100.1 RETURN +192.168.100.2 RETURN + + +
+ (FAQ 14a) Bien qu'il assigne des adresses IP publiques, le + serveur DHCP de mon FAI a une adresse de la RFC 1918. Si j'active le + filtrage RFC 1918 sur mon interface externe, mon client DHCP ne peut + plus renouveler son bail. + + La solution est la même que dans la + présentée au-dessus. Substituez-y simplement l'adresse du serveur DHCP + de votre FAI. +
+ +
+ (FAQ 14b) Je me connecte à internet par PPPoE. Quand j'essaye + de me connecter au serveur web incorporé à mon modem DSL, la connexion + est refusée. + + Dans mon journal je peux voir ce qui suit: + + Mar 1 18:20:07 Mail kernel: Shorewall:OUTPUT:REJECT:IN= OUT=eth0 SRC=192.168.1.2 DST=192.168.1.1 LEN=60 +TOS=0x00 PREC=0x00 TTL=64 ID=26774 DF PROTO=TCP SPT=32797 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0 + + Réponse: Le fait que le message + soit journalisé par la chaîne OUTPUT signifie que l'adresse de + destination n'appartient à aucune des zones définies (voir la FAQ 17). Vous devez: + + + + Ajouter une zone pour votre modem dans le fichier + /etc/shorewall/zones: + + #ZONE TYPE OPTIONS +modem ipv4 + + + + Dans le fichier + /etc/shorewall/interfaces, associer cette + zone avec l'interface à laquelle votre modem est connecté (eth0 + dans l'exemple): + + #ZONE INTERFACE BROADCAST OPTIONS +modem eth0 detect + + + + Autoriser le trafic web vers le modem dans le fichier + /etc/shorewall/rules: + + #ACTION SOURCE DEST PROTO DEST PORT(S) +ACCEPT fw modem tcp 80 +ACCEPT loc modem tcp 80 + + + + Notez qu'un grand nombre de ces modems cable/DSL n'a pas de + passerelle par défaut ou alors que leur passerelle par défaut est + fixée à une adresse IP différente de l'adresse que vous avez attribuée + à votre interface externe. Dans un cas comme dans l'autre, vous pouvez + avoir des difficultés à naviguer sur votre modem depuis votre réseau + local, même si toutes les routes sont correctement établies sur votre + firewall. Pour résoudre ce problème, on masquerade le + trafic depuis réseau local vers le modem. + + /etc/shorewall/masq: + + #INTERFACE SUBNET ADDRESS +eth0 eth1 # eth1 = interface to local network + + A titre d'exemple lorsque le modem cable/ADSL est + ponté (bridge), vous pouvez aller voir ma configuration. Dans ce cas, je + masquerade en utilisant l'adresse IP de mon interface + locale! +
+
+
+ +
+ Adresses Alias IP/Interfaces virtuelles + +
+ (FAQ 18) Existe-t-il un moyen d'utiliser des adresses IP aliasées + avec Shorewall, et de maintenir des jeux de règles séparés pour ces + différentes adresses IP? + + Réponse: Oui. Voyez Shorewall et les interfaces + aliasées. +
+
+ +
+ Divers + +
+ (FAQ 19) J'ai ajouté des entrées au fichier + /etc/shorewall/tcrules mais elles semblent n'avoir aucun effet. + Pourquoi? + + Vous n'avez probablement pas mis TC_ENABLED=Yes dans le fichier + /etc/shorewall/shorewall.conf et de ce fait le + contenu du fichier tcrules est tout simplement ignoré. +
+ +
+ (FAQ 20) Je viens d'installer un serveur. Dois-je modifier + Shorewall pour autoriser les accès internet à mon serveur? + + Oui. Consultez le guides de démarrage rapide + que vous avez utilisé pour votre configuration initiale afin d'avoir des + informations nécessaires à l'écriture des règles pour votre + serveur. +
+ +
+ (FAQ 24) Comment puis-je autoriser des connexions internet au + port ssh, par exemple, mais seulement depuis certaines adresses IP + spécifiques? + + Dans la colonne SOURCE de la règle, faites suivre + net de : puis d'une liste séparée par des + virgules d'adresses de machines ou de sous-réseaux + + net:<ip1>,<ip2>,... + + + Exemple: + + ACCEPT net:192.0.2.16/28,192.0.2.44 fw tcp 22 + +
+ +
+ (FAQ 26) Quand j'essaye d'utiliser nmap avec n'importe laquelle + des options SYN depuis le firewall lui-même ou depuis n'importe quelle + machine derrière le firewall, j'obtiens une erreur <quote>operation not + permitted</quote>. Comment utiliser nmap avec Shorewall?" + + Retirez temporairement les règles rejNotSyn, dropNotSyn and + dropInvalid du fichier /etc/shorewall/rules et + relancez Shorewall. +
+ +
+ (FAQ 27) Je compile un nouveau noyau (kernel) pour mon firewall. + A quoi devrais-je faire attention? + + Commencez par regarder la page de configuration du noyau pour Shorewall. Vous + souhaiterez sans doute vous assurer que vous avez bien sélectionné + NAT of local connections (READ + HELP) dans le menu de configuration de Netfilter. + Sans cela, les règles DNAT ayant votre firewall comme zone source ne + fonctionneraient pas avec votre nouveau noyau. + +
+ (FAQ 27a) Je viens de compiler (ou j'ai téléchargé ou récupéré + par n'importe quel autre moyen) et d'installer un nouveau noyau et + Shorewall ne démarre plus. Je sais que les options de mon noyau sont + correctes. + + Les dernières lignes de la trace + de démarrage sont les suivantes: + + + run_iptables2 -t nat -A eth0_masq -s 192.168.2.0/24 -d 0.0.0.0/0 -j +MASQUERADE ++ '[' 'x-t nat -A eth0_masq -s 192.168.2.0/24 -d 0.0.0.0/0 -j +MASQUERADE' = 'x-t nat -A eth0_masq -s 192.168.2.0/24 -d 0.0.0. +0/0 -j MASQUERADE' ']' ++ run_iptables -t nat -A eth0_masq -s 192.168.2.0/24 -d 0.0.0.0/0 -j +MASQUERADE ++ iptables -t nat -A eth0_masq -s 192.168.2.0/24 -d 0.0.0.0/0 -j +MASQUERADE +iptables: Invalid argument ++ '[' -z '' ']' ++ stop_firewall ++ set +x + + Réponse: votre noyau contient + des entêtes incompatibles avec celles utilisées pour compiler votre + programme iptables. Vous devez recompiler + iptables en utilisant l'arbre de sources de votre + nouveau noyau. +
+
+ +
+ (FAQ 28) Comment utiliser Shorewall en pont filtrant (Bridging + Firewall)? + + Le support Shorewall pour les ponts filtrant existe — voir ici pour les détails. +
+ +
+ (FAQ 39) Comment bloquer les connexion à un domaine + particulier? + + J'ai essayé de bloquer Adsense de Google. Adsense est un + Javascript que les gens ajoutent à leur pages web. J'ai ajouté la règle + suivante: + + #ACTION SOURCE DEST PROTO +REJECT fw net:pagead2.googlesyndication.com all + + Cependant, ceci bloque parfois les accès à "google.com". Pourquoi? + Avec dig, je trouve les adresses IP suivantes pour le domaine + googlesyndication.com:216.239.37.99 +216.239.39.99Et celles-ci pour google.com:216.239.37.99 +216.239.39.99 +216.239.57.99Je suppose donc que ce n'est pas le domaine qui + est bloqué mais plutôt ses adresses IP. Comment bloquer réellement un + nom de domaine? + + Réponse: Les filtres de paquets + basent leurs décisions sur le contenu des différents entêtes de + protocole qui se trouvent au début de chaque paquet. Les filtres de + paquet à suivi d'états (dont Netfilter est un exemple) utilisent une + combinaison du contenu de l'entête et de l'état de la connexion créé + lors du traitement de paquets précédents. Netfilter (et l'usage qui en + est fait par Shorewall) prend également en compte l'interface réseau sur + laquelle chaque paquet est entré ou sur laquelle le paquet va quitter le + routeur/firewall. + + Lorsque vous spécifiez un nom de domaine dans une + règle Shorewall, le programme iptables résout ce nom en une ou + plusieurs adresses IP et les véritables règles qui seront créées sont + exprimées avec ces adresses IP. C'est pourquoi la règle que vous avez + entrée est équivalente à: + + #ACTION SOURCE DEST PROTO +REJECT fw net:216.239.37.99 all +REJECT fw net:216.239.39.99 allSachant que + l'hébergement multiple basé sur le nom d'hôte est une pratique courante + (par exemple, lists.shorewall.net et www1.shorewall.net sont hébergés + tous les deux sur le même système avec un seule adresse IP), il n'est + pas possible de filtrer les connexions vers un nom particulier au seul + examen des entêtes de protocole. Alors que certains protocoles tels que + FTP nécessitent que le firewall examine et + éventuellement modifie les données (payload) du paquet, analyser les + données de paquets individuellement ne fonctionne pas toujours car le + flux de données de niveau applicatif peut être fractionné de manière + arbitraire entre les paquets. Ceci est une des faiblesses de l'extension + 'string match' de Netfilter que l'on trouve dans le Patch-O-Matic. Le + seul moyen sûr pour filtrer sur le contenu des paquets est d'utiliser un + proxy pour les connexions concernées -- dans le cas de HTTP, on pourra + utiliser une application telle que Squid. Lorsqu'on utilise un + proxy, celui-ci ré-assemble des messages complets de niveau applicatif + qui peuvent alors être analysés de manière précise. +
+ +
+ (FAQ 42) Comment connaitre quelles sont les fonctions supportées + par mon noyau et ma version d'iptables? + + Réponse: En tant que root, + utilisez la commande shorewall show + capabilities. + + gateway:~# shorewall show capabilities +Loading /usr/share/shorewall/functions... +Processing /etc/shorewall/params ... +Processing /etc/shorewall/shorewall.conf... +Loading Modules... +Shorewall has detected the following iptables/netfilter capabilities: + NAT: Available + Packet Mangling: Available + Multi-port Match: Available + Extended Multi-port Match: Available + Connection Tracking Match: Available + Packet Type Match: Available + Policy Match: Available + Physdev Match: Available + IP range Match: Available + Recent Match: Available + Owner Match: Available + Ipset Match: Available + ROUTE Target: Available + Extended MARK Target: Available + CONNMARK Target: Available + Connmark Match: Available + Raw Table: Available +gateway:~# +
+
+