Copyright © 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 ».
2007/08/08
Table des matières
Notes du traducteur : Si vous trouvez des erreurs ou si vous avez des améliorations à apporter à cette traduction 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.
Réponse: Allez voir les guides de démarrage rapide.
Réponse:
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
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.
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 FAQ 2 ).
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.
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[-lite] 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.
Si le nombre de paquets est différent de zéro, vérifiez dans votre log si la connexion est droppée ou rejetée. Si c'est le cas, il est possible que vous ayez un problème de définition de zone qui fasse que le serveur soit dans une zone différente de ce qui est spécifié dans la colonne DEST. A l'invite root, tapez "shorewall[-lite] show zones" et assurez-vous que vous avez bien spécifié dan la colonne DEST la première zone de la liste qui correspond à OUT=<dev> et DEST=<ip> dans le message REJECT/DROP de votre fichier log.
Réponse:Dans le fichier
/etc/shorewall/rules:
#ACTION SOURCE DEST PROTO DEST PORT DNAT net loc:192.168.1.3:22 tcp 1022
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
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, si vous configurez SSHD pour qu'il n'écoute que sur cette interface et que vous ajoutez 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
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.
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! Ce qui fait que les logs d'accès du serveur seront inutilisables pour déterminer quels hôtes locaux accèdent au serveur.
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.
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=0Ré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 1. 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.
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
Avec des adresses IP dynamiques, vous n'utiliserez pas shorewall[-lite] save ni shorewall[-lite] restore.
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.
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:
Si vous avez installé en utilisant le guide Firewall Monoposte (une interface), relisez cette section SVP.
Si vous avez utilisé le guide Firewall à deux interfaces pour installer merci de relire ces sections: Transfert de ports (DNAT), et Autres connexions
Si vous avez utilisé le guide Firewall à trois interfaces pour installer merci de relire ces sections: Transfert de ports (DNAT) et Autres Connexions
Si vous avez installé en utilisant le Guide de configuration Shorewall vous feriez mieux de lire le guide à nouveau -- vous avez vraiment raté beaucoup de choses.
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: 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.
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.
Answer: Vous trouverez ici la description d'une bonne intégration de Shorewall et PortSentry.
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:
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.
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é.
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.
Réponse: Ajoutez temporairement la règle suivante:
#ACTION SOURCE DEST PROTO DEST PORT(S) DROP net fw udp 10619
Sinon, si vous ne mettez pas le paramètre BLACKLIST_LOGLEVEL et
que vous avez spécifié l'option 'blacklist' sur votre interface
externe dans le fichier
/etc/shorewall/interfaces, vous pouvez
blacklister le port. Dans le fichier
/etc/shorewall/blacklist:
#ADDRESS/SUBNET PROTOCOL PORT - udp 10619
Réponse: 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 2. 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)
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).
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):
L'adresse destination est listée dans le fichier
/usr/share/shorewall/rfc1918 avec une cible
logdrop -- voir /usr/share/shorewall/rfc1918.
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.
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.
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.
A partir de Shorewall 3.3.3, les paquets loggés par ces chaines peuvent avoir une source et/ou une destination n'appartenant à aucune zone définie (voir le résultat de la commande shorewall[-lite] show zones). Souvenez-vous que l'appartenance à une zone nécessite à la fois une interface du firewall et une adresse ip.
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.
Ce paquet a été journalisé par l'option d'interface maclist .
Ce paquet a été journalisé par l'option d'interface logunclean.
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
.
Ce paquet a été journalisé parce que l'adresse IP source est
inscrite dans la liste noire /etc/shorewall/blacklist.
Ce paquet a une adresse IP source qui n'est définie dans
aucune de vos zones (« shorewall[-lite] show
zones » 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
.
A partir de 3.3.3, de tels paquets peuvent aussi être loggés par les chaines <zone>2all et all2all.
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).
A partir Shorewall 3.3.3, de tels paquets peuvent aussi être loggés par les chaines fw2all et all2all.
Ce paquet a été journalisé parce qu'il a échoué aux contrôles mis en oeuvre par l'option d'interface tcpflags.
Exemple 3. 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=47Examinons les partie importantes de ce message:
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).
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.
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.
Ce paquet a été envoyé par 192.168.2.2
Ce paquet a pour destination 192.168.1.3
Le protocole est UDP
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
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=0Ré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.
modprobe: Can't locate module ipt_physdev modprobe: Can't locate module iptable_raw
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):
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.
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 ipchainsPar 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.
Réponse: Ceci se traite en général avec la séquence de commandes présentée ci-dessus dans la la section intitulée « (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? ».
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:
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.
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:
La configuration courante est compilée afin de produire un programme shell conçu pour votre configuration.
Si la compilation se déroule sans erreur, le programme compilé est exécuté pour [re]démarrer votre firewall.
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.
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.
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.
recompilez iptables en utilisant les headers de votre nouveau kernel; ou bien
si vous n'avez pas besoin du support de "policy match" (vous
n'utilisez pas l'implémentation IPSEC du kernel 2.6) vous pouvez
renommer /lib/iptables/libipt_policy.so.
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: Oui.
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.
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.
Réponse: Oui lorsque l'option d'interface routefilter est sélectionnée.
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.
Réponse: Shorewall fonctionne avec les noyaux 2.6 avec les deux restrictions suivantes:
Dans les noyaux 2.6 jusqu'au 2.6.16, 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.
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
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
Réponse: La solution est la même que dans la FAQ 14 présentée au-dessus. Substituez-y simplement l'adresse du serveur DHCP de votre FAI.
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!
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).
| Shorewall Lite 3.2.0 | Shorewall Lite 3.2.1 | Shorewall Lite 3.2.2 | Shorewall Lite 3.2.3 | |
|---|---|---|---|---|
| Shorewall 3.2.0 | C | C | P2 | P2 |
| Shorewall 3.2.1 | C | C | C | P2 |
| Shorewall 3.2.2 | P1 | P1 | C | C |
| Shorewall 3.2.3 | P1 | P1 | C | C |
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>,...
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.
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.
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.