Réponse: Allez voir les guides de démarrage rapide.

Réponse:

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.

Réponse: Lisez les Instructions d'installation!

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.

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.

#ACTION    SOURCE   DEST                PROTO    DEST PORT
DNAT       net      loc:192.168.1.3:22  tcp      1022

#ACTION    SOURCE   DEST                PROTO    DEST PORT(S)    SOURCE      ORIGINAL
#                                                                PORT        DEST                 
DNAT       loc      dmz:192.168.2.4     tcp      80              -           206.124.146.176

ETH0_IP=`find_interface_address eth0`       

ETH0_IP=`find_first_interface_address eth0`

#ACTION    SOURCE        DEST               PROTO    DEST PORT   SOURCE    ORIGINAL
#                                                                PORT      DEST.
DNAT       loc           dmz:192.168.2.4    tcp      80          -         $ETH0_IP

#ACTION SOURCE  DEST                    PROTO   DEST PORT(S)
DNAT    net     fw:192.168.1.1:22       tcp     4104

Réponse: 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. Vous utiliserez également des règles DNAT si vous voulez ré-écrire l'adresse IP ou le numéro de port destination. 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.

Réponse: Ian Allen a écrit cet article au sujet de la DNAT et Linux.

Réponse: Vous pouvez voir Shorewall et Squid.

Réponse: j'ai deux objections à cette configuration.

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:

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

#ZONE    INTERFACE    BROADCAST       OPTIONS
dmz      eth2         192.168.2.255   routeback 

#INTERFACE    SUBNETS     ADDRESS
eth2          eth2        192.168.2.254

#ACTION    SOURCE   DEST                PROTO    DEST PORT(S)    SOURCE      ORIGINAL
#                                                                PORT        DEST                 
DNAT       loc      dmz:192.168.2.4     tcp      80              -           206.124.146.176

ETH0_IP=`find_first_interface_address eth0`  

#ACTION    SOURCE        DEST               PROTO    DEST PORT   SOURCE    ORIGINAL
#                                                                PORT      DEST.
DNAT       loc           dmz:192.168.2.4    tcp      80          -         $ETH0_IP

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:

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.

Réponse: Aucune personne ayant installé Shorewall en utilisant un des Guides de Démarrage Rapide ne devrait avoir à poser cette question.

Quel que soit le guide que vous avez utilisé, toutes les communications sortantes sont ouvertes par défaut. Vous n'avez donc pas à "ouvrir de port" en sortie.

En entrée:

Voyez également la section Transfert de Ports de cette FAQ.

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 la macro Auth (définie dans le fichier /usr/share/shorewall/macro.Auth) qui spécifie l'action REJECT (c.a.d., Auth/REJECT). 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.

Réponse: Allez voir cette contribution de Michael Cooke.

Réponse: Pour une description complète de la gestion du « ping » par Shorewall, voyez cette page.

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:

Réponse: Voir la page Shorewall et FTP.

Réponse: Très probablement, il vous faudra mettre CLAMPMSS=Yes dans le fichier /etc/shorewall/shorewall.conf.

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.

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é.

#ACTION   SOURCE    DEST    PROTO    DEST PORT(S)
DROP      net       fw      udp      10619

#ADDRESS/SUBNET         PROTOCOL        PORT
-                       udp             10619

MAC=00:04:4c:dc:e2:28:00:b0:8e:cf:3c:4c:08:00

Réponse:

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):

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

ACCEPT dmz loc udp 53

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é de IP. 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.

J'ai blacklisté l'adresse 130.252.100.59 avec la commande shorewall drop 130.252.100.59 mais je vois toujours ces messages dans le journal:

Jan 30 15:38:34 server Shorewall:net_dnat:REDIRECT:IN=eth1 OUT= MAC=00:4f:4e:14:97:8e:00:01:5c:23:24:cc:08:00
                       SRC=130.252.100.59 DST=206.124.146.176 LEN=64 TOS=0x00 PREC=0x00 TTL=43 ID=42444 DF
                       PROTO=TCP SPT=2215 DPT=139 WINDOW=53760 RES=0x00 SYN URGP=0

Réponse: Veuillez vous référer à Shorewall Netfilter Documentation. La journalisation des règles REDIRECT et DNAT se produit dans la chaîne PREROUTING de la table nat dans laquelle l'adresse est toujours valide. Le blacklistage se produit dans les chaînes INPUT et FORWARD de la table filter qui ne sont traversées que plus tard.

Réponse: Non. Ceci se produit lorsque shorewall teste votre système pour déterminer les fonctions qu'il supporte. Ils ne présentent aucun risque.

Réponse: voir cet article sur Shorewall et le routage.

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):

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.

Réponse: 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 ».

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.

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.

Réponse: 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).

Réponse: 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).

Mettez votre matériel à niveau. De nombreux utilisateurs ont constaté que même une amélioration modeste de la CPU et de la vitesse de la mémoire (par exemple passer d'un P3 avec de la SDRAM à un P4 avec de la DDR) avait des effets très significatifs. Les CPU dotées de la technologie EM64T, aussi bien celles d'AMD que celles d'Intel, montrent des performances de redémarrage très acceptables, même si vous avez un jeu de règles assez complexe.

Shorewall offre également une fonction de démarrage rapide. Pour l'utiliser:

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.

Finalement, le temps pendant lequel les nouvelles connexions sont bloquées durant le redémarrage de Shorewall peut être réduit dans de très grande proportions en upgradant vers Shorewall 3.2 ou une version ultérieure. A partir de la 3.2, shorewall [re]start procède en deux étapes:

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.

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.

Réponse: Copiez /usr/share/shorewall/modules (ou /usr/share/shorewall/xmodules suivant le cas) vers /etc/shorewall/modules et modifiez cette copie pour qu'elle ne contienne que les modules dont vous avez besoin.

Réponse: Votre version d'iptables est incompatible avec votre kernel.

Réponse: La documentation Multi-ISP vous recommande très fortement d'utiliser l'option d'équilibrage (balance) pour tous les FAIs même si vous voulez spécifier manuellement quel FAI utiliser. Si vous ne le faites pas et que votre table principale de routage n'a qu'une seule route par défaut, vous devez désactiver le filtrage de route. Ne spécifiez pas l'option routefilter sur l'autre interface dans /etc/shorewall/interfaces et désactivez toute protections contre le spoofing d'adresses IP que votre distribution pourrait offrir.

Réponse: Supposez que vous vouliez que tout le trafic passe par le FAI1 (mark 1) jusqu'à ce que vous spécifiez différemment. Dans ce cas, ajoutez simplement ces deux règles comme premières règles de marquage dans votre fichier /etc/shorewall/tcrules:

#MARK         SOURCE           DEST
1:P           0.0.0.0/0
1:P           $FW
<other MARK rules>

Maintenant, tout le trafic qui n'est pas marqué par une de vos autres règles de marquage aura mark=1 et sera envoyé par le FAI1. Ceci fonctionnera que l'option balance soit spécifiée ou pas.

Réponse: Shorewall fonctionnera sur n'importe quelle distribution GNU/Linux distribution réunissant les pré-requis Shorewall indiqués dans ce document.

Réponse: voir la liste des caractéristiques de Shorewall.

Réponse: Oui. Webmin offre le support de Shorewall 3.x à partir dans sa version 1.300. Voir http://www.webmin.com

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 ».

Réponse: 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.

Réponse: A l'invite du système, tapez:

/sbin/shorewall[-lite] version      

Réponse: Shorewall fonctionne avec les noyaux 2.6 avec les deux restrictions suivantes:

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: 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

#SUBNET        TARGET
192.168.100.1  RETURN
192.168.100.2  RETURN

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 

#INTERFACE         SUBNET          ADDRESS
eth0               eth1                        # eth1 = interface to local network

Réponse: Oui. Voyez Shorewall et les interfaces aliasées.

Réponse: Shorewall Lite est un produit partenaire de Shorewall. Il est conçu pour vous permettre de maintenir les informations de toutes vos configurations de Shorewall sur un seul système dans votre réseau. Pour plus de détails, voir Compiled Firewall script documentation.

Réponse: Non. En fait, nous recommandons que vous n'installiez pas Shorewall sur les systèmes sur lesquels vous souhaitez utiliser Shorewall Lite. Vous devez avoir installé Shorewall sur au moins un des systèmes de votre réseau pour pouvoir utiliser Shorewall Lite.

Réponse: Si vous prévoyez d'avoir un seul firewall, Shorewall est le choix logique. Je pense aussi que Shorewall est le choix le plus approprié pour un portable car vous pouvez avoir à changer sa configuration lorsque vous êtes en déplacement. Dans tous les autres cas, Shorewall Lite fonctionnera très bien. A shorewall.net, les deux portables ainsi que mon ordinateur de bureau linux sont installés avec la version complète de Shorewall. Tous les autres systèmes Linux qui ont un firewall utilisent Shorewall Lite et leurs répertoires de configuration sont sur mon ordinateur de bureau.

Réponse: Voir le tableau ci-dessous (C = Complètement compatible avec toutes les fonctionnalités disponibles, P1 = Compatible mais la totalité des fonctions de Shorewall ne sont pas disponibles, P2 = Compatible mais la totalité des fonctions de Shorewall Lite ne sont pas disponibles, I = incompatible).

Réponse : 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.

Réponse : 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>,...

ACCEPT net:192.0.2.16/28,192.0.2.44 fw tcp 22

Réponse : Retirez temporairement les règles rejNotSyn, dropNotSyn and dropInvalid du fichier /etc/shorewall/rules et relancez Shorewall.

Réponse : 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.

+ 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 : Le support Shorewall pour les ponts filtrant existe — voir ici pour les détails.

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.99

Et celles-ci pour google.com:

216.239.37.99
216.239.39.99
216.239.57.99

Je 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    all

Sachant 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 application 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-ng. 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.

Réponse: En tant que root, utilisez la commande shorewall[-lite] 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:~#

Réponse : Ajoutez ces deux politiques:

#SOURCE            DESTINATION             POLICY            LOG              LIMIT:BURST
#                                                            LEVEL
$FW                loc                     ACCEPT
loc                $FW                     ACCEPT           

Vous pouvez également supprimer toutes les règles ACCEPT de $FW->loc et loc->$FW car ces règles sont maintenant redondantes avec les deux politiques fixées ci-dessus.