shorewall-docs-xml-5.0.15/0000755000000000000000000000000013020331007014011 5ustar rootrootshorewall-docs-xml-5.0.15/Anti-Spoofing.xml0000644000000000000000000001110313020330134017204 0ustar rootroot
Countering Spoofing Attempts Tom Eastep 2012 Thomas M. Eastep 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.
Introduction Spoofing is the practice of sending packets with a forged source address in an attempt to circumvent security measures. Shorewall supports a variety of measures to counter spoofing attacks.
The <emphasis>routefilter</emphasis> Interface Option This shorewall-interfaces (5) option was the first measure implemented and uses /proc/sys/net/ipv4/conf/*/rp_filter. Many distributions set this option by default for all ip interfaces. The option works by determining the reverse path (the route from the packets destination to its source); it that route does not go out through the interface that received the packet, then the packet is declared to be a martian and is dropped. A kernel log message is generated if the interface's option is set (/proc/sys/net/ipv4/conf/*/log_martians). While this option is simple to configure, it has a couple of disadvantages: It is not supported by IPv6. It does not use packet marks so it doesn't work with some Multi-ISP configurations. The log messages produces are obscure and confusing.
Hairpin Filtering Spoofing can be used to exploit Netfilter's connection tracking to open arbitrary firewall ports. Attacks of this type establish a connection to a server that uses separate control and data connections such as an FTP server. It then sends a packet addressed to itself and from the server. Such packets are sent back out the same interface that received them (hairpin). In cases where the option can't be used, Shorewall 4.4.20 and later will set up hairpinning traps (see the SFILTER_DISPOSITION and SFILTER_LOG_LEVEL options in shorewall.conf (5)). This automatic hairpin trapping is disabled on interfaces with the option.
The <emphasis>rpfilter</emphasis> Interface Option A new iptables/ip6tables match (rpfilter) was added in kernel 3.4.4. This match performs reverse path evaluation similar to but without the disadvantages: It is supported by both IPv4 and IPv6. It uses packet marks so it works with all Multi-ISP configurations. It produces standard Shorewall/Netfilter log messages controlled by the RPFILTER_LOG_LEVEL option in shorewall.conf (5)). Both the disposition and auditing can be controlled using the RPFILTER_DISPOSITION option in shorewall.conf (5)).
shorewall-docs-xml-5.0.15/Install_fr.xml0000644000000000000000000007203113020330134016633 0ustar rootroot
Installation et mise à jour de Shorewall Version française de Shorewall Installation and Upgrade Tom Eastep Guy Marcenac Adaptation française 2001- 2007 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 traduction vous pouvez me contacter. Cet article s'applique à Shorewall 3.0 et à ses versions ultérieures. Si vous êtes en train d'installer ou de mettre à jour vers une version antérieure à Shorewall 3.0.0, merci de vous référer à la documentation de cette version. Avant de vous lancer dans l'installation, je vous encourage vivement à lire et à imprimer une copie du guide pratique présenté dans Shorewall QuickStart et décrivant la configuration la plus proche de la votre. Avant toute mise à jour, assurez-vous d'avoir passé en revue les problèmes de mise à jour. Les RPM Shorewall sont signés. Pour éviter d'avoir des avertissements tels que le suivantwarning: shorewall-3.2.1-1.noarch.rpm: V3 DSA signature: NOKEY, key ID 6c562ac4 téléchargez la clé GPG Shorewall puis exécutez cette commande: rpm --import shorewall.gpg.key
Installation avec un RPM Pour installer Shorewall avec un RPM: Assurez-vous d'avoir le paquetage RPM adéquat! On sait que le paquetage RPM standard de shorewall.net et des miroirs fonctionne avec SUSE, Power PPC, Trustix et TurboLinux. Il existe un paquetage fourni par Simon Matter construit pour RedHat/Fedora ainsi qu'un autre paquetage de Jack Coates adapté pour Mandriva. Il sont tous disponibles sur la page de téléchargement. Si vous tentez d'installer le mauvais paquetage, il ne fonctionnera probablement pas. Si vous installez Shorewall 4.0.0 ou une version ultérieure, vous aurez besoin d'installer au moins deux paquetages. Soit vous installerez Shorewall-shell (le compilateur de configuration classique basé sur le shell) et/ou Shorewall-perl (Le compilateur écrit en perl, plus récent et plus rapide). Shorewall-common Si c'est la première fois que vous installez Shorewall, nous vous recommandons vivement d'installer Shorewall-perl. Installer les RPMs rpm -ivh <compiler rpm> ... <shorewall-common rpm> Certains utilisateurs ont l'habitude d'utiliser la commande rpm -U pour installer et pour mettre à jour leurs paquetages. Si vous utilisez cette commande pour installer le RPM Shorewall vous devrez activer manuellement le lancement de Shorewall au démarrage en utilisant chkconfig, insserv ou l'utilitaire que vous utilisez pour manipuler les liens symboliques pour init. Certains utilisateurs SUSE ont rencontré un problème dans lequel le rpm signale un conflit avec un noyau de version <= 2.2 alors qu'un noyau 2.4 est installé. Si ceci se produit, utilisez simplement l'option rpm --nodeps. rpm -ivh --nodeps <rpms> Shorewall dépend du paquetage iproute. Malheureusement, certaines distribution nomment ce paquetage iproute2 ce qui provoque un échec de l'installation de Shorewall avec le diagnostic suivant: error: failed dependencies:iproute is needed by shorewall-3.2.x-1 Ce problème ne devrait pas survenir si vous utilisez le bon paquetage RPM (voir 1., ci-dessus), mais il peut être contourné en utilisant l'option --nodeps de rpm. rpm -ivh --nodeps <rpms> Exemple:rpm -ivh shorewall-perl-4.0.0-1.noarch.rpm shorewall-common-4.0.0-1.noarch.rpm Simon Matter nomme 'shorewall' son rpm 'common' au lieu de 'shorewall-common'. C'est pourquoi, si vous installez ses RPMs, la commande à utiliser sera:rpm -ivh shorewall-perl-4.0.0-1.noarch.rpm shorewall-4.0.0-1.noarch.rpm Éditez les fichiers de configuration pour qu'ils correspondent à votre configuration. VOUS NE POUVEZ PAS SIMPLEMENT INSTALLER LE RPM ET LANCER UNE COMMANDE shorewall start. UN MINIMUM DE CONFIGURATION EST NÉCESSAIRE AVANT QUE VOTRE FIREWALL NE DÉMARRE. SI VOUS EXÉCUTEZ UNE COMMANDE start ET QUE LE LANCEMENT DU FIREWALL ÉCHOUE, VOTRE SYSTÈME N'ACCEPTERA PLUS AUCUN TRAFIC RÉSEAU. SI CELA SE PRODUIT, EXÉCUTEZ LA COMMANDE shorewall clear POUR RÉTABLIR LA CONNECTIVITÉ RÉSEAU. Activez le démarrage de shorewall en éditant le fichier /etc/shorewall/shorewall.conf et mettez STARTUP_ENABLED à Yes). Lancez le firewall avec shorewall start
Installer avec le fichier tarball Si vous installez Shorewall 4.0.0 ou une version ultérieure, vous aurez besoin d'installer au moins deux paquetages. Soit vous installerez Shorewall-shell (le compilateur de configuration classique basé sur le shell) et/ou Shorewall-perl (Le compilateur écrit en perl, plus récent et plus rapide). Shorewall-common Si c'est la première fois que vous installez Shorewall, nous vous recommandons vivement d'installer Shorewall-perl. Pour installer Shorewall-perl et Shorewall-common avec le tarball et le script d'installation: Décompressez les tarballs:tar -jxf shorewall-common-4.0.0.tar.bz2 tar -jxf shorewall-perl-4.0.0.tar.bz2 Allez dans le répertoire shorewall-perl (la version est codée dans le nom de répertoire comme par exemple dans shorewall-perl-4.0.0). Tapez: ./install.sh Allez dans le répertoire shorewall-common (la version est codée dans le nom de répertoire comme par exemple dans shorewall-common-4.0.0). Tapez: ./install.sh Éditez les fichiers de configuration pour qu'ils correspondent à votre configuration. Activez le démarrage de shorewall en éditant le fichier /etc/shorewall/shorewall.conf et en y mettant STARTUP_ENABLED=Yes. Lancez le firewall avec shorewall start Si le script d'installation n'a pas réussi à configurer Shorewall pour qu'il soit lancé automatiquement au démarrage du système, allez voir ces instructions.
Installer avec le .deb Après avoir installé les paquetages .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. Le façon la plus simple d'installer Shorewall sur Debian est d'utiliser apt-get: apt-get install shorewall Pour être certain d'installer la dernière version de Shorewall, vous devriez modifier votre fichier /etc/apt/preferences Package: shorewall Pin: release o=Debian,a=testing Pin-Priority: 700 Package: shorewall-doc Pin: release o=Debian,a=testing Pin-Priority: 700Puis exécutez# apt-get update # apt-get install shorewall Lorsque vous avez fini de configurer Shorewall, vous pouvez activer son lancement au démarrage du système en positionnant startup=1 dans le fichier /etc/default/shorewall.
Observations générales sur les mises à jour de Shorewall La plupart des problèmes de mise à jour ont pour cause: L'utilisateur n'a pas lu et suivi les considération de migration présentées dans les notes de mise à jour (release notes) (ces notes sont aussi reproduites dans le document Shorewall Upgrade Issues). L'utilisateur a mal géré son fichier /etc/shorewall/shorewall.conf durant la mise à niveau. Shorewall est conçu pour permettre à son comportement par défaut d'évoluer dans le temps. Pour que ce la soit possible, il est supposé de conception que vous ne remplacerez pas votre fichier shorewall.conf lors des mises à jour. Il est donc recommandé de modifier votre fichier /etc/shorewall/shorewall.conf après la première installation de shorewall de façon à empêcher votre gestionnaire de paquets de l'écraser lors de mises à jour ultérieures (même pour l'ajout de STARTUP_ENABLED, une telle modification est garantie puisque vous devez changer son paramètrage manuellement). Si vous vous sentez vraiment tenu d'avoir les derniers commentaires et options dans votre fichier shorewall.conf, vous devrez procéder très prudemment. Vous devrez déterminer quelles nouvelles options ont été introduites. Vous devrez réinitialiser la valeur de ces nouvelles options (par exemple OPTION=""), sinon, vous obtiendrez un comportement différent de celui auquel vous vous attendez.
Mise à jour avec un RPM Si le RPM Shorewall est déjà installé et que vous mettez à jour vers une nouvelle version: Assurez-vous d'avoir le bon paquetage RPM! On sait que le paquetage RPM standard de shorewall.net et des miroirs fonctionne avec SUSE, Power PPC, Trustix et TurboLinux. Il existe un paquetage fourni par Simon Matter construit pour RedHat/Fedora ainsi qu'un autre paquetage de Jack Coates adapté pour Mandriva. Si vous tentez d'installer le mauvais paquetage, il ne fonctionnera probablement pas. Simon Matter nomme 'shorewall' son rpm 'common' au leu de 'shorewall-common'. Si vous faites une mise à jour depuis une version 2.x or 3.x vers une version 4.x, vous trouverez des instructions spécifiques pour les problèmes de mise à jour. Procédez à la mise à jour rpm -Uvh <compiler rpm file> ... <shorewall-common rpm file> Certains utilisateur de SUSE ont rencontré un problème dans lequel rpm signale un conflit avec un noyau de version <= 2.2 alors qu'un noyau 2.4 est installé. Si ceci vous arrive, vous pouvez simplement utiliser l'option --nodeps de rpm. rpm -Uvh --nodeps <shorewall-common rpm> <compiler rpm> ... Shorewall dépend du paquetage iproute. Malheureusement, certaines distributions nomment ce paquetage iproute2 ce qui provoquera un échec de la mise à jour avec le diagnostic suivant: error: failed dependencies:iproute is needed by shorewall-3.2.1-1 Ceci peut être contourné en utilisant l'option --nodeps de rpm. rpm -Uvh --nodeps <shorewall rpm> <compiler-rpm> ... Contrôlez si il existe des incompatibilités entre votre configuration et votre nouvelle version de Shorewall et corrigez quand cela est nécessaire. shorewall check Redémarrez le firewall. shorewall restart
Mise à niveau avec le tarball Si vous faites une mise à jour depuis une version 2.x or 3.x vers une version 4.x, vous trouverez des instructions spécifiques pour les problèmes de mise à jour. Si Shorewall est déjà installé et que vous procédez à une mise à jour de version avec le tarball: Décompressez les tarballs:tar -jxf shorewall-common-4.0.0.tar.bz2 tar -jxf shorewall-perl-4.0.0.tar.bz2 tar -jxf shorewall-shell-4.0.0.tar.bz2 (if you use this compiler) Allez dans le répertoire shorewall-perl (la version est codée dans le nom de répertoire comme par exemple dans shorewall-perl-4.0.0). Tapez: ./install.sh Effectuez les deux étapes ci-dessus pour le répertoire shorewall-shell si vous utilisez ce compilateur. Allez dans le répertoire shorewall-common (la version est codée dans le nom de répertoire comme par exemple dans shorewall-common-4.0.0). Tapez: ./install.sh Contrôlez si il existe des incompatibilités entre votre configuration et votre nouvelle version de Shorewall et corrigez quand cela est nécessaire. shorewall check Lancez le firewall avec shorewall start Si le script d'installation n'a pas réussi à configurer Shorewall pour un démarrage automatique au boot du système, reportez-vous à ces instructions.
Mettre à jour avec le .deb Lorsque le programme d'installation vous demande sir vous voulez remplacer le fichier de configuration /etc/shorewall/shorewall.conf par la nouvelle version, nous vous recommandons très fortement de refuser. Voir ci-dessus.
Mettre à jour avec le .lrp Ceci est une contribution de Charles Steinkuehler postée sur la liste de diffusion Leaf:
c'est *TRÈS* simple... mettez un nouveau CD et redémarrez le système :-) En réalité, je ne plaisante que très peu... c'est exactement de cette manière que je mets à jour mes firewall de production. La fonction de sauvegarde partielle que j'ai ajoutée à Dachstein permet de stocker séparément les données de configuration et le reste du paquetage. Une fois les données de configuration séparées du reste du paquetage, il devient facile de procéder à la mise à jour du paquetage en conservant votre configuration courante (dans mon cas, il me suffit d'insérer un nouveau CD et de rebooter). L'idée générale est d'utiliser un backup partiel pour sauvegarder votre configuration, de remplacer le paquetage, puis de restaurer vos anciens fichiers de configuration. Les instructions pas-à-pas données ci-après proposent une manière d'y parvenir (on suppose l'utilisation d'un système LEAF conventionnel sur une seule disquette): Faites une copie de sauvegarde de votre disquette firewall ('NEW'). C'est sur cette disquette que vous allez ajouter le(s) paquetage(s) à jour. Formattez une disquette que vous utiliserez comme emplacement temporaire pour vos fichiers de configuration ('XFER'). Cette disquette devrait avoir le même format que votre disquette firewall (une autre copie de sauvegarde de votre disquette firewall ferait très bien l'affaire). Assurez-vous de disposer d'une copie fonctionnelle de votre firewall existant ('OLD') dans un endroit sûr, et que vous N'UTILISEREZ PAS PENDANT ce processus. De cette façon, si quoi que ce soit se passait mal, vous pourriez simplement rebooter avec cette disquette OLD pour revenir à une configuration fonctionnelle. Retirez la disquette firewall courante et remplacez-la par la disquette XFER. Utilisez le menu de sauvegarde de lrcfg pour réaliser un backup partiel du(des) paquetage(s) que vous voulez mettre à jour en vous assurant de sauvegarder les fichiers sur la disquette XFER. Dans le menu de sauvegarde: t e <enter> p <enter> b <package1> <enter> b <package2> <enter> ... Téléchargez et copiez le(s) paquetage(s) que vous voulez mettre à jour sur la disquette NEW Rebootez votre firewall en utilisant la disquette NEW... à ce point du processus, les paquetages que vous mettez à jour sont avec leur configuration par défaut. Montez la disquette XFER (mount -t msdos /dev/fd0u1680 /mnt) Allez dans le répertoire racine (cd /) Extrayez manuellement les données de configuration de chaque paquetage que vous avez mis à jour: tar -xzvf /mnt/package1.lrp tar -xzvf /mnt/package2.lrp ... Démontez (umount /mnt) puis retirez la disquette XFER En utilisant lrcfg, faites une sauvegarde COMPLÈTE de vos paquetages mis à jour. Rebootez et vérifiez que le firewall fonctionne comme prévu. Il peut être nécessaire d'ajuster certains fichiers de configuration pour qu'ils fonctionnent convenablement avec les nouveaux binaires. On peut utiliser le nouveau fichier de paquetage <paquetage>.local pour fixer précisément quels fichiers du backup partiel seront inclus ou pas (pour plus détails se reporter au Dachstein-CD README). Si ce fichier n'existe pas, le script de backup suppose que tous les fichiers de <paquetage>.list qui résident dans /etc ou dans /var/lib/lrpkg font partie de la configuration et sont utilisés pour créer le backup partiel. Si Shorewall installe quoi que ce soit dans /etc qui ne soit pas un fichier de configuration modifié par l'utilisateur, un fichier shorewall.local approprié devrait être créé avant de faire le backup partiel [Remarque de l'éditeur: Shorewall ne place dans /etc/ que des fichiers modifiables par l'utilisateur]. Il est évidemment possible de réaliser tout cela 'sur-place', sans utiliser plusieurs disquettes, et même sans faire de backup partiel (c.a.d. copier les fichiers de configuration courants dans /tmp, extraire manuellement le nouveau paquetage sur le firewall en cours d'exécution, copier et fusionner les données de configuration depuis /tmp et du backup... ou autre), mais quiconque est capable de cette gymnastique en ligne de commande le fait sans doute déjà, sans avoir besoin d'instructions détaillées! :-)
Pour des informations concernant d'autres outils de mise à jour LEAF/Bering, consultez cet article de Alex Rhomberg.
Configurer Shorewall Vous devrez éditer certains voire la totalité des fichiers de configuration pour obtenir la configuration que vous souhaitez. Dans la plupart des cas, les guides de démarrage rapide shorewall contiennent toute l'information dont vous aurez besoin.
Désinstaller / Revenir à la version antérieure Voir Fallback and Uninstall.
shorewall-docs-xml-5.0.15/PPTP.xml0000644000000000000000000004744613020330134015335 0ustar rootroot
PPTP - Unmaintained Tom Eastep 2001 2002 2003 2004 2005 2006 2007 Thomas M. Eastep 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. Shorewall easily supports PPTP in a number of configurations. I have not used PPTP in years and as a consequence, this document is no longer maintained (any volunteers?). As far as I know, the information regarding Shorewall configuration is still valid but the configurations shown for for the other components may no longer work. For the most part, they show configuration files that I used when I worked for Compaq and used PPTP as my work VPN.
Preliminary Reading I recommend reading the VPN Basics article if you plan to implement any type of VPN.
PPTP Server Running on your Firewall
Configuring Samba You will need a WINS server (Samba configured to run as a WINS server is fine). Global section from /etc/samba/smb.conf on my WINS server (192.168.1.3) is: [global] workgroup = TDM-NSTOP netbios name = WOOKIE server string = GNU/Linux Box encrypt passwords = Yes log file = /var/log/samba/%m.log max log size = 0 socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192 os level = 65 domain master = True preferred master = True dns proxy = No wins support = Yes printing = lprng [homes] comment = Home Directories valid users = %S read only = No create mask = 0664 directory mask = 0775 [printers] comment = All Printers path = /var/spool/samba printable = Yes
Configuring pppd Here is a copy of my /etc/ppp/options.poptop file: ipparam PoPToP lock mtu 1490 mru 1490 ms-wins 192.168.1.3 ms-dns 206.124.146.177 multilink proxyarp auth +chap +chapms +chapms-v2 ipcp-accept-local ipcp-accept-remote lcp-echo-failure 30 lcp-echo-interval 5 deflate 0 mppe-128 mppe-stateless require-mppe require-mppe-stateless System 192.168.1.3 acts as a WINS server so I have included that IP as the ms-wins value. I have pointed the remote clients at my DNS server -- it has external address 206.124.146.177. I am requiring 128-bit stateless compression. Here's my /etc/ppp/chap-secrets: Secrets for authentication using CHAP # client server secret IP addresses CPQTDM\\TEastep * <shhhhhh> 192.168.1.7 TEastep * <shhhhhh> 192.168.1.7 I am the only user who connects to the server but I may connect either with or without a domain being specified. The system I connect from is my laptop so I give it the same IP address when tunneled in at it has when I use its wireless LAN card around the house. You will also want the following in /etc/modules.conf: alias ppp-compress-18 ppp_mppe alias ppp-compress-21 bsd_comp alias ppp-compress-24 ppp_deflate alias ppp-compress-26 ppp_deflate
Configuring pptpd PoPTop (pptpd) is available from http://www.poptop.org/. Here is a copy of my /etc/pptpd.conf file: option /etc/ppp/options.poptop speed 115200 localip 192.168.1.254 remoteip 192.168.1.33-38 I specify the /etc/ppp/options.poptop file as my ppp options file (I have several). The local IP is the same as my internal interface's (192.168.1.254). I have assigned a remote IP range that overlaps my local network. This, together with proxyarp in my /etc/ppp/options.poptop file make the remote hosts look like they are part of the local subnetwork. I use this file to start/stop pptpd -- I have this in /etc/init.d/pptpd: #!/bin/sh # # /etc/rc.d/init.d/pptpd # # chkconfig: 5 12 85 # description: control pptp server # case "$1" in start) echo 1 > /proc/sys/net/ipv4/ip_forward modprobe ppp_async modprobe ppp_generic modprobe ppp_mppe modprobe slhc if /usr/local/sbin/pptpd; then touch /var/lock/subsys/pptpd fi ;; stop) killall pptpd rm -f /var/lock/subsys/pptpd ;; restart) killall pptpd if /usr/local/sbin/pptpd; then touch /var/lock/subsys/pptpd fi ;; status) ifconfig ;; *) echo "Usage: $0 {start|stop|restart|status}" ;; esac
Configuring Shorewall
Basic Setup Here' a basic setup that treats your remote users as if they were part of your loc zone. Note that if your primary Internet connection uses ppp0, then be sure that loc follows net in /etc/shorewall/zones. /etc/shorewall/tunnels: #TYPE ZONE GATEWAY GATEWAY ZONE pptpserver net 0.0.0.0/0 /etc/shorewall/interfaces: #ZONE INTERFACE BROADCAST OPTIONS loc ppp+
Remote Users in a Separate Zone If you want to place your remote users in their own zone so that you can control connections between these users and the local network, follow this example. Note that if your primary Internet connection uses ppp0 then be sure that vpn follows net in /etc/shorewall/zones as shown below. /etc/shorewall/tunnels: #TYPE ZONE GATEWAY GATEWAY ZONE pptpserver net 0.0.0.0/0 /etc/shorewall/zones: #ZONE TYPE net ipv4 loc ipv4 vpn ipv4 /etc/shorewall/interfaces: #ZONE INTERFACE BROADCAST OPTIONS net eth0 206.124.146.255 loc eth2 192.168.10.255 vpn ppp+ Your policies and rules may now be configured for traffic to/from the vpn zone.
Multiple Remote Networks Often there will be situations where you want multiple connections from remote networks with these networks having different firewalling requirements. Here's how you configure this in Shorewall. Note that if your primary Internet connection uses ppp0 then be sure that the vpn{1-3} zones follows net in /etc/shorewall/zones as shown below. /etc/shorewall/tunnels: #TYPE ZONE GATEWAY GATEWAY ZONE pptpserver net 0.0.0.0/0 /etc/shorewall/zones: #ZONE TYPE fw firewall net ipv4 loc ipv4 vpn1 ipv4 vpn2 ipv4 vpn3 ipv4 /etc/shorewall/interfaces: #ZONE INTERFACE BROADCAST OPTIONS net eth0 206.124.146.255 loc eth2 192.168.10.255 - ppp+ /etc/shorewall/hosts: #ZONE HOST(S) OPTIONS vpn1 ppp+:192.168.1.0/24 vpn2 ppp+:192.168.2.0/24 vpn3 ppp+:192.168.3.0/24 Your policies and rules can now be configured using separate zones (vpn1, vpn2, and vpn3) for the three remote network.
PPTP Server Running Behind your Firewall If you have a single external IP address, add the following to your /etc/shorewall/rules file: /etc/shorewall/rules: #ACTION SOURCE DEST PROTO DEST PORT(S) DNAT net loc:<server address> tcp 1723 DNAT net loc:<server address> 47 If you have multiple external IP address and you want to forward a single <external address>, add the following to your /etc/shorewall/rules file: /etc/shorewall/rules: #ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL # PORT(S) DEST DNAT net loc:<server address> tcp 1723 - <external address> DNAT net loc:<server address> 47 - - <external address> You will also want to add this entry to your /etc/shorewall/masq file: #INTERFACE SUBNET ADDRESS PROTO <external interface> <server address> <external address> 47 Be sure that the above entry comes before any other entry that might match the server's address.
PPTP Clients Running Behind your Firewall Please see this article.
PPTP Client Running on your Firewall The key elements of this setup are as follows: Define a zone for the remote network accessed via PPTP. Associate that zone with a ppp interface. Define rules for PPTP traffic to/from the firewall. Define rules for traffic two and from the remote zone. Here are examples from one of my old setups: /etc/shorewall/zones: #ZONE TYPE cpq ipv4 /etc/shorewall/interfaces: #ZONE INTERFACE BROADCAST OPTIONS - ppp+ /etc/shorewall/hosts: #ZONE HOST(S) OPTIONS cpq ppp+:!192.168.1.0/24 /etc/shorewall/tunnels: #TYPE ZONE GATEWAY GATEWAY ZONE pptpclient net 0.0.0.0/0 I use the combination of interface and hosts file to define the cpq zone because I also run a PPTP server on my firewall (see above). Using this technique allows me to distinguish clients of my own PPTP server from arbitrary hosts at Compaq; I assign addresses in 192.168.1.0/24 to my PPTP clients and Compaq doesn't use that RFC1918 Class C subnet. I use this script in /etc/init.d to control the client. The reason that I disable ECN when connecting is that the Compaq tunnel servers don't do ECN yet and reject the initial TCP connection request if I enable ECN :-( #!/bin/sh # # /etc/rc.d/init.d/pptp # # chkconfig: 5 60 85 # description: PPTP Link Control # NAME="Tandem" ADDRESS=tunnel-tandem.compaq.com USER='Tandem\tommy' ECN=0 DEBUG= start_pptp() { echo $ECN > /proc/sys/net/ipv4/tcp_ecn if /usr/sbin/pptp $ADDRESS user $USER noauth $DEBUG; then touch /var/lock/subsys/pptp echo "PPTP Connection to $NAME Started" fi } stop_pptp() { if killall /usr/sbin/pptp 2> /dev/null; then echo "Stopped pptp" else rm -f /var/run/pptp/* fi # if killall pppd; then # echo "Stopped pppd" # fi rm -f /var/lock/subsys/pptp echo 1 > /proc/sys/net/ipv4/tcp_ecn } case "$1" in start) echo "Starting PPTP Connection to ${NAME}..." start_pptp ;; stop) echo "Stopping $NAME PPTP Connection..." stop_pptp ;; restart) echo "Restarting $NAME PPTP Connection..." stop_pptp start_pptp ;; status) ifconfig ;; *) echo "Usage: $0 {start|stop|restart|status}" ;; esac Here's my /etc/ppp/options file: # # Identify this connection # ipparam Compaq # # Lock the port # lock # # We don't need the tunnel server to authenticate itself # noauth +chap +chapms +chapms-v2 multilink mrru 1614 # # Turn off transmission protocols we know won't be used # nobsdcomp nodeflate # # We want MPPE # mppe-128 mppe-stateless # # We want a sane mtu/mru # mtu 1000 mru 1000 # # Time this thing out of it goes poof # lcp-echo-failure 10 lcp-echo-interval 10 My /etc/ppp/ip-up.local file sets up the routes that I need to route Compaq traffic through the PPTP tunnel: #/bin/sh case $6 in Compaq) route add -net 16.0.0.0 netmask 255.0.0.0 gw $5 $1 route add -net 130.252.0.0 netmask 255.255.0.0 gw $5 $1 route add -net 131.124.0.0 netmask 255.255.0.0 gw $5 $1 ... ;; esac Finally, I run the following script every five minutes under crond to restart the tunnel if it fails: #!/bin/sh restart_pptp() { /sbin/service pptp stop sleep 10 if /sbin/service pptp start; then /usr/bin/logger "PPTP Restarted" fi } if [ -n "`ps ax | grep /usr/sbin/pptp | grep -v grep`" ]; then exit 0 fi echo "Attempting to restart PPTP" restart_pptp > /dev/null 2>&1 & Here's a script and corresponding ip-up.local from Jerry Vonau jvonau@home.com that controls two PPTP connections.
PPTP Client running on your Firewall with PPTP Server in an ADSL Modem Some ADSL systems in Europe (most notably in Austria and the Netherlands) feature a PPTP server builtinto an ADSL Modem. In this setup, an Ethernet interface is dedicated to supporting the PPTP tunnel between the firewall and the Modem while the actual Internet access is through PPTP (interface ppp0). If you have this type of setup, you need to modify the sample configuration that you downloaded as described in this section. These changes are in addition to those described in the QuickStart Guides. Lets assume the following: ADSL Modem connected through eth0 Modem IP address = 192.168.1.1 eth0 IP address = 192.168.1.2 The changes you need to make are as follows: Add this entry to /etc/shorewall/zones: #ZONE TYPE modem ipv4 That entry defines a new zone called modem which will contain only your ADSL modem. Add the following entry to /etc/shorewall/interfaces: #ZONE INTERFACE BROADCAST OPTIONS modem eth0 192.168.1.255 dhcp You will of course modify the net entry in /etc/shorewall/interfaces to specify ppp0 as the interface as described in the QuickStart Guide corresponding to your setup. Add the following to /etc/shorewall/tunnels: #TYPE ZONE GATEWAY GATEWAY ZONE pptpclient modem 192.168.1.1 That entry allows a PPTP tunnel to be established between your Shorewall system and the PPTP server in the modem.
shorewall-docs-xml-5.0.15/Shorewall-5.xml0000644000000000000000000003007113020330134016636 0ustar rootroot
Shorewall 5 Tom Eastep 2015 Thomas M. Eastep 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.
Introduction There are currently two principle groups of changes that distinguish Shorewall 5 from Shorewall 4: Cruft Removal - over the years, as new ways to accomplish various tasks are added to Shorewall, support for the old way of doing things has generally been retained but deprecated. Shorewall 5 drops support for those deprecated features. Changes to CLI commands - In order to make command names more accurately reflect what the associated commands do, a number of commands have been renamed or the function that they perform has been changed. Each of these groups is described in more detail in the sections that follow.
Cruft Removal Removal of superseded features makes the code cleaner and easier to extend while also reducing compilation and execution time. The following subsections detail the features that are no longer supported in Shorewall 5.
Scripts Compiled with Shorewall 4.4.7 or Earlier Shorewall 5 cannot correctly run scripts compiled with Shorewall 4.4.7 or earlier releases. Such scripts must be recompiled with 4.4.8 or later prior to upgrading to Shorewall 5.
Workarounds Over the years, a number of workarounds have been added to Shorewall to work around defects in other products. In current distributions, those defects have been corrected, and in 4.6.11, a WORKAROUNDS configuration option was added to disable those workarounds. In Shorewall 5, the WORKAROUNDS setting is still available in the shorewall[6].conf files but: Its default setting has been changed to No. All workarounds for old distributions have been eliminated. If there is a need to add new workarounds in the future, those workarounds will be enabled by WORKAROUNDS=Yes.
Removal of Configuration Options A number of configuration options have been eliminated in Shorewall 5. The following options have been eliminated and the functionality that they enabled is been removed: EXPORTPARAMS IPSECFILE LEGACY_FASTSTART A compilation warning is issued when any of these options are encountered in the .conf file, and the shorewall[6] update command will remove them from the configuration file. These options have been eliminated because they have been superseded by newer options. LOGRATE and LOGBURST (superseded by LOGLIMIT) WIDE_TC_MARKS (superseded by TC_BITS) HIGH_ROUTE_MARKS (superseded by PROVIDER_OFFSET) BLACKLISTNEWONLY (superseded by BLACKLIST) A fatal compilation error is emitted if any of these options are present in the .conf file, and the shorewall[6] update command will replace these options with equivalent setting of the options that supersede them.
Obsolete Configuration Files Support has been removed for the 'blacklist', 'tcrules', 'routestopped', 'notrack' and 'tos' files. The and options of the update command are still available to convert the 'tcrules' and 'tos' files to the equivalent 'mangle' file and to convert the 'blacklist' file into an equivalent 'blrules' file. As in Shorewall 4.6.12, the option is available to convert the 'routestopped' file into the equivalent 'stoppedrules' file and the option is available to convert a 'notrack' file to the equivalent 'conntrack' file.
Macro and Action Formats Originally, macro and action files had formats that were different from that of the rules file, Format-1 action files had the following columns: TARGET SOURCE DEST PROTO DEST PORT(S) SOURCE PORT(S) RATE USER/GROUP MARK Format-1 macro files were similar but did not support the MARK column. Format-2 macro and action files have these columns: TARGET SOURCE DEST PROTO DPORT SPORT ORIGDEST RATE USER/GROUP MARK CONNLIMIT TIME HEADERS (Only valid for IPv6) SWITCH HELPER Notice that the first five columns of both sets are the same (although the port-valued column names have changed, the contents are the same). In Shorewall 5, support for format-1 macros and actions has been dropped and all macros and actions will be processed as if ?FORMAT 2 were included before the first entry. Given that the vast majority of actions and macros only use the first five columns, this change will be of no concern to most users, but will cause compilation errors if columns beyold the fifth one are populated.
COMMENT, FORMAT and SECTION Lines COMMENT, FORMAT and SECTION Lines now require the leading question mark ("?"). In earlier releases, the question mark was optional. The shorewall[6] update -D command in Shorewall 4.6 will insert the question marks for you.
CLI Command Changes A number of commands have been renamed and/or now perform a different function.
restart The restart command now does a true restart and is equivalent to a stop followed by a start.
load The function performed by the Shorewall-4 load command is now performed by the remote-start command.
reload In Shorewall 5, the reload command now performs the same function as the restart command did in Shorewall 4. The action taken by the Shorewall-4 reload command is now performed by the remote-restart command. For those that can't get used to the idea of using reload in place of restart, a RESTART option has been added to shorewall[6].conf. The option defaults to 'restart' but if set to 'reload', then the restart command does what it did in earlier releases. Beginning with Shorewall 5.0.1 and Shorewall 4.6.13.2, the update command will set RESTART=reload to maintain compatibility with earlier releases. Shorewall 5.0.0 created the setting LEGACY_RESTART=No which was equivalent to RESTART=restart. Under Shorewall 5.0.1 and later, update will convert LEGACY_RESTART to the equivalent RESTART setting.
Upgrading to Shorewall 5 It is strongly recommended that you first upgrade your installation to a 4.6 release that supports the option to the update command; 4.6.13.2 or later is preferred. Once you are on that release, execute the shorewall update -A command (and shorewall6 update -A if you also have Shorewall6). Finally, add ?FORMAT 2 to each of your macro and action files and be sure that the check command does not produce errors -- if it does, you can shuffle the columns around to make them work on both Shorewall 4 and Shorewall 5. These steps can also be taken after you upgrade, but your firewall likely won't start or work correctly until you do. The update command in Shorewall 5 has many fewer options. The , , , and options have been removed -- the updates triggered by those options are now performed unconditionally. The and options have been retained - both enable checking for issues that could result if INLINE_MATCHES were to be set to Yes.
shorewall-docs-xml-5.0.15/OpenVZ.xml0000644000000000000000000006742013020330134015725 0ustar rootroot
Shorewall and OpenVZ Tom Eastep 2009 Thomas M. Eastep 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.
Introduction Open Virtuoso (OpenVZ) is an open source kernel-based virtualization solution from Parallels (formerly SWSoft). Virtual servers take the form of containers (the OpenVZ documentation calls these Virtual Environments or VEs) which are created via templates. Templates are available for a wide variety of distributions and architectures. OpenVZ requires a patched kernel. Beginning with Lenny, Debian supplies OpenVZ kernels through the standard stable repository.
Shorewall on an OpenVZ Host As with any Shorewall installation involving other software, we suggest that you first install OpenVZ and get it working before attempting to add Shorewall. Alternatively, execute shorewall clear while installing and configuring OpenVZ.
Networking The default OpenVZ networking configuration uses Proxy ARP. You assign containers IP addresses in the IP network from one of your interfaces and you are expected to set the proxy_arp flag on that interface (/proc/sys/net/ipv4/conf/interface/proxy_arp). OpenVZ creates a point-to-point virtual interface in the host with a rather odd configuration. Example (Single VE with IP address 206.124.146.178): gateway:~# ip addr ls dev venet0 10: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN link/void gateway:~# ip route ls dev venet0 206.124.146.178 scope link gateway:~# The interface has no IP configuration yet it has a route to 206.124.146.178! From within the VE with IP address 206.124.146.178, we have the following: server:~ # ip addr ls 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 brd 127.255.255.255 scope host lo inet 127.0.0.2/8 brd 127.255.255.255 scope host secondary lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN link/void inet 127.0.0.1/32 scope host venet0 inet 206.124.146.178/32 scope global venet0:0 server:~ # ip route ls 192.0.2.0/24 dev venet0 scope link 127.0.0.0/8 dev lo scope link default via 192.0.2.1 dev venet0 server:~ # There are a couple of unique features of this configuration: 127.0.0.1/32 is configured on venet0 although the main routing table routes loopback traffic through the lo interface as normal. There is a route to 192.0.2.0/24 through venet0 even though the interface has no IP address in that network. Note: 192.0.2.0/24 is reserved for use in documentation and for testing. The default route is via 192.0.2.1 yet there is no interface on the host with that IP address. All of this doesn't really affect the Shorewall configuration but it is interesting none the less.
Shorewall Configuration We recommend handling the strange OpenVZ configuration in Shorewall as follows: /etc/shorewall/zones: ############################################################################### #ZONE TYPE OPTIONS IN_OPTION OUT_OPTIONS net ipv4 vz ipv4 /etc/shorewall/interfaces: ############################################################################### #ZONE INTERFACE OPTIONS net eth0 proxyarp=1 vz venet0 routeback,arp_filter=0
Multi-ISP If you run Shorewall Multi-ISP support on the host, you should arrange for traffic to your containers to use the main routing table. In the configuration shown here, this entry in /etc/shorewall/rtrules is appropriate: #SOURCE DEST PROVIDER PRIORITY - 206.124.146.178 main 1000
RFC 1918 Addresses in a Container You can assign an RFC 1918 address to a VE and use masquerade/SNAT to provide Internet access to the container. This is just a normal simple Shorewall configuration as shown in the Two-interface Quick Start Guide. In this configuration the firewall's internal interface is venet0. Be sure to include the options shown above.
Shorewall in an OpenVZ Virtual Environment If you have obtained an OpenVZ VE from a hosting service provider, you may find it difficult to configure any type of firewall within your VE. There are two VE parameters that control iptables behavior within the container: --iptables name Restrict access to iptables modules inside a container (The OpenVZ claims that by default all iptables modules that are loaded in the host system are accessible inside a container; I haven't tried that). You can use the following values for name: , , , , , , , , , , , , , , , , , , , , , , , . If your provider is using this option, you may be in deep trouble trying to use Shorewall in your container. Look at the output of shorewall show capabilities and weep. Then try to get your provider to remove this restriction on your container. --numiptent num This parameter limits the number of iptables rules that are allowed within the container. The default is 100 which is too small for a Shorewall configuration. We recommend setting this to at least 200. if you see annoying error messages as shown below during start/restart, remove the module-init-tools package from the VE. server:/etc/shorewall # shorewall restart Compiling... Compiling /etc/shorewall/zones... Compiling /etc/shorewall/interfaces... Determining Hosts in Zones... Preprocessing Action Files... Pre-processing /usr/share/shorewall/action.Drop... Pre-processing /usr/share/shorewall/action.Reject... Compiling /etc/shorewall/policy... Adding Anti-smurf Rules Adding rules for DHCP Compiling TCP Flags filtering... Compiling Kernel Route Filtering... Compiling Martian Logging... Compiling MAC Filtration -- Phase 1... Compiling /etc/shorewall/rules... Generating Transitive Closure of Used-action List... Processing /usr/share/shorewall/action.Reject for chain Reject... Processing /usr/share/shorewall/action.Drop for chain Drop... Compiling MAC Filtration -- Phase 2... Applying Policies... Generating Rule Matrix... Creating iptables-restore input... Compiling iptables-restore input for chain mangle:... Compiling /etc/shorewall/routestopped... Shorewall configuration compiled to /var/lib/shorewall/.restart Restarting Shorewall.... Initializing... Processing /etc/shorewall/init ... Processing /etc/shorewall/tcclear ... Setting up Route Filtering... Setting up Martian Logging... Setting up Proxy ARP... Setting up Traffic Control... Preparing iptables-restore input... Running /usr/sbin/iptables-restore... FATAL: Could not load /lib/modules/2.6.26-2-openvz-amd64/modules.dep: No such file or directory FATAL: Could not load /lib/modules/2.6.26-2-openvz-amd64/modules.dep: No such file or directory FATAL: Could not load /lib/modules/2.6.26-2-openvz-amd64/modules.dep: No such file or directory FATAL: Could not load /lib/modules/2.6.26-2-openvz-amd64/modules.dep: No such file or directory IPv4 Forwarding Enabled Processing /etc/shorewall/start ... Processing /etc/shorewall/started ... done.
Working Example This section presents a working example. This is the configuration at shorewall.net during the summer of 2009. The network diagram is shown below. The two systems shown in the green box are OpenVZ Virtual Environments (containers).
OpenVZ Configuration In the files below, items in bold font are relevant to the networking/Shorewall configuration. /etc/vz/conf (long lines folded for clarity). ## Global parameters VIRTUOZZO=yes LOCKDIR=/var/lib/vz/lock DUMPDIR=/var/lib/vz/dump VE0CPUUNITS=1000 ## Logging parameters LOGGING=yes LOGFILE=/var/log/vzctl.log LOG_LEVEL=0 VERBOSE=0 ## Disk quota parameters DISK_QUOTA=no VZFASTBOOT=no # The name of the device whose ip address will be used as source ip for VE. # By default automatically assigned. VE_ROUTE_SRC_DEV="eth3" # Controls which interfaces to send ARP requests and modify APR tables on. NEIGHBOUR_DEVS=detect ## Template parameters TEMPLATE=/var/lib/vz/template ## Defaults for VEs VE_ROOT=/home/vz/root/$VEID VE_PRIVATE=/home/vz/private/$VEID CONFIGFILE="vps.basic" #DEF_OSTEMPLATE="fedora-core-4" DEF_OSTEMPLATE="debian" ## Load vzwdog module VZWDOG="no" ## IPv4 iptables kernel modules IPTABLES="iptable_filter iptable_mangle ipt_limit ipt_multiport ipt_tos ipt_TOS ipt_REJECT ipt_TCPMSS ipt_tcpmss ipt_ttl ipt_LOG ipt_length ip_conntrack ip_conntrack_ftp ip_conntrack_irc ipt_conntrack ipt_state ipt_helper iptable_nat ip_nat_ftp ip_nat_irc ipt_REDIRECT xt_mac ipt_owner" ## Enable IPv6 IPV6="no" /etc/vz/conf/101.conf: ONBOOT="yes" # UBC parameters (in form of barrier:limit) KMEMSIZE="574890800:589781600" LOCKEDPAGES="256:256" PRIVVMPAGES="1073741824:2137483648" SHMPAGES="21504:21504" NUMPROC="240:240" PHYSPAGES="0:9223372036854775807" VMGUARPAGES="262144:9223372036854775807" OOMGUARPAGES="26112:9223372036854775807" NUMTCPSOCK="360:360" NUMFLOCK="188:206" NUMPTY="16:16" NUMSIGINFO="256:256" TCPSNDBUF="1720320:2703360" TCPRCVBUF="1720320:2703360" OTHERSOCKBUF="1126080:2097152" DGRAMRCVBUF="262144:262144" NUMOTHERSOCK="360:360" DCACHESIZE="3409920:3624960" NUMFILE="9312:9312" AVNUMPROC="180:180" NUMIPTENT="200:200" # Disk quota parameters (in form of softlimit:hardlimit) DISKSPACE="1048576:1153024" DISKINODES="200000:220000" QUOTATIME="0" # CPU fair sheduler parameter CPUUNITS="1000" VE_ROOT="/home/vz/root/$VEID" VE_PRIVATE="/home/vz/private/$VEID" OSTEMPLATE="suse-11.1-x86_64" ORIGIN_SAMPLE="vps.basic" HOSTNAME="lists.shorewall.net" IP_ADDRESS="206.124.146.177" NAMESERVER="127.0.0.1" NAME="lists" SEARCHDOMAIN="shorewall.net" This VE is the main server at shorewall.net. Note that some of the memory parameters are set ridiculously large -- I got tired of out-of-memory issues. /etc/vz/conf/102.conf (nearly default configuration on Debian): ONBOOT="yes" # UBC parameters (in form of barrier:limit) KMEMSIZE="14372700:14790164" LOCKEDPAGES="256:256" PRIVVMPAGES="65536:69632" SHMPAGES="21504:21504" NUMPROC="240:240" PHYSPAGES="0:9223372036854775807" VMGUARPAGES="33792:9223372036854775807" OOMGUARPAGES="26112:9223372036854775807" NUMTCPSOCK="360:360" NUMFLOCK="188:206" NUMPTY="16:16" NUMSIGINFO="256:256" TCPSNDBUF="1720320:2703360" TCPRCVBUF="1720320:2703360" OTHERSOCKBUF="1126080:2097152" DGRAMRCVBUF="262144:262144" NUMOTHERSOCK="360:360" DCACHESIZE="3409920:3624960" NUMFILE="9312:9312" AVNUMPROC="180:180" NUMIPTENT="200:200" # Disk quota parameters (in form of softlimit:hardlimit) DISKSPACE="1048576:1153024" DISKINODES="200000:220000" QUOTATIME="0" # CPU fair sheduler parameter CPUUNITS="1000" VE_ROOT="/home/vz/root/$VEID" VE_PRIVATE="/home/vz/private/$VEID" OSTEMPLATE="debian-5.0-amd64-minimal" ORIGIN_SAMPLE="vps.basic" HOSTNAME="server.shorewall.net" IP_ADDRESS="206.124.146.178" NAMESERVER="206.124.146.177" NAME="server" I really don't use this server for anything currently but I'm planning to eventually splt the services between the two VEs.
Shorewall Configuration on the Host Below are excerpts from the configuration files as they pertain to the OpenVZ environment. /etc/shorewall/zones: #ZONE TYPE OPTIONS IN_OPTIONS OUT_OPTIONS fw firewall net ipv4 #Internet loc ipv4 #Local wired Zone dmz ipv4 #DMZ ... /etc/shorewall/params: NET_IF=eth3 INT_IF=eth1 VPS_IF=venet0 ... /etc/shorewall/interfaces:#ZONE INTERFACE OPTIONS net $NET_IF dhcp,blacklist,tcpflags,optional,routefilter=0,nosmurfs,logmartions=0,proxyarp=1 loc $INT_IF dhcp,logmartians=1,routefilter=1,nets=(172.20.1.0/24),tcpflags dmz $VPS_IF logmartians=0,routefilter=0,nets=(206.124.146.177,206.124.146.178),routeback ...This is a multi-ISP configuration so entries are required in /etc/shorewall/rtrules: #SOURCE DEST PROVIDER PRIORITY - 172.20.0.0/24 main 1000 - 206.124.146.177 main 1001 - 206.124.146.178 main 1001
Shorewall Configuration on Server If you are running Debian Squeeze, Shorewall will not work in an OpenVZ container. This is a Debian OpenVZ issue and not a Shorewall issue. I have set up Shorewall on Server (206.124.146.178) just to have an environment to test with. It is a quite vanilla one-interface configuration. /etc/shorewall/zones: #ZONE TYPE OPTIONS IN_OPTIONS OUT_OPTIONS fw firewall net ipv4 /etc/shorewall/interfaces: #ZONE INTERFACE BROADCAST OPTIONS net venet0 detect dhcp,tcpflags,logmartians,nosmurfs
Working Example Using a Bridge This is the configuration at shorewall.net during the spring of 2010. Rather than using the venet0 configuration shown above, this configuration uses a bridge in preparation for adding IPv6 support in the DMZ. The eth0 interface in each of the containers is statically configured using the distributions' configuration tools (/etc/network/interfaces on Debian and Yast on OpenSuSE). The network diagram is shown below. The two systems shown in the green box are OpenVZ Virtual Environments (containers).
Bridge Configuration The following stanza in /etc/network/interfaces on the host configures the bridge. auto vzbr0 iface vzbr0 inet static pre-up /usr/sbin/brctl addbr vzbr0 address 206.124.146.176 network 206.124.146.176 broadcast 206.124.146.176 netmask 255.255.255.255 post-down /usr/sbin/brctl delbr br0
OpenVZ Configuration In the files below, items in bold font show the changes from the preceeding example. /etc/vz/conf (long lines folded for clarity). ## Global parameters VIRTUOZZO=yes LOCKDIR=/var/lib/vz/lock DUMPDIR=/var/lib/vz/dump VE0CPUUNITS=1000 ## Logging parameters LOGGING=yes LOGFILE=/var/log/vzctl.log LOG_LEVEL=0 VERBOSE=0 ## Disk quota parameters DISK_QUOTA=no VZFASTBOOT=no # The name of the device whose ip address will be used as source ip for VE. # By default automatically assigned. VE_ROUTE_SRC_DEV="eth3" # Controls which interfaces to send ARP requests and modify APR tables on. NEIGHBOUR_DEVS=detect ## Template parameters TEMPLATE=/var/lib/vz/template ## Defaults for VEs VE_ROOT=/home/vz/root/$VEID VE_PRIVATE=/home/vz/private/$VEID CONFIGFILE="vps.basic" #DEF_OSTEMPLATE="fedora-core-4" DEF_OSTEMPLATE="debian" ## Load vzwdog module VZWDOG="no" ## IPv4 iptables kernel modules IPTABLES="iptable_filter iptable_mangle ipt_limit ipt_multiport ipt_tos ipt_TOS ipt_REJECT ipt_TCPMSS ipt_tcpmss ipt_ttl ipt_LOG ipt_length ip_conntrack ip_conntrack_ftp ip_conntrack_irc ipt_conntrack ipt_state ipt_helper iptable_nat ip_nat_ftp ip_nat_irc ipt_REDIRECT xt_mac ipt_owner" ## Enable IPv6 IPV6="no" /etc/vz/conf/101.conf: ONBOOT="yes" # UBC parameters (in form of barrier:limit) KMEMSIZE="574890800:589781600" LOCKEDPAGES="256:256" PRIVVMPAGES="1073741824:2137483648" SHMPAGES="21504:21504" NUMPROC="240:240" PHYSPAGES="0:9223372036854775807" VMGUARPAGES="262144:9223372036854775807" OOMGUARPAGES="26112:9223372036854775807" NUMTCPSOCK="360:360" NUMFLOCK="188:206" NUMPTY="16:16" NUMSIGINFO="256:256" TCPSNDBUF="1720320:2703360" TCPRCVBUF="1720320:2703360" OTHERSOCKBUF="1126080:2097152" DGRAMRCVBUF="262144:262144" NUMOTHERSOCK="360:360" DCACHESIZE="3409920:3624960" NUMFILE="9312:9312" AVNUMPROC="180:180" NUMIPTENT="200:200" # Disk quota parameters (in form of softlimit:hardlimit) DISKSPACE="1048576:1153024" DISKINODES="200000:220000" QUOTATIME="0" # CPU fair sheduler parameter CPUUNITS="1000" VE_ROOT="/home/vz/root/$VEID" VE_PRIVATE="/home/vz/private/$VEID" OSTEMPLATE="suse-11.1-x86_64" ORIGIN_SAMPLE="vps.basic" HOSTNAME="lists.shorewall.net" NAMESERVER="127.0.0.1" NAME="lists" SEARCHDOMAIN="shorewall.net" NETIF="ifname=eth0,mac=00:18:51:22:24:81,host_ifname=veth101.0,host_mac=00:18:51:B6:1A:F1" This VE is the mail server at shorewall.net (MX and IMAP). Note that some of the memory parameters are set ridiculously large -- I got tired of out-of-memory issues. /etc/vz/conf/102.conf (nearly default configuration on Debian): ONBOOT="yes" # UBC parameters (in form of barrier:limit) KMEMSIZE="14372700:14790164" LOCKEDPAGES="256:256" PRIVVMPAGES="65536:69632" SHMPAGES="21504:21504" NUMPROC="240:240" PHYSPAGES="0:9223372036854775807" VMGUARPAGES="33792:9223372036854775807" OOMGUARPAGES="26112:9223372036854775807" NUMTCPSOCK="360:360" NUMFLOCK="188:206" NUMPTY="16:16" NUMSIGINFO="256:256" TCPSNDBUF="1720320:2703360" TCPRCVBUF="1720320:2703360" OTHERSOCKBUF="1126080:2097152" DGRAMRCVBUF="262144:262144" NUMOTHERSOCK="360:360" DCACHESIZE="3409920:3624960" NUMFILE="9312:9312" AVNUMPROC="180:180" NUMIPTENT="200:200" # Disk quota parameters (in form of softlimit:hardlimit) DISKSPACE="1048576:1153024" DISKINODES="200000:220000" QUOTATIME="0" # CPU fair sheduler parameter CPUUNITS="1000" VE_ROOT="/home/vz/root/$VEID" VE_PRIVATE="/home/vz/private/$VEID" OSTEMPLATE="debian-5.0-amd64-minimal" ORIGIN_SAMPLE="vps.basic" HOSTNAME="server.shorewall.net" NAMESERVER="206.124.146.177" NAME="server" NETIF="ifname=eth0,mac=00:18:51:22:24:80,host_ifname=veth102.0,host_mac=00:18:51:B6:1A:F0" This server runs the rest of the services for shorewall.net (web server, ftp server, rsyncd, etc.). With a bridged configuration, the VIF for a VE must be added to the bridge when the VE starts. That is accomplished using mount files. /etc/vz/conf/101.mount: #!/bin/bash # This script source VPS configuration files in the same order as vzctl does # if one of these files does not exist then something is really broken [ -f /etc/vz/vz.conf ] || exit 1 [ -f $VE_CONFFILE ] || exit 1 # source both files. Note the order, it is important . /etc/vz/vz.conf . $VE_CONFFILE # Add the VIF to the bridge after VE has started { BRIDGE=vzbr0 DEV=veth101.0 while sleep 1; do /sbin/ifconfig $DEV 0 >/dev/null 2>&1 if [ $? -eq 0 ]; then /usr/sbin/brctl addif $BRIDGE $DEV break fi done } & /etc/vz/conf/102.mount: #!/bin/bash # This script source VPS configuration files in the same order as vzctl does # if one of these files does not exist then something is really broken [ -f /etc/vz/vz.conf ] || exit 1 [ -f $VE_CONFFILE ] || exit 1 # source both files. Note the order, it is important . /etc/vz/vz.conf . $VE_CONFFILE # Add VIF to bridge after VE has started { BRIDGE=vzbr0 DEV=veth102.0 while sleep 1; do /sbin/ifconfig $DEV 0 >/dev/null 2>&1 if [ $? -eq 0 ]; then /usr/sbin/brctl addif $BRIDGE $DEV break fi done } &
Shorewall Configuration on the Host Below are excerpts from the configuration files as they pertain to the OpenVZ environment. Again, bold font indicates change from the prior configuration. /etc/shorewall/zones: #ZONE TYPE OPTIONS IN_OPTIONS OUT_OPTIONS fw firewall net ipv4 #Internet loc ipv4 #Local wired Zone dmz ipv4 #DMZ ... /etc/shorewall/params: NET_IF=eth3 INT_IF=eth1 VPS_IF=vzbr0 ... /etc/shorewall/interfaces:#ZONE INTERFACE OPTIONS net $NET_IF dhcp,blacklist,tcpflags,optional,routefilter=0,nosmurfs,logmartions=0 loc $INT_IF dhcp,logmartians=1,routefilter=1,nets=(172.20.1.0/24),tcpflags dmz $VPS_IF logmartians=0,routefilter=0,nets=(206.124.146.177,206.124.146.178),routeback ... /etc/shorewall/proxyarp: #ADDRESS INTERFACE EXTERNAL HAVEROUTE PERSISTENT 206.124.146.177 DMZ_IF eth2 no yes 206.124.146.178 DMZ_IF eth2 no yes This is a multi-ISP configuration so entries are required in /etc/shorewall/rtrules: #SOURCE DEST PROVIDER PRIORITY - 172.20.0.0/24 main 1000 - 206.124.146.177 main 1001 - 206.124.146.178 main 1001
Shorewall Configuration on Server I have set up Shorewall on VE 101 (206.124.146.178) just to have an environment to test with. It is a quite vanilla one-interface configuration. /etc/shorewall/zones: #ZONE TYPE OPTIONS IN_OPTIONS OUT_OPTIONS fw firewall net ipv4 /etc/shorewall/interfaces: #ZONE INTERFACE OPTIONS net eth0 dhcp,tcpflags,logmartians,nosmurfs
shorewall-docs-xml-5.0.15/GenericTunnels.xml0000644000000000000000000001056313020330134017465 0ustar rootroot
Generic Tunnels Tom Eastep 2001 2002 2003 2005 Thomas M. Eastep 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. Shorewall includes built-in support for a wide range of VPN solutions. If you have need for a tunnel type that does not have explicit support, you can generally describe the tunneling software using generic tunnels.
Bridging two Masqueraded Networks Suppose that we have the following situation: We want systems in the 192.168.1.0/24 subnetwork to be able to communicate with the systems in the 10.0.0.0/8 network. This is accomplished through use of the /etc/shorewall/tunnels file, the /etc/shorewall/policy file and the /etc/shorewall/tunnel script that is included with Shorewall. Suppose that you have tunneling software that uses two different protocols: TCP port 1071 GRE (Protocol 47) The tunnel interface on system A is tun0 and the tunnel interface on system B is also tun0. On each firewall, you will need to declare a zone to represent the remote subnet. We'll assume that this zone is called vpn and declare it in /etc/shorewall/zones on both systems as follows. #ZONE TYPE OPTIONS vpn ipv4 On system A, the 10.0.0.0/8 will comprise the vpn zone. In /etc/shorewall/interfaces: #ZONE INTERFACE BROADCAST OPTIONS vpn tun0 10.255.255.255 In /etc/shorewall/tunnels on system A, we need the following: #TYPE ZONE GATEWAY GATEWAY_ZONE generic:tcp:1071 net 134.28.54.2 generic:47 net 134.28.54.2 These entries in /etc/shorewall/tunnels, opens the firewall so that TCP port 1071 and the Generalized Routing Encapsulation Protocol (47) will be accepted to/from the remote gateway. #ZONE INTERFACE BROADCAST OPTIONS vpn tun0 192.168.1.255 In /etc/shorewall/tunnels on system B, we have: #TYPE ZONE GATEWAY GATEWAY_ZONE generic:tcp:1071 net 206.191.148.9 generic:47 net 206.191.148.9 You will need to allow traffic between the vpn zone and the loc zone on both systems -- if you simply want to admit all traffic in both directions, you can use the policy file: #SOURCE DEST POLICY LOG LEVEL loc vpn ACCEPT vpn loc ACCEPT On both systems, restart Shorewall and start your VPN software on each system. The systems in the two masqueraded subnetworks can now talk to each other
shorewall-docs-xml-5.0.15/samba.xml0000644000000000000000000000623513020330134015624 0ustar rootroot
Samba/SMB Tom Eastep 2002-2005 Thomas M. Eastep 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. This article applies to Shorewall 4.3 and later. If you are running a version of Shorewall earlier than Shorewall 4.3.5 then please see the documentation for that release. If you wish to run Samba on your firewall and access shares between the firewall and local hosts, you need the following rules: #ACTION SOURCE DEST PROTO DPORT SPORT SMB(ACCEPT) $FW loc SMB(ACCEPT) loc $FW To pass traffic SMB/Samba traffic between zones Z1 and Z2: #ACTION SOURCE DEST PROTO DPORT SPORT SMB(ACCEPT) Z1 Z2 SMB(ACCEPT) Z2 Z1 To make network browsing (Network Neighborhood) work properly between Z1 and Z2 requires a Windows Domain Controller and/or a WINS server. I have run Samba on my firewall to handle browsing between two zones connected to my firewall. When debugging Samba/SMB problems, I recommend that you do the following: Copy action.Drop and action.Reject from /usr/share/shorewall to /etc/shorewall. Edit the copies and remove the SMB(DROP) and SMB(REJECT) lines. shorewall restart The above steps will cause SMB traffic that is dropped or rejected by policy to be logged rather than handled silently. If you are using Windows XP to test your setup,make you sure you have a properly configured client firewall . You can just remove the copies and shorewall restart when you are finished debugging.
shorewall-docs-xml-5.0.15/Shorewall-4.xml0000644000000000000000000001563213020330134016643 0ustar rootroot
Shorewall Version 4 Tom Eastep 2007 2009 2015 Thomas M. Eastep 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.
Introduction Shorewall version 4.0 represented a substantial shift in direction for Shorewall. Up until then Shorewall had been written entirely in Bourne Shell. Shorewall had run the iptables utility to add each Netfilter rule. Shorewall version 4.0 offered you a choice. You could continue to use the existing shell-based implementation or you could use a new implementation of the Shorewall compiler written in the Perl programming language. The new compiler: had a small disk footprint was very fast. generateed a firewall script that uses iptables-restore; so the script was very fast. generated better and more consistent error messages. did a much more thorough job of checking the configuration to avoid run-time errors. supported creating either Ipv4 or Ipv6 firewalls (Shorewall 4.2.4 and later). Both compilers could be installed on your system and you could use whichever one suited you in a particular case.
Shorewall 4.4 Shorewall 4.4 discontinued the availability of the legacy shell-based compiler. All users must migrate to the perl-based compiler before or during an upgrade to Shorewall version 4.4 or later. We highly recommend that current users of the shell-based compiler migrate before upgrading to 4.4 or later so that both compilers are available during the migration. Shorewall 4.4 contains five packages: Shorewall - Everything needed to create an IPv4 firewall. Shorewall-lite- Can run scripts generated by Shorewall on another system. Shorewall6 - The utilities for creating and operating an Ipv6 firewall. Requires Shorewall. Shorewall6-lite - Ipv6 equivalent of Shorewall Lite. Can run scripts generated by Shoreall on another system. Shorewall-init - An add-on package for any of the other packages which can: Secure the firewall(s) prior to bringing up the interfaces (does not work with systems running Upstart) React to ifup/ifdown events and restart the firewall(s) if needed
Shorewall 4.5/4.6 Shorewall 4.5 added an additional Shorewall-core package. This package contains the core Shorewall shell libraries that are required by the other packages.
Prerequisites for using the Shorewall Version 4.2/4.4/4.5/4.6 Perl-based Compiler Perl (I use Perl 5.14.2 but other 5.8 or later versions should work fine). If you want to be able to use DNS names in your Shorewall6 configuration files, then Perl 5.10 or later is required together with the Perl Socket6 module. Perl Cwd Module Perl File::Basename Module Perl File::Temp Module Perl Getopt::Long Module Perl Carp Module Perl FindBin Module Perl Scalar::Util Module Perl Digest::SHA1 Module (Shorewall 4.5 only) Please note that there are additional requirements if you plan to install and use Shorewall6.
Incompatibilities Introduced in the Shorewall Version 4 Perl-based Compiler The Shorewall Perl-based compiler is not 100% compatible with the Shorewall shell-based version. See this document for details.
shorewall-docs-xml-5.0.15/OPENVPN.xml0000644000000000000000000006042513020330134015667 0ustar rootroot
OpenVPN Tunnels and Bridges Simon Matter Tom Eastep 2003 2004 2005 2006 Simon Mater Thomas M. Eastep 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. This article applies to Shorewall 3.0 and later and to OpenVPN 2.0 and later. If you are running a version of Shorewall earlier than Shorewall 3.0.0 then please see the documentation for that release. OpenVPN is a robust and highly configurable VPN (Virtual Private Network) daemon which can be used to securely link two or more private networks using an encrypted tunnel over the Internet. OpenVPN is an Open Source project and is licensed under the GPL. OpenVPN can be downloaded from http://openvpn.net/. Unless there are interoperability issues (the remote systems do not support OpenVPN), OpenVPN is my choice any time that I need a VPN. It is widely supported -- I run it on both Linux and Windows. It requires no kernel patching. It is very easy to configure. It just works!
Preliminary Reading I recommend reading the VPN Basics article if you plan to implement any type of VPN.
Bridging two Masqueraded Networks Suppose that we have the following situation: We want systems in the 192.168.1.0/24 subnetwork to be able to communicate with the systems in the 10.0.0.0/8 network. This is accomplished through use of the /etc/shorewall/tunnels file and the /etc/shorewall/policy file and OpenVPN. While it was possible to use the Shorewall start and stop script to start and stop OpenVPN, I decided to use the init script of OpenVPN to start and stop it. On each firewall, you will need to declare a zone to represent the remote subnet. We'll assume that this zone is called vpn and declare it in /etc/shorewall/zones on both systems as follows.
/etc/shorewall/zones — Systems A & B #ZONE TYPE OPTIONS IN_OPTIONS OUT_OPTIONS vpn ipv4
On system A, the 10.0.0.0/8 will comprise the vpn zone.
In /etc/shorewall/interfaces on system A: #ZONE INTERFACE OPTIONS vpn tun0
In /etc/shorewall/tunnels on system A, we need the following:
#TYPE ZONE GATEWAY GATEWAY_ZONE openvpn net 134.28.54.2
This entry in /etc/shorewall/tunnels opens the firewall so that OpenVPN traffic on the default port 1194/udp will be accepted to/from the remote gateway. If you change the port used by OpenVPN to 7777, you can define /etc/shorewall/tunnels like this:
/etc/shorewall/tunnels with port 7777: #TYPE ZONE GATEWAY GATEWAY_ZONE openvpn:7777 net 134.28.54.2
Similarly, if you want to use TCP for your tunnel rather than UDP (the default), then you can define /etc/shorewall/tunnels like this:
/etc/shorewall/tunnels using TCP: #TYPE ZONE GATEWAY GATEWAY_ZONE openvpn:tcp net 134.28.54.2
Finally, if you want to use TCP and port 7777:
/etc/shorewall/tunnels using TCP port 7777: #TYPE ZONE GATEWAY GATEWAY_ZONE openvpn:tcp:7777 net 134.28.54.2
This is the OpenVPN config on system A:
dev tun local 206.162.148.9 remote 134.28.54.2 ifconfig 192.168.99.1 192.168.99.2 route 10.0.0.0 255.0.0.0 192.168.99.2 tls-server dh dh1024.pem ca ca.crt cert my-a.crt key my-a.key comp-lzo verb 5
Similarly, On system B the 192.168.1.0/24 subnet will comprise the vpn zone
In /etc/shorewall/interfaces on system B: #ZONE INTERFACE BROADCAST OPTIONS vpn tun0
In /etc/shorewall/tunnels on system B, we have:
#TYPE ZONE GATEWAY GATEWAY_ZONE openvpn net 206.191.148.9
And in the OpenVPN config on system B:
dev tun local 134.28.54.2 remote 206.162.148.9 ifconfig 192.168.99.2 192.168.99.1 route 192.168.1.0 255.255.255.0 192.168.99.1 tls-client ca ca.crt cert my-b.crt key my-b.key comp-lzo verb 5
You will need to allow traffic between the vpn zone and the loc zone on both systems -- if you simply want to admit all traffic in both directions, you can use the policy file:
/etc/shorewall/policy on systems A & B #SOURCE DEST POLICY LOG LEVEL loc vpn ACCEPT vpn loc ACCEPT
On both systems, restart Shorewall and start OpenVPN. The systems in the two masqueraded subnetworks can now talk to each other.
Roadwarrior OpenVPN 2.0 provides excellent support for roadwarriors. Consider the setup in the following diagram: On the gateway system (System A), we need a zone to represent the remote clients — we'll call that zone road.
/etc/shorewall/zones — System A: #ZONE TYPE OPTIONS IN_OPTIONS OUT_OPTIONS road ipv4
On system A, the remote clients will comprise the road zone.
In /etc/shorewall/interfaces on system A: #ZONE INTERFACE OPTIONS road tun+
In /etc/shorewall/tunnels on system A, we need the following:
#TYPE ZONE GATEWAY GATEWAY_ZONE openvpn:1194 net 0.0.0.0/0
If you are running Shorewall 2.4.3 or later, you might prefer the following in /etc/shorewall/tunnels on system A. Specifying the tunnel type as openvpnserver has the advantage that the VPN connection will still work if the client is behind a gateway/firewall that uses NAT.
#TYPE ZONE GATEWAY GATEWAY_ZONE openvpnserver:1194 net 0.0.0.0/0
We want the remote systems to have access to the local LAN — we do that with an entry in /etc/shorewall/policy (assume that the local LAN comprises the zone loc).
#SOURCE DESTINATION POLICY road loc ACCEPT
The OpenVPN configuration file on system A is something like the following:
dev tun server 192.168.2.0 255.255.255.0 dh dh1024.pem ca /etc/certs/cacert.pem crl-verify /etc/certs/crl.pem cert /etc/certs/SystemA.pem key /etc/certs/SystemA_key.pem port 1194 comp-lzo user nobody group nogroup ping 15 ping-restart 45 ping-timer-rem persist-tun persist-key push "route 192.168.1.0 255.255.255.0" verb 3
Configuration on the remote clients follows a similar line. We define a zone to represent the remote LAN:
/etc/shorewall/zones — System B: #ZONE TYPE OPTIONS IN OUT # OPTIONS OPTIONS home ipv4
On system A, the hosts accessible through the tunnel will comprise the home zone.
In /etc/shorewall/interfaces on system B: #ZONE INTERFACE BROADCAST OPTIONS home tun0
In /etc/shorewall/tunnels on system B, we need the following:
#TYPE ZONE GATEWAY GATEWAY_ZONE openvpn:1194 net 206.162.148.9
Again, if you are running Shorewall 2.4.3 or later, in /etc/shorewall/tunnels on system B you might prefer:
#TYPE ZONE GATEWAY GATEWAY_ZONE openvpnclient:1194 net 206.162.148.9
We want the remote client to have access to the local LAN — we do that with an entry in /etc/shorewall/policy.
#SOURCE DESTINATION POLICY $FW home ACCEPT
The OpenVPN configuration on the remote clients is along the following line:
dev tun remote 206.162.148.9 up /etc/openvpn/home.up tls-client pull ca /etc/certs/cacert.pem cert /etc/certs/SystemB.pem key /etc/certs/SystemB_key.pem port 1194 user nobody group nogroup comp-lzo ping 15 ping-restart 45 ping-timer-rem persist-tun persist-key verb 3
If you want multiple remote clients to be able to communicate openly with each other then you must: Include the client-to-client directive in the server's OpenVPN configuration; or Specify the routeback option on the tun+ device in /etc/shorewall/interfaces.
Roadwarrior with Duplicate Network Issue The information in this section was contributed by Nicola Moretti. If your local lan uses a popular RFC 1918 network like 192.168.1.0/24, there will be times when your roadwarriors need to access your lan from a remote location that uses that same network. This may be accomplished by configuring a second server on your firewall that uses a different port and by using NETMAP in your Shorewall configuration. The server configuration in the above diagram is modified as shown here:
dev tun server 192.168.3.0 255.255.255.0 dh dh1024.pem ca /etc/certs/cacert.pem crl-verify /etc/certs/crl.pem cert /etc/certs/SystemA.pem key /etc/certs/SystemA_key.pem port 1195 comp-lzo user nobody group nogroup ping 15 ping-restart 45 ping-timer-rem persist-tun persist-key push "route 172.20.1.0 255.255.255.0" verb 3
In /etc/shorewall/netmap, put these entries:
#TYPE NET1 INTERFACE NET2 SNAT 192.168.1.0/24 tun1 172.20.1.0/24 DNAT 172.20.1.0/24 tun1 192.168.1.0/24
The roadwarrior can now connect to port 1195 and access the lan on the right as 172.20.1.0/24.
Roadwarrior with IPv6 While OpenVPN supports tunneling of IPv6 packets, the version of the code that I run under OS X on my Macbook Pro does not support that option. Nevertheless, I am able to take IPv6 on the road with me by creating a 6to4 tunnel through the OpenVPN IPv6 tunnel. In this configuration, the IPv4 address pair (172.20.0.10,172.20.0.11) is used for the OpenVPN tunnel and (2001:470:e857:2::1,2001:470:e857:2::2) is used for the 6to4 tunnel. Here are my config files: Server (conventional routed server config):
dev tun local 70.90.191.121 server 172.20.0.0 255.255.255.128 dh dh1024.pem ca /etc/certs/cacert.pem crl-verify /etc/certs/crl.pem cert /etc/certs/gateway.pem key /etc/certs/gateway_key.pem port 1194 comp-lzo user nobody group nogroup keepalive 15 45 ping-timer-rem persist-tun persist-key client-config-dir /etc/openvpn/clients ccd-exclusive client-to-client push "route 172.20.1.0 255.255.255.0" verb 3 In the CCD file for the Macbook Pro: ifconfig-push 172.20.0.11 172.20.0.10 From /etc/network/interfaces (very standard 6to4 tunnel configuration): auto mac iface mac inet6 v4tunnel address 2001:470:e857:2::1 netmask 64 endpoint 172.20.0.11 local 172.20.1.254 Note that while the remote endpoint (172.20.0.11) is also the remote endpoint of the OpenVPN tunnel, the local endpoint (172.20.1.254) of the 6to4 tunnel is not the local endpoint of the OpenVPN tunnel (that;s 172.20.0.10). 172.20.1.254 is the IPv4 address of the Shorewall firewall's LAN interface. The following excerpts from the Shorewall configuration show the parts of that configuration that are relevant to these two tunnels (bold font). This is not a complete configuration. /etc/shorewall/zones: #ZONE TYPE fw firewall loc ip #Local Zone drct:loc ipv4 #Direct internet access net ipv4 #Internet vpn ipv4 #OpenVPN clients /etc/shorewall/interfaces: #ZONE INTERFACE BROADCAST OPTIONS loc INT_IF detect dhcp,logmartians=1,routefilter=1,physical=$INT_IF,required,wait=5 net COM_IF detect dhcp,blacklist,optional,routefilter=0,logmartians,proxyarp=0,physical=$COM_IF,nosmurfs vpn TUN_IF+ detect physical=tun+,routeback - sit1 - ignore - mac - ignore - EXT_IF - ignore - lo - ignore /etc/shorewall/tunnels: #TYPE ZONE GATEWAY GATEWAY # ZONE openvpnserver:udp net 6to4 net 6to4 vpn Similarly, here are excerpts from the Shorewall6 configuration. /etc/shorewall6/zones: #ZONE TYPE OPTIONS IN OUT # OPTIONS OPTIONS fw firewall net ipv6 loc ipv6 rest ipv6 /etc/shorewall6/interfaces: #ZONE INTERFACE BROADCAST OPTIONS net sit1 detect tcpflags,forward=1,nosmurfs,routeback loc eth4 detect tcpflags,forward=1 loc mac detect tcpflags,forward=1 rest eth+ Note that in the IPv6 firewall configuration, the remove Macbook Pro is considered to be part of the local zone (loc).
Client (conventional routed client config):
client dev tun proto udp remote gateway.shorewall.net 1194 resolv-retry infinite nobind persist-key persist-tun mute-replay-warnings ca ca.crt cert mac.crt key mac.key ns-cert-type server comp-lzo verb 3 up /Users/teastep/bin/up down /Users/teastep/bin/down /Users/teastep/bin/up: #!/bin/bash LOCAL_IP=172.20.0.11 LOCAL_IPV6=2001:470:e857:2::2 REMOTE_IP=172.20.1.254 REMOTE_IPV6=2001:470:e857:2::1 TUNNEL_IF=gif0 if [ $(ifconfig gif0 | wc -l ) -eq 1 ]; then # # Tunnel interface is not configured yet # /sbin/ifconfig $TUNNEL_IF tunnel $LOCAL_IP $REMOTE_IP /sbin/ifconfig $TUNNEL_IF inet6 $LOCAL_IPV6 $REMOTE_IPV6 prefixlen 128 else /sbin/ifconfig $TUNNEL_IF up fi /sbin/route -n add -inet6 default $REMOTE_IPV6 > /dev/null 2>&1 /Users/teastep/bin/down: #!/bin/bash TUNNEL_IF=gif0 /sbin/ifconfig $TUNNEL_IF down /sbin/route -n delete -inet6 default > /dev/null 2>&1
Bridged Roadwarrior If you want to use a bridged OpenVPN configuration rather than a routed configuration, then follow any of the available HOWTOs to set up the bridged configuration. Then: In your current Shorewall two-interface configuration, replace references to your internal interface with the name of the bridge; and Set the routeback option in the bridge's entry in /etc/shorewall/interfaces; end Add this entry to /etc/shorewall/tunnels: #TYPE ZONE GATEWAY GATEWAY_ZONE openvpnserver:1194 net 0.0.0.0/0 This will make the roadwarrior part of your local zone.
Bridging Two Networks Occasionally, the need arises to have a single LAN span two different geographical locations. OpenVPN allows that to be done easily. Consider the following case: Part of the 192.168.1.0/24 network is in one location and part in another. The two LANs can be bridged with OpenVPN as described in this section. This example uses a fixed shared key for encryption. OpenVPN configuration on left-hand firewall: remote 130.252.100.109 dev tap0 secret /etc/openvpn/bridgekey OpenVPN configuration on right-hand firewall: remote 206.124.146.176 dev tap0 secret /etc/openvpn/bridgekey The bridges can be created by manually making the tap device tap0 and bridgeing it with the local ethernet interface. Assuming that the local interface on both sides is eth1, the following stanzas in /etc/network/interfaces (Debian and derivatives) will create the bridged interfaces. The stanzas below were written before bridges could be defined in /etc/network/interfaces. For current usage, see bridge-utils-interfaces (5). /etc/network/interfaces on the left-hand firewall: iface br0 inet static pre-up /usr/sbin/openvpn --mktun --dev tap0 pre-up /usr/sbin/brctl addbr br0 address 192.168.1.254 network 192.168.1.0 broadcast 192.168.1.255 netmask 255.255.255.0 post-up /sbin/ip link set tap0 up post-up /usr/sbin/brctl addif br0 tap0 post-up /sbin/ip link set eth1 up post-up /usr/sbin/brctl addif br0 eth1 post-down /usr/sbin/brctl delbr br0 post-down /usr/sbin/openvpn --rmtun --dev tap0 post-down /sbin/ip link set eth1 down /etc/network/interfaces on the right-hand firewall: iface br0 inet static pre-up /usr/sbin/openvpn --mktun --dev tap0 pre-up /usr/sbin/brctl addbr br0 address 192.168.1.253 network 192.168.1.0 broadcast 192.168.1.255 netmask 255.255.255.0 post-up /sbin/ip link set tap0 up post-up /usr/sbin/brctl addif br0 tap0 post-up /sbin/ip link set eth1 up post-up /usr/sbin/brctl addif br0 eth1 post-down /usr/sbin/brctl delbr br0 post-down /usr/sbin/openvpn --rmtun --dev tap0 post-down /sbin/ip link set eth1 down The Shorewall configuration is just a Simple Bridge.
shorewall-docs-xml-5.0.15/two-interface_fr.xml0000644000000000000000000020170413020330134017775 0ustar rootroot
Firewall à deux interfaces Version Française de Basic Two-Interface Firewall Tom Eastep Patrice Vetsel Traduction française initiale Fabien Demassieux Adaptation française version 2.0 Guy Marcenac Adaptation française version 3.0 et version 4.0 2002-2007 Thomas M. Eastep Patrice Vetsel Fabien Demassieux 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 : Le guide initial a été traduit par VETSEL Patrice et la pour la version 2 de Shorewall a été effectuée par Fabien Demassieux. J'ai assuré la révision pour l'adapter à la version 3 de Shorewall. Si vous trouvez des erreurs ou des améliorations à y apporter vous pouvez me contacter. Cet article s'applique à Shorewall 4.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. Ne tentez pas d'installer Shorewall sur un système distant. Il est pratiquement certain que vous vous enfermerez à l'extérieur de ce système.
Introduction Mettre en place un système Linux en tant que firewall pour un petit réseau est une chose assez simple, si vous comprenez les bases et que vous suivez la documentation. Ce guide ne prétend pas vous apprendre tous les rouages de Shorewall. Il se concentre sur ce qui est nécessaire pour configurer Shorewall dans son utilisation la plus courante: Un système Linux utilisé en tant que firewall/routeur pour un petit réseau local. Une seule adresse IP publique. Si vous avez plus d'une adresse IP publique, ce n'est pas le guide qui vous convient -- regardez plutôt du coté du Guide de Configuration Shorewall. Une connexion passant par un modem câble, ADSL, ISDN-RNIS, Frame Relay, RTC... Voici le schéma d'une installation typique:
Configuration standard d'un firewall avec deux interfaces
Si vous éditez vos fichiers de configuration sur un système Windows, vous devez les enregistrer comme des fichiers Unix si votre éditeur supporte cette option sinon vous devez les convertir avec dos2unix avant d'essayer de les utiliser. De la même manière, si vous copiez un fichier de configuration depuis votre disque dur Windows vers une disquette, vous devez lancer dos2unix sur la copie avant de l'utiliser avec Shorewall. Windows Version of dos2unix Linux Version of dos2unix
Pré-requis Système Shorewall a besoin que le package iproute/iproute2 soit installé (avec la distribution RedHat, le package s'appelle iproute). Vous pouvez vérifier que le package est installé en contrôlant la présence du programme ip sur votre firewall. En tant que root, vous pouvez utiliser la commande which pour cela: [root@gateway root]# which ip /sbin/ip [root@gateway root]# Je vous recommande de commencer par une lecture complète du guide afin de vous familiariser avec les concepts mis en oeuvre, puis de recommencer la lecture et seulement alors d'appliquer vos modifications de configuration.
Conventions Les points où des modifications s'imposent sont indiqués par . Les notes de configuration qui sont propres à LEAF/Bering sont marquées avec .
PPTP/ADSL Si vous êtes équipé d'un modem ADSL et que vous utilisez PPTP pour communiquer avec un serveur à travers ce modem, vous devez faire les changements suivants en plus de ceux décrits ci-dessous. ADSL avec PPTP est répandu en Europe, notamment en Autriche.
Les Concepts de Shorewall Les fichiers de configuration pour Shorewall sont situés dans le répertoire /etc/shorewall -- pour de simples paramétrages, vous n'aurez à faire qu'avec quelques-uns d'entre eux comme décrit dans ce guide. Note aux utilisateurs de Debian et de Ubuntu 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. Après avoir installé Shorewall, vous pourrez trouver les exemples de la manière suivante: Si vous avez installé en utilisant un RPM, les exemples seront dans le sous-répertoire Samples/two-interfaces/ du répertoire de la documentation de Shorewall. Si vous ne savez pas où se trouve le répertoire de la documentation de Shorewall, vous pouvez trouver les exemples en utilisant cette commande: ~# rpm -ql shorewall-common | fgrep two-interfaces /usr/share/doc/packages/shorewall/Samples/two-interfaces /usr/share/doc/packages/shorewall/Samples/two-interfaces/interfaces /usr/share/doc/packages/shorewall/Samples/two-interfaces/masq /usr/share/doc/packages/shorewall/Samples/two-interfaces/policy /usr/share/doc/packages/shorewall/Samples/two-interfaces/routestopped /usr/share/doc/packages/shorewall/Samples/two-interfaces/rules /usr/share/doc/packages/shorewall/Samples/two-interfaces/zones ~# Si vous avez installé depuis le tarball, les exemples sont dans le répertoire Samples/two-interfaces du tarball. Si vous avez installé en utilisant un .deb de Shorewall 3.x, les exemples sont dans /usr/share/doc/shorewall/examples/two-interface. Il vous faut installer le paquetage shorewall-doc. Si vous avez installé en utilisant un .deb de Shorewall 4.x, les exemples sont dans /usr/share/doc/shorewall-common/examples/two-interface. Vous n'avez pas besoin d'installer le paquetage shorewall-doc pour pouvoir accéder aux exemples. Si vous installez la version 3.4.0 de Shorewall ou une version ultérieure, au fur et à mesure de la présentation de chaque fichier, je vous suggère de jeter un oeil à ceux qui sont physiquement présents sur votre système et que vous voyez la page de manuel (man page) pour ce fichier. Par exemple, tapez man shorewall-zones à l'invite du système pour voir la page de manuel du fichier /etc/shorewall/zones. Si vous installez une version antérieure à shorewall 3.4.0, au fur et à mesure de la présentation de chaque fichier, je vous suggère de jeter un oeil à ceux qui sont physiquement présents sur votre système -- chacun de ces fichiers contient des instructions de configuration détaillées et des entrées par défaut. Shorewall voit le réseau où il fonctionne, comme étant composé d'un ensemble de zones. Dans une configuration avec deux interfaces, les noms de zone suivants sont utilisés:#ZONE TYPE OPTIONS IN OUT # OPTIONS OPTIONS fw firewall net ipv4 loc ipv4 Les zones de Shorewall sont définies dans le fichier /etc/shorewall/zones. Remarquez que Shorewall reconnaît le système de firewall comme sa propre zone. Quand le fichier /etc/shorewall/zones est traité, le nom de la zone firewall est stocké dans la variable d'environnement $FW, qui peut être utilisée depuis l'ensemble des autres fichiers de configuration de Shorewall pour faire référence au firewall lui-même. Les règles à propos du trafic à autoriser et à interdire sont exprimées en utilisant le terme de zones. Vous exprimez votre politique par défaut pour les connexions d'une zone vers une autre zone dans le fichier /etc/shorewall/policy. Vous définissez les exceptions à ces politiques pas défaut dans le fichier /etc/shorewall/rules. Pour chaque connexion demandant à entrer dans le firewall, la requête est en premier lieu vérifiée par rapport au contenu du fichier /etc/shorewall/rules. Si aucune règle dans ce fichier ne correspond à la demande de connexion alors la première politique dans le fichier /etc/shorewall/policy qui y correspond sera appliquée. S'il y a une action commune définie pour cette politique dans /etc/shorewall/actions ou dans /usr/share/shorewall/actions.std cette action commune sera exécutée avant que la politique ne soit appliquée. Le but de l'action commune est double: Elle ignore (DROP) ou rejette (REJECT) silencieusement le trafic courant qui n'est pas dangereux qui sans cela encombrerait votre fichier journal - les messages de broadcast, par exemple. Elle garantit que le trafic nécessaire à un fonctionnement normal est autorisé à traverser le firewall — ICMP fragmentation-needed par exemple Le fichier /etc/shorewall/policy inclus dans l'archive d'exemple (two-interface) contient les politiques suivantes: #SOURCE DEST POLICY LOG LEVEL LIMIT:BURST loc net ACCEPT net all DROP info all all REJECT infoDans le fichier d'exemple (two-interface), la ligne suivante est incluse mais elle est commentée. Si vous voulez que votre firewall puisse avoir un accès complet aux serveurs sur internet, dé-commentez cette ligne.#SOURCE DEST POLICY LOG LEVEL LIMIT:BURST $FW net ACCEPT Ces politiques vont: Autoriser (ACCEPT) toutes les demandes de connexion depuis votre réseau local vers internet Ignorer (DROP) toutes les demandes de connexion depuis internet vers votre firewall ou votre réseau local Autoriser (ACCEPT) toutes les demandes de connexion de votre firewall vers internet (si vous avez dé-commenté la politique additionnelle) Rejeter (REJECT) toutes les autres requêtes de connexion. Il est important de remarquer que les politiques Shorewall (ainsi que les règles) font référence à des connexions et non pas à un flux de paquets. Avec les politiques définies dans le fichier /etc/shorewall/policy présenté plus haut, les connexions sont autorisées de la zone loc vers la zone net même si les connexions ne sont pas permises de la zone loc vers le firewall lui-même. A ce point, éditez votre fichier /etc/shorewall/policy et faites-y les changements que vous désirez.
Interfaces Réseau Le firewall possède deux interfaces réseau. Lorsque la connexion internet passe par un modem câble ou ADSL, l'Interface Externe sera l'adaptateur ethernet qui est connecté à ce Modem (par exemple eth0). Par contre, si vous vous connectez avec PPPoE (Point-to-Point Protocol over Ethernet) ou avec PPTP (Point-to-Point Tunneling Protocol), l'interface externe sera une interface ppp (par exemple ppp0). Si vous vous connectez avec un simple modem RTC, votre interface externe sera aussi ppp0. Si vous vous connectez en utilisant l'ISDN, votre interface externe sera ippp0. Assurez-vous de savoir laquelle de vos interfaces est l'interface externe. Certains utilisateurs qui avaient configuré la mauvaise interface ont passé des heures avant de comprendre leur erreur. Si vous n'êtes pas sûr, tapez la commande ip route ls en tant que root. L'interface listée à la fin (default) devrait être votre interface externe. Exemple: root@lists:~# ip route ls 192.168.1.1 dev eth0 scope link 192.168.2.2 dev tun0 proto kernel scope link src 192.168.2.1 192.168.3.0/24 dev br0 proto kernel scope link src 192.168.3.254 10.13.10.0/24 dev tun1 scope link 192.168.2.0/24 via 192.168.2.2 dev tun0 192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.254 206.124.146.0/24 dev eth0 proto kernel scope link src 206.124.146.176 10.10.10.0/24 dev tun1 scope link default via 206.124.146.254 dev eth0 root@lists:~# Dans cette exemple, l'interface externe est eth0. Si votre interface vers l'extérieur est ppp0 ou ippp0 alors il faut mettre CLAMPMSS=yes dans le fichier /etc/shorewall/shorewall.conf. Votre Interface Interne (interface vers votre réseau local LAN) sera un adaptateur ethernet (eth1 or eth0) et sera connectée à un hub ou un switch. Vos autres ordinateurs seront connectés à ce même hub ou switch (note: Si vous avez un seul ordinateur, vous pouvez y connecter le firewall directement en utilisant un câble croisé). Ne connectez pas les interfaces interne et externe sur le même hub ou le même switch, sauf à des fins de test. Vous pouvez tester en utilisant ce type de configuration si vous spécifiez l'option arp_filter ou l'option arp_ignore dans le fichier /etc/shorewall/interfaces, et ce pour toutes les interfaces connectées au hub/switch commun. Il est très fortement déconseillé d'utiliser une telle configuration avec un firewall en production. Le fichier de configuration d'exemple pour un firewall à deux interfaces suppose que votre interface externe est eth0 et que l'interface interne est eth1. Si votre configuration est différente, vous devrez modifier le fichier /etc/shorewall/interfaces en conséquence. Tant que vous y êtes, vous pourriez parcourir la liste des options qui sont spécifiées pour les interfaces. Quelques astuces: Si votre interface vers l'extérieur est ppp0 ou ippp0, vous pouvez remplacer le detect dans la seconde colonne par un - (sans guillemets). Si votre interface vers l'extérieur est ppp0 or ippp0 ou si vous avez une adresse IP statique, vous pouvez enlever dhcp dans la liste des options . Si votre interface est un bridge utilisant l'utilitaire brctl alors vous devez ajouter l'option routeback à la liste des options.
Adresses IP Avant d'aller plus loin, nous devons dire quelques mots au sujet des adresses IP. Normalement, votre Fournisseur d' Accès Internet (FAI) ne vous allouera qu'une seule adresse IP. Cette adresse peut vous être allouée par DHCP (Dynamic Host Configuration Protocol), lors de l'établissement de votre connexion (modem standard) ou bien lorsque vous établissez un autre type de connexion PPP (PPPoA, PPPoE, etc.). Dans certains cas , votre fournisseur peut vous allouer une adresse statique IP. Dans ce cas vous devez configurer l'interface externe de votre firewall afin d'utiliser cette adresse de manière permanente. Quelle que soit la façon dont votre adresse externe vous est attribuée, elle va être partagée par tous vos systèmes lors de l'accès à internet. Vous devrez assigner vos propres adresses au machines de votre réseau local (votre interface interne sur le firewall ainsi que les autres ordinateurs). La RFC 1918 réserve des plages d'adresses IP pour l'utilisation dans les réseau privés: 10.0.0.0 - 10.255.255.255 172.16.0.0 - 172.31.255.255 192.168.0.0 - 192.168.255.255 Avant de lancer Shorewall, il faut regarder l'adresse IP de votre interface externe, et, si elle est dans l'une des plages précédentes, vous devez enlever l'option "norfc1918" dans la ligne concernant l'interface externe dans le fichier /etc/shorewall/interfaces. Pour déterminer l'adresse IP de votre interface externe, en tant que root tapez ip addr ls dev <interface> à l'invite du système. <interface> étant votre interface externe. La ligne qui commence par inet vous donne votre adresse IP. Exemple: root@lists:~# ip addr ls dev eth0 2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc htb qlen 1000 link/ether 00:02:e3:08:48:4c brd ff:ff:ff:ff:ff:ff inet 206.124.146.176/24 brd 206.124.146.255 scope global eth0 inet6 fe80::202:e3ff:fe08:484c/64 scope link valid_lft forever preferred_lft forever root@lists:~# Dans cet exemple, l'adresse IP de votre interface externe est 206.124.146.176 Vous devrez allouer vos adresses depuis le même sous-réseau (subnet). Pour ce faire, nous pouvons considérer un sous-réseau comme étant une plage d'adresses allant de x.y.z.0 à x.y.z.255. Un tel sous-réseau aura un masque (subnet mask) de 255.255.255.0. L'adresse x.y.z.0 est réservée comme l'adresse de sous-réseau (Subnet Address) et l'adresse x.y.z.255 est réservée en tant qu'adresse de diffusion (broadcast). Dans Shorewall, un tel sous-réseau est décrit en utilisant la notation CIDR (Classless InterDomain Routing) qui consiste en l'adresse du sous-réseau suivie par /24. Le 24 indiquant le nombre consécutif de bits à 1 dans la partie gauche du masque de sous-réseau. Un exemple de sous-réseau : Etendue: 10.10.10.0 - 10.10.10.255 Adresse de sous-réseau: 10.10.10.0 Adresse de diffusion: 10.10.10.255 Notation CIDR: 10.10.10.0/24
La convention veut que l'on affecte à l'interface interne du firewall la première adresse utilisable du sous-réseau (10.10.10.1 dans l'exemple précédent) ou bien la dernière adresse utilisable (10.10.10.254). L'un des objectifs de la gestion en sous-réseaux est de permettre à tous les ordinateurs du sous-réseau de savoir avec quels autres ordinateurs ils peuvent communiquer directement. Pour communiquer avec des systèmes en dehors du sous-réseau auquel ils appartiennent, les ordinateurs doivent envoyer leurs paquets par l'intermédiaire d'une passerelle (gateway). Vos ordinateurs locaux (computer 1 et computer 2 dans le diagramme) doivent être configurés avec leur passerelle par défaut (default gateway) pointant sur l'adresse IP de l'interface interne du firewall. Cette brève présentation ne fait qu'effleurer la question des sous-réseaux et du routage. Si vous voulez en apprendre plus sur l'adressage IP et le routage, je recommande IP Fundamentals: What Everyone Needs to Know about Addressing & Routing, Thomas A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0 (link). Dans le reste de ce guide on prendra l'hypothèse que vous avez configuré votre réseau comme montré ci-dessous : La passerelle par défaut pour les ordinateurs Computer 1 et Computer 2 sera 10.10.10.254. Votre FAI (fournisseur d'accès internet) pourrait vous allouer une adresse de la RFC 1918 pour votre interface externe. Si cette adresse est le sous-réseau 10.10.10.0/24 alors vous aurez besoin d'un sous-réseau RFC 1918 DIFFÉRENT pour votre réseau local.
IP Masquerading (SNAT) On désigne parfois les adresses réservées par la RFC 1918 comme étant non-routables, car les routeurs centraux d'internet (backbone) ne font pas suivre les paquets qui ont une adresse de destination appartenant à la RFC-1918. Lorsqu'un de vos systèmes en local (supposons Computer 1 dans le schéma ci-dessus) envoie une demande de connexion à un serveur internet, le firewall doit effectuer une traduction d'adresse réseau ou Network Address Translation (NAT). Le firewall réécrit l'adresse source dans le paquet et la remplace par l'adresse de l'interface externe du firewall; en d'autres termes, le firewall fait croire à l'hôte destination sur internet que c'est le firewall lui même qui initie la connexion. Ceci est nécessaire afin que l'hôte de destination soit capable de renvoyer les paquets au firewall (souvenez vous que les paquets qui ont pour adresse de destination une adresse réservée par la RFC 1918 ne peuvent pas être routés à travers internet, donc l'hôte internet ne peut adresser sa réponse à l'ordinateur 1). Lorsque le firewall reçoit le paquet de réponse, il réécrit l'adresse de destination à 10.10.10.1 et fait passer le paquet vers l'ordinateur Computer 1. Sur les systèmes Linux, ce procédé est souvent appelé IP Masquerading mais vous verrez aussi le terme de traduction d'adresses source ou Source Network Address Translation (SNAT). Shorewall suit la convention utilisée avec Netfilter: Masquerade désigne le cas ou vous laissez votre firewall détecter automatiquement l'adresse de votre interface externe. SNAT désigne le cas où vous spécifiez explicitement l'adresse source des paquets sortant de votre réseau local. Sous Shorewall, autant le Masquerading que la SNAT sont configurés avec des entrées dans le fichier /etc/shorewall/masq. Vous utiliserez normalement le Masquerading si votre adresse IP externe est dynamique, et la SNAT si votre adresse IP externe est statique. Si l'interface externe de votre firewall est eth0, vous n'avez pas besoin de modifier le fichier fourni avec l'exemple. Dans le cas contraire, éditez /etc/shorewall/masq et changez la première colonne par le nom de votre interface externe, et la seconde colonne par le nom de votre interface interne. Si votre adresse externe IP est statique, vous pouvez la mettre dans la troisième colonne (SNAT) dans /etc/shorewall/masq si vous le désirez. De toutes façons votre firewall fonctionnera bien si vous laissez cette colonne vide. Le fait de mettre votre adresse IP statique dans la troisième colonne permet un traitement des paquets sortants un peu plus efficace. Si vous utilisez un paquetage Debian, vérifiez dans votre fichier de configuration shorewall.conf que la valeur suivante est convenablement paramétrée, sinon faites les changements nécessaires: IP_FORWARDING=On
Transfert de ports (DNAT) Un de vos objectifs est peut-être de faire tourner un ou plusieurs serveurs sur nos ordinateurs locaux. Comme ces ordinateurs ont une adresse RFC-1918, il n' est pas possible pour les clients sur internet de s'y connecter directement. Il faudra plutôt à que ces clients adressent leurs demandes de connexion au firewall qui réécrira l'adresse de votre serveur comme adresse de destination, puis lui fera passer le paquet. Lorsque votre serveur retournera sa réponse, le firewall appliquera automatiquement une règle SNAT pour réécrire l'adresse source dans la réponse. Ce procédé est appelé transfert de port (Port Forwarding) ou traduction d'adresses réseau destination ou Destination Network Address Translation (DNAT). Vous configurez le transfert de port en utilisant des règles DNAT dans le fichier /etc/shorewall/rules. La forme générale d'une simple règle de transfert de port dans /etc/shorewall/rules est: #ACTION SOURCE DEST PROTO DEST PORT(S) DNAT net loc:<server local ip address>[:<server port>] <protocol> <port> Assurez-vous d'ajouter vos règles après la ligne contenant SECTION NEW. Le serveur doit avoir une adresse IP statique. Si vous utilisez DHCP pour attribuer les adresses de votre système local, vous devez configurer votre serveur DHCP pour qu'il attribue toujours la même adresse IP aux hôtes cible d'une règle DNAT. Shorewall possède des macros pour de nombreuses applications. Regardez le résultat de la commande shorewall show macros pour avoir une liste des macros comprises dans votre version de Shorewall. Les macros simplifient la création de règles DNAT en fournissant directement le protocole et le(s) port(s) pour un service standard comme on peut le voir dans les exemples suivants: Serveur Web Si vous voulez faire tourner un serveur Web sur l'ordinateur Computer 2 dans le diagramme ci-dessus et que vous voulez faire passer les requêtes TCP sur le port 80 à ce système : #ACTION SOURCE DEST PROTO DEST PORT(S) Web/DNAT net loc:10.10.10.2 Serveur FTP Si vous faites tourner un serveur FTP sur l'ordinateur Computer 1 et que vous voulez re-diriger les requêtes TCP entrantes sur le port 21 vers ce système: #ACTION SOURCE DEST PROTO DEST PORT(S) FTP/DNAT net loc:10.10.10.1 Pour FTP, vous aurez aussi besoin d'avoir le support du suivi de connexion et du NAT pour FTP dans votre noyau (kernel). Pour les noyaux fournis dans une distribution, cela veut dire que les modules ip_conntrack_ftp et ip_nat_ftp (nf_conntrack_ftp et nf_nat_ftp dans les noyaux 2.6) doivent être disponibles. Shorewall chargera automatiquement ces modules si ils sont disponibles à leur emplacement habituel /lib/modules/<kernel version>/kernel/net/ipv4/netfilter. Pour plus d'information, reportez-vous à la documentation Shorewall FTP. Deux points importants sont à garder en mémoire : Vous devez tester les règles précédentes depuis un client à l'extérieur de votre réseau local (c.a.d., ne pas tester depuis un navigateur tournant sur l'ordinateur Computer 1 ou Computer 2 ni sur le firewall). Si vous voulez avoir la possibilité d'accéder à votre serveur web ou FTP depuis l'intérieur de votre firewall en utilisant l'adresse de l'interface externe IP, consultez Shorewall FAQ #2. Quelques Fournisseurs d'Accès Internet (FAI) bloquent les requêtes de connexion entrantes sur le port 80. Si vous avez des problèmes pour vous connecter à votre serveur web, essayez la règle suivante et connectez vous sur le port 5000 (c.a.d., connectez vous à http://w.x.y.z:5000 ou w.x.y.z est votre IP externe). #ACTION SOURCE DEST PROTO DEST PORT(S) DNAT net loc:10.10.10.2:80 tcp 5000 Maintenant, modifiez /etc/shorewall/rules pour ajouter les règles DNAT dont vous avez besoin. Quand vous testez des règles DNAT telles que celles présentées plus haut, vous devez les tester depuis un client A L'EXTÉRIEUR DE VOTRE FIREWALL (depuis la zone net). Vous ne pouvez pas tester ces règles de l'intérieur ! Pour des astuces en cas de problème avec la DNAT, allez lire les FAQ 1a et 1b. Si vous avez besoin d'information pour paramétrer les règles DNAT pour des adresses externes multiples, consultez la Shorewall Aliased Interface documentation et le Guide de configuration Shorewall.
Service de Noms de Domaines (DNS) Normalement, quand vous vous connectez à votre fournisseur d'accès (FAI), en même temps que vous obtenez votre adresse IP, votre resolver pour le Service des Noms de Domaines ou Domain Name Service (DNS) pour le firewall est configuré automatiquement (c.a.d., le fichier /etc/resolv.conf est mis à jour). Il arrive que votre fournisseur d'accès vous donne une paire d'adresse IP pour les serveurs DNS afin que vous configuriez manuellement vos serveurs de noms primaire et secondaire. Quelle que soit la manière dont le DNS est configuré sur votre firewall, il est de votre responsabilité de configurer le resolver sur chacun de vos systèmes internes. Vous pouvez procéder d'une de ces deux façons : Vous pouvez configurer votre système interne pour utiliser les serveurs de noms de votre fournisseur d'accès. Si votre fournisseur vous donne les adresses de ses serveurs ou si ces adresses sont disponibles sur son site web, vous pouvez les utiliser pour configurer vos systèmes internes. Si cette information n' est pas disponible, regardez dans /etc/resolv.conf sur votre firewall -- les noms des serveurs sont donnés dans l'enregistrement "nameserver" de ce fichier. Vous pouvez configurer un cache DNS (Caching Name Server) sur votre firewall. Red Hat fournit un RPM pour serveur cache DNS (ce RPM à aussi besoin aussi du paquetage RPM bind) et pour les utilisateurs de Bering, il y a le paquetage dnscache.lrp. Si vous adoptez cette approche, vous configurez vos systèmes internes pour utiliser le firewall lui même comme étant le seul serveur de noms primaire. Vous utilisez l'adresse IP interne du firewall (10.10.10.254 dans l'exemple précédent) pour adresse du serveur de nom. Pour permettre à vos systèmes locaux d'accéder à votre serveur cache DNS, vous devez ouvrir le port 53 (à la fois UDP and TCP) depuis le réseau local vers le firewall; vous ferez ceci en ajoutant les règles suivantes dans /etc/shorewall/rules. #ACTION SOURCE DEST PROTO DEST PORT(S) DNS/ACCEPT loc $FW
Autres Connexions Les fichiers exemples inclus dans l'archive pour le firewall à deux interfaces (two-interface) contiennent les règles suivantes :#ACTION SOURCE DEST PROTO DEST PORT(S) DNS/ACCEPT $FW netCes règles autorisent l'accès DNS à partir de votre firewall et peuvent être enlevées si vous avez dé-commenté la ligne dans /etc/shorewall/policy autorisant toutes les connexions depuis le firewall vers internet. Dans la règle ci-dessus, DNS/ACCEPT est un exemple d'invocation d'une macro. Shorewall offre un certain nombre de macros pré-définies (voir /usr/share/shorewall/macro.*). Vous pouvez également ajouter vos propres macros. Vous n'êtes pas obligés d'utiliser des macros. Vous pouvez aussi ajouter des régles dans le fichier /etc/shorewall/rules. Shorewall démarrera légèrement plus rapidement si vous codez directement vos règles que si vous utilisez les macros. La régle vue ci-dessus aurait également pu être codée comme cela: #ACTION SOURCE DEST PROTO DEST PORT(S) ACCEPT $FW net udp 53 ACCEPT $FW net tcp 53 Au cas ou Shorewall n'inclue pas de macro pré-définie qui vous convienne, vous pouvez définir une macro vous-même ou bien coder directement les régles appropriées. L'exemple inclue aussi la règle suivante: #ACTION SOURCE DEST PROTO DEST PORT(S) SSH/ACCEPT loc $FWCette régle autorise un serveur SSH sur votre firewall et la connexion à celui-ci depuis votre réseau local. Si vous souhaitez autoriser d'autre connexions de votre firewall vers d'autres systèmes, la syntaxe générale d'une macro est: #ACTION SOURCE DEST PROTO DEST PORT(S) <macro>/ACCEPT $FW <destination zone>La syntaxe générale lorsqu'on n'utilise pas de macro est:#ACTION SOURCE DEST PROTO DEST PORT(S) ACCEPT $FW <destination zone> <protocol> <port> Serveur Web sur le Firewall Si vous voulez ouvrir un serveur web sur votre firewall et que vous voulez le rendre accessible depuis le réseau local et depuis l'extérieur: #ACTION SOURCE DEST PROTO DEST PORT(S) Web/ACCEPT net $FW Web/ACCEPT loc $FWCes deux régles devraient évidemment s'ajouter à celles listées avant dans Vous pouvez configurer un cache DNS sur votre firewall. Si vous ne savez pas quel port(s) et protocole(s) une application particulière utilise, vous pouvez regarder ici. Je ne recommande pas d'autoriser telnet vers/de internet parce qu'il utilise du texte en clair (même pour le login !). Si vous voulez un accès shell à votre firewall, utilisez SSH:#ACTION SOURCE DEST PROTO DEST PORT(S) SSH/ACCEPT net $FW Les utilisateurs de Bering pourront ajouter les deux régles suivantes pour rester compatible avec la configuration du firewall de Jacques (Jacques's Shorewall configuration).#ACTION SOURCE DEST PROTO DEST PORT(S) ACCEPT loc $FW udp 53 #Allow DNS Cache to work ACCEPT loc $FW tcp 80 #Allow Weblet to work Maintenant, éditez votre fichier de configuration /etc/shorewall/rules pour ajouter, modifier ou supprimer d'autres connexions suivant vos besoins.
Journalisation (log) Shorewall ne produit pas un fichier journal lui-même, mais il s'appuie sur votre configuration de la journalisation système. Les commandes suivantes nécessitent un bonne configuration de la journalisation, car elles ont besoin de connaître le fichier dans lequel netfilter enregistre ses messages. shorewall show log (Affiche les 20 derniers messages enregistrés par netfilter) shorewall logwatch (Consulte le fichier journal à un intervalle régulier paramétrable) shorewall dump (Produit un état très détaillé à inclure à vos rapports d'anomalie) Il est important que ces commandes fonctionnent correctement. En effet, lorsque vous rencontrez des problèmes de connexion alors que shorewall est actif, la première chose que vous devriez faire est de regarder le journal netfilter, et vous pourrez généralement résoudre rapidement votre problème en vous aidant de la FAQ 17 de Shorewall. La plupart du temps, les messages de Netfilter sont journalisés dans le fichier /var/log/messages. Certaines version récentes de SuSE/OpenSuSE sont pré configurées pour utiliser syslog-ng et journalisent les messages de netfilter dans le fichier /var/log/firewall. Si votre distribution enregistre les message de netfilter dans un autre fichier que /var/log/messages, il faut modifier le paramètre LOGFILE dans le fichier /etc/shorewall/shorewall.conf et y spécifier le nom de votre fichier journal. Le paramètre LOGFILE ne contrôle pas le fichier dans lequel netfilter va enregistrer ses messages -- Il indique simplement à /sbin/shorewalloù trouver le fichier journal.
Quelques Points à Garder en Mémoire Vous ne pouvez pas tester votre firewall depuis l'intérieur de votre réseau. Envoyer des requêtes à l'adresse IP externe de votre firewall ne signifie pas qu'elle seront associées à votre interface externe ou à la zone net. Tout trafic généré par le réseau local sera associé à l'interface locale et sera traité comme du trafic du réseau local vers le firewall (loc->fw). Les adresses IP sont des propriétés des systèmes, pas des interfaces. C'est une erreur de croire que votre firewall est capable de faire suivre (forward) des paquets simplement parce que vous pouvez faire un ping sur l'adresse IP de toutes les interfaces du firewall depuis le réseau local. La seule conclusion que vous puissiez tirer dans ce cas est que le lien entre le réseau local et le firewall fonctionne et que vous avez probablement la bonne adresse de passerelle par défaut sur votre système. Toutes les adresses IP configurées sur le firewall sont dans la zone $FW (fw). Si 192.168.1.254 est l'adresse IP de votre interface interne, alors vous pouvez écrire $FW:192.168.1.254 dans une régle mais vous ne devez pas écrire loc:192.168.1.254. C'est aussi une absurdité d'ajouter 192.168.1.254 à la zone loc en utilisant une entrée dans /etc/shorewall/hosts. Les paquets de retour (reply) ne suivent PAS automatiquement le chemin inverse de la requête d'origine. Tous les paquets sont routés en se référant à la table de routage respective de chaque hôte à chaque étape du trajet. Ce problème se produit en général lorsque on installe un firewall Shorewall en parallèle à une passerelle existante et qu'on essaye d'utiliser des règles DNAT dans Shorewall sans changer la passerelle par défaut sur les systèmes recevant les requêtes transférées (forwarded). Les requêtes passent dans le firewall Shorewall où l'adresse de destination IP est réécrite, mais la réponse revient par l'ancienne passerelle qui, elle, ne modifiera pas le paquet. Shorewall lui-même n'a aucune notion du dedans et du dehors. Ces concepts dépendent de la façon dont Shorewall est configuré.
Démarrer et Arrêter Votre Firewall La procédure d'installation configure votre système pour lancer Shorewall dès le boot du système, mais le lancement est désactivé, de façon à ce que votre système ne tente pas de lancer Shorewall avant que la configuration ne soit terminée. Une fois que vous en avez fini avec la configuration du firewall, vous devez éditer /etc/shorewall/shorewall.conf et y mettre STARTUP_ENABLED=Yes. Les utilisateurs des paquetages .deb doivent éditer /etc/default/shorewall et mettre startup=1. Le firewall est activé en utilisant la commande shorewall start et arrêté avec la commande shorewall stop. Lorsque le firewall est arrêté, le routage est autorisé sur les hôtes qui possèdent une entrée dans /etc/shorewall/routestopped. Un firewall qui tourne peut être relancé en utilisant la commande shorewall restart. Si vous voulez enlever toute trace de Shorewall sur votre configuration de Netfilter, utilisez shorewall clear Les fichier de l'exemple Firewall à Deux Interfaces (two-interface) supposent que vous voulez autoriser le routage depuis ou vers eth1 (le réseau local) lorsque Shorewall est arrêté. Si votre réseau local n' est pas connecté à eth1 ou que vous voulez permettre l'accès depuis ou vers d'autres hôtes, modifiez /etc/shorewall/routestopped en conséquence. Si vous êtes connecté à votre firewall depuis internet, n'essayez pas d'exécuter une commande shorewall stop tant que vous n'avez pas ajouté une entrée dans /etc/shorewall/routestopped pour l'adresse IP à partir de laquelle vous êtes connecté . De la même manière, je vous déconseille d'utiliser shorewall restart; il est plus intéressant de créer une configuration alternative et de la tester en utilisant la commande shorewall try
Si cela ne marche pas Vérifiez à nouveau chacun des points repérés par un flèche rouge. Vérifiez vos journaux. Vérifiez le Troubleshooting Guide. Vérifiez la FAQ.
Autres Lectures Recommandées Je vous recommande vivement de lire la page des Fonctionnalités Générales des Fichiers de Configuration -- elle contient des astuces sur des possibilités de Shorewall qui peuvent rendre plus aisée l'administration de votre firewall Shorewall.
Ajouter un Segment Sans-fil à votre Firewall à deux interfaces Maintenant que vous avez une configuration à deux interfaces qui marche, l'étape suivante logique est d'ajouter un réseau sans-fil. La première chose à faire est d'ajouter une carte à votre firewall, soit une carte sans-fil soit une carte ethernet reliée à un point d'accès sans-fil. Quant vous ajoutez une carte réseau à un machine, il se peut qu'elle ne soit pas détectée comme celle suivant la plus haute interface. Par exemple, si vous avez deux cartes sur votre système (eth0 and eth1) et que vous en ajoutez une troisième qui utilise le même driver qu'une des deux autres, cette troisième carte ne sera pas obligatoirement détectée en tant que eth2. Elle peut très bien être détectée en tant que eth0 ou eth1! Vous pouvez soit faire avec, soit intervertir les cartes dans les slots jusqu'à obtenir la valeur eth2 pour la nouvelle carte. Update: Les distributions s'améliorent sur ce point. SuSE associe maintenant un nom d'interface unique à chaque adresse MAC. D'autres distributions ont des paquetages additionnels qui permettent de gérer la relation entre l'adresse MAC et le nom de périphérique. Votre nouveau réseau ressemblera à la figure ci-dessous. La première chose à remarquer est que les ordinateurs sur votre réseau sans-fil seront sur un sous-réseau différent de celui de votre réseau local câblé LAN. Dans l'exemple, nous avons choisi de lui attribuer le réseau 10.10.11.0/24. Les ordinateurs Computer 3 et Computer 4 seront configurés avec une passerelle par défaut dont l'adresse IP sera 10.10.11.254. Ensuite, nous avons choisi d'inclure le réseau sans-fil à la zone local. Puisque Shorewall autorise le trafic intra-zone par défaut, le trafic pourra circuler librement entre le réseau local câblé et le réseau sans-fil. Il n'y a que deux changements à effectuer à la configuration de Shorewall: Une entrée doit être ajouté au fichier d'interfaces /etc/shorewall/interfaces pour l'interface du réseau sans-fil. Si l'interface du réseau sans-fil est wlan0, l'entrée correspondante devrait ressembler à: #ZONE INTERFACE BROADCAST OPTIONS loc wlan0 detect maclist Comme montré dans l'entrée ci-dessus, je recommande d'utiliser l'option maclist pour le segment sans-fil. En ajoutant les entrées pour les ordinateurs Computer 3 et Computer 4 dans le fichier /etc/shorewall/maclist, vous contribuez à vous assurer que vos voisins n'utiliseront pas votre connexion internet. Commencez sans cette option. Lorsque tout fonctionne, ajoutez l'option et configurez votre fichier /etc/shorewall/maclist. Vous devez ajouter une entrée au fichier /etc/shorewall/masq afin de permettre le trafic de votre réseau sans-fil vers internet. Si votre interface internet est eth0 et votre interface sans-fil est wlan0, l'entrée sera: #INTERFACE SUBNET ADDRESS eth0 wlan0 Autre chose. Pour que le réseau Microsoft fonctionne entre réseau filaire et sans-fil, vous avez besoin d'un serveur WINS ou bien d'un PDC. Personnellement, j'utilise Samba configuré en serveur WINS sur mon firewall. Utiliser un serveur WINS sur le firewall nécessite de configurer les régles nécessaires listées dans le document Shorewall/Samba.
shorewall-docs-xml-5.0.15/shorewall_logging.xml0000644000000000000000000005562213020330134020253 0ustar rootroot
Shorewall Logging Tom Eastep Bill Shirley 2001 - 2016 Thomas M. Eastep Bill Shirley 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. This article applies to Shorewall 4.3 and later. If you are running a version of Shorewall earlier than Shorewall 4.3.5 then please see the documentation for that release.
How to Log Traffic Through a Shorewall Firewall The disposition of packets entering a Shorewall firewall is determined by one of a number of Shorewall facilities. Only some of these facilities permit logging. The packet is part of an established connection. While the packet can be logged using LOG rules in the ESTABLISHED section of /etc/shorewall/rules, that is not recommended because of the large amount of information that may be logged. The packet represents a connection request that is related to an established connection (such as a data connection associated with an FTP control connection). These packets may be logged using LOG rules in the RELATED section of /etc/shorewall/rules. The packet is rejected because of an option in /etc/shorewall/shorewall.conf or /etc/shorewall/interfaces. These packets can be logged by setting the appropriate logging-related option in /etc/shorewall/shorewall.conf. The packet matches a rule in /etc/shorewall/rules. By including a syslog level (see below) in the ACTION column of a rule (e.g., ACCEPT:info net $FW tcp 22), the connection attempt will be logged at that level. The packet doesn't match a rule so it is handled by a policy defined in /etc/shorewall/policy. These may be logged by specifying a syslog level in the LOG LEVEL column of the policy's entry (e.g., loc net ACCEPT info).
Where the Traffic is Logged and How to Change the Destination By default, Shorewall directs Netfilter to log using syslog (8). Syslog classifies log messages by a facility and a priority (using the notation facility.priority). The facilities defined by syslog are auth, authpriv, cron, daemon, kern, lpr, mail, mark, news, syslog, user, uucp and local0 through local7. Throughout the Shorewall documentation, I will use the term level rather than priority since level is the term used by Netfilter. The syslog documentation uses the term priority.
Syslog Levels Syslog levels are a method of describing to syslog (8) the importance of a message. A number of Shorewall parameters have a syslog level as their value. Valid levels are: 7 - debug (Debug-level messages) 6 - info (Informational) 5 - notice (Normal but significant Condition) 4 - warning (Warning Condition) 3 - err (Error Condition) 2 - crit (Critical Conditions) 1 - alert (must be handled immediately) 0 - emerg (System is unusable) For most Shorewall logging, a level of 6 (info) is appropriate. Shorewall log messages are generated by Netfilter and are logged using the kern facility and the level that you specify. If you are unsure of the level to choose, 6 (info) is a safe bet. You may specify levels by name or by number. Beginning with Shorewall 4.5.5, the level name or number may be optionally followed by a comma-separated list of one or more log options. The list is enclosed in parentheses. Log options cause additional information to be included in each log message. Valid log options are: ip_options Log messages will include the option settings from the IP header. macdecode Decode the MAC address and protocol. tcp_sequence Include TCP sequence numbers. tcp_options Include options from the TCP header. uid Include the UID of the sending program; only valid for packets originating on the firewall itself. Example: info(tcp_options,tcp_sequence) Syslogd writes log messages to files (typically in /var/log/*) based on their facility and level. The mapping of these facility/level pairs to log files is done in /etc/syslog.conf (5). If you make changes to this file, you must restart syslogd before the changes can take effect. Syslog may also write to your system console. See Shorewall FAQ 16 for ways to avoid having Shorewall messages written to the console.
Configuring a Separate Log for Shorewall Messages (ulogd) There are a couple of limitations to syslogd-based logging: If you give, for example, kern.info its own log destination then that destination will also receive all kernel messages of levels 5 (notice) through 0 (emerg). All kernel.info messages will go to that destination and not just those from Netfilter. If your kernel has NFLOG target support (and most vendor-supplied kernels do), you may also specify a log level of NFLOG (must be all caps). When NFLOG is used, Shorewall will direct Netfilter to log the related messages via the ULOG target which will send them to a process called ulogd. The ulogd program is included in most distributions and is also available from http://www.netfilter.org/projects/ulogd/index.html. Ulogd can be configured to log all Shorewall messages to their own log file. The NFLOG logging mechanism is completely separate from syslog. Once you switch to ULOG, the settings in /etc/syslog.conf have absolutely no effect on your Shorewall logging (except for Shorewall status messages which still go to syslog). You will need to change all instances of log levels (usually info) in your Shorewall configuration files to NFLOG - this includes entries in the policy, rules and shorewall.conf files. Here's what I had at one time: gateway:/etc/shorewall# grep -v ^\# * | egrep '\$LOG|ULOG|LOGFILE' params:LOG=NFOG policy:loc $FW REJECT $LOG policy:net all DROP $LOG 10/sec:40 policy:all all REJECT $LOG rules:REJECT:$LOG loc net tcp 25 rules:REJECT:$LOG loc net udp 1025:1031 rules:REJECT:$LOG dmz net udp 1025:1031 rules:ACCEPT:$LOG dmz net tcp 1024: 20 rules:REJECT:$LOG $FW net udp 1025:1031 shorewall.conf:LOGFILE=/var/log/shorewall shorewall.conf:LOGUNCLEAN=$LOG shorewall.conf:MACLIST_LOG_LEVEL=$LOG shorewall.conf:TCP_FLAGS_LOG_LEVEL=$LOG shorewall.conf:RFC1918_LOG_LEVEL=$LOG gateway:/etc/shorewall# Finally edit /etc/shorewall/shorewall.conf and set LOGFILE=<file that you wish to log to>. This tells the /sbin/shorewall program where to look for the log when processing its show log, logwatch and dump commands. The NFLOG target is a successor to ULOG. Both ULOG and NFLOG may be followed by a list of up to three numbers in parentheses. The first number specifies the netlink group (0-65535). If omitted (e.g., NFLOG(,0,10)) then a value of 0 is assumed. The second number specifies the maximum number of bytes to copy. If omitted, 0 (no limit) is assumed. The third number specifies the number of log messages that should be buffered in the kernel before they are sent to user space. The default is 1. Examples: /etc/shorewall/shorewall.conf: MACLIST_LOG_LEVEL=NFLOG(1,0,1) /etc/shorewall/rules:#ACTION SOURCE DEST PROTO DPORT ACCEPT:NFLOG(1,0,1) vpn fw tcp ssh,time,631,8080 Shorewall considers ULOG(...) and NFLOG(...) to be log levels, just like info, debug, etc. even though they are not defined by syslog. Here is a copy of a ulogd.conf file that logs to /var/log/firewall. It was contributed by a Shorewall user on IRC: [global] user="ulogd" logfile="/var/log/ulogd/ulogd.log" loglevel=7 plugin="/usr/lib64/ulogd/ulogd_inppkt_NFLOG.so" plugin="/usr/lib64/ulogd/ulogd_filter_IFINDEX.so" plugin="/usr/lib64/ulogd/ulogd_filter_IP2STR.so" plugin="/usr/lib64/ulogd/ulogd_filter_PRINTPKT.so" plugin="/usr/lib64/ulogd/ulogd_output_LOGEMU.so" plugin="/usr/lib64/ulogd/ulogd_raw2packet_BASE.so" stack=log:NFLOG,base1:BASE,ifi1:IFINDEX,ip2str1:IP2STR,print1:PRINTPKT,firewall:LOGEMU [firewall] file="/var/log/firewall" sync=1 This sample config file assumes that NFLOG is being used in logging rules and policies.
Log Backends Netfilter logging allows configuration of multiple backends. Logging backends provide the The low-level forward of log messages. There are currently three backends: LOG (ipt_LOG and ip6t_LOG). Normal kernel-based logging to a syslog daemon. ULOG (ipt_ULOG) ULOG logging as described ablve. Only available for IPv4. netlink (nfnetlink_log) The logging backend behind NFLOG, defined above. The currently-available and currently-selected IPv4 and IPv6 backends are shown in /proc/sys/net/netfilter/nf_log: cat /proc/net/netfilter/nf_log 0 NONE (nfnetlink_log) 1 NONE (nfnetlink_log) 2 ipt_ULOG (ipt_ULOG,ipt_LOG,nfnetlink_log) 3 NONE (nfnetlink_log) 4 NONE (nfnetlink_log) 5 NONE (nfnetlink_log) 6 NONE (nfnetlink_log) 7 NONE (nfnetlink_log) 8 NONE (nfnetlink_log) 9 NONE (nfnetlink_log) 10 ip6t_LOG (ip6t_LOG,nfnetlink_log) 11 NONE (nfnetlink_log) 12 NONE (nfnetlink_log) The magic numbers (0-12) are Linux address family numbers (AF_INET is 2 and AF_INET6 is 10). The name immediately following the number is the currently-selected backend, and the ones in parantheses are the ones that are available. You can change the currently selected backend by echoing it's name into /proc/net/netfilter/nf_log.number. Example - change the IPv4 backend to LOG: sysctl net.netfilter.nf_log.2=ipt_LOG Beginning with Shorewall 4.6.4, you can configure the backend using the LOG_BACKEND option in shorewall.conf(5) and shorewall6.conf(5).
Syslog-ng Here is a post describing configuring syslog-ng to work with Shorewall. Recent SUSE releases come preconfigured with syslog-ng with Netfilter messages (including Shorewall's) are written to /var/log/firewall.
Understanding the Contents of Shorewall Log Messages For general information on the contents of Netfilter log messages, see http://logi.cc/en/2010/07/netfilter-log-format/. For Shorewall-specific information, see FAQ #17.
Customizing the Content of Shorewall Log Messages In addition to the options mentioned above, a certain amount of customization of the Netfilter-generated messages is allowed.
Log Tags In a Shorewall logging rule, the log level can be followed by a log tag as in "DROP:NFLOG:junk". The generated log message will include "chain-name junk DROP".
LOGTAGONLY By setting the LOGTAGONLY option to Yes in shorewall.conf(5) or shorewall6.conf(5), the disposition ('DROP' in the above example) will be omitted. Consider the following rule: #ACTION SOURCE DEST PROTO REJECT(icmp-proto-unreachable):notice:IPv6 loc net 41 # who's using IPv6 tunneling This rule generates the following warning at compile time: WARNING: Log Prefix shortened to "Shorewall:IPv6:REJECT(icmp-p " /etc/shorewall/rules (line 212) and produces the rather ugly prefix "Shorewall:IPv6:REJECT(icmp-p ". Now consider this similar rule: #ACTION SOURCE DEST PROTO REJECT(icmp-proto-unreachable):notice:IPv6,tunneling loc net 41 # who's using IPv6 tunneling With LOGTAGONLY=Yes, no warning is generated and the prefix becomes "Shorewall:IPv6:tunneling:" See the shorewall[6].conf man page for further information about how LOGTAGONLY=Yes can be used.
Log Levels in shorewall[6].conf shorewall.conf(5) and shorewall6.conf(5) have a number of options whose values are log levels. Beginning with Shorewall 5.0.0, these specifcations may include a log tag as described above.
Some Additional Thoughts on Logging (by Bill Shirley) As a side note to the LOGTAGONLY example above, i recommend blocking all tunneling because it bypasses the firewall rules: #ACTION SOURCE DEST PROTO DPORT ?COMMENT tunneling REJECT(icmp-proto-unreachable):notice:IPv6,tunneling loc net 41 # who's using IPv6 tunneling REJECT(icmp-port-unreachable) loc net tcp,udp teredo REJECT(icmp-port-unreachable) loc net tcp,udp isakmp,ipsec-nat-t Here is an example of logging traffic only once: /etc/shorewall/init: ipset -exist create IPv4 hash:ip timeout 86400 ipset -exist create IPv4-port hash:ip,port timeout 14400 /etc/shorewall/rules (at the top): #ACTION SOURCE DEST PROTO ?SECTION NEW # ------------------ ?COMMENT drop previously flagged DROP net:+IPv4[src] fw DROP net:+IPv4-port[src,dst] fw After all the rules have been checked, at the bottom of /etc/shorewall/rules: # ============================================================================= # =============================== H@ck0rz ===================================== # ============================================================================= ?COMMENT dont whack myself REJECT:notice inet:$ME_NET fw ?COMMENT not public ADD(+IPv4-port:src,dst) net fw tcp,udp domain ADD(+IPv4-port:src,dst) net fw tcp ldap,ldaps ADD(+IPv4-port:src,dst) net fw tcp,udp ipp ?COMMENT H@ck0rz ADD(+IPv4:src) net fw tcp ssh ADD(+IPv4:src) net fw tcp ftp,ftps,sftp,telnet,telnets,exec,login,shell,sunrpc ADD(+IPv4:src) net fw tcp,udp ms-sql-s,ms-sql-m ?COMMENT drop if added DROP:info:BAN,IPv4 net:+IPv4[src] fw DROP:info:BAN,IPv4-port net:+IPv4-port[src,dst] fw One final note: I wanted less firewall messages in /var/log/messages so I added to rsyslog.conf: #### RULES #### <-- find this if $msg contains 'Shorewall' then { action(type="omfile" file="/var/log/shorewall.log") # if ($syslogfacility == 0 and $syslogseverity >= 4) then stop # warning # if ($syslogfacility == 0 and $syslogseverity >= 5) then stop # notice if ($syslogfacility == 0 and $syslogseverity >= 6) then stop # info } I log at 'notice' log level if I want the message in /var/log/messages and everything goes to /var/log/shorewall.log. Don't forget to add /var/log/shorewall.log to logrotate.
shorewall-docs-xml-5.0.15/kernel.xml0000644000000000000000000003700413020330134016017 0ustar rootroot
Kernel Configuration Tom Eastep 2001-2006 Thomas M. Eastep 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. This article is unmaintained.
Network Options Configuration Here's a screen shot of my Network Options Configuration: While not all of the options that I've selected are required, they should be sufficient for most applications. Here's an excerpt from the corresponding .config file (Note: If you are running a kernel older than 2.4.17, be sure to select CONFIG_NETLINK and CONFIG_RTNETLINK):
# # Networking options # CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set # CONFIG_NETLINK_DEV is not set CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set CONFIG_FILTER=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_FWMARK=y CONFIG_IP_ROUTE_NAT=y CONFIG_IP_ROUTE_MULTIPATH=y CONFIG_IP_ROUTE_TOS=y CONFIG_IP_ROUTE_VERBOSE=y # CONFIG_IP_ROUTE_LARGE_TABLES is not set # CONFIG_IP_PNP is not set CONFIG_NET_IPIP=y CONFIG_NET_IPGRE=y # CONFIG_NET_IPGRE_BROADCAST is not set # CONFIG_IP_MROUTE is not set # CONFIG_ARPD is not set CONFIG_INET_ECN=y CONFIG_SYN_COOKIES=y
Netfilter Configuration Here's a screen shot of my Netfilter configuration: Note that I have built everything I need as modules. You can also build everything into your kernel but if you want to be able to deal with FTP running on a non-standard port then you must modularize FTP Protocol support. Here's the corresponding part of my .config file:
# # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=m CONFIG_IP_NF_FTP=m CONFIG_IP_NF_AMANDA=m CONFIG_IP_NF_TFTP=m # CONFIG_IP_NF_IRC is not set # CONFIG_IP_NF_QUEUE is not set CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_LIMIT=m CONFIG_IP_NF_MATCH_MAC=m CONFIG_IP_NF_MATCH_PKTTYPE=m CONFIG_IP_NF_MATCH_MARK=m CONFIG_IP_NF_MATCH_MULTIPORT=m CONFIG_IP_NF_MATCH_TOS=m CONFIG_IP_NF_MATCH_ECN=m CONFIG_IP_NF_MATCH_DSCP=m CONFIG_IP_NF_MATCH_AH_ESP=m CONFIG_IP_NF_MATCH_LENGTH=m # CONFIG_IP_NF_MATCH_TTL is not set CONFIG_IP_NF_MATCH_TCPMSS=m CONFIG_IP_NF_MATCH_HELPER=m CONFIG_IP_NF_MATCH_STATE=m CONFIG_IP_NF_MATCH_CONNTRACK=m CONFIG_IP_NF_MATCH_UNCLEAN=m # CONFIG_IP_NF_MATCH_OWNER is not set CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m # CONFIG_IP_NF_TARGET_MIRROR is not set CONFIG_IP_NF_NAT=m CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_IP_NF_NAT_AMANDA=m CONFIG_IP_NF_NAT_LOCAL=y # CONFIG_IP_NF_NAT_SNMP_BASIC is not set CONFIG_IP_NF_NAT_FTP=m CONFIG_IP_NF_NAT_TFTP=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_TOS=m CONFIG_IP_NF_TARGET_ECN=m CONFIG_IP_NF_TARGET_DSCP=m CONFIG_IP_NF_TARGET_MARK=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_TARGET_ULOG=m CONFIG_IP_NF_TARGET_TCPMSS=m CONFIG_IP_NF_ARPTABLES=m CONFIG_IP_NF_ARPFILTER=m # CONFIG_IP_NF_COMPAT_IPCHAINS is not set # CONFIG_IP_NF_COMPAT_IPFWADM is not set
Kernel 2.6 Netfilter Options Here's a screenshot of my modularized 2.6 Kernel config (Navigation: Device Drivers → Networking Support → Networking Options → Network Packet Filtering (replaces ipchains) → IP: Netfilter configuration): Here is the corresponding part of the .config file:
CONFIG_IP_NF_CONNTRACK=m CONFIG_IP_NF_FTP=m CONFIG_IP_NF_IRC=m CONFIG_IP_NF_TFTP=m CONFIG_IP_NF_AMANDA=m CONFIG_IP_NF_QUEUE=m CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_LIMIT=m CONFIG_IP_NF_MATCH_IPRANGE=m CONFIG_IP_NF_MATCH_MAC=m CONFIG_IP_NF_MATCH_PKTTYPE=m CONFIG_IP_NF_MATCH_MARK=m CONFIG_IP_NF_MATCH_MULTIPORT=m CONFIG_IP_NF_MATCH_TOS=m CONFIG_IP_NF_MATCH_RECENT=m CONFIG_IP_NF_MATCH_ECN=m CONFIG_IP_NF_MATCH_DSCP=m CONFIG_IP_NF_MATCH_AH_ESP=m CONFIG_IP_NF_MATCH_LENGTH=m CONFIG_IP_NF_MATCH_TTL=m CONFIG_IP_NF_MATCH_TCPMSS=m CONFIG_IP_NF_MATCH_HELPER=m CONFIG_IP_NF_MATCH_STATE=m CONFIG_IP_NF_MATCH_CONNTRACK=m CONFIG_IP_NF_MATCH_OWNER=m CONFIG_IP_NF_MATCH_PHYSDEV=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_NAT=m CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_IP_NF_TARGET_NETMAP=m CONFIG_IP_NF_TARGET_SAME=m CONFIG_IP_NF_NAT_LOCAL=y CONFIG_IP_NF_NAT_SNMP_BASIC=m CONFIG_IP_NF_NAT_IRC=m CONFIG_IP_NF_NAT_FTP=m CONFIG_IP_NF_NAT_TFTP=m CONFIG_IP_NF_NAT_AMANDA=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_TOS=m CONFIG_IP_NF_TARGET_ECN=m CONFIG_IP_NF_TARGET_DSCP=m CONFIG_IP_NF_TARGET_MARK=m CONFIG_IP_NF_TARGET_CLASSIFY=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_TARGET_ULOG=m CONFIG_IP_NF_TARGET_TCPMSS=m # CONFIG_IP_NF_ARPTABLES is not set # CONFIG_IP_NF_COMPAT_IPCHAINS is not set # CONFIG_IP_NF_COMPAT_IPFWADM is not set # CONFIG_IP_NF_RAW is not set CONFIG_IP_NF_MATCH_ADDRTYPE=m # CONFIG_IP_NF_MATCH_REALM is not set CONFIG_IP6_NF_QUEUE=m CONFIG_IP6_NF_IPTABLES=m CONFIG_IP6_NF_MATCH_LIMIT=m CONFIG_IP6_NF_MATCH_MAC=m CONFIG_IP6_NF_MATCH_RT=m CONFIG_IP6_NF_MATCH_OPTS=m CONFIG_IP6_NF_MATCH_FRAG=m CONFIG_IP6_NF_MATCH_HL=m CONFIG_IP6_NF_MATCH_MULTIPORT=m CONFIG_IP6_NF_MATCH_OWNER=m CONFIG_IP6_NF_MATCH_MARK=m CONFIG_IP6_NF_MATCH_IPV6HEADER=m CONFIG_IP6_NF_MATCH_AHESP=m CONFIG_IP6_NF_MATCH_LENGTH=m CONFIG_IP6_NF_MATCH_EUI64=m CONFIG_IP6_NF_FILTER=m CONFIG_IP6_NF_TARGET_LOG=m CONFIG_IP6_NF_MANGLE=m CONFIG_IP6_NF_TARGET_MARK=m # CONFIG_IP6_NF_RAW is not set CONFIG_DECNET_NF_GRABULATOR=m CONFIG_BRIDGE_NF_EBTABLES=m
Kernel 2.6.16 and Later Netfilter Options Here's a screenshot of my modularized 2.6.16 Kernel config (Navigation: Networking → Networking Options → Network Packet Filtering (replaces ipchains) → Core Netfilter configuration): Note that is is particularly important to select "Netfilter Xtables support (required for ip_tables). Here's a screenshot of the IP Netfilter config (Navigation: Networking → Networking Options → Network Packet Filtering (replaces ipchains) → IP: Netfilter configuration): Here is the corresponding part of the .config file:
# # Core Netfilter Configuration # CONFIG_NETFILTER_NETLINK=m CONFIG_NETFILTER_NETLINK_QUEUE=m CONFIG_NETFILTER_NETLINK_LOG=m CONFIG_NETFILTER_XTABLES=m CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m CONFIG_NETFILTER_XT_TARGET_CONNMARK=m CONFIG_NETFILTER_XT_TARGET_MARK=m CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m CONFIG_NETFILTER_XT_TARGET_NOTRACK=m CONFIG_NETFILTER_XT_MATCH_COMMENT=m CONFIG_NETFILTER_XT_MATCH_CONNBYTES=m CONFIG_NETFILTER_XT_MATCH_CONNMARK=m CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m CONFIG_NETFILTER_XT_MATCH_DCCP=m CONFIG_NETFILTER_XT_MATCH_HELPER=m CONFIG_NETFILTER_XT_MATCH_LENGTH=m CONFIG_NETFILTER_XT_MATCH_LIMIT=m CONFIG_NETFILTER_XT_MATCH_MAC=m CONFIG_NETFILTER_XT_MATCH_MARK=m CONFIG_NETFILTER_XT_MATCH_PHYSDEV=m CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m CONFIG_NETFILTER_XT_MATCH_REALM=m CONFIG_NETFILTER_XT_MATCH_SCTP=m CONFIG_NETFILTER_XT_MATCH_STATE=m CONFIG_NETFILTER_XT_MATCH_STRING=m CONFIG_NETFILTER_XT_MATCH_TCPMSS=m # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=m CONFIG_IP_NF_CT_ACCT=y CONFIG_IP_NF_CONNTRACK_MARK=y CONFIG_IP_NF_FTP=m CONFIG_IP_NF_IRC=m CONFIG_IP_NF_TFTP=m CONFIG_IP_NF_AMANDA=m CONFIG_IP_NF_PPTP=m CONFIG_IP_NF_QUEUE=m CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_IPRANGE=m CONFIG_IP_NF_MATCH_MULTIPORT=m CONFIG_IP_NF_MATCH_TOS=m CONFIG_IP_NF_MATCH_RECENT=m CONFIG_IP_NF_MATCH_ECN=m CONFIG_IP_NF_MATCH_DSCP=m CONFIG_IP_NF_MATCH_AH_ESP=m CONFIG_IP_NF_MATCH_TTL=m CONFIG_IP_NF_MATCH_OWNER=m CONFIG_IP_NF_MATCH_ADDRTYPE=m CONFIG_IP_NF_MATCH_HASHLIMIT=m CONFIG_IP_NF_MATCH_POLICY=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_TARGET_ULOG=m CONFIG_IP_NF_TARGET_TCPMSS=m CONFIG_IP_NF_NAT=m CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_IP_NF_TARGET_NETMAP=m CONFIG_IP_NF_TARGET_SAME=m CONFIG_IP_NF_NAT_IRC=m CONFIG_IP_NF_NAT_FTP=m CONFIG_IP_NF_NAT_TFTP=m CONFIG_IP_NF_NAT_AMANDA=m CONFIG_IP_NF_NAT_PPTP=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_TOS=m CONFIG_IP_NF_TARGET_ECN=m CONFIG_IP_NF_TARGET_DSCP=m CONFIG_IP_NF_TARGET_TTL=m CONFIG_IP_NF_RAW=m CONFIG_IP_NF_ARPTABLES=m CONFIG_IP_NF_ARPFILTER=m CONFIG_IP_NF_ARP_MANGLE=m
Kernel 2.6.20 and Later Netfilter Options Beginning with kernel 2.6.20, the Netfilter kernel configuration was completely changed. It is split into "Core Netfilter Configuration" and "IP Netfilter Configuration". The first graphic shows the link to the Netfilter configuration from the "Networking Options" menu: The next graphic show the Core Configuration settings - these are the standard Ubuntu setting with the exception of CONNMARK Target support (Ubuntu inexplicably includes connmark match support but not CONNTRACK target support).The next graphic shows the IP Netfilter Configuration -- these are the standard Ubuntu settings.Here is the corresponding CONFIG file excerpt.CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m CONFIG_NETFILTER_XT_TARGET_CONNMARK=m CONFIG_NETFILTER_XT_TARGET_DSCP=m CONFIG_NETFILTER_XT_TARGET_MARK=m CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m CONFIG_NETFILTER_XT_TARGET_NFLOG=m # CONFIG_NETFILTER_XT_TARGET_NOTRACK is not set CONFIG_NETFILTER_XT_TARGET_SECMARK=m CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=m CONFIG_NETFILTER_XT_MATCH_COMMENT=m CONFIG_NETFILTER_XT_MATCH_CONNBYTES=m CONFIG_NETFILTER_XT_MATCH_CONNMARK=m CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m CONFIG_NETFILTER_XT_MATCH_DCCP=m CONFIG_NETFILTER_XT_MATCH_DSCP=m CONFIG_NETFILTER_XT_MATCH_ESP=m CONFIG_NETFILTER_XT_MATCH_HELPER=m CONFIG_NETFILTER_XT_MATCH_LENGTH=m CONFIG_NETFILTER_XT_MATCH_LIMIT=m CONFIG_NETFILTER_XT_MATCH_MAC=m CONFIG_NETFILTER_XT_MATCH_MARK=m CONFIG_NETFILTER_XT_MATCH_POLICY=m CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m CONFIG_NETFILTER_XT_MATCH_PHYSDEV=m CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m CONFIG_NETFILTER_XT_MATCH_QUOTA=m CONFIG_NETFILTER_XT_MATCH_REALM=m CONFIG_NETFILTER_XT_MATCH_SCTP=m CONFIG_NETFILTER_XT_MATCH_STATE=m CONFIG_NETFILTER_XT_MATCH_STATISTIC=m CONFIG_NETFILTER_XT_MATCH_STRING=m CONFIG_NETFILTER_XT_MATCH_TCPMSS=m CONFIG_NETFILTER_XT_MATCH_HASHLIMIT=m CONFIG_NF_CONNTRACK_SUPPORT=y CONFIG_NF_CONNTRACK_ENABLED=m # CONFIG_IP_NF_CONNTRACK_SUPPORT is not set CONFIG_NF_CONNTRACK=m CONFIG_NF_CT_ACCT=y CONFIG_NF_CONNTRACK_MARK=y CONFIG_NF_CONNTRACK_SECMARK=y CONFIG_NF_CONNTRACK_EVENTS=y CONFIG_NF_CT_PROTO_GRE=m CONFIG_NF_CT_PROTO_SCTP=m CONFIG_NF_CONNTRACK_AMANDA=m CONFIG_NF_CONNTRACK_FTP=m CONFIG_NF_CONNTRACK_H323=m CONFIG_NF_CONNTRACK_IRC=m CONFIG_NF_CONNTRACK_NETBIOS_NS=m CONFIG_NF_CONNTRACK_PPTP=m CONFIG_NF_CONNTRACK_SIP=m CONFIG_NF_CONNTRACK_TFTP=m CONFIG_NF_CT_NETLINK=m CONFIG_NF_CONNTRACK_IPV4=m CONFIG_NF_CONNTRACK_PROC_COMPAT=y CONFIG_IP_NF_QUEUE=m CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_IPRANGE=m CONFIG_IP_NF_MATCH_TOS=m CONFIG_IP_NF_MATCH_RECENT=m CONFIG_IP_NF_MATCH_ECN=m CONFIG_IP_NF_MATCH_AH=m CONFIG_IP_NF_MATCH_TTL=m CONFIG_IP_NF_MATCH_OWNER=m CONFIG_IP_NF_MATCH_ADDRTYPE=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_TARGET_ULOG=m CONFIG_IP_NF_TARGET_TCPMSS=m CONFIG_NF_NAT=m CONFIG_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_IP_NF_TARGET_NETMAP=m CONFIG_IP_NF_TARGET_SAME=m CONFIG_NF_NAT_SNMP_BASIC=m CONFIG_NF_NAT_PROTO_GRE=m CONFIG_NF_NAT_FTP=m CONFIG_NF_NAT_IRC=m CONFIG_NF_NAT_TFTP=m CONFIG_NF_NAT_AMANDA=m CONFIG_NF_NAT_PPTP=m CONFIG_NF_NAT_H323=m CONFIG_NF_NAT_SIP=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_TOS=m CONFIG_IP_NF_TARGET_ECN=m CONFIG_IP_NF_TARGET_TTL=m CONFIG_IP_NF_TARGET_CLUSTERIP=m CONFIG_IP_NF_RAW=m CONFIG_IP_NF_ARPTABLES=m CONFIG_IP_NF_ARPFILTER=m CONFIG_IP_NF_ARP_MANGLE=m
Minimal Configuration using Kernel 2.6.20 and later Massimo Burcheri has contributed this minimal configuration which is suitable for securing a laptop or desktop. It is strictly a "no-frills" configuration and represents the minimum that will work with Shorewall when using only the very basic Shorewall features described in the one-interface quickstart guide.Here are the corresponding entries from the .config file: # Networking # CONFIG_NET=y # # Networking options # # CONFIG_NETDEBUG is not set CONFIG_PACKET=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_FIB_HASH=y CONFIG_TCP_CONG_CUBIC=y CONFIG_DEFAULT_TCP_CONG="cubic" # # IP: Virtual Server Configuration # CONFIG_NETFILTER=y # # Core Netfilter Configuration # CONFIG_NETFILTER_NETLINK=m CONFIG_NETFILTER_NETLINK_QUEUE=m CONFIG_NETFILTER_NETLINK_LOG=m CONFIG_NF_CONNTRACK_ENABLED=m CONFIG_NF_CONNTRACK_SUPPORT=y CONFIG_NF_CONNTRACK=m CONFIG_NETFILTER_XTABLES=m CONFIG_NETFILTER_XT_TARGET_MARK=m CONFIG_NETFILTER_XT_MATCH_MAC=m CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m CONFIG_NETFILTER_XT_MATCH_STATE=m # # IP: Netfilter Configuration # CONFIG_NF_CONNTRACK_IPV4=m CONFIG_NF_CONNTRACK_PROC_COMPAT=y CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_ADDRTYPE=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_ARPTABLES=m CONFIG_IP_NF_ARPFILTER=m
shorewall-docs-xml-5.0.15/ManualChains.xml0000644000000000000000000001662113020330134017104 0ustar rootroot
Manual Chains Tom Eastep 2008 2009 Thomas M. Eastep 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.
Introduction For Perl programmers, manual chains provide an alternative to Actions with extension scripts. Manual chains are chains which you create and populate yourself using the low-level functions in Shorewall::Chains. Manual chains work in conjunction with the compile extension script and Embedded PERL scripts. The general idea is like this: In the compile extension script, you define functions that you can call later using Embedded PERL. These functions create a manual chain using Shorewall::Chains::new_manual_chain() and populate it with rules using Shorewall::Chains::add_rule(). The name passed to new_manual_chain() must not be longer than 29 characters. The functions also call Shorewall::Config::shorewall() to create and pass a rule to Shorewall. The TARGET in that rule is the name of the chain just created. The functions defined in the compile script are called by embedded PERL statements. The arguments to those calls define the contents of the manual chains and the rule(s) passed back to Shorewall for normal processing.
Example This example provides an alternative to the Port Knocking example. In this example, a Knock.pm module is created and placed in /etc/shorewall: package Knock; use strict; use warnings; use base qw{Exporter}; use Carp; use Shorewall::Chains; use Scalar::Util qw{reftype}; use Shorewall::Config qw{shorewall}; our @EXPORT = qw{Knock}; my %recent_names; my %chains_created; sub scalar_or_array { my $arg = shift; my $name = shift; return () unless defined $arg; return ($arg) unless reftype($arg); return @$arg if reftype($arg) eq 'ARRAY'; croak "Expecting argument '$name' to be scalar or array ref"; } sub Knock { my $src = shift; my $dest = shift; my $args = shift; my $proto = $args->{proto} || 'tcp'; my $seconds = $args->{seconds} || 60; my $original_dest = $args->{original_dest} || '-'; my @target = scalar_or_array($args->{target}, 'target'); my @knocker_ports = scalar_or_array($args->{knocker}, 'knocker'); my @trap_ports = scalar_or_array($args->{trap}, 'trap'); if (not defined $args->{name}) { # If you don't supply a name, then this must be the single-call # variant, so you have to specify all the arguments unless (scalar @target) { croak "No 'target' ports specified"; } unless (scalar @knocker_ports) { croak "No 'knock' ports specified"; } } # We'll need a unique name for the recent match list. Construct one # from the port and a serial number, if the user didn't supply one. my $name = $args->{name} || ($target[0] . '_' . ++$recent_names{$target[0]}); $name = 'Knock' . $name; # We want one chain for all Knock rules that share a 'name' field my $chainref = $chains_created{$name}; unless (defined $chainref) { $chainref = $chains_created{$name} = new_manual_chain($name); } # Logging if ($args->{log_level}) { foreach my $port (@target) { log_rule_limit($args->{log_level}, $chainref, 'Knock', 'ACCEPT', '', $args->{log_tag} || '', 'add', "-p $proto --dport $port -m recent --rcheck --name $name" ); log_rule_limit($args->{log_level}, $chainref, 'Knock', 'DROP', '', $args->{log_tag} || '', 'add', "-p $proto --dport ! $port" ); } } # Add the recent match rules to the manual chain foreach my $knock (@knocker_ports) { add_rule($chainref, "-p $proto --dport $knock -m recent --name $name --set -j DROP"); } foreach my $trap (@trap_ports) { add_rule($chainref, "-p $proto --dport $trap -m recent --name $name --remove -j DROP"); } foreach my $port (@target) { add_rule($chainref, "-p $proto --dport $port -m recent --rcheck --seconds $seconds --name $name -j ACCEPT"); } # And add a rule to the main chain(s) to jump into the manual chain at the appropriate points my $all_dest_ports = join(',', @target, @knocker_ports, @trap_ports); shorewall "$chainref->{name} $src $dest $proto $all_dest_ports - $original_dest"; return 1; } 1; This simplifies /etc/shorewall/compile:use Knock; 1; The rule from the Port Knocking article: #ACTION SOURCE DEST PROTO DPORT SSHKnock net $FW tcp 22,1599,1600,1601 becomes:PERL Knock 'net', '$FW', {target => 22, knocker => 1600, trap => [1599, 1601]};Similarly#ACTION SOURCE DEST PROTO DPORT SPORT ORIGDEST DNAT- net 192.168.1.5 tcp 22 - 206.124.146.178 SSHKnock net $FW tcp 1599,1600,1601 SSHKnock net loc:192.168.1.5 tcp 22 - 206.124.146.178becomes:#ACTION SOURCE DEST PROTO DPORT SPORT ORIGDEST DNAT- net 192.168.1.5 tcp 22 - 206.124.146.178 PERL Knock 'net', '$FW', {name => 'SSH', knocker => 1600, trap => [1599, 1601]}; PERL Knock 'net', 'loc:192.168.1.5', {name => 'SSH', target => 22, original_dest => '206.124.136.178'};
shorewall-docs-xml-5.0.15/GnuCopyright.xml0000644000000000000000000005424513020330134017167 0ustar rootroot GNU Free Documentation License Version 1.2, November 2002
PREAMBLE The purpose of this License is to make a manual, textbook, or other functional and useful document "free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others. This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software. We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.
APPLICABILITY AND DEFINITIONS This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The "Document", below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as "you". You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law. A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language. A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them. The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none. The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words. A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not "Transparent" is called "Opaque". Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only. The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text. A section "Entitled XYZ" means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as "Acknowledgements", "Dedications", "Endorsements", or "History".) To "Preserve the Title" of such a section when you modify the Document means that it remains a section "Entitled XYZ" according to this definition. The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License.
VERBATIM COPYING You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3. You may also lend copies, under the same conditions stated above, and you may publicly display copies.
COPYING IN QUANTITY If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects. If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages. If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public. It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.
MODIFICATIONS You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version: Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has fewer than five), unless they release you from this requirement. State on the Title page the name of the publisher of the Modified Version, as the publisher. Preserve all the copyright notices of the Document. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document's license notice. Include an unaltered copy of this License. Preserve the section Entitled "History", Preserve its Title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section Entitled "History" in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the "History" section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission. For any section Entitled "Acknowledgements" or "Dedications", Preserve the Title of the section, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles. Delete any section Entitled "Endorsements". Such a section may not be included in the Modified Version. Do not retitle any existing section to be Entitled "Endorsements" or to conflict in title with any Invariant Section. Preserve any Warranty Disclaimers. If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles. You may add a section Entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various parties--for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard. You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one. The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.
COMBINING DOCUMENTS You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers. The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work. In the combination, you must combine any sections Entitled "History" in the various original documents, forming one section Entitled "History"; likewise combine any sections Entitled "Acknowledgements", and any sections Entitled "Dedications". You must delete all sections Entitled "Endorsements".
COLLECTIONS OF DOCUMENTS You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects. You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.
AGGREGATION WITH INDEPENDENT WORKS A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, is called an "aggregate" if the copyright resulting from the compilation is not used to limit the legal rights of the compilation's users beyond what the individual works permit. When the Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document. If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Document's Cover Texts may be placed on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate.
TRANSLATION Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail. If a section in the Document is Entitled "Acknowledgements", "Dedications", or "History", the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title.
TERMINATION You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.
FUTURE REVISIONS OF THIS LICENSE The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/. Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.
ADDENDUM: How to use this License for your documents To use this License in a document you have written, include a copy of the License in the document and put the following copyright and license notices just after the title page: If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, replace the "with...Texts." line with this:
with the Invariant Sections being LIST THEIR TITLES, with the Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.
If you have Invariant Sections without Cover Texts, or some other combination of the three, merge those two alternatives to suit the situation. If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software.
shorewall-docs-xml-5.0.15/bridge_fr.xml0000644000000000000000000005536513020330134016474 0ustar rootroot
Shorewall et pont filtrant Version Franaise de Shorewall and Bridged Firewalls Tom Eastep Guy Marcenac Adaptation franaise 2004-2006 Thomas M. Eastep Guy Marcenac Permission est accorde 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 ultrieure publie par la Free Software Foundation ; sans section Invariables, sans premire de Couverture, et sans texte de quatrime de couverture. Une copie de la prsente Licence est incluse dans la section intitule. Une traduction franaise de la licence se trouve dans la section Licence de Documentation Libre GNU. Ce paragraphe est une traduction franaise pour aider votre comprhension. Seul le texte original en anglais prsent 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 amliorations apporter cette documentation vous pouvez me contacter. Cet article s'applique Shorewall 3.0 et ses versions ultrieures. Si vous utilisez une version plus ancienne de Shorewall, rfrez-vous la documentation s'appliquant votre version.
Contexte Les systmes sur lesquels tourne Shorewall fonctionnent en gnral comme des routeurs. Dans le modle de rfrence OSI (Open System Interconnect), un routeur opre au niveau 3. Shorewall peut galement tre dploy sur un systme GNU Linux se comportant comme un pont (bridge). Les ponts sont des quipements de niveau 2 dans le modle OSI (pensez un pont comme un switch ethernet). Voici quelques-unes des diffrences entre les routeurs et les ponts: Les routeurs dterminent la destination d'un paquet en fonction de l'adresse IP de destination alors que les ponts routent le trafic en fonction de l'adresse MAC de destination de la trame ethernet. Par consquent, les routeurs peuvent tre connects plusieurs rseaux IP alors qu'un pont ne peut appartenir qu' un seul rseau. Dans la plupart des configurations, les routeurs ne font pas suivre les paquets de diffusion (broadcast) alors que les ponts le font. Les conditions dans lesquelles un routeur peut ou doit faire suivre les paquets de diffusion sont dcrites dans la section 4 de la RFC 1812.
Pr-requis systme LE SUPPORT POUR LES PONTS TEL QU'IL EST DECRIT DANS CET ARTICLE RISQUE D'ETRE ABANDONNE. Les fonctions sous-jacentes de netfilter sur lesquelles le pont filtrant de Shorewall reposent sont en train d'tre abandonnes et il n'est pas certain que Shorewall puisse continuer supporter les ponts filtrants tels qu'ils sont dcrits ici. Dans un autre article (en aglais), je dcris comment configurer avec Shorewall un pont-routeur qui fonctionnera avec les versions futures du kernel. N'importe quelle version de Shorewall fera l'affaire si vous avez besoin d'un pont mais que vous n'avez pas besoin de restreindre le trafic travers ce pont. Pour plus de dtails, reportez vous la Documentation pour un pont simple. Pour utiliser Shorewall comme pont filtrant: Votre noyau doit tre compil avec le support pour les ponts (CONFIG_BRIDGE=m ou CONFIG_BRIDGE=y). Votre noyau doit comprendre l'intgration bridge/netfilter (CONFIG_BRIDGE_NETFILTER=y). Votre noyau doit tre compil avec le support pour les correspondances physdev de Netfilter (CONFIG_IP_NF_MATCH_PHYSDEV=m ou CONFIG_IP_NF_MATCH_PHYSDEV=y). Le support des correspondances physdev est en standard dans le noyau 2.6 mais doit tre patch dans les noyaux 2.4 (voir icit). Les utilisateurs de Bering et de Bering uCLibc doivent trouver et installer ipt_physdev.o pour leur distribution puis ajouter ipt_physdev au fichier /etc/modules. Votre version d'iptables doit offrir le support pour les correspondances physdev. Ceci est le cas avec iptables 1.2.9 et toutes ses versions ultrieures. Vous devez avoir install le paquetage des utilitaires pour les ponts (bridge-utils).
Application Le diagramme au dessous prsente une application classique d'un pont/firewall. Il y a dj un routeur install qui supporte un rseau local sur son interface interne et vous voulez insrer un firewall entre ce routeur et les systmes de ce rseau local. Dans notre exemple, le rseau local utilise des adresses de la RFC 1918 mais ceci n'est pas obligatoire. Le pont marcherait de la mme faon si on utilisait des adresses IP publiques (n'oubliez pas qu'un pont ne s'occupe pas d'adresses IP). Il existe des diffrences cl entre cette configuration et une configuration normale de Shorewall: Le systme Shorewall Pont/Firewall ne possde qu'une seule adresse IP mme si il dispose de deux interfaces ethernet ! Cette adresse IP est configure sur le pont mme au lieu de l'tre sur l'une des cartes rseau. Les systmes connects au LAN sont configurs avec l'adresse du routeur IP (192.168.1.254 dans notre exemple) comme passerelle par dfaut. traceroute ne dtectera pas le Pont/Firewall comme un routeur intermdiaire Si le routeur excute un serveur DHCP, les htes connects au rseau local peuvent utiliser ce serveur sans avoir excuter dhcrelay sure le Pont/Firewal. L'insertion d'un pont filtrant entre un routeur et un ensemble d'htes locaux ne fonctionne que si ces machines locales forment un rseau IP unique. Dans le schma ci-dessus, tous les htes dans la zone loc sont dans le rseau 192.168.1.0/24. Si le routeur doit router entre plusieurs rseaux locaux par la mme interface physique (plusieurs rseaux IP partagent le mme rseau local), l'insertion d'un pont filtrant entre le routeur et le rseau local ne fonctionnera pas. Voici d'autres possibilits -- Il pourrait y avoir un hub ou un switch entre le routeur et le Pont/Firewall, et il pourrait y avoir d'autres systmes connects ce hub ou ce switch. Tous les systmes du cot local du routeur devraient toujours tre configurs avec des adresses IP prises dans 192.168.1./24.
Configuration du pont Configure le pont est une chose assez simple. On se sert de l'utilitaire brctl issu du paquetage bridge-utils. Vous trouverez des informations sur la configuration d'un pont http://linux-net.osdl.org/index.php/Bridge. Malheureusement peu de distributions Linux ont de bons outils de configuration pour un pont et les outils de configuration rseau graphiques ne dtectent pas la prsence d'un pont. Voici l'extrait d'un fichier de configuration Debian pour un pont deux interfaces et ayant une adresse IP statique:
auto br0 iface br0 inet static address 192.168.1.253 netmask 255.255.255.0 network 192.168.1.0 broadcast 192.168.1.255 pre-up /sbin/ip link set eth0 up pre-up /sbin/ip link set eth1 up pre-up /usr/sbin/brctl addbr br0 pre-up /usr/sbin/brctl addif br0 eth0 pre-up /usr/sbin/brctl addif br0 eth1
Bien qu'il ne soit pas obligatoire de donner une adresse IP un pont, le faire permet au Pont/Firewall d'accder d'autres systmes et permet galement l'administration distante du pont. Le pont doit aussi avoir une adresse IP pour que les politiques et les rgles REJECT fonctionnent correctement - sinon les rgles REJECT se comporteront exactement de la mme manire que des rgles DROP. Enfin, si un pont fait partie d'un Pont/Routeur, il est galement indispensable de lui donner une adresse IP. Avant de configurer Shorewall, assurerez-vous d'avoir un pont qui fonctionne et qui se lance au boot. On peut attribuer une adresse IP au pont par DHCP. Voici un fichier /etc/sysconfig/network/ifcfg-br0 issu d'un systme SUSE:
BOOTPROTO='dhcp' REMOTE_IPADDR='' STARTMODE='onboot' UNIQUE='3hqH.MjuOqWfSZ+C' WIRELESS='no' MTU=''
Voici un fichier /etc/sysconfig/network-scripts/ifcfg-br0 issu d'un systme Mandriva:
DEVICE=br0 BOOTPROTO=dhcp ONBOOT=yes
Aussi bien sur les systmes SUSE que sur les systmes Mandriva, il faudra un script spar pour configurer le pont. Voil les scripts dont je me sers sur un systme SUSE 9.1.
/etc/sysconfig/network/ifcfg-br0 BOOTPROTO='dhcp' REMOTE_IPADDR='' STARTMODE='onboot' UNIQUE='3hqH.MjuOqWfSZ+C' WIRELESS='no' MTU='' /etc/init.d/bridge#!/bin/sh ################################################################################ # Script to create a bridge # # (c) 2004 - Tom Eastep (teastep@shorewall.net) # # Modify the following variables to match your configuration # #### BEGIN INIT INFO # Provides: bridge # Required-Start: coldplug # Required-Stop: # Default-Start: 2 3 5 # Default-Stop: 0 1 6 # Description: starts and stops a bridge ### END INIT INFO # # chkconfig: 2345 05 89 # description: GRE/IP Tunnel # ################################################################################ PATH=$PATH:/sbin:/usr/sbin:/usr/local/sbin INTERFACES="eth1 eth0" BRIDGE="br0" MODULES="tulip" do_stop() { echo "Stopping Bridge $BRIDGE" brctl delbr $BRIDGE for interface in $INTERFACES; do ip link set $interface down done } do_start() { echo "Starting Bridge $BRIDGE" for module in $MODULES; do modprobe $module done sleep 5 for interface in $INTERFACES; do ip link set $interface up done brctl addbr $BRIDGE for interface in $INTERFACES; do brctl addif $BRIDGE $interface done } case "$1" in start) do_start ;; stop) do_stop ;; restart) do_stop sleep 1 do_start ;; *) echo "Usage: $0 {start|stop|restart}" exit 1 esac exit 0
Voici une contribution de Axel Westerhold qui propose cet exemple de configuration d'un pont ayant une adresse statique sur un systme Fedora (Core 1 and Core 2 Test 1). Remarquez que ces fichiers configurent galement le pont ce qui vite d'avoir crire un script de configuration spar.
/etc/sysconfig/network-scripts/ifcfg-br0: DEVICE=br0 TYPE=Bridge IPADDR=192.168.50.14 NETMASK=255.255.255.0 ONBOOT=yes /etc/sysconfig/network-scripts/ifcfg-eth0:DEVICE=eth0 TYPE=ETHER BRIDGE=br0 ONBOOT=yes/etc/sysconfig/network-scripts/ifcfg-eth1:DEVICE=eth1 TYPE=ETHER BRIDGE=br0 ONBOOT=yes
Florin Grad de Mandriva fournit ce script pour configurer un pont:
#!/bin/sh # chkconfig: 2345 05 89 # description: Layer 2 Bridge # [ -f /etc/sysconfig/bridge ] && . /etc/sysconfig/bridge PATH=$PATH:/sbin:/usr/sbin:/usr/local/sbin do_stop() { echo "Stopping Bridge" for i in $INTERFACES $BRIDGE_INTERFACE ; do ip link set $i down done brctl delbr $BRIDGE_INTERFACE } do_start() { echo "Starting Bridge" for i in $INTERFACES ; do ip link set $i up done brctl addbr br0 for i in $INTERFACES ; do ip link set $i up brctl addif br0 $i done ifup $BRIDGE_INTERFACE } case "$1" in start) do_start ;; stop) do_stop ;; restart) do_stop sleep 1 do_start ;; *) echo "Usage: $0 {start|stop|restart}" exit 1 esac exit 0 Le fichier /etc/sysconfig/bridge: BRIDGE_INTERFACE=br0 #The name of your Bridge INTERFACES="eth0 eth1" #The physical interfaces to be bridged
Andrzej Szelachowski a propos la contribution suivante:
Here is how I configured bridge in Slackware: 1) I had to compile bridge-utils (It's not in the standard distribution) 2) I've created rc.bridge in /etc/rc.d: ######################### #! /bin/sh ifconfig eth0 0.0.0.0 ifconfig eth1 0.0.0.0 #ifconfig lo 127.0.0.1 #this line should be uncommented if you don't use rc.inet1 brctl addbr most brctl addif most eth0 brctl addif most eth1 ifconfig most 192.168.1.31 netmask 255.255.255.0 up #route add default gw 192.168.1.1 metric 1 #this line should be uncommented if #you don't use rc.inet1 ######################### 3) I made rc.brige executable and added the following line to /etc/rc.d/rc.local /etc/rc.d/rc.bridge
Joshua Schmidlkofer a crit:
Bridge Setup for Gentoo #install bridge-utils emerge bridge-utils ## create a link for net.br0 cd /etc/init.d ln -s net.eth0 net.br0 # Remove net.eth*, add net.br0 and bridge. rc-update del net.eth0 rc-update del net.eth1 rc-update add net.br0 default rc-update add bridge boot /etc/conf.d/bridge: #bridge contains the name of each bridge you want created. bridge="br0" # bridge_<bridge>_devices contains the devices to use at bridge startup. bridge_br0_devices="eth0 eth1" /etc/conf.d/net iface_br0="10.0.0.1 broadcast 10.0.0.255 netmask 255.255.255.0" #for dhcp: #iface_br0="dhcp" #comment this out if you use dhcp. gateway="eth0/10.0.0.1"
Les utilisateurs qui russissent dans la configuration d'un pont sur d'autres distributions que celles prsentes plus haut, sont encourags m'envoyer leurs configurations afin que je puisse les publier ici.
Configuration de Shorewall Dans Shorewall, on active le mode Pont avec l'option BRIDGING du fichier /etc/shorewall/shorewall.conf: BRIDGING=Yes Dans le scnario prsent plus haut, il y aurait probablement deux zones dfinies. - une pour internet et une pour le rseau local, ce qui donnerait un fichier /etc/shorewall/zones comme celui-ci: #ZONE TYPE OPTIONS fw firewall net ipv4 loc ipv4 #LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE Une politique habituelle deux zones est parfaitement adapte ce cas — /etc/shorewall/policy: #SOURCE DEST POLICY LOG LIMIT:BURST loc net ACCEPT net all DROP info all all REJECT info #LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE Puisque c'est le pont lui-mme qui est configur avec une adresse IP, seul ce dispositif doit tre dfini pour Shorewall dans /etc/shorewall/interfaces: #ZONE INTERFACE BROADCAST OPTIONS - br0 192.168.1.255 #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE Les zones sont dfinies en utilisant le fichier /etc/shorewall/hosts. En supposant que le routeur est connect eth0 et que le switch est connect eth1: #ZONE HOST(S) OPTIONS net br0:eth0 loc br0:eth1 #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS LINE -- DO NOT REMOVE Mme lorsque Shorewall est arrt, vous voudrez probablement autoriser le trafic transiter par le pont — /etc/shorewall/routestopped: #INTERFACE HOST(S) OPTIONS br0 192.168.1.0/24 routeback #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE Pour la dfinition de votre jeu de rgles pour votre firewall, vous pouvez prendre comme point de dpart le fichier /etc/shorewall/rules prsent dans l'exemple de Firewall Deux Interfaces.
Combinaison Pont/Routeur Un systme Shorewall n'a pas s'excuter exclusivement comme un pont ou bien comme un routeur -- il peut parfaitement faire les deux. Voici un exemple: Il s'agit quasiment de la mme configuration que celle prsente dans le Guide de Configuration de Shorewall si ce n'est que la DMZ utilise un pont plutt qu'un Proxy ARP. Les modifications apporter la configuration prsente dans le Guide de Configuration sont les suivants: Le fichier /etc/shorewall/proxyarp doit tre vide dans cette configuration. Le fichier /etc/shorewall/interfaces ressemble ceci:#ZONE INTERFACE BROADCAST OPTIONS - br0 detect routefilter loc eth1 detect Le fichier /etc/shorewall/hosts devrait avoir: #ZONE HOSTS OPTIONS net br0:eth0 dmz br0:eth2 Les systmes en DMZ ont besoin d'avoir une route par 192.0.2.176 vers le rseau 192.168.201.0/24 afin qu'ils puissent communiquer avec le rseau local.
Limites Avec certaines cartes sans fil, le mode pont ne fonctionne pas — vous pouvez regarder http://linux-net.osdl.org/index.php/Bridge.
Liens Vous trouverez ici un article en Espagnol qui prsente de manire dtaille comment ponter un rseau public et un rseau local avec Shorewall. Il s'agit d'une autre configuration en Pont/Routeur.
shorewall-docs-xml-5.0.15/NAT.xml0000644000000000000000000002530213020330134015157 0ustar rootroot
One-to-one NAT Tom Eastep 2001-2004 Thomas M. Eastep 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. This article applies to Shorewall 4.3 and later. If you are running a version of Shorewall earlier than Shorewall 4.3.5 then please see the documentation for that release.
One-to-one NAT If all you want to do is forward ports to servers behind your firewall, you do NOT want to use one-to-one NAT. Port forwarding can be accomplished with simple entries in the rules file. One-to-one NAT is a way to make systems behind a firewall and configured with private IP addresses (those reserved for private use in RFC 1918) appear to have public IP addresses. Before you try to use this technique, I strongly recommend that you read the Shorewall Setup Guide. The following figure represents a one-to-one NAT environment. One-to-one NAT can be used to make the systems with the 10.1.1.* addresses appear to be on the upper (130.252.100.*) subnet. If we assume that the interface to the upper subnet is eth0, then the following /etc/shorewall/nat file would make the lower left-hand system appear to have IP address 130.252.100.18 and the right-hand one to have IP address 130.252.100.19. It should be stressed that these entries in the /etc/shorewall/nat file do not automatically enable traffic between the external network and the internal host(s) — such traffic is still subject to your policies and rules. /etc/shorewall/nat#EXTERNAL INTERFACE INTERNAL ALLINTS LOCAL 130.252.100.18 eth0 10.1.1.2 no no 130.252.100.19 eth0 10.1.1.3 no no Be sure that the internal system(s) (10.1.1.2 and 10.1.1.3 in the above example) is (are) not included in any specification in /etc/shorewall/masq (/etc/shorewall/snat) or /etc/shorewall/proxyarp. The ALL INTERFACES column is used to specify whether access to the external IP from all firewall interfaces should undergo NAT (Yes or yes) or if only access from the interface in the INTERFACE column should undergo NAT. If you leave this column empty, No is assumed . Specifying Yes in this column will not by itself allow systems on the lower LAN to access each other using their public IP addresses. For example, the lower left-hand system (10.1.1.2) cannot connect to 130.252.100.19 and expect to be connected to the lower right-hand system. See FAQ 2a. Shorewall will automatically add the external address to the specified interface unless you specify ADD_IP_ALIASES=no (or No) in /etc/shorewall/shorewall.conf; If you do not set ADD_IP_ALIASES or if you set it to Yes or yes then you must NOT configure your own alias(es). The contents of the LOCAL column determine whether packets originating on the firewall itself and destined for the EXTERNAL address are redirected to the internal ADDRESS. If this column contains yes or Yes (and the ALL INTERFACES COLUMN also contains Yes or yes) then such packets are redirected; otherwise, such packets are not redirected. This feature requires that you enabled CONFIG_IP_NF_NAT_LOCAL in your kernel. Entries in /etc/shorewall/nat only arrange for address translation; they do not allow traffic to pass through the firewall in violation of your policies. In the above example, suppose that you wish to run a web server on 10.1.1.2 (a.k.a. 130.252.100.18). You would need the following entry in /etc/shorewall/rules: #ACTION SOURCE DEST PROTO DPORT SPORT ORIGDEST ACCEPT net loc:10.1.1.2 tcp 80 - 130.252.100.18
ARP cache A word of warning is in order here. ISPs typically configure their routers with a long ARP cache timeout. If you move a system from parallel to your firewall to behind your firewall with one-to-one NAT, it will probably be HOURS before that system can communicate with the Internet. If you sniff traffic on the firewall's external interface, you can see incoming traffic for the internal system(s) but the traffic is never sent out the internal interface. You can determine if your ISP's gateway ARP cache is stale using ping and tcpdump. Suppose that we suspect that the gateway router has a stale ARP cache entry for 130.252.100.19. On the firewall, run tcpdump as follows: tcpdump -nei eth0 icmp Now from 10.1.1.3, ping the ISP's gateway (which we will assume is 130.252.100.254): ping 130.252.100.254 We can now observe the tcpdump output: 13:35:12.159321 0:4:e2:20:20:33 0:0:77:95:dd:19 ip 98: 130.252.100.19 > 130.252.100.254: icmp: echo request (DF) 13:35:12.207615 0:0:77:95:dd:19 0:c0:a8:50:b2:57 ip 98: 130.252.100.254 > 130.252.100.177 : icmp: echo reply Notice that the source MAC address in the echo request is different from the destination MAC address in the echo reply!! In this case 0:4:e2:20:20:33 was the MAC of the firewall's eth0 NIC while 0:c0:a8:50:b2:57 was the MAC address of the system on the lower right. In other words, the gateway's ARP cache still associates 130.252.100.19 with the NIC in that system rather than with the firewall's eth0. If you have this problem, there are a couple of things that you can try: A reading of TCP/IP Illustrated, Vol 1 by Stevens reveals Courtesy of Bradey Honsinger that a gratuitous ARP packet should cause the ISP's router to refresh their ARP cache (section 4.7). A gratuitous ARP is simply a host requesting the MAC address for its own IP; in addition to ensuring that the IP address isn't a duplicate...
if the host sending the gratuitous ARP has just changed its hardware address..., this packet causes any other host...that has an entry in its cache for the old hardware address to update its ARP cache entry accordingly.
Which is, of course, exactly what you want to do when you switch a host from being exposed to the Internet to behind Shorewall using one-to-one NAT (or Proxy ARP for that matter). Happily enough, recent versions of Redhat's iputils package include arping, whose -U flag does just that: arping -U -I <net if> <newly proxied IP> arping -U -I eth0 66.58.99.83 # for example Stevens goes on to mention that not all systems respond correctly to gratuitous ARPs, but googling for arping -U seems to support the idea that it works most of the time. To use arping with one-to-one NAT in the above example, you would have to: shorewall clear ip addr add 130.252.100.18 dev eth0 # You need to add the addresses only if Shorewall clear ip addr add 130.252.100.19 dev eth0 # deletes them arping -U -c 10 -I eth0 130.252.100.18 arping -U -c 10 -I eth0 130.252.100.19 ip addr del 130.252.100.18 dev eth0 # You need to delete the addresses only if you added ip addr del 130.252.100.19 dev eth0 # them above shorewall start You can call your ISP and ask them to purge the stale ARP cache entry but many either can't or won't purge individual entries. There are two distinct versions of arping available: arping by Thomas Habets (Debian package arping). arping as part of the iputils package by Alexey Kuznetsov (Debian package iputils-arping). You want the second one by Alexey Kuznetsov.
shorewall-docs-xml-5.0.15/troubleshoot.xml0000644000000000000000000005426013020330134017273 0ustar rootroot shorewall-docs-xml-5.0.15/Shorewall_and_Kazaa.xml0000644000000000000000000000544113020330134020430 0ustar rootroot
Kazaa Filtering Tom Eastep 2003-2005 Thomas M. Eastep 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. This article applies to Shorewall 3.0 and later. If you are running a version of Shorewall earlier than Shorewall 3.0.0 then please see the documentation for that release. Beginning with Shorewall version 1.4.8, Shorewall can interface to ftwall. ftwall is part of the p2pwall project and is a user-space filter for applications based on the Fast Track peer to peer protocol. Applications using this protocol include Kazaa, KazaaLite, iMash and Grokster. To filter traffic from your loc zone with ftwall, you insert the following rules in the ESTABLISHED section of /etc/shorewall/rules file after any DROP or REJECT rules whose source is the loc zone. #ACTION SOURCE DEST PROTO QUEUE loc net tcp QUEUE loc net udp QUEUE loc $FW udp Now simply configure ftwall as described in the ftwall documentation and restart Shorewall. There are ftwall init scripts for use with SUSE and Debian Linux at http://shorewall.net/pub/shorewall/contrib/ftwall. Shorewall versions 2.2.0 and later also include support for the ipp2p match facility which can be use to control P2P traffic. See the Shorewall IPP2P documentation for details.
shorewall-docs-xml-5.0.15/IPv6Support.xml0000644000000000000000000004500213020330134016715 0ustar rootroot
Shorewall IPv6 Support Tom Eastep 2008 2009 2016 Thomas M. Eastep 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. This article applies to Shorewall 4.3 and later. If you are running a version of Shorewall earlier than Shorewall 4.3.5 then please see the documentation for that release.
Overview Beginning with Shorewall 4.2.4, support for firewalling IPv6 is included as part of Shorewall.
Prerequisites In order to use Shorewall with IPv6, your firewall must meet the following prerequisites: Kernel 2.6.24 or later. Iptables 1.4.0 or later (1.4.1.1 is strongly recommended) If you wish to include DNS names in your IPv6 configuration files, you must have Perl 5.10 and must install the Perl Socket6 library.
Packages Shorewall IPv6 support introduced two new packages: Shorewall6. This package provides /sbin/shorewall6 which is the IPv6 equivalent of /sbin/shorewall. /sbin/shorewall only handles IPv4 while /sbin/shorewall6 handles only IPv6.. Shorewall6 depends on Shorewall. The Shorewall6 configuration is stored in /etc/shorewall6. Shorewall6 Lite. This package is to IPv6 what Shorewall Lite is to IPv4. The package stores its configuration in /etc/shorewall6-lite. As with Shorewall Lite, Shorewall6 Lite usually requires no configuration changes on the firewall system.
IPv4/IPv6 Interaction IP connections are either IPv4 or IPv6; there is no such thing as a mixed IPv4/6 connecton. IPv4 connections are controlled by Shorewall (or Shorewall-lite); IPv6 connections are controlled by Shorewall6 (or Shorewall6-lite). Starting and stopping the firewall for one address family has no effect on the other address family. As a consequence, there is very little interaction between Shorewall and Shorewall6.
DISABLE_IPV6 An obvious area where the configuration of Shorewall affects Shorewall6 is the DISABLE_IPV6 setting in /etc/shorewall/shorewall.conf. When configuring Shorewall6, you will want to set DISABLE_IPV6=No and restart Shorewall or Shorewall-lite.
TC_ENABLED Another area where their configurations overlap is in traffic shaping; the tcdevices and tcclasses files do exactly the same thing in both Shorewall and Shorewall6. Consequently, you will have TC_ENABLED=Internal in Shorewall or in Shorewall6 and TC_ENABLED=No in the other product. Also, you will want CLEAR_TC=No in the configuration with TC_ENABLED=No. Regardless of which product has TC_ENABLED=Internal: IPv4 packet marking is controlled by /etc/shorewall/mangle (Shorewall 4.6.0 and later) or by /etc/shorewall/tcrules IPv6 packet marking is controlled by /etc/shorewall6/mangle (Shorewall 4.6.0 and later) or by /etc/shorewall6/tcrules
KEEP_RT_TABLES Multi-ISP users will need to be aware of this one. When there are entries in the providers file, Shorewall normally installs a modified /etc/iproute2/rt_tables during shorewall start and shorewall restart and restores a default file during shorewall stop. Setting KEEP_RT_TABLES=Yes in shorewall.conf(5) stops Shorewall (Shorewall lite) from modifying /etc/iproute2/rt_tables. Shorewall6 is also capable of modifying /etc/iproute2/rt_tables in a similar way. Our recommendation to Multi-ISP users is to: Select the same names for similar providers. Set KEEP_RT_TABLES=No in shorewall.conf(5) and set KEEP_RT_TABLES=Yes in shorewall6.conf(5). These setting allow Shorewall to control the contents of /etc/iproute2/rt_tables.
6TO4 If you are using a 6to4 tunnel for your IPv6 connectivity, you need an entry in /etc/shorewall/tunnels.#TYPE ZONE GATEWAY GATEWAY_ZONE 6to4 net
Shorewall6 Differences from Shorewall Configuring and operating Shorewall6 is very similar to configuring Shorewall with some notable exceptions: Default Zone Type The default zone type in Shorewall6 is ipv6. It is suggested that you specify ipv6 in the TYPE column of /etc/shorewall6/zones and a type of ipv4 in /etc/shorewall/zones; that way, if you run the wrong utility on a configuration, you will get an instant error. Interface Options The following interface options are available in /etc/shorewall6/interfaces: blacklist Same as in Shorewall bridge Same as in Shorewall dhcp Interface is assigned by IPv6 DHCP or the firewall hosts an IPv6 DHCP server on the interface. maclist Same as in Shorewall nosmurfs Checks the source IP address of packets arriving on the interface and drops packets whose SOURCE address is: An IPv6 multicast address The subnet-router anycast address for any of the global unicast addresses assigned to the interface. An RFC 2526 anycast address for any of the global unicast addresses assigned to the interface. optional Same as in Shorewall routeback Same as in Shorewall sourceroute[={0|1}] Same as in Shorewall tcpflags Same as in Shorewall mss=mss Same as in Shorewall forward[={0|1}] Override the setting of IP_FORWARDING in shorewall6.conf with respect to how the system behaves on this interface. If 1, behave as a router; if 0, behave as a host. Host Options The following host options are available in /etc/shorewall6/hosts: blacklist Same as in Shorewall maclist Same as in Shorewall routeback Same as in Shorewall tcpflags Same as in Shorewall Specifying Addresses Shorewall follows the usual convention of distinguishing IPv6 address by enclosing them in square brackets ("[" and "]"). Anywhere that an address or address list follows a colon (":"), the address or list may be enclosed in square brackets to improve readability. Example (/etc/shorewall6/rules): #ACTION SOURCE DEST PROTO DPORT ?SECTION NEW ACCEPT net $FW:[2002:ce7c:92b4::3] tcp 22 When the colon is preceeded by an interface name, the angle brackets are required. This is true even when the address is a MAC address in Shorewall format. Example (/etc/shorewall6/rules): #ACTION SOURCE DEST PROTO DPORT ?SECTION NEW ACCEPT net:wlan0:[2002:ce7c:92b4::3] $FW tcp 22 Prior to Shorewall 4.5.4, angled brackets ("<" and ">") were used. While these are still accepted, their use is deprecated in favor of square brackets. Example (/etc/shorewall6/rules): #ACTION SOURCE DEST PROTO DPORT SECTION NEW ACCEPT net:wlan0:<2002:ce7c:92b4::3> $FW tcp 22 Prior to Shorewall 4.5.9, network addresses were required to be enclosed in either angle brackets or square brackets (e.g. [2001:470:b:787::/64]). Beginning with Shorewall 4.5.9, the more common representation that places the VLSM outside the brackets is accepted and preferred (e.g., [2001:470:b:787::]/64). Beginning with Shorewall 4.5.14, the rules compiler translates "<" and ">" to "[" and "]" respectively before parsing. So square brackets may appear in error messages even when angled brackets were used. Stopped State When Shorewall6 or Shorewall6 Lite is in the stopped state, the following traffic is still allowed. Traffic with a multicast destination IP address (ff00::/8). Traffic with a link local source address (ff800::/8) Traffic with a link local destination address. Multi-ISP The Linux IPv6 stack does not support balancing (multi-hop) routes. Thehe and options in shorewall6-providers(5) and USE_DEFAULT_RT=Yes in shorewall6.conf(5) are supported, but at most one provider can have the option and at most one provider can have the option. /sbin/shorewall6 and /sbin/shorewall6-lite Commands Several commands supported by /sbin/shorewall and /sbin/shorewall-lite are not supported by /sbin/shorewall6 and /sbin/shorewall6-lite: hits ipcalc iprange Macros The Shorewall6 package depends on Shorewall for application macros. Only certain address-family specific macros such as macro.AllowICMPs are included in Shorewall6. As a consequence, /usr/share/shorewall/ is included in the default Shorewall6 CONFIG_PATH.
Installing IPv6 Support You will need at least the following packages: Shorewall 4.3.5 or later. Shorewall6 4.3.5 or later. You may also with to install Shorewall6-lite 4.3.5 or later on your remote firewalls to allow for central IPv6 firewall administration.
More information about IPv6 I strongly suggest that you read the Linux IPv6 HOWTO. The 6to4 Tunnels page also includes instructions for setting up your first IPv6 environment. In addition to the Linux IPv6 HOWTO, I have found the following two books to be useful: IPv6 Essentials, Silvia Hagen, 2002, O'Reilly Media, Inc, ISBN 0-596-00125-8. O'Reilly published a second edition of this book in 2006. IPV6 Theory, Protocol, and Practice, Second Edition, Pete Loshin, 2004, Morgan-Kaufmann Publishers, IBSN 1-55860-820-9
shorewall-docs-xml-5.0.15/FAQ_fr.xml0000644000000000000000000032445713020330134015650 0ustar rootroot
FAQ Shorewall Version Franaise de Shorewall FAQs Shorewall Community Tom Eastep Guy Marcenac Adaptation franaise 2001-2006 Thomas M. Eastep Guy Marcenac Permission est accorde 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 ultrieure publie par la Free Software Foundation ; sans section Invariables, sans premire de Couverture, et sans texte de quatrime de couverture. Une copie de la prsente Licence est incluse dans la section intitule. Une traduction franaise de la licence se trouve dans la section Licence de Documentation Libre GNU. Ce paragraphe est une traduction franaise pour aider votre comprhension. Seul le texte original en anglais prsent 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 amliorations apporter cette traduction vous pouvez me contacter. Cet article s'applique Shorewall 3.0 et ses versions ultrieures. Si vous utilisez une version plus ancienne de Shorewall, rfrez-vous la documentation s'appliquant votre version.
Installation de Shorewall
O puis-je trouver des instructions d'installation et de configuration pas pas ? Rponse: Allez voir les guides de dmarrage rapide.
(FAQ 37) Je viens d'installer Shorewall sur Debian et le rpertoire /etc/shorewall est vide!!! Rponse: Aprs 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 systme 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 rpertoire /etc/shorewall est vide. Ceci est voulu. Les squelettes des fichiers de configuration se trouvent sur votre systme dans le rpertoire /usr/share/doc/shorewall/default-config. Copiez simplement les fichiers dont vous avez besoin depuis ce rpertoire 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 mme 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..." Rponse: 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" Rponse: Vous pouvez sans aucun risque ignorer ce message. Il tait d une erreur mineure de paquetage qui a t corrige 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. Rponse: Le premier exemple de la documentation du fichier rules vous indique comment faire du transfert de port avec Shorewall. Le format d'une rgle de redirection de port vers un systme local se prsente 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 systme interne 192.168.1.5, la rgle est: #ACTION SOURCE DEST PROTO DEST PORT DNAT net loc:192.168.1.5 udp 7777 Si vous voulez rediriger vers un systme interne les requtes envoyes une adresse donne (<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, spcifiez 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. Rponse: Ceci se produit gnralement lorsque: Vous tentez de tester depuis l'intrieur de votre firewall (non, cela ne marchera pas -- allez voir la FAQ 2 ). Vous avez un problme plus lmentaire de configuration de votre systme local (celui vers lequel vous tentez de rediriger les paquets), une mauvaise passerelle par dfaut par exemple (elle devrait tre configure 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 antrieure 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 rgles 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 dtails.
(FAQ 1b) J'ai malgr tout encore des problmes avec la redirection de port Rponse: pour aller plus avant dans le diagnostic du problme: En tant que root, tapez iptables -t nat -Z . Ceci remet zro les compteurs Netfilter de la table nat. Essayez de vous connecter au port redirig depuis un hte externe. En tant que root, tapez shorewall[-lite] show nat Reprez la rgle DNAT approprie. Elle sera dans une chane nomme <zone source>_dnat (net_dnat dans les exemples ci-dessus). Est-ce que le dcompte de paquets dans la premire colonne est suprieur zro ? Si cela est le cas, la requte de connexion atteint le firewall et est bien redirige vers le serveur. Dans ce cas, le problme vient en gnral de l'absence de paramtrage ou d'un paramtrage erron de la passerelle par dfaut sur le systme local (celui vers lequel vous essayez de transfrer les paquets -- sa passerelle par dfaut devrait tre l'adresse IP de l'interface du firewall connecte ce systme local). Si le dcompte de paquets est gal zro: La requte 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 rgle ne redirige que l'adresse IP primaire (dans votre rgle DNAT vous devez spcifier l'adresse IP secondaire dans la colonne ORIG. DEST.) Pour d'autres raisons, votre rgle DNAT ne correspond pas la requte 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 diffrent de zro, vrifiez dans votre log si la connexion est droppe ou rejete. Si c'est le cas, il est possible que vous ayez un problme de dfinition de zone qui fasse que le serveur soit dans une zone diffrente de ce qui est spcifi dans la colonne DEST. A l'invite root, tapez "shorewall[-lite] show zones" et assurez-vous que vous avez bien spcifi dan la colonne DEST la premire zone de la liste qui correspond OUT=<dev> et DEST=<ip> dans le message REJECT/DROP de votre fichier log.
(FAQ 1c) Je voudrais que lorsque je me connecte depuis internet au port 1022 de mon firewall, cette connexion soit redirige vers le port 22 de mon systme local 192.168.1.3. Comment faire ? Rponse:Dans 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 trs bien sauf lorsque mes utilisateurs locaux essayent de se connecter au serveur en utilisant l'adresse IP externe du firewall. Rponse: 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'accs au serveur depuis votre rseau local en utilisant l'adresse IP externe du firewall. Pour cela, vous pouvez ajouter cette rgle: #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 ultrieures: ETH0_IP=`find_first_interface_address eth0` Et votre rgle 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 dcourager 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 paramtre une rgle 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 ignores ? Rponse: 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 rgle 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 rgles DNAT et quand doit-on utiliser des rgles ACCEPT ? Rponse: Je vous suggre de revenir au guides de dmarrage rapide adapt votre configuration. Ces guides couvrent ce sujet sous un angle didactique. Vous devriez utiliser des rgles 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 rseau local vers internet, vous aurez besoin d'utiliser des rgles DNAT pour autoriser les connexions d'internet vers votre rseau local. Vous utiliserez galement des rgles DNAT si vous voulez r-crire l'adresse IP ou le numro 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-mme, vous utiliserez une rgle REDIRECT. Dans tous les autres cas, vous utiliserez ACCEPT.
(FAQ 38) O trouver plus d'information sur la DNAT? Rponse: Ian Allen a crit cet article au sujet de la DNAT et Linux.
(FAQ 48) Comment configurer un proxy transparent avec Shorewall? Rponse: Vous pouvez voir Shorewall et Squid.
DNS et Transfert de Port/Traduction d'Adresses Rseau NAT
(FAQ 2) Je transfre (port forward) toutes les requtes web soumises www.mondomaine.com (IP 130.151.100.69) vers le systme 192.168.1.5 de mon rseau local. Les clients externes peuvent accder http://www.mondomaine.com mais les clients internes ne le peuvent pas. Rponse: j'ai deux objections cette configuration. Avoir un serveur sur votre rseau 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 systmes locaux. Pour le prix d'un adaptateur ethernet et d'un cble crois, vous pouvez mettre votre serveur en DMZ de telle faon qu'il soit isol de vos systmes 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 spar pour les clients locaux) afin que www.mondomaine.com soit rsolu 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 systmes 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-rseau 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'accs du serveur seront inutilisables pour dterminer quels htes locaux accdent 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 rgle 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 rgle 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 faon 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-rseau RFC 1918 et j'utilise la NAT un--un (one-to-one NAT) pour assigner des adresses non-RFC1918 aux htes de la zone <quote>Z</quote>. Les htes 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'accder un hte de la zone Z depuis un autre hte 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 Rponse: C'est encore un problme trs bien rsolu par l'utilisation des vues de Bind Version 9. Les clients internes comme les clients externes peuvent alors accder aux htes NATs en utilisant leur nom rseau. Une autre bonne faon d'approcher le problme est d'abandonner la NAT un--un au profit du Proxy ARP. De cette faon, les machines dans Z ont des adresses non-RFC1918 et on peut y accder aussi bien depuis l'intrieur que depuis l'extrieur en utilisant la mme adresse. Si vous n'aimez pas ces solutions et que vous prfrez btement 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-rseau: 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 prsente dans la FAQ2 ci-dessus, le trafic de la dmz vers la dmz semblera provenir du firewall et non du vritable hte 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 trs bien sauf pour mes utilisateurs locaux lorsqu'ils tentent de se connecter www.mondomaine.com. Rponse: 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 rseau local accder votre serveur en utilisant l'adresse IP externe du firewall. Il suffit d'ajouter cette rgle: #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 alloue dynamiquement, vous devez faire comme suit: Dans le fichier /etc/shorewall/params: ETH0_IP=`find_first_interface_address eth0` Et votre rgle 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.
(FAQ 2c) J'ai essay d'appliquer la rponse la FAQ 2 mon interface externe et la zone net. Cela ne marche pas. Pourquoi ? Rponse: Avez-vous activ IP_FORWARDING=On dans shorewall.conf?
Netmeeting/MSN
(FAQ 3) Je veux utiliser Netmeeting ou la messagerie instantane MSN avec Shorewall. Que faire ? Rponse: Il existe un module de suivi de connexion H.323 qui est d'un grand secours avec Netmeeting. Prenez cependant en compte cet article rcent d'un des dveloppeurs de Netfilter:
> Je sais que PoM -ng va traiter ce problme, mais en attendant qu'il soit prt, > et que tous les extras y soient ports, 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 systme, 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 rseau) ou un proxy (ce que je prfrerais viter) ? Je suggre tous de configurer un proxy (gatekeeper): le module est vraiment nul et ne mrite pas d'exister. a a t un trs bon outil de dveloppement et de deboguage de l'interface newnat.
Vous pouvez aller voir ici une solution pour la messagerie instantane MSN. Vous devez avoir conscience que cette solution comporte des risques de scurit significatifs. Vous pouvez galement vrifier auprs de la liste de diffusion de Netfilter http://www.netfilter.org.
Ports ouverts
(FAQ 51) Comment ouvrir des ports dans Shorewall? Rponse: Aucune personne ayant install Shorewall en utilisant un des Guides de Dmarrage Rapide ne devrait avoir poser cette question. Quel que soit le guide que vous avez utilis, toutes les communications sortantes sont ouvertes par dfaut. Vous n'avez donc pas "ouvrir de port" en sortie. En entre: 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.
(FAQ 4) Je viens juste d'utiliser un scanner de port en ligne pour vrifier le paramtrage de mon firewall et certains ports apparaissent <quote>ferms</quote> (closed) alors que d'autres sont <quote>bloqus</quote> (blocked). Pourquoi ? Rponse: La configuration par dfaut de Shorewall invoque l'action Drop avant de mettre en oeuvre une politique DROP, et la politique par dfaut d'internet vers toutes les zones est DROP. L'action Drop est dfinie dans le fichier /usr/share/shorewall/action.Drop qui invoque lui-mme la macro Auth (dfinie dans le fichier /usr/share/shorewall/macro.Auth) qui spcifie l'action REJECT (c.a.d., Auth/REJECT). Cela est ncessaire pour viter les problmes de connexion sortante des services qui utilisent le mcanisme Auth pour identifier les utilisateurs. C'est le seul service configur par dfaut pour rejeter (REJECT) les paquets. Si vous voyez d'autres ports TCP ferms autres que le port 113 (auth) c'est que vous avez ajout des rgles REJECT pour ces ports ou bien qu'un routeur l'extrieur de votre firewall rpond aux requtes de connexion sur ce port.
(FAQ 4a) Je viens d'excuter un scan UDP de mon firewall avec nmap et il trouve des centaines de ports ouverts!!!! Rponse: 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 rellement 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 rgles, Il y a un port que je n'arrive pas fermer. J'avais une rgle qui autorisait telnet de mon rseau local vers mon firewall. Je l'ai enleve et j'ai relanc Shorewall mais ma session telnet fonctionne encore!!! Rponse: Les rgles traitent de l'tablissement de nouvelles connexions. Lorsqu'une connexion est tablie par le firewall, elle restera utilisable jusqu' la dconnexion 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? Answer: Vous trouverez ici la description d'une bonne intgration de Shorewall et PortSentry.
(FAQ 4d) Comment utiliser Shorewall avec Snort-Inline? Rponse: Allez voir cette contribution de Michael Cooke.
Problmes de connexion
(FAQ 5) J'ai install Shorewall et je ne peux plus <quote>pinger</quote> travers le firewall Rponse: Pour une description complte de la gestion du ping par Shorewall, voyez cette page.
(FAQ 15) Mes systmes locaux ne peuvent rien voir sur internet Rponse: Chaque fois que je lis mes systmes 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 problmes sont: L'adresse de la passerelle par dfaut n'est pas configure l'adresse de l'interface locale du firewall sur chacun des systmes locaux. L'entr pour le rseau local dans le fichier /etc/shorewall/masq est errone ou manquante. La configuration du DNS sur les systmes 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). Excutez cette commande: cat /proc/sys/net/ipv4/ip_forward Si la valeur est 0 (zro) mettez IP_FORWARDING=On dans le fichier /etc/shorewall/shorewall.conf et relancez Shorewall.
(FAQ 29) FTP ne fonctionne pas Rponse: Voir la page Shorewall et FTP.
(FAQ 33) Depuis mes clients derrire le firewall les connexions vers certains sites chouent. Les connexions vers les mmes sites, mais depuis le firewall fonctionnent. Qu'est-ce qui ne va pas ? Rponse: Trs probablement, il vous faudra mettre CLAMPMSS=Yes dans le fichier /etc/shorewall/shorewall.conf.
(FAQ 35) J'ai deux interfaces ethernet vers mon rseau local que j'ai montes en pont (bridge). Quand Shorewall est dmarr, je n'arrive pas faire passer le trafic travers le pont. J'ai dfini l'interface pont (br0) comme interface locale dans /etc/shorewall/interfaces. Les interfaces ethernet <quote>pontes</quote> ne sont pas dfinies pour Shorewall. Comment demander Shorewall d'autoriser le trafic travers le pont ? Rponse: 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 enregistrs les messages de journalisation et comment modifier leur destination ? Rponse: 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 rgles. La destination des messages journaliss par syslog est contrle avec /etc/syslog.conf (voir man syslog.conf). Lorsque vous avez modifi /etc/syslog.conf, assurez-vous de redmarrer syslogd (sur un systme RedHat, service syslog restart). Par dfaut, les versions plus anciennes de Shorewall limitaient le taux de journalisation des messages grce des paramtres du fichier /etc/shorewall/shorewall.conf -- Si vous voulez journaliser tous les messages, positionnez ces paramtres comme suit: LOGLIMIT="" LOGBURST="" On peut galement paramtrer Shorewall pour qu'il enregistre les messages de journalisation dans un fichier spar.
(FAQ 6a) Existe-t-il des analyseur de journal qui fonctionnent avec Shorewall? Rponse: 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 diffrents systmes. Chaque rapport rsume l'activit journalise sur le systme correspondant.
(FAQ 6b) Mes journaux sont inonds de messages DROP pour des requtes de connections sur le port 10619. Puis-je exclure temporairement de la journalisation Shorewall les messages d'erreur pour ce port ? Rponse: Ajoutez temporairement la rgle suivante: #ACTION SOURCE DEST PROTO DEST PORT(S) DROP net fw udp 10619 Sinon, si vous ne mettez pas le paramtre BLACKLIST_LOGLEVEL et que vous avez spcifi 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
(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. Rponse: Ce qui est labelis comme adresse MAC dans les messages de journalisation Shorewall est en fait l'entte 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! Rponse: Trouvez o klogd est dmarr (ce sera depuis un des fichiers du rpertoire /etc/init.d -- sysklogd, klogd, ...). Modifiez ce fichier ou le fichier de configuration appropri de telle manire que klogd soit dmarr avec -c <n> avec <n> tant un niveau de journalisation infrieur ou gal 5; ou alors Voir la page man de dmesg (man dmesg). Vous devez ajouter une commande dmesg adapte dans vos scripts de dmarrage ou la placer dans le fichier /etc/shorewall/start. Sous RedHat et Mandriva, le niveau de journalisation maximum envoy la console est spcifi 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 ignors/rejets (dropped/rejected)? Comment dcode-t-on les messages de journalisation Shorewall? Rponse: Avec Shorewall, les paquets ignors/rejets peuvent avoir t journaliss en sortie d'un certain nombre de chanes (comme indiqu dans le message): man1918 or logdrop L'adresse destination est liste 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 liste dans le fichier /usr/share/shorewall/rfc1918 avec un cible logdrop -- voir /usr/share/shorewall/rfc1918. Si vous voyez des paquets rejets par la chane rfc1918 et que ni l'adresse IP source ni l'adresse IP de destination ne sont rserves par la RFC 1918, cela provient la plupart du temps d'un ancien fichier rfc1918 dans /etc/shorewall (ceci arrive le plus frquemment lorsque vous utilisez une Debian ou un de ses drivs). Le fichier rfc1918 incluait aussi bien les bogons que les trois plages rserves par la RFC 1918. Il tait install dans le rpertoire /etc/shorewall. Maintenant le fichier ne contient que les trois plages d'adresse de la RFC 1918 et il est install dans le rpertoire /usr/share/shorewall. Retirez le fichier rfc1918 prim de votre rpertoire /etc/shorewall. all2<zone>, <zone>2all or all2all Vous avez une politique qui spcifie un niveau de journalisation et ce paquet a t journalis par cette politique. Si vous voulez autoriser (ACCEPT) ce trafic, il vous faudra une rgle cette fin. <zone1>2<zone2> Ou bien vous avez une politique pour le trafic de la <zone1> vers la <zone2> qui spcifie un niveau de journalisation et ce paquet a t journalis par cette politique ou alors ce paquet correspond une rgle incluant un niveau de journalisation. A partir de Shorewall 3.3.3, les paquets loggs par ces chaines peuvent avoir une source et/ou une destination n'appartenant aucune zone dfinie (voir le rsultat de la commande shorewall[-lite] show zones). Souvenez-vous que l'appartenance une zone ncessite la fois une interface du firewall et une adresse ip. @<source>2<dest> Vous avez une politique pour le trafic de <source> vers <dest> dans laquelle vous avez spcifi un taux de limitation des connexions TCP (les valeurs dans la colonne LIMIT:BURST). Les paquet journalis dpassait cette limite et a t ignor (DROP). Il faut noter que ces messages au journal sont eux-mme svrement limits afin qu'une inondation SYN (syn-flood) ne provoque pas un dni 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 spcifi dans le paramtre 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 dfinie dans aucune de vos zones (shorewall[-lite] show zones et regardez les dfinitions de zones) ou alors la chane est FORWARD et l'adresse IP de destination ne figure dans aucune de vos zones dfinies. Si la chane 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'entre adquate dans le fichier /etc/shorewall/hosts . A partir de 3.3.3, de tels paquets peuvent aussi tre loggs par les chaines <zone>2all et all2all. OUTPUT Ce paquet a une adresse IP destination qui n'est dfinie dans aucune de vos zones (shorewall check et regardez les dfinitions de zones). A partir Shorewall 3.3.3, de tels paquets peuvent aussi tre loggs par les chaines fw2all et all2all. logflags Ce paquet a t journalis parce qu'il a chou aux contrles 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 chane 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-mme. 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-mme. Lorsqu'une rgle DNAT est journalise, 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 numro 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 rgle 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 rseau local est 172.16.0.0/24 Rponse: Bien que la plupart des gens associent ICMP (Internet Control Message Protocol) ping, ICMP est une pice cl de IP. ICMP sert informer l'expditeur d'un paquet des problmes rencontrs. C'est ce qui se produit ici. Malheureusement, de nombreuses implmentations ne fonctionnent pas ds lors que la traduction d'adresses est implique (y compris SNAT, DNAT et Masquerade). C'est ce que vous voyez avec travers ces messages. Quand Netfilter renvoie ces messages, la partie prcdent le "[" dcrit le paquet ICMP, et la partie entre "[" et "]" dcrit le paquet pour lequel ICMP rpond. Voici mon interprtation de ce qui se passe -- pour confirmer l'analyse, il faudrait avoir un sniffeur de paquets chacune des extrmits de la connexion. L'hte 172.16.1.10 plac derrire la passerelle NAT 206.124.146.179 a envoy une requte DNS UDP 192.0.2.3 et votre serveur DNS a tent d'envoyer un rponse (l'information en rponse est entre les crochets -- remarquez le port source 53 qui indique qu'il s'agit d'une rponse DNS). Quand la rponse a t envoye 206.124.146.179, le firewall a rcrit 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 gnration 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 mme faon l'IP destination dans la rponse 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 rponse DNS 172.16.1.10 et par consquent ce paquet ICMP semble n'tre associ rien de ce qui a t envoy. Le rsultat est que ce paquet est journalis et ignor (DROP) par la chane all2all. J'ai galement vu des cas dans lesquels la source IP dans le paquet ICMP lui-mme 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 chane rfc1918 cas son IP source est rserve par la RFC 1918.
(FAQ 52) Quand je blackliste une adresse IP avec "shorewall[-lite] drop www.xxx.yyy.zzz", pourquoi est-ce qu'il y a toujours des entres REDIRECT et DNAT en provenance de cette adresse dans mon journal ? 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 Rponse: Veuillez vous rfrer Shorewall Netfilter Documentation. La journalisation des rgles REDIRECT et DNAT se produit dans la chane PREROUTING de la table nat dans laquelle l'adresse est toujours valide. Le blacklistage se produit dans les chanes INPUT et FORWARD de la table filter qui ne sont traverses que plus tard.
(FAQ 56) Quand je dmarre ou redmarre Shorewall, je vois ces messages dans mon fichier log. Est-ce grave ?
modprobe: Can't locate module ipt_physdev modprobe: Can't locate module iptable_raw
Rponse: Non. Ceci se produit lorsque shorewall teste votre systme pour dterminer les fonctions qu'il supporte. Ils ne prsentent aucun risque.
Routage
(FAQ 32) J'ai deux connexions internet avec deux FAI diffrents sur mon firewall. Comment le configurer avec Shorewall? Rponse: voir cet article sur Shorewall et le routage.
(FAQ 49) Quand je dmarre Shorewall, ma table de routage est dtruite. Pourquoi Shorewall fait-il cela? Rponse: Ceci est en gnral la consquence d'une btise dans la configuration du NAT un--un (one-to-one NAT): Vous spcifiez 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 spcifiez ADD_IP_ALIASES=Yes et RETAIN_ALIASES=No dans le fichier /etc/shorewall/shorewall.conf. Cette combinaison fait dtruire par Shorewall l'adresse primaire de l'interface rseau spcifie dans la colonne INTERFACE, ce qui a en gnral pour consquence de dtruire routes les routes sortantes de cette interface. La solution est de ne pas spcifier l'adresse primaire d'une interface dans la colonne EXTERNAL.
Dmarrer et arrter Shorewall
(FAQ 7) Quand j'arrte Shorewall avec la commande <quote>shorewall[-lite] stop</quote>, je ne peux plus me connecter quoi que ce soit. Pourquoi cette commande ne fonctionne-t-elle pas? Rponse: La commande stop est prvue pour mettre votre firewall dans un tat de scurit o seuls les htes lists dans le fichier /etc/shorewall/routestopped sont activs. Si vous voulez ouvrir compltement votre firewall, il vous faut utiliser la commande shorewall clear.
(FAQ 8) Quand je tente de lancer Shorewall sur RedHat, je reois des messages d'erreur insmod -- qu'est-ce qui ne va pas? Rponse: 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 gnral, ce problme est corrig par la squence de commandes qui suit: service ipchains stop chkconfig --delete ipchains rmmod ipchains Par ailleurs, assurez-vous d'avoir vrifi dans l'errata que vous n'avez pas de problmes li la version d'iptables (v1.2.3) distribue avec RH7.2.
(FAQ 8a) Quand je tente de lancer Shorewall sur une RedHat, je reois un message qui me renvoie la FAQ #8 Rponse: Ceci se traite en gnral avec la squence de commandes prsente ci-dessus dans la .
(FAQ 9) Pourquoi Shorewall ne russit-il pas dtecter convenablement mes interfaces au dmarrage? 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 dtecte-t-il pas correctement mes interfaces? Rponse: La sortie ci-dessus est parfaitement normale. La zone Net est dfinie comme tant compose de toutes les machines connectes eth0 et la zone Local est dfinie comme tant compose de toutes celles connectes eth1. Si vous utilisez Shorewall 1.4.10 ou une version plus rcente, vous pouvez envisager de paramtrer l'option d'interface detectnet pour votre interface locale (eth1 dans l'exemple ce-dessus). Ceci forcera Shorewall restreindre la zone locale aux seuls rseaux routs par cette interface.
(FAQ 22) Je voudrais excuter certaines commandes iptables au dmarrage de Shorewall. Dans quel fichier les mettre? Rponse: Vous pouvez placer ces commandes dans une des Scripts d'Extension Shorewall. Assurez-vous de bien examiner le contenu des chanes que vos commandes vont modifier afin d'tre certain que ces commandes feront bien ce qu'elles sont censes faire. De nombreuses commandes publies dans des guides (HOWTOs) ainsi que dans d'autres modes opratoires font usage de la commande -A qui ajoute les rgles en fin de chane. La plupart des chanes construites par Shorewall se terminent par une rgle inconditionnelle DROP, ACCEPT ou REJECT et donc toute rgle que vous pourriez ajouter aprs serait ignore. Consultez man iptables et prenez connaissance de la commande -I (--insert).
(FAQ 34) Comment acclrer le dmarrage (start/restart)? Rponse: L'utilisation d'un shell lger tel que ash peut diminuer de faon trs significative le temps ncessaire pour dmarrer (start/restart) Shorewall. Voyez la variable SHOREWALL_SHELL dans le fichier shorewall.conf . Utilisez un mulateur de terminal rapide -- en particulier la console KDE dfile beaucoup plus vite que le terminal Gnome. Vous pouvez galement utiliser l'option '-q' si vous redmarrez distance ou depuis un terminal lent (ou rediriger la sortie vers un fichier comme dans shorewall restart > /dev/null). Mettez votre matriel niveau. De nombreux utilisateurs ont constat que mme une amlioration modeste de la CPU et de la vitesse de la mmoire (par exemple passer d'un P3 avec de la SDRAM un P4 avec de la DDR) avait des effets trs significatifs. Les CPU dotes de la technologie EM64T, aussi bien celles d'AMD que celles d'Intel, montrent des performances de redmarrage trs acceptables, mme si vous avez un jeu de rgles assez complexe. Shorewall offre galement une fonction de dmarrage rapide. Pour l'utiliser: Avec Shorewall dans l'tat dmarr, excutez shorewall save. Cela va crer 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'excuter si il existe. Excuter /var/lib/shorewall/restore prend beaucoup moins de temps que d'excuter un shorewall start complet. Le script /etc/init.d/shorewall excut au dmarrage du systme utilise l'option -f. Le script /var/lib/shorewall/restore peut tre excut 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 excuter 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 excute et non celle que reprsentent les fichiers de configuration que vous avez modifis. De mme, si vous modifiez votre configuration Shorewall et que vous tes satisfait du rsultat, vous devez excuter une commande shorewall save, sans quoi vous reviendriez l'ancienne configuration enregistre dans /var/lib/shorewall/restore lors du prochain dmarrage de votre systme. Finalement, le temps pendant lequel les nouvelles connexions sont bloques durant le redmarrage de Shorewall peut tre rduit dans de trs grande proportions en upgradant vers Shorewall 3.2 ou une version ultrieure. A partir de la 3.2, shorewall [re]start procde en deux tapes: La configuration courante est compile afin de produire un programme shell conu pour votre configuration. Si la compilation se droule sans erreur, le programme compil est excut pour [re]dmarrer votre firewall.
(FAQ 43) Je viens d'installer le RPM Shorewall et Shorewall ne dmarre pas au lancement du systme (boot). Rponse: Quand vous installez avec la commande "rpm -U", Shorewall n'excute pas les outils de votre distribution qui configurent le dmarrage de Shorewall. Vous devrez excuter cet outils vous-mme (insserv, chkconfig, run-level editor, …) pour que Shorewall dmarre aux niveaux d'excutions (run-level) auxquels vous voulez l'utiliser.
(FAQ 45) Pourquoi est-ce que "shorewall[-lite] 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 Rponse: Dans 99.999% des cas, cette erreur provient d'un problme 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 excutez sur votre systme. Si vous recompilez iptables avec les paramtres par dfaut puis que vous l'installez, il sera install dans /usr/local/sbin/iptables. Comme on peut le voir ci-dessus, votre variable IPTABLES est configure /sbin/iptables dans votre fichier shorewall.conf.
(FAQ 59) Aprs le dmarrage de Shorewall, de nombreux modules netfilter inutiliss sont chargs. Comment viter cela ? Rponse: 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.
(FAQ 61) Je viens juste d'installer le nouveau kernel Debian, et maintenant "shorewall start" choue avec le message "ipt_policy: matchsize 116 != 308". Qu'est-ce qui ne va pas? Rponse: 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'implmentation IPSEC du kernel 2.6) vous pouvez renommer /lib/iptables/libipt_policy.so.
Multiples FAIs
(FAQ 57) J'ai configur deux FAIs dans Shorewall mais quand j'essaye d'utiliser le second, cela ne fonctionne pas. Rponse: La documentation Multi-ISP vous recommande trs fortement d'utiliser l'option d'quilibrage (balance) pour tous les FAIs mme si vous voulez spcifier manuellement quel FAI utiliser. Si vous ne le faites pas et que votre table principale de routage n'a qu'une seule route par dfaut, vous devez dsactiver le filtrage de route. Ne spcifiez pas l'option routefilter sur l'autre interface dans /etc/shorewall/interfaces et dsactivez toute protections contre le spoofing d'adresses IP que votre distribution pourrait offrir.
(FAQ 58) Mais si je spcifie 'balance' est-ce que shorewall ne va pas quilibrer le trafic entre les interfaces ? Je ne veux pas qu'il le fasse ! Rponse: Supposez que vous vouliez que tout le trafic passe par le FAI1 (mark 1) jusqu' ce que vous spcifiez diffremment. Dans ce cas, ajoutez simplement ces deux rgles comme premires rgles 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 rgles de marquage aura mark=1 et sera envoy par le FAI1. Ceci fonctionnera que l'option balance soit spcifie ou pas.
Au sujet de Shorewall
(FAQ 10) Sur quelles distributions Shorewall tourne-t-il? Rponse: Shorewall fonctionnera sur n'importe quelle distribution GNU/Linux distribution runissant les pr-requis Shorewall indiqus dans ce document.
(FAQ 11) Quelles sont les caractristiques de Shorewall ? Rponse: voir la liste des caractristiques de Shorewall.
(FAQ 12) Existe-t-il une interface graphique? Rponse: Oui. Webmin offre le support de Shorewall 3.x partir dans sa version 1.300. Voir http://www.webmin.com
(FAQ 13) Pourquoi l'avez-vous appel <quote>Shorewall</quote>? Rponse: Shorewall est le rsultat de la concatnation de Shoreline (la ville o je vis) et de Firewall . En fait le nom complet du produit est Shoreline Firewall mais on utilise plus communment Shorewall.
(FAQ 23) Pourquoi utilisez-vous des polices de caractres aussi affreuses sur votre site web? Rponse: Le site web de Shorewall est presque entirement neutre en ce qui concerne les polices ( l'exception de quelques pages il ne spcifie explicitement aucune police). Les polices que vous voyez sont largement celles configures par dfaut dans votre navigateur. Si vous ne les aimez pas reconfigurez votre navigateur.
(FAQ 25) Comment savoir quelle version de Shorewall ou de Shorewall Lite j'utilise? Rponse: A l'invite du systme, tapez: /sbin/shorewall[-lite] 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 rseau local comme adresse source? Rponse: Oui. Tear Drop: Envoyer des paquets contenant des fragments qui se recouvrent ? Rponse: 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? Rponse: 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 mme adresse comme source et comme destination? Rponse: Oui lorsque l'option d'interface routefilter est slectionne. DOS: Dni de Service SYN Dos - ICMP Dos - protection DOS par hte Rponse: 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 hte distant sauf en utilisant une rgle explicite qui spcifie l'adresse IP de l'hte. Cette forme de limitation est supporte par Shorewall.
(FAQ 36) Est-ce que Shorewall tourne sur le noyau Linux 2.6? Rponse: 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 dtails 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 cble qui a son propre serveur web interne utilis pour le paramtrage 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 rgle avant la rgle de blocage rfc1918 de faon 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? Rponse: Ajoutez ce qui suit dans le fichier /etc/shorewall/rfc1918 (Remarque: Si vous utilisez 2.0.0 ou une version ultrieure, il est possible que ayez pralablement copier le fichier /usr/share/shorewall/rfc1918 vers /etc/shorewall/rfc1918): Assurez-vous d'ajouter l'entre AU-DESSUS de l'entre 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 entre 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 entres 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. Rponse: La solution est la mme que dans la FAQ 14 prsente 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 refuse. 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 Rponse: Le fait que le message soit journalis par la chane OUTPUT signifie que l'adresse de destination n'appartient aucune des zones dfinies (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 dfaut ou alors que leur passerelle par dfaut est fixe une adresse IP diffrente de l'adresse que vous avez attribue votre interface externe. Dans un cas comme dans l'autre, vous pouvez avoir des difficults naviguer sur votre modem depuis votre rseau local, mme si toutes les routes sont correctement tablies sur votre firewall. Pour rsoudre ce problme, on masquerade le trafic depuis rseau 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 aliases avec Shorewall, et de maintenir des jeux de rgles spars pour ces diffrentes adresses IP? Rponse: Oui. Voyez Shorewall et les interfaces aliases.
Shorewall Lite
(FAQ 53) Qu'est-ce que Shorewall Lite? Rponse: Shorewall Lite est un produit partenaire de Shorewall. Il est conu pour vous permettre de maintenir les informations de toutes vos configurations de Shorewall sur un seul systme dans votre rseau. Pour plus de dtails, voir Compiled Firewall script documentation.
(FAQ 54) Si je veux installer Shorewall Lite, est-ce que je dois aussi installer Shorewall sur le mme systme ? Rponse: Non. En fait, nous recommandons que vous n'installiez pas Shorewall sur les systmes sur lesquels vous souhaitez utiliser Shorewall Lite. Vous devez avoir install Shorewall sur au moins un des systmes de votre rseau pour pouvoir utiliser Shorewall Lite.
(FAQ 55) Comment dcider quel produit utiliser - Shorewall ou Shorewall Lite? Rponse: Si vous prvoyez 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 dplacement. Dans tous les autres cas, Shorewall Lite fonctionnera trs bien. A shorewall.net, les deux portables ainsi que mon ordinateur de bureau linux sont installs avec la version complte de Shorewall. Tous les autres systmes Linux qui ont un firewall utilisent Shorewall Lite et leurs rpertoires de configuration sont sur mon ordinateur de bureau.
(FAQ 60) Quelles restrictions de compatibilit existent entre Shorewall et Shorewall Lite Rponse: Voir le tableau ci-dessous (C = Compltement compatible avec toutes les fonctionnalits 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
Divers
(FAQ 20) Je viens d'installer un serveur. Dois-je modifier Shorewall pour autoriser les accs internet mon serveur? Rponse : Oui. Consultez le guides de dmarrage rapide que vous avez utilis pour votre configuration initiale afin d'avoir des informations ncessaires l'criture des rgles pour votre serveur.
(FAQ 24) Comment puis-je autoriser des connexions internet au port ssh, par exemple, mais seulement depuis certaines adresses IP spcifiques? Rponse : Dans la colonne SOURCE de la rgle, faites suivre net de : puis d'une liste spare par des virgules d'adresses de machines ou de sous-rseaux 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-mme ou depuis n'importe quelle machine derrire le firewall, j'obtiens une erreur <quote>operation not permitted</quote>. Comment utiliser nmap avec Shorewall?" Rponse : Retirez temporairement les rgles 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? Rponse : Commencez par regarder la page de configuration du noyau pour Shorewall. Vous souhaiterez sans doute vous assurer que vous avez bien slectionn NAT of local connections (READ HELP) dans le menu de configuration de Netfilter. Sans cela, les rgles DNAT ayant votre firewall comme zone source ne fonctionneraient pas avec votre nouveau noyau.
(FAQ 27a) Je viens de compiler (ou j'ai tlcharg ou rcupr par n'importe quel autre moyen) et d'installer un nouveau noyau et Shorewall ne dmarre plus. Je sais que les options de mon noyau sont correctes. Les dernires lignes de la trace de dmarrage 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 Rponse: votre noyau contient des enttes incompatibles avec celles utilises 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)? Rponse : Le support Shorewall pour les ponts filtrant existe — voir ici pour les dtails.
(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 rgle suivante: #ACTION SOURCE DEST PROTO REJECT fw net:pagead2.googlesyndication.com all Cependant, ceci bloque parfois les accs "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 plutt ses adresses IP. Comment bloquer rellement un nom de domaine? Rponse: Les filtres de paquets basent leurs dcisions sur le contenu des diffrents enttes de protocole qui se trouvent au dbut de chaque paquet. Les filtres de paquet suivi d'tats (dont Netfilter est un exemple) utilisent une combinaison du contenu de l'entte et de l'tat de la connexion cr lors du traitement de paquets prcdents. Netfilter (et l'usage qui en est fait par Shorewall) prend galement en compte l'interface rseau sur laquelle chaque paquet est entr ou sur laquelle le paquet va quitter le routeur/firewall. Lorsque vous spcifiez un nom de domaine dans une rgle Shorewall, le programme iptables rsout ce nom en une ou plusieurs adresses IP et les vritables rgles qui seront cres sont exprimes avec ces adresses IP. C'est pourquoi la rgle que vous avez entre est quivalente : #ACTION SOURCE DEST PROTO REJECT fw net:216.239.37.99 all REJECT fw net:216.239.39.99 allSachant que l'hbergement multiple bas sur le nom d'hte est une pratique courante (par exemple, lists.shorewall.net et www1.shorewall.net sont hbergs tous les deux sur le mme systme avec un seule adresse IP), il n'est pas possible de filtrer les connexions vers un nom particulier au seul examen des enttes de protocole. Alors que certains protocoles tels que FTP ncessitent que le firewall examine et ventuellement modifie les donnes (payload) du paquet, analyser les donnes de paquets individuellement ne fonctionne pas toujours car le flux de donnes de niveau application peut tre fractionn de manire 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 sr pour filtrer sur le contenu des paquets est d'utiliser un proxy pour les connexions concernes -- 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 analyss de manire prcise.
(FAQ 42) Comment connatre quelles sont les fonctions supportes par mon noyau et ma version d'iptables? Rponse: 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:~#
(FAQ 19) Comment ouvrir le firewall pour tout le trafic de/vers le LAN? Rponse : Ajoutez ces deux politiques: #SOURCE DESTINATION POLICY LOG LIMIT:BURST # LEVEL $FW loc ACCEPT loc $FW ACCEPT Vous pouvez galement supprimer toutes les rgles ACCEPT de $FW->loc et loc->$FW car ces rgles sont maintenant redondantes avec les deux politiques fixes ci-dessus.
shorewall-docs-xml-5.0.15/LXC.xml0000644000000000000000000001172513020330134015167 0ustar rootroot
LXC and Shorewall Tom Eastep 2011 Thomas M. Eastep 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.
Background LXC (http://lxc.sourceforge.net/) is a set of user-space tools for managing the container capabilities that have been in the Linux Kernel since 2.6.27. This short article describes how I've implemented LXC here at shorewall.net, with emphasis on the networking and firewall aspects.
Overview of a Working Configuration The following diagram shows the network at shorewall.net in the spring of 2011. As shown in that diagram, the LXC containers are bridged to br0. Here are the relevant configuration entries. /etc/network/interfaces: # # LXC bridge # auto br0 iface br0 inet static bridge_ports none bridge_fd 0 address 70.90.191.121 broadcast 0.0.0.0 netmask 255.255.255.255 post-up ip route add 70.90.191.124/31 dev br0 iface br0 inet6 static address 2001:470:b:227::41 netmask 124 /etc/lxc/mail.conflxc.network.type=veth lxc.network.link=br0 lxc.network.flags=up lxc.network.ipv4=70.90.191.124/29 lxc.network.ipv6=2001:470:b:227::42/124 … /etc/lxc/server.conflxc.network.type=veth lxc.network.link=br0 lxc.network.flags=up lxc.network.ipv4=70.90.191.125/29 lxc.network.ipv6=2001:470:b:227::43/124 … Note that I have subnetted 2001:470:b:227::/64 with a /124 (2001:470:b:227::40/124) assigned to the bridge. To make those addresses accessible from the LOC zone, the following entries are required in /etc/shorewall6/proxyndp: #ADDRESS INTERFACE EXTERNAL HAVEROUTE PERSISTENT 2001:470:b:227::41 - eth1 Yes Yes 2001:470:b:227::42 - eth1 Yes Yes 2001:470:b:227::43 - eth1 Yes Yes The entries in the LXC .conf files are expected to configure eth0 in the LXC containers; they do, sort of. In both of the containers, no ipv6 default route was assigned. I corrected that by adding this entry in /etc/sysctl.conf in both containers: net.ipv6.conf.all.forwarding=0 I then added this stanza to /etc/radvd.conf on the host: interface br0{ AdvSendAdvert on; MinRtrAdvInterval 300; MaxRtrAdvInterval 505; AdvDefaultLifetime 9000; route ::/0 { AdvRouteLifetime infinity; }; }; Curiosly, LXC gives container mail's eth0 this somewhat odd configuration, and fails to add a default ipv4 route: 14: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 4e:56:66:11:3c:6b brd ff:ff:ff:ff:ff:ff inet 70.90.191.124/29 brd 70.90.191.120 scope global eth0 inet6 2001:470:b:227::42/124 scope global valid_lft forever preferred_lft forever inet6 fe80::4c56:66ff:fe11:3c6b/64 scope link valid_lft forever preferred_lft forever So in that container's /etc/rc.local, I also have: ip route add default via 70.90.191.121 With the exception of the entries in /etc/shorewall6/proxyndp. the Shorewall and Shorewall6 configurations are fairly conventional three-interface setups. In both configurations, the interfaces file entry for br0 has the option specified.
shorewall-docs-xml-5.0.15/shorewall_features.xml0000644000000000000000000002145713020330134020442 0ustar rootroot
Shorewall 5.0 Features Tom Eastep 2001-2016 Thomas M Eastep 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.
Features Uses Netfilter's connection tracking facilities for stateful packet filtering. Can be used in a wide range of router/firewall/gateway applications . Completely customizable using configuration files. No limit on the number of network interfaces. Allows you to partition the network into zones and gives you complete control over the connections permitted between each pair of zones. Multiple interfaces per zone and multiple zones per interface permitted. Supports nested and overlapping zones. Supports centralized firewall administration. Shorewall installed on a single administrative system. May be a Windows PC running Cygwin or an Apple MacIntosh running OS X. Centrally generated firewall scripts run on the firewalls under control of Shorewall-lite. QuickStart Guides (HOWTOs) to help get your first firewall up and running quickly A GUI is available via Webmin 1.060 and later (http://www.webmin.com) Extensive documentation is available in both Docbook XML and HTML formats. Flexible address management/routing support (and you can use all types in the same firewall): Masquerading/SNAT. Port Forwarding (DNAT). One-to-one NAT. Proxy ARP. NETMAP. Multiple ISP support (Multiple Internet Links from the same firewall/gateway) Blacklisting of individual IP addresses and subnetworks is supported. Operational Support. Commands to start, stop and clear the firewall Supports status monitoring with an audible alarm when an interesting packet is detected. Wide variety of informational commands. VPN Support. IPSEC, GRE, IPIP and OpenVPN Tunnels. PPTP clients and Servers. Support for Traffic Control/Shaping. Wide support for different GNU/Linux Distributions. RPM and Debian packages available. Includes automated install, upgrade and uninstall facilities for users who can't use or choose not to use the RPM or Debian packages. Included as a standard part of LEAF/Bering (router/firewall on a floppy, CD or compact flash). Media Access Control (MAC) Address Verification. Traffic Accounting. Bridge/Firewall support IPv6 Support Works with a wide range of Virtualization Solutions: KVM Xen Linux-Vserver OpenVZ VirtualBox LXC Docker (Shorewall 5.0.6 and later)
shorewall-docs-xml-5.0.15/Actions.xml0000644000000000000000000012434713020330134016146 0ustar rootroot
Actions Tom Eastep 2005 2007 2008 2009 2010 2012 2013 2015-2016 Thomas M. Eastep 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. This article applies to Shorewall 4.3 and later. If you are running a version of Shorewall earlier than Shorewall 4.3.5 then please see the documentation for that release.
What are Shorewall Actions? Shorewall actions allow a symbolic name to be associated with a series of one or more iptables rules. The symbolic name may appear in the ACTION column of an /etc/shorewall/rules entry, in a macro body and within another action, in which case the traffic matching that rules file entry will be passed to the series of iptables rules named by the action. Actions can be thought of as templates. When an action is invoked in an /etc/shorewall/rules entry, it may be qualified by a logging specification (log level and optionally a log tag). The presence of the log level/tag causes a modified series of rules to be generated in which each packet/rule match within the action causes a log message to be generated. For readers familiar with iptables, actions are the way in which you can create your own filter-table chains. There are three types of Shorewall actions: Built-in Actions. These actions are known by the Shorewall code itself. They are listed in the comments at the top of the file /usr/share/shorewall/actions.std. Standard Actions. These actions are released as part of Shorewall. They are listed in the file /usr/share/shorewall/actions.std and are defined in the corresponding action.* files in /usr/share/shorewall. Each action.* file has a comment at the beginning of the file that describes what the action does. As an example, here is the definition of the AllowSMB standard action from Shorewall version 2.2. # # Shorewall 2.2 /usr/share/shorewall/action.AllowSMB # # Allow Microsoft SMB traffic. You need to invoke this action in # both directions. # ###################################################################################### #TARGET SOURCE DEST PROTO DPORT SPORT RATE USER ACCEPT - - udp 135,445 ACCEPT - - udp 137:139 ACCEPT - - udp 1024: 137 ACCEPT - - tcp 135,139,445 If you wish to modify one of the standard actions, do not modify the definition in /usr/share/shorewall. Rather, copy the file to /etc/shorewall (or somewhere else on your CONFIG_PATH) and modify the copy. Standard Actions have been largely replaced by macros . User-defined Actions. These actions are created by end-users. They are listed in the file /etc/shorewall/actions and are defined in action.* files in /etc/shorewall or in another directory listed in your CONFIG_PATH (defined in /etc/shorewall/shorewall.conf).
Default Actions (Formerly Common Actions) Shorewall allows the association of a default action with policies. A separate default action may be associated with ACCEPT, DROP, REJECT, QUEUE and NFQUEUE policies. Default actions provide a way to invoke a set of common rules just before the policy is enforced. Default actions accomplish two goals: Relieve log congestion. Default actions typically include rules to silently drop or reject traffic that would otherwise be logged when the policy is enforced. Ensure correct operation. Shorewall supports default actions for the ACCEPT, REJECT, DROP, QUEUE and NFQUEUE policies. These default actions are specified in the /etc/shorewall/shorewall.conf file using the ACCEPT_DEFAULT, REJECT_DEFAULT, DROP_DEFAULT, QUEUE_DEFAULT and NFQUEUE_DEFAULT options respectively. Policies whose default is set to a value of none have no default action. In addition, the default specified in /etc/shorewall/shorewall.conf may be overridden by specifying a different action in the POLICY column of /etc/shorewall/policy. Entries in the DROP and REJECT default actions ARE NOT THE CAUSE OF CONNECTION PROBLEMS. Remember — default actions are only invoked immediately before the packet is going to be dropped or rejected anyway!!! Beginning with Shorewall 4.4.21, the standard Drop and Reject options are parameterized. Each has five parameters as follows: ACTION PARAMETER VALUE DEFAULT Drop 1 Either '-' or 'audit'. 'audit' causes auditing by the builtin actions invoked by Drop - Drop 2 Determines what to do with Auth requests - Drop 3 Determines what to do with SMB DROP or A_DROP depending on the setting of parameter 1 Reject 1 Either '-' or 'audit'. 'audit' causes auditing by the builtin actions invoked by Drop - Reject 2 Determines what to do with Auth requests - Reject 3 Determines what to do with SMB REJECT or A_REJECT depending on the setting of parameter 1 Both 4 Determines what to do with accepted critical ICMP packets. ACCEPT or A_ACCEPT depending on the setting of parameter 1 Both 5 Determines what to do with late-arriving DNS replies (source port 53) or UPnP (udp port 1900). DROP or A_DROP depending on the setting of parameter 1. The parameters may be specified in either shorewall.conf (e.g., DROP_DEFAULT=Drop(-,DROP) or in the POLICY column of shorewall-policy(5) (e.g., DROP:Drop(audit):audit).
Defining your own Actions Before defining a new action, you should evaluate whether your goal can be best accomplished using an action or a macro. See this article for details. To define a new action: Add a line to /etc/shorewall/actions that names your new action. Action names must be valid shell variable names (must begin with a letter and be composed of letters, digits and underscore characters) as well as valid Netfilter chain names. If you intend to log from the action, the name must have a maximum of 11 characters. It is recommended that the name you select for a new action begins with a capital letter; that way, the name won't conflict with a Shorewall-defined chain name. Normally. the rules in an action are placed in a separate chain. Beginning with Shorewall 4.5.10, the action rules can be expanded inline in a manner similar to a macro by specifying in the OPTIONS column of /etc/shorewall/actions. Beginning in Shorewall 4.5.11, the option may be specified; see the logging section below for details. Shorewall includes pre-defined actions for DROP and REJECT -- see above. Once you have defined your new action name (ActionName), then copy /usr/share/shorewall/action.template to /etc/shorewall/action.ActionName (for example, if your new action name is Foo then copy /usr/share/shorewall/action.template to /etc/shorewall/action.Foo). Now modify the new file to define the new action.
Shorewall 5.0.0 and Later. In Shorewall 5.0, the columns in action.template are the same as those in shorewall-rules (5). There are no restrictions regarding which targets can be used within your action. The SOURCE and DEST columns in the action file may not include zone names; those are given when the action is invoked. Additionally, it is possible to pass parameters to an action, when it is invoked in the rules file or in another action. Here's a trivial example: /etc/shorewall/action.A: #TARGET SOURCE DEST PROTO Dport SPORT ORIGDEST $1 - - tcp 80 - 1.2.3.4 /etc/shorewall/rules: #TARGET SOURCE DEST PROTO DPORT SPORT ORIGDEST A(REDIRECT) net fw The above is equivalent to this rule: #TARGET SOURCE DEST PROTO DPORT SPORT ORIGDEST REDIRECT net - tcp 80 - 1.2.3.4 You can 'omit' parameters by using '-'. Example: ACTION(REDIRECT,-,info) In the above example, $2 would expand to nothing. Beginning with Shorewall 4.5.13, completely omitting a arameter is equivalent to passing '-'. Example: ACTION(REDIRECT,,info) This example behaves the same as the one shown above. If you refer to a parameter $n in the body of the action, then the nth paramer must either be passed to all action invocations or it's default value must be established via a DEFAULTS line. If you want to make '-' a parameter value, use '--' (e.g., ACTION(REDIRECT,--.info)). Beginning with Shorewall 4.4.21, you can specify the default values of your FORMAT-2 actions: DEFAULTS def1,def2,... where def1 is the default value for the first parameter, def2 is the default value for the second parameter and so on. You can specify an empty default using '-' (e.g. DEFAULTS DROP,-,audit). For additional information about actions, see the Action Variables section of the Configuration Basics article.
Mangle Actions Beginning with Shorewall 5.0.7, actions may be used in shorewall-mangle(5) and shorewall6-mangle(5). Because the rules and mangle files have different column layouts, actions can be defined to be used in one file or the other but not in both. To designate an action to be used in the mangle file, specify the option in the action's entry in shorewall-actions(5) or shorewall6-actions(5). To create a mangle action, follow the steps in the preceding section, but use the /usr/share/shorewall/action.mangletemplate file.
Actions and Logging Specifying a log level in a rule that specifies a user-defined or Shorewall-defined action will cause each rule in the action to be logged with the specified level (and tag), unless the option is specified in the action's entry in /etc/shorewall/actions. The extent to which logging of action rules occur is governed by the following: When you invoke an action and specify a log level, only those rules in the action that have no log level will be changed to log at the level specified at the action invocation. Example: /etc/shorewall/action.foo #TARGET SOURCE DEST PROTO DPORT ACCEPT - - tcp 22 bar:info /etc/shorewall/rules: #ACTION SOURCE DEST PROTO DPORT foo:debug $FW net Logging in the invoke foo action will be as if foo had been defined as: #TARGET SOURCE DEST PROTO DPORT ACCEPT:debug - - tcp 22 bar:info If you follow the log level with ! then logging will be set at that level for all rules recursively invoked by the action. Example: /etc/shorewall/action.foo #TARGET SOURCE DEST PROTO DPORT ACCEPT - - tcp 22 bar:info /etc/shorewall/rules: #ACTION SOURCE DEST PROTO DPORT foo:debug! $FW net Logging in the invoke foo action will be as if foo had been defined as: #TARGET SOURCE DEST PROTO DPORT ACCEPT:debug - - tcp 22 bar:debug
Using Embedded Perl in an Action There may be cases where you wish to create a chain with rules that can't be constructed using the tools defined in the action.template. Such rules can be constructed using Embedded Perl. For those who are comfortable using Perl, embedded Perl is more efficient that using complicated conditional entries. The Perl compiler is invoked only once for a BEGIN PERL...END PERL block; it is invoked most times that an expression is evaluated in an ?IF, ?ELSEIF or ?SET directive. The Shorewall compiler provides a set of services that are available to Perl code embedded in an action file. These services are not available in in-line actions when running Shorewall 4.5.12 or earlier. Shorewall::Config::get_action_params( $howmany ) This function returns an array containing the functions parameters. The scalar argument $howmany is the number of parameters that you expect to be passed. You can ensure that at least this many parameters are passed by including a DEFAULTS line prior to the embedded Perl. Shorewall::Config::set_action_param( $ordinal, $value ) Set the value of parameter $ordinal to $value. Care must be take when using this function such that for a given set of parameters actually passed to the action, the same rules are created. That is because the compiler assumes that all invocations of an action with the same parameters, log level and log tag can share the same action chain. Shorewall::Config::get_action_chain() This function returns a reference to the chain table entry for the current action chain. Shorewall::Config::get_action_logging() Returns a two-element list containing the the log level and log tag specified when the action was invoked. Note that you must use this function rather than @loglevel and @logtag within embedded Perl, as the compiler does not expand Shorewall Variables within embedded Perl (or embedded shell). Shorewall::Config::push_comment() Prior to Shorewall 4.5.21, this required: use Shorewall::Config (:DEFAULT :internal); Returns the current rule comment to the caller and clears the comment. The returned comment may be restored by calling either pop_comment() or set_comment(). Shorewall::Config::pop_comment($comment) and Shorewall::Config::set_comment($comment). The set_comment() function was added in Shorewall 4.5.21. Prior to that release, accessing pop_comment() required: use Shorewall::Config (:DEFAULT :internal); These functions are identical and set the current rule comment to the contents of the passed simple variable. Shorewall::Chains::add_rule( $chainref, $rule [, $expandports ] ) This function adds a rule to a chain. As of Shoreall 4.5.13, it is deprecated in favor of Shorewall::Rules::perl_action_helper(). Arguments are: $chainref Normally, you get this from get_action_chain() described above. $rule The matches and target for the rule that you want added. $expandports (optional) This optional argument is for compiler-internal use only. Either omit it or pass a false value. Do not call this function in a inline action. Use perl_action_helper() instead (see below). Shorewall::Chains::log_rule_limit( $level, $chainref, $chain, $disposition, $limit, $tag, $command, $matches ) This function adds a logging rule to a chain. As of Shoreall 4.5.13, it is deprecated in favor of Shorewall::Rules::perl_action_helper(). Arguments are: $level Either a syslog level or a ULOG or NFLOG target expression (e.g., "NFLOG(1,0,1)"). Specifies how you want the logging done. $chainref Normally, you get this from get_action_chain() described above. $chain The value you want substituted for the first %s formatting directive in the LOGFORMAT setting in /etc/shorewall/shorewall.conf. $disposition This is the value substituted for the second '%s' formatting directive in the LOGFORMAT setting in /etc/shorewall/shorewall.conf. $limit If you want to use the default limit set in LOGLIMIT (/etc/shorewall/shorewall.conf), you can specify your own '-limit' match. Otherwise, if you want to use the default, pass 0 or "". If you want the rule to be unlimited, pass '-'. $tag Log tag. $command Pass 'add' here, unless you want the rule to be inserted at the front of the chain. $matches Zero or more iptables matches that limit when logging will occur. If this parameter is other than the empty string, the last character must be a space. Shorewall::Chains::allow::optimize( $chainref ) This allows the passed action chain to be optimized away (jumps to the chain are replaced by the chain's rule(s)). The chainref argument is usually obtained from get_action_chain() described above. Shorewall::Rules::perl_action_helper( $target, $matches ) This function adds a rule to the current chain. For a regular action, the chain will be an action chain; for an inline action, the chain is determined by the invoking rule. To use this function, you must include: use Shorewall::Rules; Arguments are: $target The target of the rule. Legal values are anything that can appear in the TARGET column of in an action body and may include log level, tag, and parameters. $matches ip[6]tables matches to be included in the rule. When called in an inline action, these matches are augmented by matches generated by the invoking rule. This function has additional optional arguments which are used internally by Shorewall standard actions. Their number and behavior is likely to change in future Shorewall releases. Shorewall::Rules::perl_action_tcp_helper( $target, $proto ) This function is similar to Shorewall::Rules::perl_action_helper but is taylored for specifying options to "-p tcp". To use this function, you must include: use Shorewall::Rules; Arguments are: $target The target of the rule. Legal values are anything that can appear in the TARGET column of in an action body and may include log level, tag, and parameters. $proto The '-p' part of the rule to be generated (e.g., "-p tcp --tcp-flags RST RST"). For examples of using these services, look at the standard actions in /usr/share/shorewall/action.*.
Creating an Action using an Extension Script (deprecated in favor of BEGIN PERL ... END PERL) There may be cases where you wish to create a chain with rules that can't be constructed using the tools defined in the action.template. In that case, you can use an extension script. Beginning with Shorewall 4.5.16, such scripts require CHAIN_SCRIPTS=Yes in shorewall.conf (5) If you actually need an action to drop broadcast packets, use the dropBcast standard action rather than create one like this. An action to drop all broadcast packets If you define an action acton and you have an /etc/shorewall/acton script, the rules compiler sets lexical variables as follows: $chainref is a reference to the chain-table entry for the chain where your rules are to be placed. $level is the log level. If false, no logging was specified. $tag is the log tag. @params is the list of parameter values (Shorewall 4.4.16 and later). 'Omitted' parameters contain '-'. Example: /etc/shorewall/actionsDropBcasts /etc/shorewall/action.DropBcasts# This file is empty/etc/shorewall/DropBcastsuse Shorewall::Chains; if ( $level ne '' ) { log_rule_limit $level, $chainref, 'dropBcast' , 'DROP', '', $tag, 'add', ' -m addrtype --dst-type BROADCAST '; log_rule_limit $level, $chainref, 'dropBcast' , 'DROP', '', $tag, 'add', ' -d 224.0.0.0/4 '; } add_rule $chainref, '-m addrtype --dst-type BROADCAST -j DROP'; add_rule $chainref, '-d 224.0.0.0/4 -j DROP'; 1; For a richer example, see the next section.
Limiting Per-IP Connection Rate using the Limit Action Shorewall supports a Limit built-in action. Prior to Shorewall 4.4.16, Limit is invoked with a comma-separated list in place of a logging tag. Beginning in Shorewall 4.4.16, it may also be invoked with a list of three parameters enclosed in parentheses. The list has three elements: The name of a recent list. You select the list name which must conform to the rules for a valid chain name. Different rules that specify the same list name will use the same set of counters. The number of connections permitted in a specified time period. The time period, expressed in seconds. Connections that exceed the specified rate are dropped. For example, to use a recent list name of SSHA, and to limit SSH connections to 3 per minute, use this entry in /etc/shorewall/rules: #ACTION SOURCE DEST PROTO DPORT Limit:none:SSHA,3,60 net $FW tcp 22 Using Shorewall 4.4.16 or later, you can also invoke the action this way: #ACTION SOURCE DEST PROTO DPORT Limit(SSHA,3,60):none net $FW tcp 22 If you want dropped connections to be logged at the info level, use this rule instead: #ACTION SOURCE DEST PROTO DPORT Limit:info:SSHA,3,60 net $FW tcp 22 Shorewall 4.4.16 and later:#ACTION SOURCE DEST PROTO DPORT Limit(SSH,3,60):info net $FW tcp 22 To summarize, you pass four pieces of information to the Limit action: The log level. If you don't want to log, specify none. The name of the recent list that you want to use (SSHA in this example). The maximum number of connections to accept (3 in this example). The number of seconds over which you are willing to accept that many connections (60 in this example).
How Limit is Implemented For those who are curious, the Limit action in Shorewall 4.4.16 is implemented as follows: use Shorewall::Chains; @params = split( /,/, $tag ), $tag='' unless @params; fatal_error 'Limit rules must include <list name>,<max connections>,<interval> as the log tag or params' unless @params == 3; my $list = $params[0]; for ( @params[1,2] ) { fatal_error 'Max connections and interval in Limit rules must be numeric (' . $_ . ')' unless /^\d+$/ } my $count = $params[1] + 1; add_rule $chainref, "-m recent --name $list --set"; if ( $level ) { my $xchainref = new_chain 'filter' , "$chainref->{name}%"; log_rule_limit $level, $xchainref, $params[0], 'DROP', $tag, '', 'add', ''; add_rule $xchainref, '-j DROP'; add_rule $chainref, "-m recent --name $list --update --seconds $params[2] --hitcount $count -j $xchainref->{name}"; } else { add_rule $chainref, "-m recent --update --name $list --seconds $params[2] --hitcount $count -j DROP"; } add_rule $chainref, '-j ACCEPT'; 1;
Mangle Actions Beginning with Shorewall 5.0.7, actions are supported in shorewall-mangle(5). Like actions used out of shorewall-rules(5), they must be declared in shorewall-actions(5). These mangle actions must have the option specified on shorewall-actions(5). Like the actions described in the preceding sections, mangle actions are defined in a files with names of the form action.action. Rules in those files have the same format as those in shorewall-mangle(5) with the restriction that chain designators (:P, :F, etc.) are not permitted in the ACTION column. Both regular and inline actions are supported. Inline Example /etc/shorewall/actions: #ACTION OPTIONS Divert inline,mangle # TProxy Rules /etc/shorewall/action.Divert: #ACTION SOURCE DEST PROTO DPORT SPORT DIVERT COMB_IF - tcp - 80 DIVERT COMC_IF - tcp - 80 DIVERT DMZ_IF 172.20.1.0/24 tcp - 80 /etc/shorewall/mangle: #ACTION SOURCE DEST PROTO DPORT SPORT Divert More efficient way to do this: /etc/shorewall/actions: #ACTION OPTIONS Divert inline # TProxy Rules /etc/shorewall/action.Divert: #ACTION SOURCE DEST PROTO DPORT SPORT DIVERT COMB_IF - DIVERT COMC_IF - DIVERT DMZ_IF 172.20.1.0/24 /etc/shorewall/mangle: #ACTION SOURCE DEST PROTO DPORT SPORT Divert - - tcp - 80
SNAT Actions Beginning with Shorewall 5.0.14, actions are supported in shorewall-snat(5); that file supercedes shorewall-masq(5) which is still supported. The shorewall update command will convert a masq file into the equivalent snat file. Like actions used out of shorewall-rules(5), SNAT actions must be declared in shorewall-actions(5). These mangle actions must have the option specified on shorewall-actions(5). Like the actions described in the preceding sections, SNAT actions are defined in a files with names of the form action.action. Rules in those files have the same format as those in shorewall-snat(5) with two restrictions: The plus sign ("+") is not allowed in the ACTION column, so all rules in the action will either be pre-nat or post-nat depending on whether '+' was present in the action's invocation. Interface names are not allowed in the DEST column, so all rules in the action will apply to the interface specified in the action's invocation. Both regular and inline actions are supported. Example: /etc/shorewall/actions: #ACTION OPTIONS custEPTs nat,inline /etc/shorewall/action.custEPTs: #ACTION SOURCE DEST PROTO PORT SNAT($GW_IP) { proto=udp port=1146 } SNAT($GW_IP) { proto=tcp port=1156,7221,21000 } /etc/shorewall/snat: ACTION SOURCE DEST PROTO PORT custEPTs { source=$EPT_LIST dest=$IF_NET:$EPT_SERVERS } More effeciently: /etc/shorewall/actions: #ACTION OPTIONS custEPTs nat /etc/shorewall/action.custEPTs: #ACTION SOURCE DEST PROTO PORT SNAT($GW_IP) { proto=udp port=1146 } SNAT($GW_IP) { proto=tcp port=1156,7221,21000 } /etc/shorewall/snat: ACTION SOURCE DEST PROTO PORT custEPT { source=$EPT_LIST dest=$IF_NET:$EPT_SERVERS }
shorewall-docs-xml-5.0.15/ping.xml0000644000000000000000000000670413020330134015477 0ustar rootroot
ICMP Echo-request (Ping) Tom Eastep 2001-2005 Thomas M. Eastep 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. This article applies to Shorewall 3.0 and later. If you are running a version of Shorewall earlier than Shorewall 3.0.0 then please see the documentation for that release. Enabling ping will also enable ICMP-based traceroute. For UDP-based traceroute, see the port information page.
'Ping' Management In Shorewall , ICMP echo-requests are treated just like any other connection request. In order to accept ping requests from zone z1 to zone z2 where the policy for z1 to z2 is not ACCEPT, you need a rule in /etc/shorewall/rules of the form: #ACTION SOURCE DEST PROTO DPORT Ping(ACCEPT) z1 z2 Ping from local zone to firewall To permit ping from the local zone to the firewall: #ACTION SOURCE DEST PROTO DPORT Ping(ACCEPT) loc $FW If you would like to accept ping by default even when the relevant policy is DROP or REJECT, copy /usr/share/shorewall/action.Drop or /usr/share shorewall/action.Reject respectively to /etc/shorewall and simply add this line to the copy: Ping(ACCEPT) With that rule in place, if you want to ignore ping from z1 to z2 then you need a rule of the form: #ACTION SOURCE DEST PROTO DPORT Ping(DROP) z1 z2 Silently drop pings from the Internet To drop ping from the Internet, you would need this rule in /etc/shorewall/rules: #ACTION SOURCE DEST PROTO DPORT Ping(DROP) net $FW Note that the above rule may be used without changing the action files to prevent your log from being flooded by messages generated from remote pinging.
shorewall-docs-xml-5.0.15/NetfilterOverview.xml0000644000000000000000000002720513020330134020224 0ustar rootroot
Netfilter Overview Tom Eastep 2003 2005 Thomas M. Eastep 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.
Netfilter Overview Netfilter consists of three tables: Filter, Nat and Mangle. Each table has a number of build-in chains: PREROUTING, INPUT, FORWARD, OUTPUT and POSTROUTING. Rules in the various tables are used as follows: Filter Packet filtering (rejecting, dropping or accepting packets) Nat Network Address Translation including DNAT, SNAT and Masquerading Mangle General packet header modification such as setting the TOS value or marking packets for policy routing and traffic shaping. Raw Used primarily for creating exemptions from connection tracking with the NOTRACK target. Also used for stateless DNAT. Rawpost Used for stateless SNAT. The following diagram shows how packets traverse the various builtin chains within Netfilter. Note that not all table/chain combinations are used. Local Process means a process running on the Shorewall system itself. A more elaborate version of this flow is available here and this one contrasts the Netfilter flow with that of ipchains. In the above diagram are boxes similar to this: The above box gives the name of the built-in chain (INPUT) along with the names of the tables (Mangle and Filter) that the chain exists in and in the order that the chains are traversed. The above sample indicates that packets go first through the INPUT chain of the Mangle table then through the INPUT chain of the Filter table. When a chain is enclosed in parentheses, Shorewall does not use the named chain (INPUT) in that table (Mangle). Keep in mind that chains in the Nat table are only traversed for new connection requests (including those related to existing connections) while the chains in the other tables are traversed on every packet. The above diagram should help you understand the output of shorewall dump. You may also wish to refer to this article that describes the flow of packets through a Shorewall-generated firewall. Here are some excerpts from shorewall dump on a server with one interface (eth0): [root@tipper ~]# shorewall dump Shorewall 4.4.2.2 Dump at tipper - Fri Oct 16 07:38:16 PDT 2009 Counters reset Thu Oct 8 00:38:06 PDT 2009 The first table shown is the Filter table. Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 6428 1417K dynamic all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID,NEW 967K 629M eth0_in all -- eth0 * 0.0.0.0/0 0.0.0.0/0 49 3896 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED The dynamic chain above is where dynamic blacklisting is done. The following rule indicates that all traffic destined for the firewall that comes into the firewall on eth0 is passed to a chain called eth0_in. That chain will be shown further down. 785K 93M eth0_in all -- eth0 * 0.0.0.0/0 0.0.0.0/0 0 0 Reject all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 6 prefix `Shorewall:INPUT:REJECT:' 0 0 reject all -- * * 0.0.0.0/0 0.0.0.0/0 Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 accounting all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 DROP !icmp -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID 0 0 eth0_fwd all -- eth0 * 0.0.0.0/0 0.0.0.0/0 0 0 Reject all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 6 prefix `Shorewall:FORWARD:REJECT:' 0 0 reject all -- * * 0.0.0.0/0 0.0.0.0/0 Chain OUTPUT (policy DROP 1 packets, 60 bytes) pkts bytes target prot opt in out source destination 895K 181M fw2net all -- * eth0 0.0.0.0/0 0.0.0.0/0 49 3896 ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 Reject all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 6 prefix `Shorewall:OUTPUT:REJECT:' 0 0 reject all -- * * 0.0.0.0/0 0.0.0.0/0 [goto] Here is the eth0_in chain: Chain eth0_in (1 references) pkts bytes target prot opt in out source destination 49 3896 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 Reject all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 6 prefix `Shorewall:INPUT:REJECT:' 0 0 reject all -- * * 0.0.0.0/0 0.0.0.0/0 [goto] Next comes the Nat table: NAT Table Chain PREROUTING (policy ACCEPT 5593 packets, 1181K bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 11579 packets, 771K bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 11579 packets, 771K bytes) pkts bytes target prot opt in out source destination Next, the Mangle table: Mangle Table Chain PREROUTING (policy ACCEPT 967K packets, 629M bytes) pkts bytes target prot opt in out source destination 967K 629M tcpre all -- * * 0.0.0.0/0 0.0.0.0/0 Chain INPUT (policy ACCEPT 967K packets, 629M bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 tcfor all -- * * 0.0.0.0/0 0.0.0.0/0 Chain OUTPUT (policy ACCEPT 895K packets, 181M bytes) pkts bytes target prot opt in out source destination 895K 181M tcout all -- * * 0.0.0.0/0 0.0.0.0/0 Chain POSTROUTING (policy ACCEPT 895K packets, 181M bytes) pkts bytes target prot opt in out source destination 895K 181M tcpost all -- * * 0.0.0.0/0 0.0.0.0/0 Chain tcfor (1 references) pkts bytes target prot opt in out source destination Chain tcout (1 references) pkts bytes target prot opt in out source destination Chain tcpost (1 references) pkts bytes target prot opt in out source destination Chain tcpre (1 references) pkts bytes target prot opt in out source destination And finally, the Raw table: Raw Table Chain PREROUTING (policy ACCEPT 1004K packets, 658M bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 926K packets, 186M bytes) pkts bytes target prot opt in out source destination
shorewall-docs-xml-5.0.15/Shorewall-Lite.xml0000644000000000000000000010077713020330134017402 0ustar rootroot
Shorewall Lite Tom Eastep 2006-2011 Thomas M. Eastep 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. This article applies to Shorewall 4.3 and later. If you are running a version of Shorewall earlier than Shorewall 4.3.5 then please see the documentation appropriate for your version.
Overview Shorewall has the capability to compile a Shorewall configuration and produce a runnable firewall program script. The script is a complete program which can be placed on a system with Shorewall Lite installed and can serve as the firewall creation script for that system.
Shorewall Lite Shorewall Lite is a companion product to Shorewall and is designed to allow you to maintain all Shorewall configuration information on a single system within your network. You install the full Shorewall release on one system within your network. You need not configure Shorewall there and you may totally disable startup of Shorewall in your init scripts. For ease of reference, we call this system the 'administrative system'. The administrative system may be a GNU/Linux system, a Windows system running Cygwin or an Apple MacIntosh running OS X. Install from a shell prompt using the install.sh script. On each system where you wish to run a Shorewall-generated firewall, you install Shorewall Lite. For ease of reference, we will call these systems the 'firewall systems'. The firewall systems do NOT need to have the full Shorewall product installed but rather only the Shorewall Lite product. Shorewall and Shorewall Lite may be installed on the same system but that isn't encouraged. On the administrative system you create a separate 'export directory' for each firewall system. You copy the contents of /usr/share/shorewall/configfiles into each export directory. Users of Debian and derivatives that install the package from their distribution will be disappointed to find that /usr/share/shorewall/configfiles does not exist on their systems. They will instead need to either: Copy the files in /usr/share/doc/shorewall/default-config/ into each export directory. Copy /etc/shorewall/shorewall.conf into each export directory and remove /etc/shorewall from the CONFIG_PATH setting in the copied files. or Download the Shorewall tarball corresponding to their package version. Untar and copy the files from the configfiles sub-directory in the untarred shorewall-... directory. After copying, you may need to change two setting in the copy of shorewall.conf: CONFIG_PATH=/usr/share/shorewall STARTUP_LOG=/var/log/shorewall-lite-init.log Older versions of Shorewall included copies of shorewall.conf with these settings already modified. This practice was discontinued in Shorewall 4.4.20.1. Prior to Shorewall 4.5.8, the /etc/shorewall/shorewall.conf file was used to determine the VERBOSITY setting which determines how much output the compiler generates. All other settings were taken from the shorewall.conf file in the remote systems export directory. Prior to Shorewall 4.5.8, if you want to be able to allow non-root users to manage remote firewall systems, then the files /etc/shorewall/params and /etc/shorewall/shorewall.conf must be readable by all users on the administrative system. Not all packages secure the files that way and you may have to change the file permissions yourself. Prior to Shorewall 4.5.14, /etc/shorewall/params must be readable by non-root users or each export directory must have its own params file. On each firewall system, If you are running Debian or one of its derivatives like Ubuntu then edit /etc/default/shorewall-lite and set startup=1. On the administrative system, for each firewall system you do the following (this may be done by a non-root user who has root ssh access to the firewall system): modify the files in the corresponding export directory appropriately (i.e., just as you would if you were configuring Shorewall on the firewall system itself). It's a good idea to include the IP address of the administrative system in the stoppedrules file. It is important to understand that with Shorewall Lite, the firewall's export directory on the administrative system acts as /etc/shorewall for that firewall. So when the Shorewall documentation gives instructions for placing entries in files in the firewall's /etc/shorewall, when using Shorewall Lite you make those changes in the firewall's export directory on the administrative system. The CONFIG_PATH variable is treated as follows: The value of CONFIG_PATH in /etc/shorewall/shorewall.conf is ignored when compiling for export (the -e option in given) and when the load or reload command is being executed (see below). The value of CONFIG_PATH in the shorewall.conf file in the export directory is used to search for configuration files during compilation of that configuration. The value of CONFIG_PATH used when the script is run on the firewall system is "/etc/shorewall-lite:/usr/share/shorewall-lite". Prior to Shorewall 4.5.14, the export directory should contain a params file, even if it is empty. Otherwise, /sbin/shorewall will attempt to read /etc/shorewall/params. If the remote system has a different directory layout from the administrative system, then the export directory should contain a copy of the remote system's shorewallrc file (normally found in /usr/share/shorewall/shorewallrc). cd <export directory> /sbin/shorewall load firewall The load command compiles a firewall script from the configuration files in the current working directory (using shorewall compile -e), copies that file to the remote system via scp and starts Shorewall Lite on the remote system via ssh. Example (firewall's DNS name is 'gateway'): /sbin/shorewall load gateway Although scp and ssh are used by default, you can use other utilities by setting RSH_COMMAND and RCP_COMMAND in /etc/shorewall/shorewall.conf. The first time that you issue a load command, Shorewall will use ssh to run /usr/share/shorewall-lite/shorecap on the remote firewall to create a capabilities file in the firewall's administrative direction. It also uses scp to copy the shorewallrc file from the remote firewall system. See below. If you later need to change the firewall's configuration, change the appropriate files in the firewall's export directory then: cd <export directory> /sbin/shorewall reload firewall The reload command compiles a firewall script from the configuration files in the current working directory (using shorewall compile -e), copies that file to the remote system via scp and restarts Shorewall Lite on the remote system via ssh. The reload command also supports the '-c' option. There is a shorewall-lite.conf file installed as part of Shorewall Lite (/etc/shorewall-lite/shorewall-lite.conf). You can use that file on the firewall system to override some of the settings from the shorewall.conf file in the export directory. Settings that you can override are:
VERBOSITY LOGFILE LOGFORMAT IPTABLES PATH SHOREWALL_SHELL SUBSYSLOCK RESTOREFILE
You will normally never touch /etc/shorewall-lite/shorewall-lite.conf unless you run Debian or one of its derivatives (see above). The /sbin/shorewall-lite program included with Shorewall Lite supports the same set of commands as the /sbin/shorewall program in a full Shorewall installation with the following exceptions:
add compile delete refresh reload try safe-start safe-restart show actions show macros
On systems with only Shorewall Lite installed, I recommend that you create a symbolic link /sbin/shorewall and point it at /sbin/shorewall-lite. That way, you can use shorewall as the command regardless of which product is installed.
ln -sf shorewall-lite /sbin/shorewall
Module Loading As with a normal Shorewall configuration, the shorewall.conf file can specify LOAD_HELPERS_ONLY which determines if the modules file (LOAD_HELPERS_ONLY=No) or helpers file (LOAD_HELPERS_ONLY=Yes) is used. Normally, the file on the firewall system is used. If you want to specify modules at compile time on the Administrative System, then you must place a copy of the appropriate file (modules or helpers) in the firewall's configuration directory before compilation. In Shorewall 4.4.17, the EXPORTMODULES option was added to shorewall.conf (and shorewall6.conf). When EXPORTMODULES=Yes, any modules or helpers file found on the CONFIG_PATH on the Administrative System during compilation will be used.
Converting a system from Shorewall to Shorewall Lite Converting a firewall system that is currently running Shorewall to run Shorewall Lite instead is straight-forward. On the administrative system, create an export directory for the firewall system. Copy the contents of /etc/shorewall/ from the firewall system to the export directory on the administrative system. On the firewall system: Be sure that the IP address of the administrative system is included in the firewall's export directory stoppedrules file. shorewall stop We recommend that you uninstall Shorewall at this point. Install Shorewall Lite on the firewall system. If you are running Debian or one of its derivatives like Ubuntu then edit /etc/default/shorewall-lite and set startup=1. On the administrative system: It's a good idea to include the IP address of the administrative system in the firewall system's stoppedrules file. Also, edit the shorewall.conf file in the firewall's export directory and change the CONFIG_PATH setting to remove /etc/shorewall. You can replace it with /usr/share/shorewall/configfiles if you like. Example:
Before editing: CONFIG_PATH=/etc/shorewall:/usr/share/shorewall After editing: CONFIG_PATH=/usr/share/shorewall/configfiles:/usr/share/shorewall
Changing CONFIG_PATH will ensure that subsequent compilations using the export directory will not include any files from /etc/shorewall other than shorewall.conf and params. If you set variables in the params file, there are a couple of issues: The params file is not processed at run time if you set EXPORTPARAMS=No in shorewall.conf. For run-time setting of shell variables, use the init extension script. Beginning with Shorewall 4.4.17, the variables set in the params file are available in the firewall script when EXPORTPARAMS=No. If the params file needs to set shell variables based on the configuration of the firewall system, you can use this trick: EXT_IP=$(ssh root@firewall "/sbin/shorewall-lite call find_first_interface_address eth0") The shorewall-lite call command allows you to to call interactively any Shorewall function that you can call in an extension script. After having made the above changes to the firewall's export directory, execute the following commands.
cd <export directory> /sbin/shorewall load <firewall system> Example (firewall's DNS name is 'gateway'): /sbin/shorewall load gateway
The first time that you issue a load command, Shorewall will use ssh to run /usr/share/shorewall-lite/shorecap on the remote firewall to create a capabilities file in the firewall's administrative direction. See below. The load command compiles a firewall script from the configuration files in the current working directory (using shorewall compile -e), copies that file to the remote system via scp and starts Shorewall Lite on the remote system via ssh. If you later need to change the firewall's configuration, change the appropriate files in the firewall's export directory then: cd <export directory> /sbin/shorewall reload firewall The reload command compiles a firewall script from the configuration files in the current working directory (using shorewall compile -e), copies that file to the remote system via scp and restarts Shorewall Lite on the remote system via ssh. If the kernel/iptables configuration on the firewall later changes and you need to create a new capabilities file, do the following on the firewall system: /usr/share/shorewall-lite/shorecap > capabilities scp capabilities <admin system>:<this system's config dir> Or simply use the -c option the next time that you use the reload command (e.g., shorewall reload -c gateway).
Restrictions While compiled Shorewall programs (as are used in Shorewall Lite) are useful in many cases, there are some important restrictions that you should be aware of before attempting to use them. All extension scripts used are copied into the program (with the exception of those executed at compile-time by the compiler). The ramifications of this are: If you update an extension script, the compiled program will not use the updated script. The params file is only processed at compile time if you set EXPORTPARAMS=No in shorewall.conf. For run-time setting of shell variables, use the init extension script. Although the default setting is EXPORTPARAMS=Yes for compatibility, the recommended setting is EXPORTPARAMS=No. Beginning with Shorewall 4.4.17, the variables set in the params file are available in the firewall script when EXPORTPARAMS=No. If the params file needs to set shell variables based on the configuration of the firewall system, you can use this trick: EXT_IP=$(ssh root@firewall "/sbin/shorewall-lite call find_first_interface_address eth0") The shorewall-lite call command allows you to to call interactively any Shorewall function that you can call in an extension script. You must install Shorewall Lite on the system where you want to run the script. You then install the compiled program in /usr/share/shorewall-lite/firewall and use the /sbin/shorewall-lite program included with Shorewall Lite to control the firewall just as if the full Shorewall distribution was installed. Beginning with Shorewall 4.4.9, the compiler detects bridges and sets the bridge and routeback options explicitly. That can't happen when the compilation no longer occurs on the firewall system.
The "shorewall compile" command A compiled script is produced using the compile command:
shorewall compile [ -e ] [ <directory name> ] [ <path name> ]
where
-e Indicates that the program is to be "exported" to another system. When this flag is set, neither the "detectnets" interface option nor DYNAMIC_ZONES=Yes in shorewall.conf are allowed. The created program may be run on a system that has only Shorewall Lite installed When this flag is given, Shorewall does not probe the current system to determine the kernel/iptables features that it supports. It rather reads those capabilities from /etc/shorewall/capabilities. See below for details. Also, when is specified you should have a copy of the remote firewall's shorewallrc file in the the directory specified by <directory name>. <directory name> specifies a directory to be searched for configuration files before those directories listed in the CONFIG_PATH variable in shorewall.conf. When -e <directory-name> is included, only the SHOREWALL_SHELL and VERBOSITY settings from /etc/shorewall/shorewall.conf are used and these apply only to the compiler itself. The settings used by the compiled firewall script are determined by the contents of <directory name>/shorewall.conf. Beginning with Shorewall 4.5.7.2, /etc/shorewall/shorewall.conf is not read if there is a shorewall.conf file in the specified configuration directory. <path name> specifies the name of the script to be created. If not given, ${VARDIR}/firewall is assumed (by default, ${VARDIR} is /var/lib/shorewall/)
The compile command can be used to stage a new compiled strict that can be activated later using shorewall restart -f
The /etc/shorewall/capabilities file and the shorecap program As mentioned above, the /etc/shorewall/capabilities file specifies that kernel/iptables capabilities of the target system. Here is a sample file:
# # Shorewall detected the following iptables/netfilter capabilities - Tue Jul 15 07:28:12 PDT 2008 # NAT_ENABLED=Yes MANGLE_ENABLED=Yes MULTIPORT=Yes XMULTIPORT=Yes CONNTRACK_MATCH=Yes USEPKTTYPE=Yes POLICY_MATCH=Yes PHYSDEV_MATCH=Yes PHYSDEV_BRIDGE=Yes LENGTH_MATCH=Yes IPRANGE_MATCH=Yes RECENT_MATCH=Yes OWNER_MATCH=Yes IPSET_MATCH=Yes CONNMARK=Yes XCONNMARK=Yes CONNMARK_MATCH=Yes XCONNMARK_MATCH=Yes RAW_TABLE=Yes IPP2P_MATCH= CLASSIFY_TARGET=Yes ENHANCED_REJECT=Yes KLUDGEFREE=Yes MARK=Yes XMARK=Yes MANGLE_FORWARD=Yes COMMENTS=Yes ADDRTYPE=Yes TCPMSS_MATCH=Yes HASHLIMIT_MATCH=Yes NFQUEUE_TARGET=Yes REALM_MATCH=Yes CAPVERSION=40190
As you can see, the file contains a simple list of shell variable assignments — the variables correspond to the capabilities listed by the shorewall show capabilities command and they appear in the same order as the output of that command. To aid in creating this file, Shorewall Lite includes a shorecap program. The program is installed in the /usr/share/shorewall-lite/ directory and may be run as follows:
[ IPTABLES=<iptables binary> ] [ MODULESDIR=<kernel modules directory> ] /usr/share/shorewall-lite/shorecap > capabilities
The IPTABLES and MODULESDIR options have their usual Shorewall default values. The capabilities file may then be copied to a system with Shorewall installed and used when compiling firewall programs to run on the remote system. The capabilities file may also be creating using /sbin/shorewall-lite:
shorewall-lite show -f capabilities > capabilities
Note that unlike the shorecap program, the show capabilities command shows the kernel's current capabilities; it does not attempt to load additional kernel modules.
Running compiled programs directly Compiled firewall programs are complete shell programs that support the following command line forms:
<program> [ -q ] [ -v ] [ -n ] start <program> [ -q ] [ -v ] [ -n ] stop <program> [ -q ] [ -v ] [ -n ] clear <program> [ -q ] [ -v ] [ -n ] refresh <program> [ -q ] [ -v ] [ -n ] reset <program> [ -q ] [ -v ] [ -n ] restart <program> [ -q ] [ -v ] [ -n ] status <program> [ -q ] [ -v ] [ -n ] version
The options have the same meanings as when they are passed to /sbin/shorewall itself. The default VERBOSITY level is the level specified in the shorewall.conf file used when the program was compiled.
shorewall-docs-xml-5.0.15/Shorewall_and_Aliased_Interfaces.xml0000644000000000000000000004062013020330134023104 0ustar rootroot
Shorewall and Aliased Interfaces Tom Eastep 2001-2009 Thomas M. Eastep 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. This article applies to Shorewall 4.3 and later. If you are running a version of Shorewall earlier than Shorewall 4.3.5 then please see the documentation for that release.
Background The traditional net-tools contain a program called ifconfig which is used to configure network devices. ifconfig introduced the concept of aliased or virtual interfaces. These virtual interfaces have names of the form interface:integer (e.g., eth0:0) and ifconfig treats them more or less like real interfaces. ifconfig [root@gateway root]# ifconfig eth0:0 eth0:0 Link encap:Ethernet HWaddr 02:00:08:3:FA:55 inet addr:206.124.146.178 Bcast:206.124.146.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Interrupt:11 Base address:0x2000 [root@gateway root]# The ifconfig utility is being gradually phased out in favor of the ip utility which is part of the iproute package. The ip utility does not use the concept of aliases or virtual interfaces but rather treats additional addresses on an interface as objects in their own right. The ip utility does provide for interaction with ifconfig in that it allows addresses to be labeled where these labels take the form of ipconfig virtual interfaces. ip [root@gateway root]# ip addr show dev eth0 2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc htb qlen 100 link/ether 02:00:08:e3:fa:55 brd ff:ff:ff:ff:ff:ff inet 206.124.146.176/24 brd 206.124.146.255 scope global eth0 inet 206.124.146.178/24 brd 206.124.146.255 scope global secondary eth0:0 [root@gateway root]# One cannot type ip addr show dev eth0:0 because eth0:0 is a label for a particular address rather than a device name. [root@gateway root]# ip addr show dev eth0:0 Device "eth0:0" does not exist. [root@gateway root]# The iptables program doesn't support virtual interfaces in either its -i or -o command options; as a consequence, Shorewall does not allow them to be used in the /etc/shorewall/interfaces file or anywhere else except as described in the discussion below.
Adding Addresses to Interfaces Most distributions have a facility for adding additional addresses to interfaces. If you have already used your distribution's capability to add your required addresses, you can skip this section. Shorewall provides facilities for automatically adding addresses to interfaces as described in the following section. It is also easy to add them yourself using the ip utility. The above alias was added using: ip addr add 206.124.146.178/24 brd 206.124.146.255 dev eth0 label eth0:0 You probably want to arrange to add these addresses when the device is started rather than placing commands like the above in one of the Shorewall extension scripts. For example, on RedHat systems, you can place the commands in /sbin/ifup-local: #!/bin/sh case $1 in eth0) /sbin/ip addr add 206.124.146.178 dev eth0 label eth0:0 ;; esac RedHat systems also allow adding such aliases from the network administration GUI (which only works well if you have a graphical environment on your firewall). On Debian and LEAF/Bering systems, it is as simple as adding the command to the interface definition as follows: # Internet interface auto eth0 iface eth0 inet static address 206.124.146.176 netmask 255.255.255.0 gateway 206.124.146.254 up ip addr add 206.124.146.178/24 brd 206.124.146.255 dev eth0 label eth0:0
So how do I handle more than one address on an interface? The answer depends on what you are trying to do with the interfaces. In the sub-sections that follow, we'll take a look at common scenarios. The examples in the following sub-sections assume that the local network is 192.168.1.0/24.
Separate Rules If you need to make a rule for traffic to/from the firewall itself that only applies to a particular IP address, simply qualify the $FW zone with the IP address. allow SSH from net to eth0:0 above /etc/shorewall/rules#ACTION SOURCE DEST PROTO DPORT ACCEPT net $FW:206.124.146.178 tcp 22
DNAT Suppose that I had set up eth0:0 as above and I wanted to port forward from that virtual interface to a web server running in my local zone at 192.168.1.3. That is accomplished by a single rule in the /etc/shorewall/rules file: #ACTION SOURCE DEST PROTO DPORT SPORT ORIGDEST DNAT net loc:192.168.1.3 tcp 80 - 206.124.146.178 If I wished to forward tcp port 10000 on that virtual interface to port 22 on local host 192.168.1.3, the rule would be: #ACTION SOURCE DEST PROTO DPORT SPORT ORIGDEST DNAT net loc:192.168.1.3 tcp 80 - 206.124.146.178 DNAT net loc:192.168.1.3:22 tcp 10000 - 206.124.146.178
SNAT If you wanted to use eth0:0 as the IP address for outbound connections from your local zone (eth1), then in /etc/shorewall/masq: #INTERFACE SUBNET ADDRESS eth0 192.168.1.0/24 206.124.146.178 When running Shorewall 5.0.14 or later, the equivalent /etc/shorewall/snat is: #ACTION SOURCE DEST PROTO PORT SNAT(206.124.146.178) 0.0.0.0/0 eth0 Similarly, you want SMTP traffic from local system 192.168.1.22 to have source IP 206.124.146.178:#INTERFACE SUBNET ADDRESS PROTO DPORT eth0 192.168.1.22 206.124.146.178 tcp 25 When running Shorewall 5.0.14 or later, the equivalent /etc/shorewall/snat is: #ACTION SOURCE DEST PROTO PORT SNAT(206.124.146.178) 0.0.0.0/0 eth0 tcp 25 Shorewall can create the alias (additional address) for you if you set ADD_SNAT_ALIASES=Yes in /etc/shorewall/shorewall.conf. Addresses added by ADD_SNAT_ALIASES=Yes are deleted and re-added during shorewall restart. As a consequence, connections using those addresses may be severed. Shorewall can create the label (virtual interface) so that you can see the created address using ifconfig. In addition to setting ADD_SNAT_ALIASES=Yes, you specify the virtual interface name in the INTERFACE column as follows. /etc/shorewall/masq#INTERFACE SUBNET ADDRESS eth0:0 192.168.1.0/24 206.124.146.178 When running Shorewall 5.0.14 or later, the equivalent /etc/shorewall/snat is: #ACTION SOURCE DEST PROTO PORT SNAT(206.124.146.178) 192.168.1.0/24 eth0 Shorewall can also set up SNAT to round-robin over a range of IP addresses. To do that, you specify a range of IP addresses in the ADDRESS column. If you specify a label in the INTERFACE column, Shorewall will use that label for the first address of the range and will increment the label by one for each subsequent label. /etc/shorewall/masq#INTERFACE SOURCE ADDRESS eth0:0 192.168.1.0/24 206.124.146.178-206.124.146.180 When running Shorewall 5.0.14 or later, the equivalent /etc/shorewall/snat is: #ACTION SOURCE DEST PROTO PORT SNAT(206.124.146.178-206.24.146.80) 192.168.1.0/24 eth0 The above would create three IP addresses: eth0:0 = 206.124.146.178 eth0:1 = 206.124.146.179 eth0:2 = 206.124.146.180
One-to-one NAT If you wanted to use one-to-one NAT to link eth0:0 with local address 192.168.1.3, you would have the following in /etc/shorewall/nat: #EXTERNAL INTERFACE INTERNAL ALL_INTERFACES LOCAL 206.124.146.178 eth0 192.168.1.3 no no Shorewall can create the alias (additional address) for you if you set ADD_IP_ALIASES=Yes in /etc/shorewall/shorewall.conf. Addresses added by ADD_IP_ALIASES=Yes are deleted and re-added during shorewall restart. As a consequence, connections using those addresses may be severed. Shorewall can create the label (virtual interface) so that you can see the created address using ifconfig. In addition to setting ADD_IP_ALIASES=Yes, you specify the virtual interface name in the INTERFACE column as follows. /etc/shorewall/nat#EXTERNAL INTERFACE INTERNAL ALL_INTERFACES LOCAL 206.124.146.178 eth0:0 192.168.1.3 no no In either case, to create rules in /etc/shorewall/rules that pertain only to this NAT pair, you simply qualify the local zone with the internal IP address. You want to allow SSH from the net to 206.124.146.178 a.k.a. 192.168.1.3. #ACTION SOURCE DEST PROTO DPORT ACCEPT net loc:192.168.1.3 tcp 22
MULTIPLE SUBNETS Sometimes multiple IP addresses are used because there are multiple subnetworks configured on a LAN segment. This technique does not provide for any security between the subnetworks if the users of the systems have administrative privileges because in that case, the users can simply manipulate their system's routing table to bypass your firewall/router. Nevertheless, there are cases where you simply want to consider the LAN segment itself as a zone and allow your firewall/router to route between the two subnetworks. Local interface eth1 interfaces to 192.168.1.0/24 and 192.168.20.0/24. The primary IP address of eth1 is 192.168.1.254 and eth1:0 is 192.168.20.254. You simply want your firewall to route between these two subnetworks. In /etc/shorewall/zones: #ZONE TYPE OPTIONS loc ipv4 In /etc/shorewall/interfaces: #ZONE INTERFACE OPTIONS loc eth1 routeback In /etc/shorewall/rules, simply specify ACCEPT rules for the traffic that you want to permit. Local interface eth1 interfaces to 192.168.1.0/24 and 192.168.20.0/24. The primary IP address of eth1 is 192.168.1.254 and eth1:0 is 192.168.20.254. You want to make these subnetworks into separate zones and control the access between them (the users of the systems do not have administrative privileges). In /etc/shorewall/zones: #ZONE TYPE OPTIONS loc ipv4 loc2 ipv4 In /etc/shorewall/interfaces: #ZONE INTERFACE OPTIONS - eth1 In /etc/shorewall/hosts: #ZONE HOSTS OPTIONS loc eth1:192.168.1.0/24 loc2 eth1:192.168.20.0/24 In /etc/shorewall/rules, simply specify ACCEPT rules for the traffic that you want to permit. For more information on handling multiple networks through a single interface, see Routing on One Interface.
Defining a Zone-per-Address Shorewall's support for Linux Vservers can (mis-)used to create a separate zone per alias. Note that this results in a partitioning of the firewall zone. In this usage, you probably want to define an ACCEPT policy between your vserver zones and the firewall zone.
shorewall-docs-xml-5.0.15/PacketMarking.xml0000644000000000000000000007103313020330134017257 0ustar rootroot
Packet Marking using /etc/shorewall/mangle and /etc/shorewall/tcrules Tom Eastep 2006 2013 Thomas M. Eastep 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. This article includes information that applies to Shorewall version 3.2.5 and later. Not all features described here will be available in earlier releases. /etc/shorewall/mangle superseded /etc/shorewall/tcrules in Shorewall 4.6.0. /etc/shorwall/tcrules is still supported but its use is deprecated.
Packet and Connection Marks Perhaps no aspect of Shorewall causes more confusion than packet marking. This article will attempt to clear up some of that confusion. Each packet has a mark whose value is initially 0. Mark values are stored in the skb (socket buffer) structure used by the Linux kernel to track packets; the mark value is not part of the packet itself and cannot be seen with tcpdump, ethereal or any other packet sniffing program. They can be seen in an iptables/ip6tables trace -- see the iptrace command in shorewall(8) and shorewall6(8). Example (output has been folded for display ): [11692.096077] TRACE: mangle:tcout:return:3 IN= OUT=eth0 SRC=172.20.1.130 DST=206.124.146.254 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=7212 SEQ=3 UID=0 GID=1000 MARK=0x10082 Each active connection (even those that are not yet in ESTABLISHED state) has a mark value that is distinct from the packet marks. Connection mark values can be seen using the shorewall show connections command. The default connection mark value is 0. Example (output has been folded for display ): shorewall show connections Shorewall 3.3.2 Connections at gateway - Mon Oct 2 09:08:18 PDT 2006 tcp 6 19 TIME_WAIT src=206.124.146.176 dst=192.136.34.98 sport=58597 dport=80 packets=23 bytes=4623 src=192.136.34.98 dst=206.124.146.176 sport=80 dport=58597 packets=23 bytes=22532 [ASSURED] mark=256 use=1 … Packet marks are valid only while the packet is being processed by the firewall. Once the packet has been given to a local process or sent on to another system, the packet's mark value is no longer available. Connection mark values, on the other hand, persist for the life of the connection. Other parts of the system such as Traffic Shaping and Policy Routing cannot use connection marks — they can only use packet marks.
Packet Marking "Programs" Packet marking occurs in Netfilter's mangle table. See the Netfilter Overview article. You can think of entries in the mangle and tcrules files like instructions in a program coded in a crude assembly language. The program gets executed for each packet. That is another way of saying that if you don't program, you may have difficulty making full use of Netfilter/Shorewall's Packet Marking. Actually, the mangle/tcrules files define several programs. Each program corresponds to one of the built-in chains in the mangle table. PREROUTING program — If MARK_IN_FORWARD_CHAIN=No in shorewall.conf, then by default entries in /etc/shorewall/mangle and /etc/shorewall/tcrules are part of the PREROUTING program. Entries specifying the ":P" suffix in the ACTION column are also part of the PREROUTING program. The PREROUTING program gets executed for each packet entering the firewall. FORWARD program — If MARK_IN_FORWARD_CHAIN=Yes in shorewall.conf, then by default entries in/etc/shorewall/mangle and /etc/shorewall/tcrules are part of the FORWARD program. Entries specifying the ":F" suffix in the ACTION column are also part of the FORWARD program. The FORWARD program gets executed for each packet forwarded by the firewall. OUTPUT program — Entries with $FW in the SOURCE column are part of the OUTPUT program. The OUTPUT program is executed for each packet originating on the firewall itself. POSTROUTING program — Entries with a class-id in the ACTION column (and that don't specify $FW in the SOURCE column) are part of the POSTROUTING program. These rules are executed for each packet leaving the firewall. Entries specifying the ":T" suffix in the ACTION column are also part of the POSTROUTING program (Shorewall version 3.4.0 and later). INPUT program — No entries in tcrules will add entries to this program. It is executed for each packet that is targeted to the firewall itself. Note that a packet being forwarded by your firewall actually gets processed by three different programs: PREROUTING, FORWARD and POSTROUTING. Similarly, packets addressed to the firewall itself are processed by two programs (PREROUTING and INPUT) while packets originating on the firewall are likewise processed by two programs (OUTPUT and POSTROUTING). Rules in each program are executed as follows: Rules are conditionally executed based on whether the current packet matches the contents of the SOURCE, DEST, PROTO, DPORT, SPORT, USER, TEST, LENGTH and TOS columns. When a rule is executed, either: the current packet receives a new mark value; or the connection to which the current packet belongs receives a new mark value (":C", ":CF" or ":CP" suffix in the ACTION column); or the packet is classified for traffic shaping (class-id in the ACTION column); or the packet mark in the current packet is moved to the connection mark for the connection that the current packet is part of ("SAVE" in the ACTION column); or the connection mark value for the connection that the current packet is part of is moved to the current packet's mark ("RESTORE" in the ACTION column); or jump to a subroutine (another chain in the mangle table). These jumps are generated by Shorewall; or exit the current subroutine ("CONTINUE" in the ACTION column). Unless the subroutine is exited using CONTINUE, the current packet is always passed to the next tcrule in the subroutine.
Mark and Mask Values The mark value is held in a 32-bit field. Because packet marking is the Netfilter kludge of last resort for solving many hard technical problems, Shorewall originally reserved half of this field (16 bits) for future use. The remainder was split into two 8-bit values: The low-order eight bits are used for traffic shaping marks. These eight bits were also used for selecting among multiple providers when HIGH_ROUTE_MARKS=No in shorewall.conf. Some rules that deal with only these bits used a mask value of 0xff. The next 8 bits were used for selecting among multiple providers when HIGH_ROUTE_MARKS=Yes in shorewall.conf. These bits are manipulated using a mask value of 0xff00. As hinted above, marking rules can specify both a mark value and a mask. The mask determines the subset of the 32 bits in the mark to be used in the operation — only those bits that are on in the mask are manipulated when the rule is executed. For entries in tcrules, Shorewall-generated rules use a mask value that depends on which program the rule is part of, what the rule does, and the setting of HIGH_ROUTE_MARKS. For entries in mangle and tcrules, the default mask value is 0xffff except in these cases: RESTORE rules use a default mask value of 0xff. SAVE rules use a default mask value of 0xff. Connection marking rules use a mask value of 0xff. When WIDE_TC_MARKS was added, the number of bits reserved for TC marks was increased to 14 when WIDE_TC_MARKS=Yes and the provider mark field (when HIGH_ROUTE_MARKS=Yes) was offset 16 bits. Also, when HIGH_ROUTE_MARKS=Yes, the mask used for setting/testing TC marks was 0xffff (16 bits). Shorewall actually allows you to have complete control over the layout of the 32-bit mark using the following options in shorewall.conf (5) (these options were documented in the shorewall.conf(5) manpage in Shorewall 4.4.26): TC_BITS The number of bits at the low end of the mark to be used for traffic shaping marking. May be zero. PROVIDER_BITS The number of bits in the mark to be used for provider numbers. May be zero. PROVIDER_OFFSET The offset from the right (low-order end) of the provider number field. If non-zero, must be >= TC_BITS (Shorewall automatically adjusts PROVIDER_OFFSET's value). PROVIDER_OFFSET + PROVIDER_BITS must be <= 32. MASK_BITS Number of bits on the right of the mark to be masked when clearing the traffic shaping mark. Must be >= TC_BITS and <= PROVIDER_OFFSET (if PROVIDER_OFFSET > 0) In Shorewall 4.4.26, a new option was added: ZONE_BITS Number of bits in the mark to use for automatic zone marking (see the Shorewall Bridge/Firewall HOWTO). The relationship between these options is shown in this diagram. The default values of these options are determined by the settings of other options as follows: Default Values WIDE_TC_MARKS=No, HIGH_ROUTE_MARKS=No TC_BITS=8, PROVIDER_BITS=8, PROVIDER_OFFSET=0, MASK_BITS=8 WIDE_TC_MARKS=No, HIGH_ROUTE_MARKS=Yes TC_BITS=8, PROVIDER_BITS=8, PROVIDER_OFFSET=8, MASK_BITS=8 WIDE_TC_MARKS=Yes, HIGH_ROUTE_MARKS=No TC_BITS=14, PROVIDER_BITS=8, PROVIDER_OFFSET=0, MASK_BITS=16 WIDE_TC_MARKS=Yes, HIGH_ROUTE_MARKS=Yes TC_BITS=14, PROVIDER_BITS=8, PROVIDER_OFFSET=16, MASK_BITS=16
The existence of both TC_BITS and MASK_BITS is owed to the way that WIDE_TC_MARKS was originally implemented. Note that TC_BITS is 14 rather than 16 when WIDE_TC_MARKS=Yes. Beginning with Shorewall 4.4.12, the field between MASK_BITS and PROVIDER_OFFSET can be used for any purpose you want. Beginning with Shorewall 4.4.13, the first unused bit on the left is used by Shorewall as an exclusion mark, allowing exclusion in CONTINUE, NONAT and ACCEPT+ rules. Beginning with Shorewall 4.4.26, WIDE_TC_MARKS and HIGH_ROUTE_MARKS are deprecated in favor of the options described above. The shorewall update (shorewall6 update) command will set the above options based on the settings of WIDE_TC_MARKS and HIGH_ROUTE_MARKS. In Shorewall 4.5.4, a TPROXY mark was added for TPROXY support. It is a single bit wide and is to the immediate left of the exclusion mark. The Event Mark bit was added in Shorewall 4.5.19. It is to the immediate left of the TPROXY mark, and it need not fall within the 32-bit mark unless the reset command is used in the IfEvent action.
Shorewall-defined Chains in the Mangle Table Shorewall creates a set of chains in the mangle table to hold rules defined in your /etc/shorewall/mangle (/etc/shorewall/tcrules) file. As mentioned above, chains are like subroutines in the packet marking programming language. By placing all of your rules in subroutines, CONTINUE (which generates a Netfilter RETURN rule) can be used to stop processing your rules while still allowing following Shorewall-generated rules to be executed. tcpre PREROUTING rules. tcfor FORWARD rules. tcout OUTPUT rules. tcpost POSTROUTING rules. Shorewall generates jumps to these chains from the built-in chains (PREROUTING, FORWARD, etc.).
An Example Here's the example (slightly expanded) from the comments at the top of the /etc/shorewall/mangle file. #ACTION SOURCE DEST PROTO DPORT SPORT USER TEST LENGTH TOS MARK(1) 0.0.0.0/0 0.0.0.0/0 icmp echo-request #Rule 1 MARK(1) 0.0.0.0/0 0.0.0.0/0 icmp echo-reply #Rule 2 MARK(1) $FW 0.0.0.0/0 icmp echo-request #Rule 3 MARK(1) $FW 0.0.0.0/0 icmp echo-reply #Rule 4 RESTORE 0.0.0.0/0 0.0.0.0/0 all - - - 0 #Rule 5 CONTINUE 0.0.0.0/0 0.0.0.0/0 all - - - !0 #Rule 6 MARK(4) 0.0.0.0/0 0.0.0.0/0 ipp2p:all #Rule 7 SAVE 0.0.0.0/0 0.0.0.0/0 all - - - !0 #Rule 8 Let's take a look at each rule: This straight-forward rule simply marks all 'ping' requests passing through the firewall with mark value 1. Note that it does not mark pings that originate on the firewall itself. Similarly, this rule marks 'ping' replies. This rule marks 'ping' requests that originate on the firewall. This rule and the next ones are part of the OUTPUT program. Similarly, this rule marks 'ping' replies from the firewall itself. Remember that even though 'ping' packets were marked in one of the first two rules, they are still passed on to rule 5 (note that packets marked by rules 3 and 4 are not processed by this rule since it is in a different program). That rule moves the connection mark to the packet mark, if the packet mark is still zero (note the '0' in the TEST column). Without the '0' in the TEST column, this rule would overwrite the marks assigned in the first two rules. If the packet mark is non-zero (note the '!0' in the TEST column), then exit — The remaining rules will not be executed in this case. The packet mark will be non-zero if this is a 'ping' packet, or if the connection mark restored in rule 5 was non-zero. The packet mark is still zero. This rule checks to see if this is a P2P packet and if it is, the packet mark is set to 4. If the packet mark is non-zero (meaning that it was set to 4 in rule 7), then save the value (4) in the connection. The next time that a packet from this same connection comes through this program, rule 6 will be executed and the P2P check will be avoided.
Examining the Marking Programs on a Running System You can see the mangle (tcrules) entries in action using the shorewall show mangle command. The sample output from that command shown below has the following in /etc/shorewall/providers: #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS COPY Blarg 1 0x100 main eth3 206.124.146.254 track,balance br0,eth1 Here is /etc/shorewall/mangle: #ACTION SOURCE DEST PROTO DPORT SPORT USER TEST CLASSIFY(1:110) 192.168.0.0/22 eth3 #Our internal nets get priority #over the server CLASSIFY(1:130) 206.124.146.177 eth3 tcp - 873 And here is /etc/shorewall/tcdevices and /etc/shorewall/tcclasses: #INTERFACE IN_BANDWITH OUT_BANDWIDTH eth3 1.3mbit 384kbit #INTERFACE MARK RATE CEIL PRIORITY OPTIONS eth3 10 full full 1 tcp-ack,tos-minimize-delay eth3 20 9*full/10 9*full/10 2 default eth3 30 6*full/10 6*full/10 3 I've annotated the following output with comments beginning with "<<<<" and ending with ">>>>". This example uses HIGH_ROUTE_MARKS=Yes and TC_EXPERT=No in shorewall.conf. gateway:~ # shorewall show mangle Shorewall 3.3.2 Mangle Table at gateway - Mon Oct 2 15:07:32 PDT 2006 Counters reset Mon Oct 2 07:49:52 PDT 2006 <<<< The PREROUTING Program >>>> Chain PREROUTING (policy ACCEPT 409K packets, 122M bytes) pkts bytes target prot opt in out source destination <<<< Restore the provider mark from the connection, if any >>>> 185K 77M CONNMARK all -- * * 0.0.0.0/0 0.0.0.0/0 CONNMARK match !0x0/0xff00 CONNMARK restore mask 0xff00 <<<< If there is no mark in the connection and the packet came in on eth3, then jump to the routemark chain This rule is generated as a result of 'track' being specified in the providers file entry for eth3 >>>> 8804 1396K routemark all -- eth3 * 0.0.0.0/0 0.0.0.0/0 MARK match 0x0/0xff00 <<<< If the packet came in on eth3, jump the the tcpre chain -- packets entering on a 'track'ed interface can have their mark set to zero there >>>> 102K 52M tcpre all -- eth3 * 0.0.0.0/0 0.0.0.0/0 <<<< Otherwise, jump to the tcpre chain if there is no current provider mark -- if we would have had TC_EXPERT=Yes, this jump would have been unconditional>>>> 215K 44M tcpre all -- * * 0.0.0.0/0 0.0.0.0/0 MARK match 0x0/0xff00 <<<< End of PREROUTING program >>>> <<<< INPUT Program -- Shorewall generates the single rule here which turns off the provider mark in the packet after routing The rule does that by logically ANDing the mark value with 0xff which will turn off all but the low-order 8 bits >>>> Chain INPUT (policy ACCEPT 98238 packets, 16M bytes) pkts bytes target prot opt in out source destination 98234 16M MARK all -- * * 0.0.0.0/0 0.0.0.0/0 MARK and 0xff <<<< End of INPUT program >>>> <<<< FORWARD Program -- Shorewall generates the first rule here which turns off the provider mark in the packet after routing >>>> Chain FORWARD (policy ACCEPT 312K packets, 106M bytes) pkts bytes target prot opt in out source destination 312K 106M MARK all -- * * 0.0.0.0/0 0.0.0.0/0 MARK and 0xff <<<< Jump unconditionally to the tcfor chain >>>> 312K 106M tcfor all -- * * 0.0.0.0/0 0.0.0.0/0 <<<< End of FORWARD program >>>> <<<< OUTPUT Program >>>> Chain OUTPUT (policy ACCEPT 1462K packets, 396M bytes) pkts bytes target prot opt in out source destination <<<< Restore the provider mark from the connection -- this rule was generated by Shorewall because of the 'track' option >>>> 3339 615K CONNMARK all -- * * 0.0.0.0/0 0.0.0.0/0 CONNMARK match !0x0/0xff00 CONNMARK restore mask 0xff00 <<<< If there is no provider mark, then jump to the tcout chain -- if we would have had TC_EXPERT=Yes, this jump would have been unconditional >>>> 92747 28M tcout all -- * * 0.0.0.0/0 0.0.0.0/0 MARK match 0x0/0xff00 <<<< End of FORWARD program >>>> <<<< POSTROUTING Program -- Unconditionally jump to the tcpost chain >>>> Chain POSTROUTING (policy ACCEPT 407K packets, 135M bytes) pkts bytes target prot opt in out source destination 407K 135M tcpost all -- * * 0.0.0.0/0 0.0.0.0/0 <<<< End of FORWARD program >>>> Chain routemark (1 references) pkts bytes target prot opt in out source destination <<<< Set connection 'track' mark for packets coming in on eth3 >>>> 8804 1396K MARK all -- eth3 * 0.0.0.0/0 0.0.0.0/0 MARK or 0x100 <<<< Save any mark added above in the connection mark >>>> 8804 1396K CONNMARK all -- * * 0.0.0.0/0 0.0.0.0/0 MARK match !0x0/0xff00 CONNMARK save mask 0xff00 Chain tcfor (1 references) pkts bytes target prot opt in out source destination Chain tcout (1 references) pkts bytes target prot opt in out source destination Chain tcpost (1 references) pkts bytes target prot opt in out source destination <<<< The next two rules are the entries in the /etc/shorewall/mangle file >>>> 65061 11M CLASSIFY all -- * eth3 192.168.0.0/22 0.0.0.0/0 CLASSIFY set 1:110 2224 2272K CLASSIFY tcp -- * eth3 206.124.146.177 0.0.0.0/0 tcp spt:873 CLASSIFY set 1:130 <<<< The following rules are generated by Shorewall and classify the traffic according to the marks in /etc/shorewall/classes >>>> 0 0 CLASSIFY all -- * eth3 0.0.0.0/0 0.0.0.0/0 MARK match 0xa/0xff CLASSIFY set 1:110 0 0 CLASSIFY all -- * eth3 0.0.0.0/0 0.0.0.0/0 MARK match 0x14/0xff CLASSIFY set 1:120 0 0 CLASSIFY all -- * eth3 0.0.0.0/0 0.0.0.0/0 MARK match 0x1e/0xff CLASSIFY set 1:130 Chain tcpre (2 references) pkts bytes target prot opt in out source destination gateway:~ #
shorewall-docs-xml-5.0.15/bridge-Shorewall-perl.xml0000644000000000000000000010460613020330134020674 0ustar rootroot
Bridged Firewalls Tom Eastep 2007 2009 Thomas M. Eastep 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. This article applies to Shorewall 4.4 and later.
Background Systems where Shorewall runs normally function as routers. In the context of the Open System Interconnect (OSI) reference model, a router operates at layer 3, Shorewall may also be deployed on a GNU Linux System that acts as a bridge. Bridges are layer 2 devices in the OSI model (think of a bridge as an Ethernet switch). Some differences between routers and bridges are: Routers determine packet destination based on the destination IP address, while bridges route traffic based on the destination MAC address in the Ethernet frame. As a consequence of the first difference, routers can be connected to more than one IP network while a bridge/firewall may be part of only a single network (see below). In most configurations, routers don't forward broadcast packets while bridges do. Section 4 of RFC 1812 describes the conditions under which a router may or must forward broadcasts.
Requirements Note that if you need a bridge but do not need to restrict the traffic through the bridge then any version of Shorewall will work. See the Simple Bridge documentation for details. In order to use Shorewall as a bridging firewall: Your kernel must contain bridge support (CONFIG_BRIDGE=m or CONFIG_BRIDGE=y). Your kernel must contain bridge/netfilter integration (CONFIG_BRIDGE_NETFILTER=y). Your kernel must contain Netfilter physdev match support (CONFIG_IP_NF_MATCH_PHYSDEV=m or CONFIG_IP_NF_MATCH_PHYSDEV=y). Physdev match is standard in the 2.6 and later kernel series but must be patched into the 2.4 kernels (see http://bridge.sf.net). Your iptables must contain physdev match support and must support multiple instances of '-m physdev' in a single rule. iptables 1.3.6 and later contain this support. You must have the bridge utilities (bridge-utils) package installed.
Application The following diagram shows a typical application of a bridge/firewall. There is already an existing router in place whose internal interface supports a network, and you want to insert a firewall between the router, and the systems in the local network. In the example shown, the network uses RFC 1918 addresses but that is not a requirement; the bridge would work exactly the same if public IP addresses were used (remember that the bridge doesn't deal with IP addresses). There are a several key differences in this setup and a normal Shorewall configuration: The Shorewall system (the Bridge/Firewall) has only a single IP address even though it has two Ethernet interfaces! The IP address is configured on the bridge itself, rather than on either of the network cards. The systems connected to the LAN are configured with the router's IP address (192.168.1.254 in the above diagram) as their default gateway. traceroute doesn't detect the Bridge/Firewall as an intermediate router. If the router runs a DHCP server, the hosts connected to the LAN can use that server without having dhcrelay running on the Bridge/Firewall. Inserting a bridge/firewall between a router and a set of local hosts only works if those local hosts form a single IP network. In the above diagram, all of the hosts in the loc zone are in the 192.168.1.0/24 network. If the router is routing between several local networks through the same physical interface (there are multiple IP networks sharing the same LAN), then inserting a bridge/firewall between the router and the local LAN won't work. There are other possibilities here -- there could be a hub or switch between the router and the Bridge/Firewall and there could be other systems connected to that switch. All of the systems on the local side of the router would still be configured with IP addresses in 192.168.1.0/24 as shown below.
Configuring the Bridge Configuring the bridge itself is quite simple and uses the brctl utility from the bridge-utils package. Bridge configuration information may be found at http://bridge.sf.net. Unfortunately, many Linux distributions don't have good bridge configuration tools, and the network configuration GUIs don't detect the presence of bridge devices. Here is an excerpt from a Debian /etc/network/interfaces file for a two-port bridge with a static IP address:
auto br0 iface br0 inet static address 192.168.1.253 netmask 255.255.255.0 network 192.168.1.0 broadcast 192.168.1.255 pre-up /sbin/ip link set eth0 up pre-up /sbin/ip link set eth1 up pre-up /usr/sbin/brctl addbr br0 pre-up /usr/sbin/brctl addif br0 eth0 pre-up /usr/sbin/brctl addif br0 eth1 pre-down /usr/sbin/brctl delif br0 eth0 pre-down /sbin/ip link set eth0 down pre-down /usr/sbin/brctl delif br0 eth1 pre-down /sbin/ip link set eth1 down post-down /usr/sbin/brctl delbr br0
While it is not a requirement to give the bridge an IP address, doing so allows the bridge/firewall to access other systems and allows the bridge/firewall to be managed remotely. The bridge must also have an IP address for REJECT rules and policies to work correctly — otherwise REJECT behaves the same as DROP. It is also a requirement for bridges to have an IP address if they are part of a bridge/router. Get your bridge configuration working first, including bridge startup at boot, before you configure and start Shorewall. The bridge may have its IP address assigned via DHCP. Here's an example of an /etc/sysconfig/network/ifcfg-br0 file from a SUSE system:
BOOTPROTO='dhcp' REMOTE_IPADDR='' STARTMODE='onboot' UNIQUE='3hqH.MjuOqWfSZ+C' WIRELESS='no' MTU=''
Here's an /etc/sysconfig/network-scripts/ifcfg-br0 file for a Mandriva system:
DEVICE=br0 BOOTPROTO=dhcp ONBOOT=yes
On both the SUSE and Mandriva systems, a separate script is required to configure the bridge itself. Here are scripts that I used on a SUSE 9.1 system.
/etc/sysconfig/network/ifcfg-br0 BOOTPROTO='dhcp' REMOTE_IPADDR='' STARTMODE='onboot' UNIQUE='3hqH.MjuOqWfSZ+C' WIRELESS='no' MTU='' /etc/init.d/bridge#!/bin/sh ################################################################################ # Script to create a bridge # # (c) 2004 - Tom Eastep (teastep@shorewall.net) # # Modify the following variables to match your configuration # #### BEGIN INIT INFO # Provides: bridge # Required-Start: coldplug # Required-Stop: # Default-Start: 2 3 5 # Default-Stop: 0 1 6 # Description: starts and stops a bridge ### END INIT INFO # # chkconfig: 2345 05 89 # description: GRE/IP Tunnel # ################################################################################ PATH=$PATH:/sbin:/usr/sbin:/usr/local/sbin INTERFACES="eth1 eth0" BRIDGE="br0" MODULES="tulip" do_stop() { echo "Stopping Bridge $BRIDGE" brctl delbr $BRIDGE for interface in $INTERFACES; do ip link set $interface down done } do_start() { echo "Starting Bridge $BRIDGE" for module in $MODULES; do modprobe $module done sleep 5 for interface in $INTERFACES; do ip link set $interface up done brctl addbr $BRIDGE for interface in $INTERFACES; do brctl addif $BRIDGE $interface done } case "$1" in start) do_start ;; stop) do_stop ;; restart) do_stop sleep 1 do_start ;; *) echo "Usage: $0 {start|stop|restart}" exit 1 esac exit 0
Axel Westerhold has contributed this example of configuring a bridge with a static IP address on a Fedora System (Core 1 and Core 2 Test 1). Note that these files also configure the bridge itself, so there is no need for a separate bridge config script.
/etc/sysconfig/network-scripts/ifcfg-br0: DEVICE=br0 TYPE=Bridge IPADDR=192.168.50.14 NETMASK=255.255.255.0 ONBOOT=yes /etc/sysconfig/network-scripts/ifcfg-eth0:DEVICE=eth0 TYPE=ETHER BRIDGE=br0 ONBOOT=yes/etc/sysconfig/network-scripts/ifcfg-eth1:DEVICE=eth1 TYPE=ETHER BRIDGE=br0 ONBOOT=yes
Florin Grad at Mandriva provides this script for configuring a bridge:
#!/bin/sh # chkconfig: 2345 05 89 # description: Layer 2 Bridge # [ -f /etc/sysconfig/bridge ] && . /etc/sysconfig/bridge PATH=$PATH:/sbin:/usr/sbin:/usr/local/sbin do_stop() { echo "Stopping Bridge" for i in $INTERFACES $BRIDGE_INTERFACE ; do ip link set $i down done brctl delbr $BRIDGE_INTERFACE } do_start() { echo "Starting Bridge" for i in $INTERFACES ; do ip link set $i up done brctl addbr br0 for i in $INTERFACES ; do ip link set $i up brctl addif br0 $i done ifup $BRIDGE_INTERFACE } case "$1" in start) do_start ;; stop) do_stop ;; restart) do_stop sleep 1 do_start ;; *) echo "Usage: $0 {start|stop|restart}" exit 1 esac exit 0 The /etc/sysconfig/bridge file: BRIDGE_INTERFACE=br0 #The name of your Bridge INTERFACES="eth0 eth1" #The physical interfaces to be bridged
Andrzej Szelachowski contributed the following.
Here is how I configured bridge in Slackware: 1) I had to compile bridge-utils (It's not in the standard distribution) 2) I've created rc.bridge in /etc/rc.d: ######################### #! /bin/sh ifconfig eth0 0.0.0.0 ifconfig eth1 0.0.0.0 #ifconfig lo 127.0.0.1 #this line should be uncommented if you don't use rc.inet1 brctl addbr most brctl addif most eth0 brctl addif most eth1 ifconfig most 192.168.1.31 netmask 255.255.255.0 up #route add default gw 192.168.1.1 metric 1 #this line should be uncommented if #you don't use rc.inet1 ######################### 3) I made rc.bridge executable and added the following line to /etc/rc.d/rc.local /etc/rc.d/rc.bridge
Joshua Schmidlkofer writes:
Bridge Setup for Gentoo #install bridge-utils emerge bridge-utils ## create a link for net.br0 cd /etc/init.d ln -s net.eth0 net.br0 # Remove net.eth*, add net.br0 and bridge. rc-update del net.eth0 rc-update del net.eth1 rc-update add net.br0 default rc-update add bridge boot /etc/conf.d/bridge: #bridge contains the name of each bridge you want created. bridge="br0" # bridge_<bridge>_devices contains the devices to use at bridge startup. bridge_br0_devices="eth0 eth1" /etc/conf.d/net iface_br0="10.0.0.1 broadcast 10.0.0.255 netmask 255.255.255.0" #for dhcp: #iface_br0="dhcp" #comment this out if you use dhcp. gateway="eth0/10.0.0.1"
Users who successfully configure bridges on other distributions, with static or dynamic IP addresses, are encouraged to send me their configuration so I can post it here.
Configuring Shorewall As described above, Shorewall bridge support requires the physdev match feature of Netfilter/iptables. Physdev match allows rules to be triggered based on the bridge port that a packet arrived on and/or the bridge port that a packet will be sent over. The latter has proved to be problematic because it requires that the evaluation of rules be deferred until the destination bridge port is known. This deferral has the unfortunate side effect that it makes IPSEC Netfilter filtration incompatible with bridges. To work around this problem, in kernel version 2.6.20 the Netfilter developers decided to remove the deferred processing in two cases: When a packet being sent through a bridge entered the firewall on another interface and was being forwarded to the bridge. When a packet originating on the firewall itself is being sent through a bridge. Notice that physdev match was only weakened with respect to the destination bridge port -- it remains fully functional with respect to the source bridge port. To deal with the asymmetric nature of the new physdev match, Shorewall supports a new type of zone - a Bridge Port (BP) zone. Bridge port zones have a number of restrictions: BP zones may only be associated with bridge ports. All ports associated with a given BP zone must be on the same bridge. Policies from a non-BP zone to a BP are disallowed. Rules where the SOURCE is a non-BP zone and the DEST is a BP zone are disallowed. In /etc/shorewall/zones, BP zones are specified using the bport (or bport4) keyword. If your version of shorewall.conf contains the BRIDGING option, it must be set to No. In the scenario pictured above, there would probably be two BP zones defined -- one for the Internet and one for the local LAN so in /etc/shorewall/zones: #ZONE TYPE OPTIONS fw firewall world ipv4 net:world bport loc:world bport The world zone can be used when defining rules whose source zone is the firewall itself (remember that fw-><BP zone> rules are not allowed). A conventional two-zone policy file is appropriate here — /etc/shorewall/policy: #SOURCE DEST POLICY LOGLEVEL LIMIT loc net ACCEPT net all DROP info all all REJECT info In /etc/shorewall/shorewall.conf: IMPLICIT_CONTINUE=No Bridges use a special syntax in /etc/shorewall/interfaces. Assuming that the router is connected to eth0 and the switch to eth1: #ZONE INTERFACE OPTIONS world br0 bridge net br0:eth0 loc br0:eth1 The world zone is associated with the bridge itself which is defined with the bridge option. Bridge port entries may not have any OPTIONS. When a bridge is configured without an IP address, the option must also be specified. When Shorewall is stopped, you want to allow only local traffic through the bridge — /etc/shorewall/routestopped: #INTERFACE HOST(S) OPTIONS br0 192.168.1.0/24 routeback The /etc/shorewall/rules file from the two-interface sample is a good place to start for defining a set of firewall rules.
Multiple Bridges with Wildcard Ports It is sometimes required to configure multiple bridges on a single firewall/gateway. The following seemingly valid configuration results in a compile-time error ERROR: Duplicate Interface Name (p+) /etc/shorewall/zones: #ZONE TYPE fw firewall world ipv4 z1:world bport4 z2:world bport4 /etc/shorewall/interfaces: #ZONE INTERFACE OPTIONS world br0 bridge world br1 bridge z1 br0:p+ z2 br1:p+ The reason is that the Shorewall implementation requires each bridge port to have a unique name. The interface option was added in Shorewall 4.4.4 to work around this problem. The above configuration may be defined using the following in /etc/shorewall/interfaces: #ZONE INTERFACE OPTIONS world br0 bridge world br1 bridge z1 br0:x+ physical=p+ z2 br1:y+ physical=p+ In this configuration, 'x+' is the logical name for ports p+ on bridge br0 while 'y+' is the logical name for ports p+ on bridge br1. If you need to refer to a particular port on br1 (for example p1023), you write it as y1023; Shorewall will translate that name to p1023 when needed. Example from /etc/shorewall/rules: #ACTION SOURCE DEST PROTO DPORT REJECT z1:x1023 z1:x1024 tcp 1234
Combination Router/Bridge A system running Shorewall doesn't have to be exclusively a bridge or a router -- it can act as both, which is also know as a brouter. Here's an example: This is basically the same setup as shown in the Shorewall Setup Guide with the exception that the DMZ is bridged rather than using Proxy ARP. Changes in the configuration shown in the Setup Guide are as follows: The /etc/shorewall/proxyarp file is empty in this configuration. The /etc/shorewall/zones file is modified: #ZONE TYPE OPTIONS fw firewall pub ipv4 #zone containing all public addresses net:pub bport4 dmz:pub bport4 loc ipv4 The /etc/shorewall/interfaces file is as follows:#ZONE INTERFACE OPTIONS pub br0 routefilter,bridge net br0:eth0 dmz br0:eth2 loc eth1 The DMZ systems need a route to the 192.168.201.0/24 network via 192.0.2.176 to enable them to communicate with the local network. This configuration does not support separate fw->dmz and fw->net policies/rules; similarly, it does not support separate loc->dmz and loc->net rules. This will make it a bit trickier to configure the rules. I suggest something like the following: /etc/shorewall/params: SERVERS=192.0.2.177,192.0.2.178 #IP Addresses of hosts in the DMZ DMZ=pub:$SERVERS #Use in place of 'dmz' in rule DEST NET=pub:!$SERVERS #Use in place of 'net' in rule DEST /etc/shorewall/policy: #SOURCE DEST POLICY LEVEL loc pub ACCEPT loc $FW REJECT info loc all REJECT info $FW pub REJECT info $FW loc REJECT info $FW all REJECT info dmz net REJECT info dmz $FW REJECT info dmz loc REJECT info dmz all REJECT info net dmz DROP info net $FW DROP info net loc DROP info net all DROP info # THE FOLLOWING POLICY MUST BE LAST all all REJECT info /etc/shorewall/rules: #ACTION SOURCE DEST PROTO DPORT SPORT ACCEPT all all icmp 8 ACCEPT loc $DMZ tcp 25,53,80,443,... ACCEPT loc $DMZ udp 53 ACCEPT loc $NET ACCEPT $FW $DMZ udp 53 ACCEPT $FW $DMZ tcp 53
Using Back-to-back veth Devices to Interface with a Bridge Beginning with Shorewall 4.4.26, Shorewall has limited support for using back-to-back veth devices to interface with a bridge. This approach has the advantage that traffic between any pair of zones can be filtered. The disadvantage is the complexity of the approach. This configuration is shown in the following diagram. In this configuration, veth0 is assigned the internal IP address; br0 does not have an IP address. Traffic from the net and fw zones to the zonei zones goes thru veth0->veth1->ethN->. Traffic from the zonei zones to the fw and net zones takes the reverse path: ethN->veth1->veth0. As a consequence, traffic between net,fw and zonei goes through Netfilter twice: once in the routed firewall (eth0,veth0) and once in the bridged firewall (eth1,eth2,eth3,veth1). The back-to-back veth devices (veth0 and veth1) are created using this command: ip link add type veth If you have veth devices and want to assign specific names to the created devices, use this format: ip link add name FOO type veth peer name BAR Here's an /etc/network/interfaces stanza that configures veth0, veth1 and the bridge: auto veth0 iface veth0 inet static address 10.10.10.1 netmask 255.255.255.0 network 10.10.10.0 broadcast 10.10.10.255 pre-up /sbin/ip link add name veth0 type veth peer name veth1 pre-up /sbin/ip link set eth1 up pre-up /sbin/ip link set eth2 up pre-up /sbin/ip link set eth3 up pre-up /sbin/ip link set veth1 up pre-up /usr/sbin/brctl addbr br0 pre-up /usr/sbin/brctl addif br0 eth1 pre-up /usr/sbin/brctl addif br0 eth2 pre-up /usr/sbin/brctl addif br0 eth3 pre-up /usr/sbin/brctl addif br0 veth1 pre-down /usr/sbin/brctl delif br0 eth1 pre-down /sbin/ip link set eth2 down pre-down /usr/sbin/brctl delif br0 eth2 pre-down /sbin/ip link set eth2 down pre-down /usr/sbin/brctl delif br0 eth3 pre-down /sbin/ip link set eth3 down pre-down /usr/sbin/brctl delif br0 veth1 pre-down /sbin/ip link set veth1 down post-down /usr/sbin/brctl delbr br0 post-down /sbin/ip link del veth0 In shorewall.conf (5), we need this: ZONE_BITS=3 This does two things: It enables automatic packet marking. It allows up to 7 marked zones (2**3 - 1). Zones are marked unless they have in the OPTIONS column of their entry in shorewall-zones (5). Packets originating in a marked zone have a mark assigned automatically by Shorewall. For this configuration, we need several additional zones as shown here: #ZONE TYPE OPTIONS IN_OPTIONS OUT_OPTIONS fw firewall net ipv4 zone1 bport zone2 bport zone3 bport loc ipv4 nomark col ipv4 nomark col is loc spelled backward. #ZONE INTERFACES BROADCAST OPTIONS net eth0 ... - br0 ... zone1 br0:eth1 ... zone2 br0:eth2 ... zone3 br0:eth3 ... loc veth0 ... col br0:veth1 ... Several things to note here We have defined two unmarked zones: loc and col. This allows traffic from the zonei zones to the fw and net zones to retain the mark of their originating bport zones. It also allows traffic from the fw and net zones to the zonei zones to retain the fw and net marks respectively. That means that traffic entering the bridge on veth1 will have a different mark value, depending on whether it originated in the net zone or in the fw zone. Similarly, traffic arriving on the veth0 interface will have a mark that indicates which of the zonei zones each packet originated on. The basic idea here is that we want to filter traffic to the zonei zones as it leaves veth1 and we want to filter traffic from those zones as it leaves veth0. So we use this type of polices: #SOURCE DEST POLICY fw loc ACCEPT net loc ACCEPT net all DROP:info zone1 col ACCEPT zone2 col ACCEPT zone3 col ACCEPT all all REJECT:info Rules allowing traffic from the net to zone2 look like this: #ACTION SOURCE DEST PROTO DPORT SPORT ORIGDEST RATE USER MARK ACCEPT col zone2 tcp 22 - - - - net or more compactly: #ACTION SOURCE DEST PROTO DPORT ACCEPT col zone2 tcp 22 ; mark=net Similarly, rules allowing traffic from the firewall to zone3: #ACTION SOURCE DEST PROTO DPORT ACCEPT col zone3 tcp 22 ; mark=fw The important point here is that, when ZONE_BITS is non-zero, you are allowed to place zone names in the MARK column. Shorewall will automatically replae the name with the zone's mark value. Suppose that you want to forward tcp port 80 to 192.168.4.45 in zone3: #ACTION SOURCE DEST PROTO DPORT SPORT ORIGDEST RATE USER MARK DNAT- net loc:172.168.4.45 tcp 80 ACCEPT col zone3:172.168.4.45 tcp 80 - - - - net Rules allowing traffic from the zonei zones to the net zone look like this: #ACTION SOURCE DEST PROTO DPORT SPORT ORIGDEST RATE USER MARK ACCEPT loc net tcp 21 - - - - zone1 And to the firewall: #ACTION SOURCE DEST PROTO DPORT SPORT ORIGDEST RATE USER MARK ACCEPT zone2 col tcp - - - - zone2
Limitations Bridging doesn't work with some wireless cards — see http://bridge.sf.net.
shorewall-docs-xml-5.0.15/Dynamic.xml0000644000000000000000000001522013020330134016117 0ustar rootroot
Dynamic Zones Tom Eastep 2009 2013 Thomas M. Eastep 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.
Overview There is sometimes a need to be able to define a zone whose members are unknown at compile-time. For example, you may wish to require authentication of internal users before allowing them access to the internet. When a user is authenticated, the user's IP address is added to the zone of users permitted web access. Shorewall provides basic support for defining such zones. This support is based on ipset. Most current distributions have ipset, but you may need to install the xtables-addons package.
Dynamic Zones Prior to Shorewall 4.5.9, when multiple records for a zone appear in /etc/shorewall/hosts, Shorewall would create a separate ipset for each interface. This meant that an add or delete command was required for each of the interface, when the address involved was reachable via multiple interfaces. Beginning with Shoreawll 4.5.9, it is possible to have a single ipset shared among all interfaces. This also simplifies management of dynamic zone contents for dynamic zones associated with only a single interface. The earlier implementation described below is still available in these later releases.
Defining a Dynamic Zone A dynamic zone is defined by specifying the dynamic_shared option in the zones file and using the dynamic keyword in the hosts list. /etc/shorewall/zones:#NAME TYPE OPTIONS net ipv4 rsyncok:loc ipv4 dynamic_shared/etc/shorewall/interfaces: #ZONE INTERFACE BROADCAST OPTIONS loc eth0 - … loc eth1 - … /etc/shorewall/hosts: #ZONE HOSTS OPTIONS rsyncok eth0:dynamic rsyncok eth1:dynamic When the dynamic_shared option is specified, a single ipset is created; the ipset has the same name as the zone. In the above example, rsyncok is a sub-zone of the single zone loc. Making a dynamic zone a sub-zone of multiple other zones is also supported.
Adding a Host to a Dynamic Zone. Adding a host to a dynamic zone is accomplished by adding the host's IP address to the appropriate ipset. Shorewall provldes a command for doing that:
shorewall add zone address ...
Example:
shorewall add rsyncok 70.90.191.124
Deleting a Host from a Dynamic Zone Deleting a host from a dynamic zone is accomplished by removing the host's IP address from the appropriate ipset. Shorewall provldes a command for doing that:
shorewall delete zone address ...
Example:
shorewall delete rsyncok 70.19.191.124
The command can only be used when the ipset involved is of type iphash. For other ipset types, the ipset command must be used directly.
Listing the Contents of a Dynamic Zone The shorewall show command may be used to list the current contents of a dynamic zone.
shorewall show dynamic zone
Example:
shorewall show dynamic rsyncok rsyncok: 70.90.191.122 70.90.191.124
Dynamic Zone Contents and Shorewall stop/start/restart When SAVE_IPSETS=Yes in shorewall.conf, the contents of a dynamic zone survive shorewall stop/shorewall start and shorewall restart. During shorewall stop, the contents of the ipsets are saved in the file ${VARDIR}/ipsets.save (usually /var/lib/shorewall/ipsets.save). During shorewall start, the contents of that file are restored to the sets. During both shorewall start and shorewall restart, any new ipsets required as a result of a configuration change are added.
shorewall-docs-xml-5.0.15/SplitDNS.xml0000644000000000000000000001643113020330134016200 0ustar rootroot
Simple way to set up Split DNS Tom Eastep 2008 Thomas M. Eastep 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.
What is Split DNS Split DNS is simply a configuration in which the IP address to which a DNS name resolves is dependent on the location of the client. It is most often used in a NAT environment to insure that local clients resolve the DNS names of local servers to their RFC 1918 addresses while external clients resolve the same server names to their public counterparts.
Why would I want to use Split DNS? See Shorewall FAQ 2.
Setting up Split DNS Setting up Split DNS is extremely simple: Be sure that your firewall/router can resolve external DNS names. Install the dnsmasq package (http://www.thekelleys.org.uk/dnsmasq/doc.html) and arrange for it to start at boot time. There are many dnsmasq HOWTOs on the Internet. Add your local hosts to /etc/hosts on the firewall/router using their local RFC 1918 addresses. Here's an example:# # hosts This file describes a number of hostname-to-address # mappings for the TCP/IP subsystem. It is mostly # used at boot time, when no name servers are running. # On small systems, this file can be used instead of a # "named" name server. # Syntax: # # IP-Address Full-Qualified-Hostname Short-Hostname # 127.0.0.1 localhost 172.20.0.1 openvpn.shorewall.net openvpn 172.20.0.2 vpn02.shorewall.net vpn02 172.20.0.3 vpn03.shorewall.net vpn03 172.20.0.4 vpn04.shorewall.net vpn04 172.20.0.5 vpn05.shorewall.net vpn05 172.20.0.6 vpn06.shorewall.net vpn06 172.20.0.7 vpn07.shorewall.net vpn07 172.20.0.8 vpn08.shorewall.net vpn08 172.20.0.9 vpn09.shorewall.net vpn09 172.20.0.10 vpn10.shorewall.net vpn10 172.20.0.11 vpn11.shorewall.net vpn11 172.20.0.12 vpn12.shorewall.net vpn12 172.20.0.13 vpn13.shorewall.net vpn13 172.20.0.14 vpn14.shorewall.net vpn14 172.20.0.15 vpn15.shorewall.net vpn15 172.20.0.16 vpn16.shorewall.net vpn16 172.20.1.1 linksys.shorewall.net linksys 172.20.1.100 hp8500.shorewall.net hp8500 172.20.1.102 ursa.shorewall.net ursa 172.20.1.105 tarry.shorewall.net tarry 172.20.1.107 teastep.shorewall.net teastep 172.20.1.109 hpmini.shorewall.net hpmini 172.20.1.130 lanursa.shorewall.net lanursa 172.20.1.131 wookie.shorewall.net wookie 172.20.1.132 tipper.shorewall.net tipper 172.20.1.133 nasty.shorewall.net nasty 172.20.1.134 ursadog.shorewall.net ursadog 172.20.1.135 opensuse.shorewall.net opensuse 172.20.1.136 centos.shorewall.net centos 172.20.1.137 fedora.shorewall.net fedora 172.20.1.138 debian.shorewall.net debian 172.20.1.139 archlinux.shorewall.net archlinux 172.20.1.140 foobar.shorewall.net foobar 172.20.1.141 deblap.shorewall.net deblap 172.20.1.254 firewall.shorewall.net firewall 206.124.146.254 blarg.shorewall.net blarg # special IPv6 addresses ::1 localhost ipv6-localhost ipv6-loopback fe00::0 ipv6-localnet ff00::0 ipv6-mcastprefix ff02::1 ipv6-allnodes ff02::2 ipv6-allrouters ff02::3 ipv6-allhosts 2002:ce7c:92b4::1 gateway6.shorewall.net gateway6 2002:ce7c:92b4:1::2 mail6.shorewall.net mail6 2002:ce7c:92b4:1::2 lists6.shorewall.net lists6 2002:ce7c:92b4:2::2 server6.shorewall.net server6 If your local hosts are configured using DHCP, that is a simple one-line change to the DHCP configuration. And that's it! Your local clients will resolve those names in the firewall/router's /etc/hosts file as defined in that file. All other names will be resolved using the firewall/router's Name Server as defined in /etc/resolv.conf. Example: From an Internet Host:gateway:~ # host linksys.shorewall.net linksys.shorewall.net has address 206.124.146.180 gateway:~ # From Tipper (192.168.1.132):teastep@tipper:~$ host linksys linksys.shorewall.net has address 172.20.1.1 teastep@tipper:~$ As a bonus, dnsmasq can also act as a DHCP server. Here are some excerpts from the corresponding /etc/dnsmasq.conf: interface=eth1 dhcp-range=172.20.1.210,172.20.1.219,24h dhcp-host=00:11:85:89:da:9b,172.20.1.220 dhcp-host=00:1A:73:DB:8C:35,172.20.1.102 dhcp-host=00:25:B3:9F:5B:FD,172.20.1.100 dhcp-host=00:1F:E1:07:53:CA,172.20.1.105 dhcp-host=00:1F:29:7B:04:04,172.20.1.107 dhcp-host=00:24:2b:59:96:e2,172.20.1.109 dhcp-host=00:1B:24:CB:2B:CC,172.20.1.130 dhcp-host=00:21:5a:22:ac:e0,172.20.1.131 dhcp-host=08:00:27:B1:46:a9,172.20.1.132 dhcp-host=08:00:27:31:45:83,172.20.1.133 dhcp-host=08:00:27:28:64:50,172.20.1.134 dhcp-host=08:00:27:4b:38:88,172.20.1.135 dhcp-host=08:00:27:f6:4d:65,172.20.1.136 dhcp-host=08:00:27:dc:cd:94,172.20.1.137 dhcp-host=08:00:27:0f:d3:8f,172.20.1.138 dhcp-host=08:00:27:42:9c:01,172.20.1.139 dhcp-host=08:00:27:5a:6c:d8,172.20.1.140 dhcp-host=08:00:27:da:96:78,172.20.1.141 dhcp-option=19,0 # option ip-forwarding off dhcp-option=44,0.0.0.0 # set netbios-over-TCP/IP nameserver(s) aka WINS server(s) dhcp-option=45,0.0.0.0 # netbios datagram distribution server dhcp-option=46,8 # netbios node type dhcp-option=47 # empty netbios scope. dhcp-option=option:domain-search,shorewall.net
shorewall-docs-xml-5.0.15/blacklisting_support_ru.xml0000644000000000000000000003005513020330134021506 0ustar rootroot
Чёрные списки в Shorewall Tom Eastep 2002-2006 Thomas M. Eastep 2007 Russian Translation: Grigory Mokhin Этот документ разрешается копировать, распространять и/или изменять при выполнении условий лицензии GNU Free Documentation License версии 1.2 или более поздней, опубликованной Free Software Foundation; без неизменяемых разделов, без текста на верхней обложке, без текста на нижней обложке. Копия лицензии приведена по ссылке GNU Free Documentation License.
Введение В Shorewall предусмотрены два вида чёрных списков, статические и динамические. Опция BLACKLISTNEWONLY в файле /etc/shorewall/shorewall.conf задаёт параметры фильтрации согласно этим спискам: BLACKLISTNEWONLY=No -- проверка осуществляется для всех входящих пакетов. Новые записи в чёрном списке позволяют прервать уже существующие соединения. BLACKLISTNEWONLY=Yes -- проверка осуществляется только для новых запросов на установление соединения. Записи в чёрном списке не влияют на уже существующие соединения. На соответствие чёрному списку проверяется только адрес источника. На соответствие чёрному списку проверяется только адрес источника . Чёрные списки закрывают доступ только хостам, перечисленным в списке, но не закрывают доступ к самим этим хостам. Динамические чёрные списки в Shorewall непригодны для случаев, когда список содержит тысячи адресов. Статические списки могут работать с большим числом адресов, но только при использовании наборов IP (ipset). Без ipset большие чёрные списки будут загружаться слишком долго и заметно снизят производительность файрвола.
Статические чёрные списки Далее описаны параметры конфигурации статических чёрных списков в Shorewall: Пакеты с хостов из чёрного списка будут отбрасываться без уведомления (drop) или с уведомлением (reject), согласно параметру BLACKLIST_DISPOSITION из файла /etc/shorewall/shorewall.conf. Пакеты с хостов из чёрного списка будут заноситься в протокол с заданным уровнем syslog согласно параметру BLACKLIST_LOGLEVEL из файла /etc/shorewall/shorewall.conf. IP-адреса или подсети, которые требуется занести в чёрный список, указываются в файле /etc/shorewall/blacklist. В этом файле можно также указать имена протоколов, номера портов или имена служб. Интерфейсы, для которых входящие пакеты проверяются на соответствие чёрному списку, задаются с помощью опции blacklist в файле /etc/shorewall/interfaces. Чёрный список из файла /etc/shorewall/blacklist можно обновить командой shorewall refresh. При наличии большого статического чёрного списка можно включить опцию DELAYBLACKLISTLOAD в файле shorewall.conf (начиная с Shorewall версии 2.2.0). Если DELAYBLACKLISTLOAD=Yes, то Shorewall будет загружать правила чёрного списка после установления соединений. Хотя при этом соединения с хостов из чёрного списка могут осуществляться в течение времени создания списка, эта опция позволяет существенно снизить время запрета соединений в ходе выполнения команд "shorewall [re]start". Для определения статического чёрного списка в Shorewall начиная с версии 2.4.0 поддерживаются наборы IP, или ipsets. Пример: #ADDRESS/SUBNET PROTOCOL PORT +Blacklistports[dst] +Blacklistnets[src,dst] +Blacklist[src,dst] #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE В этом примере задан ipset набора портов (portmap) Blacklistports для запрета трафика на целевые порты, указанные в этом ipset. Есть также списки сетей - Blacklistnets (типа nethash) и адресов - Blacklist (типа iphash), закрывающие доступ из подсетей и с отдельных адресов. Обратите внимание, что указаны [src,dst], чтобы можно было связать отдельные записи наборов с другими portmap ipset и включить чёрные списки сочетаний ( адрес источника, целевой порт). Пример: ipset -N SMTP portmap --from 1 --to 31 ipset -A SMTP 25 ipset -A Blacklist 206.124.146.177 ipset -B Blacklist 206.124.146.177 -b SMTP При этом блокируется трафик SMTP с хоста 206.124.146.177.
Динамические чёрные списки Динамические списки не имеют никаких параметров конфигурации, но настраиваются следующими командами /sbin/shorewall[-lite]: drop <список IP-адресов> - пакеты с указанных IP-адресов будут отбрасываться файрволом без уведомления. reject <список IP-адресов> - пакеты с указанных IP-адресов будут отбрасываться файрволом с уведомлением. allow <список IP-адресов> - разрешить пакеты с хостов, ранее занесённых в чёрный список командами drop или reject. save - сохранить конфигурацию динамического чёрного списка; она будет восстановлена автоматически при следующем перезапуске файрвола. show dynamic - показать конфигурацию динамического чёрного списка. Начиная с Shorewall версии 3.2.0 Beta2 доступны следующие дополнительные команды: logdrop <список IP-адресов> - пакеты с указанных IP-адресов будут заноситься в протокол и отбрасываться файрволом без уведомления. Уровень протокола задаётся опцией BLACKLIST_LOGLEVEL в ходе последнего [пере]запуска (по умолчанию - 'info', если опция BLACKLIST_LOGLEVEL не задана). logreject <список IP-адресов> - пакеты с указанных IP-адресов будут заноситься в протокол и отбрасываться файрволом с уведомлением. Уровень протокола задаётся опцией BLACKLIST_LOGLEVEL в ходе последнего [пере]запуска (по умолчанию - 'info', если опция BLACKLIST_LOGLEVEL не задана). Динамические чёрные списки не зависят от опции blacklist в файле /etc/shorewall/interfaces. Игноpиpовать пакеты с двух IP-адресов shorewall[-lite] drop 192.0.2.124 192.0.2.125 При этом блокируется доступ с хостов 192.0.2.124 и 192.0.2.125 Разрешить пакеты с IP-адреса shorewall[-lite] allow 192.0.2.125 Разрешает трафик с 192.0.2.125.
shorewall-docs-xml-5.0.15/ECN.xml0000644000000000000000000000753213020330134015147 0ustar rootroot
ECN Tom Eastep 2001 2002 2003 2005 2016 Thomas M. Eastep 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. 2006-01-17. The ECN Netfilter target in some 2.6 Linux Kernels is broken. Symptoms are that you will be unable to establish a TCP connection to hosts defined in the /etc/shorewall/ecn file.
Explicit Congestion Notification (ECN) Explicit Congestion Notification (ECN) is described in RFC 3168 and is a proposed Internet standard. Unfortunately, not all sites support ECN and when a TCP connection offering ECN is sent to sites that don't support it, the result is often that the connection request is ignored. To allow ECN to be used, Shorewall allows you to enable ECN on your Linux systems then disable it in your firewall when the destination matches a list that you create (the /etc/shorewall/ecn file). You enable ECN by echo 1 > /proc/sys/net/ipv4/tcp_ecn You must arrange for that command to be executed at system boot. Most distributions have a method for doing that -- on RedHat, you make an entry in /etc/sysctl.conf. net.ipv4.tcp_ecn = 1 Entries in /etc/shorewall/ecn have two columns as follows: INTERFACE The name of an interface on your system HOST(S) An address (host or subnet) of a system or group of systems accessed through the interface in the first column. You may include a comma-separated list of such addresses in this column. Your external interface is eth0 and you want to disable ECN for tcp connections to 192.0.2.0/24: /etc/shorewall/ecn INTERFACE HOST(S) eth0 192.0.2.0/24
Beginning with Shorewall 5.0.6, you may also specify clearing of the ECN flags through use of the ECN action in shorewall-mangle(8).
shorewall-docs-xml-5.0.15/standalone.xml0000644000000000000000000007327213020330134016676 0ustar rootroot
Standalone Firewall Tom Eastep 2002-2009 Thomas M. Eastep 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. This article applies to Shorewall 4.4 and later. If you are running a version of Shorewall earlier than Shorewall 4.4.0 then please see the documentation for that release.
Introduction Setting up Shorewall on a standalone Linux system is very easy if you understand the basics and follow the documentation. This guide doesn't attempt to acquaint you with all of the features of Shorewall. It rather focuses on what is required to configure Shorewall in one of its most common configurations: Linux system Single external IP address Connection through Cable Modem, DSL, ISDN, Frame Relay, dial-up... or connected to a LAN and you simply wish to protect your Linux system from other systems on that LAN.
System Requirements Shorewall requires that you have the iproute/iproute2 package installed (on RedHat, the package is called iproute). You can tell if this package is installed by the presence of an ip program on your firewall system. As root, you can use the which command to check for this program: [root@gateway root]# which ip /sbin/ip [root@gateway root]#
Before you start I recommend that you read through the guide first to familiarize yourself with what's involved then go back through it again making your configuration changes. If you edit your configuration files on a Windows system, you must save them as Unix files if your editor supports that option or you must run them through dos2unix before trying to use them. Similarly, if you copy a configuration file from your Windows hard drive to a floppy disk, you must run dos2unix against the copy before using it with Shorewall. Windows Version of dos2unix Linux Version of dos2unix
Conventions Points at which configuration changes are recommended are flagged with . Configuration notes that are unique to Debian and it's derivatives are marked with .
PPTP/ADSL If you have an ADSL Modem and you use PPTP to communicate with a server in that modem, you must make the changes recommended here in addition to those detailed below. ADSL with PPTP is most commonly found in Europe, notably in Austria.
Shorewall Concepts The configuration files for Shorewall are contained in the directory /etc/shorewall -- for simple setups, you only need to deal with a few of these as described in this guide. After you have installed Shorewall, you can find the Samples as follows: If you installed using an RPM, the samples will be in the Samples/one-interface subdirectory of the Shorewall documentation directory. If you don't know where the Shorewall documentation directory is, you can find the samples using this command: ~# rpm -ql shorewall | fgrep one-interface /usr/share/doc/packages/shorewall/Samples/one-interface /usr/share/doc/packages/shorewall/Samples/one-interface/interfaces /usr/share/doc/packages/shorewall/Samples/one-interface/policy /usr/share/doc/packages/shorewall/Samples/one-interface/rules /usr/share/doc/packages/shorewall/Samples/one-interface/zones ~# If you installed using the tarball, the samples are in the Samples/one-interface directory in the tarball. If you installed using a Shorewall 4.x .deb, the samples are in /usr/share/doc/shorewall/examples/one-interface.. You do not need the shorewall-doc package to have access to the samples. Note to Debian Users You will find that your /etc/shorewall directory is empty. This is intentional. If you need configuration files other than those found in /usr/share/doc/shorewall/examples/one-interface, they may be found on your system in the directory /usr/share/doc/shorewall/default-config. Simply copy the files you need from that directory to /etc/shorewall and modify the copies. As each file is introduced, I suggest that you look at the actual file on your system and that you look at the man page for that file. For example, to look at the man page for the /etc/shorewall/zones file, type man shorewall-zones at a shell prompt. Note: Beginning with Shorewall 4.4.20.1, there are versions of the sample files that are annotated with the corresponding manpage contents. These files have names ending in '.annotated'. You might choose to look at those files instead. Shorewall views the network where it is running as being composed of a set of zones. In the one-interface sample configuration, only two zones are defined: #ZONE TYPE OPTIONS IN OUT # OPTIONS OPTIONS fw firewall net ipv4 Shorewall zones are defined in /etc/shorewall/zones. Note that Shorewall recognizes the firewall system as its own zone. When the /etc/shorewall/zones file is processed, the name of the firewall zone (fw in the above example) is stored in the shell variable $FW which may be used to refer to the firewall zone throughout the Shorewall configuration. Rules about what traffic to allow and what traffic to deny are expressed in terms of zones. You express your default policy for connections from one zone to another zone in the /etc/shorewall/policy file. You define exceptions to those default policies in the /etc/shorewall/rules file. For each connection request entering the firewall, the request is first checked against the /etc/shorewall/rules file. If no rule in that file matches the connection request then the first policy in /etc/shorewall/policy that matches the request is applied. If there is a common action defined for the policy in /etc/shorewall/actions or /usr/share/shorewall/actions.std then that action is performed before the policy is applied. The purpose of the common action is two-fold: It silently drops or rejects harmless common traffic that would otherwise clutter up your log — Broadcasts for example. If ensures that traffic critical to correct operation is allowed through the firewall — ICMP fragmentation-needed for example. The /etc/shorewall/policy file included with the one-interface sample has the following policies: #SOURCE DEST POLICY LOGLEVEL LIMIT $FW net ACCEPT net all DROP info all all REJECT info The above policy will: allow all connection requests from the firewall to the Internet drop (ignore) all connection requests from the Internet to your firewall reject all other connection requests (Shorewall requires this catchall policy). The word info in the LOG LEVEL column for the last two policies indicates that packets dropped or rejected under those policies should be logged at that level. At this point, edit your /etc/shorewall/policy and make any changes that you wish.
External Interface The firewall has a single network interface. Where Internet connectivity is through a cable or DSL Modem, the External Interface will be the Ethernet adapter (eth0) that is connected to that Modem unless you connect via Point-to-Point Protocol over Ethernet (PPPoE) or Point-to-Point Tunneling Protocol (PPTP) in which case the External Interface will be a PPP interface (e.g., ppp0). If you connect via a regular modem, your External Interface will also be ppp0. If you connect using ISDN, your external interface will be ippp0. Be sure you know which interface is your external interface. Many hours have been spent floundering by users who have configured the wrong interface. If you are unsure, then as root type ip route ls at the command line. The device listed in the last (default) route should be your external interface. Example: root@lists:~# ip route ls 192.168.2.2 dev tun0 proto kernel scope link src 192.168.2.1 10.13.10.0/24 dev tun1 scope link 192.168.2.0/24 via 192.168.2.2 dev tun0 206.124.146.0/24 dev eth0 proto kernel scope link src 206.124.146.176 10.10.10.0/24 dev tun1 scope link default via 206.124.146.254 dev eth0 root@lists:~# In that example, eth0 is the external interface. The Shorewall one-interface sample configuration assumes that the external interface is eth0. If your configuration is different, you will have to modify the sample /etc/shorewall/interfaces file accordingly. While you are there, you may wish to review the list of options that are specified for the interface. Some hints: If your external interface is ppp0 or ippp0, you can replace the detect in the second column with - (minus the quotes). If your external interface is ppp0 or ippp0 or if you have a static IP address, you can remove dhcp from the option list.
IP Addresses Before going further, we should say a few words about Internet Protocol (IP) addresses. Normally, your Internet Service Provider (ISP) will assign you a single IP address. That address can be assigned statically, by the Dynamic Host Configuration Protocol (DHCP), through the establishment of your dial-up connection, or during establishment of your other type of PPP (PPPoA, PPPoE, etc.) connection. RFC-1918 reserves several Private IP address ranges for use in private networks: 10.0.0.0 - 10.255.255.255 172.16.0.0 - 172.31.255.255 192.168.0.0 - 192.168.255.255 These addresses are sometimes referred to as non-routable because the Internet backbone routers will not forward a packet whose destination address is reserved by RFC-1918. In some cases though, ISPs are assigning these addresses then using Network Address Translation - NAT) to rewrite packet headers when forwarding to/from the Internet.
Logging Shorewall does not maintain a log itself but rather relies on your system's logging configuration. The following commands rely on knowing where Netfilter messages are logged: shorewall show log (Displays the last 20 Netfilter log messages) shorewall logwatch (Polls the log at a settable interval shorewall dump (Produces an extensive report for inclusion in Shorewall problem reports) It is important that these commands work properly because when you encounter connection problems when Shorewall is running, the first thing that you should do is to look at the Netfilter log; with the help of Shorewall FAQ 17, you can usually resolve the problem quickly. The Netfilter log location is distribution-dependent: Debian and its derivatives log Netfilter messages to /var/log/kern.log. Recent SuSE/OpenSuSE releases come preconfigured with syslog-ng and log netfilter messages to /var/log/firewall. For other distributions, Netfilter messages are most commonly logged to /var/log/messages. If you are running a distribution that logs Netfilter messages to a log other than /var/log/messages, then modify the LOGFILE setting in /etc/shorewall/shorewall.conf to specify the name of your log. The LOGFILE setting does not control where the Netfilter log is maintained -- it simply tells the /sbin/shorewall utility where to find the log.
Kernel Module Loading Beginning in Shorewall 4.4.7, /etc/shorewall/shorewall.conf contains a LOAD_HELPERS_ONLY option which is set to in the samples. This causes Shorewall to attempt to load the modules listed in /usr/share/shorewall/helpers. In addition, it sets sip_direct_media=0 when loading the nf_conntrack_sip module. That setting is somewhat less secure than sip_direct_media=1, but it generally makes VOIP through the firewall work much better. The modules in /usr/share/shorewall/helpers are those that are not autoloaded. If your kernel does not support module autoloading and you want Shorewall to attempt to load all netfilter modules that it might require, then set LOAD_HELPERS_ONLY=No. That will cause Shorewall to try to load the modules listed in /usr/share/shorewall/modules. That file does not set sip_direct_media=0. If you need to modify either /usr/share/shorewall/helpers or /usr/share/shorewall/modules then copy the file to /etc/shorewall and modify the copy. Modify the setting of LOAD_HELPER_ONLY as necessary.
Enabling other Connections Shorewall includes a collection of macros that can be used to quickly allow or deny services. You can find a list of the macros included in your version of Shorewall using the command ls /usr/share/shorewall/macro.*. If you wish to enable connections from the Internet to your firewall and you find an appropriate macro in /usr/share/shorewall/macro.*, the general format of a rule in /etc/shorewall/rules is: #ACTION SOURCE DEST PROTO DPORT <macro>(ACCEPT) net $FW Be sure to add your rules after the line that reads ?SECTION NEW. You want to run a Web Server and a IMAP Server on your firewall system: #ACTION SOURCE DEST PROTO DPORT Web(ACCEPT) net $FW IMAP(ACCEPT)net $FW The Shorewall-provided macros assume that the associated service is using it's standard port and will not work with services listening on a non-standard port. You may also choose to code your rules directly without using the pre-defined macros. This will be necessary in the event that there is not a pre-defined macro that meets your requirements. In that case the general format of a rule in /etc/shorewall/rules is: #ACTION SOURCE DEST PROTO DPORT ACCEPT net $FW <protocol> <port> You want to run a Web Server and a IMAP Server on your firewall system: #ACTION SOURCE DEST PROTO DPORT ACCEPT net $FW tcp 80 ACCEPT net $FW tcp 143 If you don't know what port and protocol a particular application uses, see here. I don't recommend enabling telnet to/from the Internet because it uses clear text (even for login!). If you want shell access to your firewall from the Internet, use SSH: #ACTION SOURCE DESTINATION PROTO DPORT SSH(ACCEPT) net $FW At this point, edit /etc/shorewall/rules to add other connections as desired.
Starting and Stopping Your Firewall The installation procedure configures your system to start Shorewall at system boot but startup is disabled so that your system won't try to start Shorewall before configuration is complete. Once you have completed configuration of your firewall, you must edit /etc/shorewall/shorewall.conf and set STARTUP_ENABLED=Yes. Users of the .deb package must edit /etc/default/shorewall and set startup=1. You must enable startup by editing /etc/shorewall/shorewall.conf and setting STARTUP_ENABLED=Yes. While you are editing shorewall.conf, it is a good idea to check the value of the SUBSYSLOCK option. You can find a description of this option by typing 'man shorewall.conf' at a shell prompt and searching for SUBSYSLOCK. The firewall is started using the shorewall start command and stopped using shorewall stop. When the firewall is stopped, traffic is enabled on those hosts that have an entry in /etc/shorewall/stoppedrules (/etc/shorewall/routestopped in Shorewall 4.5.7 and earlier). A running firewall may be restarted using the shorewall reload command. If you want to totally remove any trace of Shorewall from your Netfilter configuration, use shorewall clear. If you are connected to your firewall from the Internet, do not issue a shorewall stop command unless you have either: Used ADMINISABSENTMINDED=Yes in /etc/shorewall/shorewall.conf or added an entry for the IP address that you are connected from to /etc/shorewall/routestopped. Also, I don't recommend using shorewall reload; it is better to create an alternate configuration and test it using the shorewall try command. The firewall will start after your network interface has been brought up. This leaves a small window between the time that the network interface is working and when the firewall is controlling connections through that interface. If this is a concern, you can close that window by installing the Shorewall Init Package.
If it Doesn't Work Re-check each of the items flagged with a red arrow above. Check your log. Check the Troubleshooting Guide. Check the FAQ.
Disabling your existing Firewall Before starting Shorewall for the first time, it's a good idea to stop your existing firewall. On older Redhat/CentOS/Fedora: service iptables stop On recent Fedora systems that run systemd, the command is: systemctl stop iptables.service If you are running SuSE, use Yast or Yast2 to stop SuSEFirewall. On other systems that use a classic SysV init system: /etc/init.d/iptables stop Once you have Shorewall running to your satisfaction, you should totally disable your existing firewall. On older Redhat/CentOS/Fedora: chkconfig --del iptables On Debian systems: update-rc.d iptables disable On recent Fedora system running systemd: systemctl disable iptables.service At this point, disable your existing firewall service.
Additional Recommended Reading I highly recommend that you review the Common Configuration File Features page -- it contains helpful tips about Shorewall features than make administering your firewall easier. Also, Operating Shorewall and Shorewall Lite contains a lot of useful operational hints.
shorewall-docs-xml-5.0.15/FAQ.xml0000644000000000000000000043543613020330134015161 0ustar rootroot
Shorewall FAQs Shorewall Community Tom Eastep 2001-2016 Thomas M. Eastep 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 . This article applies to Shorewall 4.4 and later. If you are running a version of Shorewall earlier than Shorewall 4.4.0 then please see the documentation for that release.
Installing Shorewall
Where do I find Step by Step Installation and Configuration Instructions? Answer: Check out the QuickStart Guides.
(FAQ 92) There are lots of Shorewall packages; which one(s) do I install? Answer: When first installing Shorewall 4.4.0 or later, you must install the shorewall package. If you want to configure an IPv6 firewall, you must also install shorewall6. Beginning with Shorewall 4.5, you must first install the shorewall-core package.
(FAQ 92a) Someone once told me to install shorewall-perl; anything to that? Answer: That was good advice in Shorewall 4.2 and earlier. In those releases, there were two packages that provided the basic firewalling functionality: shorewall-shell and shorewall-perl. Beginning with Shorewall 4.4.0, shorewall-shell is discontinued and shorewall-perl is renamed shorewall.
(FAQ 37) I just installed Shorewall on Debian and the /etc/shorewall directory is almost empty!!! Answer: Once you have installed the .deb package and before you attempt to configure Shorewall, please heed the advice of Lorenzo Martignoni, former Shorewall Debian Maintainer: For more information about Shorewall usage on Debian system please look at /usr/share/doc/shorewall-common/README.Debian provided by [the] shorewall-common Debian package. If you install using the .deb, you will find that your /etc/shorewall directory is almost empty. This is intentional. The released configuration file skeletons may be found on your system in the directory /usr/share/doc/shorewall-common/default-config. Simply copy the files you need from that directory to /etc/shorewall and modify the copies.
(FAQ 37a) I just installed Shorewall on Debian and I can't find the sample configurations. Answer: Beginning with Shorewall 4.4, the samples are in the shorewall package and are installed in /usr/share/doc/shorewall/examples/.
(FAQ 14) I can't find the Shorewall 4.4 shorewall-common, shorewall-shell and shorewall-perl packages? Where are they? Answer:In Shorewall 4.4, the shorewall-shell package was discontinued. The shorewall-common and shorewall-perl packages were combined to form a single shorewall package. In Shorewall 4.5, the shorewall-core package was added and all of the other packages depend on shorewall-core.
Upgrading Shorewall
(FAQ 66) I'm trying to upgrade to Shorewall 4.x; which of these packages do I need to install? Answer: Please see the upgrade issues.
(FAQ 34) I am trying to upgrade to Shorewall 4.4 and I can't find the shorewall-common, shorewall-shell and shorewall-perl packages? Where are they? Answer:In Shorewall 4.4, the shorewall-shell package was discontinued. The shorewall-common and shorewall-perl packages were combined to form a single shorewall package. For further information, please see the upgrade issues..
(FAQ 34a) I am trying to upgrade to Shorewall 4.4 and I'm getting errors when I try to start Shorewall. Where can I find information about these issues? Answer: Please see the upgrade issues.
(FAQ 34b) I am trying to upgrade to Shorewall 4.4 and I'm seeing warning messages when I try to start Shorewall. Where can I find information about these issues? Answer: Please see the upgrade issues.
(FAQ 76) I just upgraded my Debian (Ubuntu, Kubuntu, ...) system and now masquerading doesn't work? What happened? Answer: This happens to people who ignore our advice and allow the installer to replace their working /etc/shorewall/shorewall.conf with one that has default settings. Failure to forward traffic (such as during masqueraded net access from a local network) usually means that /etc/shorewall/shorewall.conf contains the Debian default setting IP_FORWARDING=Keep; it should be IP_FORWARDING=On. Update: Beginning with Shorewall 4.4.21, there is a shorewall update command that does a smart merge of your existing shorewall.conf and the new one.
Port Forwarding (Port Redirection)
(FAQ 1) I want to forward UDP port 7777 to my personal PC with IP address 192.168.1.5. I've looked everywhere and can't find how to do it. Answer: The format of a port-forwarding rule from the net to a local system is as follows: #ACTION SOURCE DEST PROTO DPORT DNAT net loc:local-IP-address[:local-port] protocol port-number So to forward UDP port 7777 to internal system 192.168.1.5, the rule is: #ACTION SOURCE DEST PROTO DPORT DNAT net loc:192.168.1.5 udp 7777 If you want to forward requests directed to a particular address ( external-IP ) on your firewall to an internal system: #ACTION SOURCE DEST PROTO DPORT SPORT ORIGDEST DNAT net loc:local-IP-address>[:local-port] protocol port-number - external-IP If you want to forward requests from a particular Internet address ( address ): #ACTION SOURCE DEST PROTO DPORT SPORT ORIGDEST DNAT net:address loc:local-IP-address[:local-port] protocol port-number - Finally, if you need to forward a range of ports, in the DEST PORT column specify the range as low-port:high-port. The above does not work for forwarding from the local network. If you want to do that, see FAQ 2.
(FAQ 1a) Okay -- I followed those instructions but it doesn't work Answer: That is usually the result of one of four things: You are trying to test from inside your firewall (no, that won't work -- see ). You have a more basic problem with your local system (the one that you are trying to forward to) such as an incorrect default gateway (it must be set to the IP address of your firewall's internal interface; if that isn't possible for some reason, see FAQ 1f). Your ISP is blocking that particular port inbound or, for TCP, your ISP is dropping the outbound SYN,ACK response. You are running Mandriva Linux prior to 10.0 final and have configured Internet Connection Sharing. In that case, the name of your local zone is 'masq' rather than 'loc' (change all instances of 'loc' to 'masq' in your rules). You may want to consider re-installing Shorewall in a configuration which matches the Shorewall documentation. See the two-interface QuickStart Guide for details.
(FAQ 1b) I'm still having problems with port forwarding Answer: To further diagnose this problem: As root, type shorewall reset ("shorewall-lite reset", if you are running Shorewall Lite). This clears all Netfilter counters. Try to connect to the redirected port from an external host. As root type shorewall show nat ("shorewall-lite show nat", if you are running Shorewall Lite). Locate the appropriate DNAT rule. It will be in a chain called <source zone>_dnat (net_dnat in the above examples). Is the packet count in the first column non-zero? If so, the connection request is reaching the firewall and is being redirected to the server. In this case, the problem is usually a missing or incorrect default gateway setting on the local system (the system you are trying to forward to -- its default gateway must be the IP address of the firewall's interface to that system unless you use the hack described in FAQ 1f). If the packet count is zero: the connection request is not reaching your server (possibly it is being blocked by your ISP); or you are trying to connect to a secondary IP address on your firewall and your rule is only redirecting the primary IP address (You need to specify the secondary IP address in the ORIG. DEST. column in your DNAT rule); or your DNAT rule doesn't match the connection request in some other way. In that case, you may have to use a packet sniffer such as tcpdump or Wireshark to further diagnose the problem. The traffic is entering your firewall on a different interface (interfaces reversed in /etc/shorewall/interfaces?). If the packet count is non-zero, check your log to see if the connection is being dropped or rejected. If it is, then you may have a zone definition problem such that the server is in a different zone than what is specified in the DEST column. At a root prompt, type "shorewall show zones" ("shorewall-lite show zones") then be sure that in the DEST column you have specified the first zone in the list that matches OUT=<dev> and DEST= <ip>from the REJECT/DROP log message. If everything seems to be correct according to these tests but the connection doesn't work, it may be that your ISP is blocking SYN,ACK responses. This technique allows your ISP to detect when you are running a server (usually in violation of your service agreement) and to stop connections to that server from being established.
(FAQ 1c) From the Internet, I want to connect to port 1022 on my firewall and have the firewall forward the connection to port 22 on local system 192.168.1.3. How do I do that? Answer:In /etc/shorewall/rules: #ACTION SOURCE DEST PROTO DPORT DNAT net loc:192.168.1.3:22 tcp 1022
(FAQ 1d) I have a web server in my DMZ and I use port forwarding to make that server accessible from the Internet. That works fine but when my local users try to connect to the server using the Firewall's external IP address, it doesn't work. Answer: See FAQ 2b.
(FAQ 1e) In order to discourage brute force attacks I would like to redirect all connections on a non-standard port (4104) to port 22 on the router/firewall. I notice that setting up a REDIRECT rule causes the firewall to open both ports 4104 and 22 to connections from the net. Is it possible to only redirect 4104 to the localhost port 22 and have connection attempts to port 22 from the net dropped? Answer courtesy of Ryan: Assume that the IP address of your local firewall interface is 192.168.1.1. If you configure SSHD to only listen on that address and add the following rule, then you will have access on port 4104 from the net and on port 22 from your LAN. #ACTION SOURCE DEST PROTO DPORT DNAT net fw:192.168.1.1:22 tcp 4104
(FAQ 1f) Why must the server that I port forward to have it's default gateway set to my Shorewall system's IP address? Answer: Let's take an example. Suppose that Your Shorewall firewall's external IP address is 206.124.146.176 (eth0) and its internal IP address is 192.168.1.1 (eth1). You have another gateway router with external IP address 130.252.100.109 and internal IP address 192.168.1.254. You have an FTP server behind both routers with IP address 192.168.1.4 The FTP server's default gateway is through the second router (192.168.1.254). You have this rule on the Shorewall system:#ACTION SOURCE DEST PROTO DPORT SPORT ORIGDEST DNAT net loc:192.168.1.4 tcp 21 - 206.124.146.176 Internet host 16.105.221.4 issues the command ftp 206.124.146.176 This results in the following sequence of events: 16.105.221.4 sends a TCP SYN packet to 206.124.146.176 specifying destination port 21. The Shorewall box rewrites the destination IP address to 192.168.1.4 and forwards the packet. The FTP server receives the packet and accepts the connection, generating a SYN,ACK packet back to 16.105.221.4. Because the server's default gateway is through the second router, it sends the packet to that router. At this point, one of two things can happen. Either the second router discards or rejects the packet; or, it rewrites the source IP address to 130.252.100.109 and forwards the packet back to 16.105.221.4. Regardless of which happens, the connection is doomed. Clearly if the packet is rejected or dropped, the connection will not be successful. But even if the packet reaches 16.105.221.4, that host will reject it since it's SOURCE IP address (130.252.100.109) doesn't match the DESTINATION IP ADDRESS (206.124.146.176) of the original SYN packet. The best way to work around this problem is to change the default gateway on the FTP server to the Shorewall system's internal IP address (192.168.1.1). But if that isn't possible, you can work around the problem with the following ugly hack in /etc/shorewall/masq:#INTERFACE SOURCE ADDRESS PROTO PORT eth1:192.168.1.4 0.0.0.0/0 192.168.1.1 tcp 21 When running Shorewall 5.0.14 or later, the eqivalent /etc/shorewall/snat file is: #ACTION SOURCE DEST PROTO PORT SNAT(192.168.1.1) 0.0.0.0/0 eth1:192.168.1.4 tcp 21 This rule has the undesirable side effect of making all FTP connections from the net appear to the FTP server as if they originated on the Shorewall system. But it will force the FTP server to reply back through the Shorewall system who can then rewrite the SOURCE IP address in the responses properly.
(FAQ 1g) I would like to redirect port 80 on my public IP address (206.124.146.176) to port 993 on Internet host 66.249.93.111 Answer: This requires a vile hack similar to the one in FAQ 2. Assuming that your Internet zone is named net and connects on interface eth0: In /etc/shorewall/rules:#ACTION SOURCE DEST PROTO DPORT SPORT ORIGDEST ?SECTION ALL ?SECTION ESTABLISHED ?SECTION RELATED ?SECTION INVALID ?SECTION UNTRACKED ?SECTION NEW DNAT net net:66.249.93.111:993 tcp 80 - 206.124.146.176 In /etc/shorewall/interfaces, specify the routeback option on eth0:?FORMAT 2 #ZONE INTERFACE OPTIONS net eth0 routeback /etc/shorewall/masq;#INTERFACE SOURCE ADDRESS PROTO PORT eth0:66.249.93.111 0.0.0.0/0 206.124.146.176 tcp 993 When running Shorewall 5.0.14 or later, the equivalent /etc/shorewall/snat file is: #ACTION SOURCE DEST PROTO PORT SNAT(206.124.146.176) 0.0.0.0/0 eth0:66.249.93.111 tcp 993 and in /etc/shorewall/shorewall.conf: IP_FORWARDING=On Like the hack in FAQ 2, this one results in all forwarded connections looking to the server (66.249.93.11) as if they originated on your firewall (206.124.146.176).
(FAQ 1h) How do I set shorewall to allow ssh on port 9022 from net? SSHD is listening on port 22. Answer: Use this rule. #ACTION SOURCE DEST PROTO DPORT REDIRECT net 22 tcp 9022 Note that the above rule will also allow connections from the net on TCP port 22. If you don't want that, see FAQ 1e.
(FAQ 1j) Why doesn't this DNAT rule work? I added this rule but I'm still seeing the log message below RULE: DNAT scnet:172.19.41.2 dmz0:10.199.198.145 udp 2055 LOG: Sep 21 12:55:37 fw001 kernel: [10357687.114928] Shorewall:scnet2fw:DROP:IN=eth2 OUT= MAC=00:26:33:dd:aa:05:00:24:f7:19:ce:44:08:00 SRC=172.19.41.2 DST=172.19.1.1 LEN=1492 TOS=0x00 PREC=0x00 TTL=63 ID=23035 PROTO=UDP SPT=6376 DPT=2055 LEN=1472 Answer: There was already a conntrack entry for the failing connection before you added the rule. Install the conntrack utility program and use it to delete the entry. conntrack -D -s 172.19.41.2 -d 172.19.1.1 -p udp -sport 6367 -dport 2055
(FAQ 30) I'm confused about when to use DNAT rules and when to use ACCEPT rules. Answer: It would be a good idea to review the QuickStart Guide appropriate for your setup; the guides cover this topic in a tutorial fashion. DNAT rules should be used for connections that need to go the opposite direction from SNAT/MASQUERADE. So if you masquerade or use SNAT from your local network to the Internet then you will need to use DNAT rules to allow connections from the Internet to your local network. If you use both 1:1 NAT and SNAT/MASQUERADE, those connections that are subject to 1:1 NAT should use ACCEPT rather than DNAT. Note, however, that DNAT can be used to override 1:1 NAT so as to redirect a connection to a different internal system or port than would be the case using 1:1 NAT. You also want to use DNAT rules when you intentionally want to rewrite the destination IP address or port number. In all other cases, you use ACCEPT unless you need to hijack connections as they go through your firewall and handle them on the firewall box itself; in that case, you use a REDIRECT rule. The preceding answer should not be interpreted to mean that DNAT can only be used in conjunction with SNAT. But in common configurations using private local addresses, that is the most common usage.
(FAQ 8) I have several external IP addresses and use /etc/shorewall/nat to associate them with systems in my DMZ. When I add a DNAT rule, say for ports 80 and 443, Shorewall redirects connections on those ports for all of my addresses. How can I restrict DNAT to only a single address? Answer: Specify the external address that you want to redirect in the ORIGDEST column. Example: #ACTION SOURCE DEST PROTO DPORT SPORT ORIGDEST DNAT net net:192.168.4.22 tcp 80,443 - 206.124.146.178
(FAQ 38) Where can I find more information about DNAT? Answer: Ian Allen has written a Paper about DNAT and Linux.
(FAQ 48) How do I Set up a Transparent HTTP Proxy with Shorewall? Answer: See Shorewall_Squid_Usage.html.
DNS and Port Forwarding/NAT
(FAQ 2) I port forward www requests to www.mydomain.com (IP 130.151.100.69) to system 192.168.1.5 in my local network. External clients can browse http://www.mydomain.com but internal clients can't. Answer: I have two objections to this setup. Having an Internet-accessible server in your local network is like raising foxes in the corner of your hen house. If the server is compromised, there's nothing between that server and your other internal systems. For the cost of another NIC and a cross-over cable, you can put your server in a DMZ such that it is isolated from your local systems - assuming that the Server can be located near the Firewall, of course :-) The accessibility problem is best solved using Split DNS (either use a separate DNS server for local clients or use Bind Version 9 views on your main name server) such that www.mydomain.com resolves to 130.141.100.69 externally and 192.168.1.5 internally. I use a separate DNS server (dnsmasq) here at shorewall.net. So the best and most secure way to solve this problem is to move your Internet-accessible server(s) to a separate LAN segment with it's own interface to your firewall and follow FAQ 2b. That way, your local systems are still safe if your server gets hacked and you don't have to run a split DNS configuration (separate server or Bind 9 views). If physical limitations make it impractical to segregate your servers on a separate LAN, the next best solution it to use Split DNS. Before you complain "It's too hard to set up split DNS!", check here. If you really want to route traffic between two internal systems through your firewall, then proceed as described below. All traffic redirected through use of this technique will look to the server as if it originated on the firewall rather than on the original client! So the server's access logs will be useless for determining which local hosts are accessing the server. Assuming that your external interface is eth0 and your internal interface is eth1 and that eth1 has IP address 192.168.1.254 with subnet 192.168.1.0/24, then: In /etc/shorewall/interfaces: ?FORMAT 2 #ZONE INTERFACE OPTIONS loc eth1 routeback In /etc/shorewall/masq: #INTERFACE SOURCE ADDRESS PROTO PORT eth1:192.168.1.5 192.168.1.0/24 192.168.1.254 tcp www When running Shorewall 5.0.14 or later, the corresponding /etc/shorewall/snat file is: #ACTION SOURCE DEST PROTO PORT SNAT(192.168.1.254) 192.168.1.0/24 eth1:192.168.1.5 tcp www Note: The technique described here is known as hairpinning NAT and is described in section 6 of RFC 4787. In that RFC, it is required that the external IP address be used as the source: #INTERFACE SOURCE ADDRESS PROTO PORT eth1:192.168.1.5 192.168.1.0/24 130.151.100.69 tcp www Equivalent /etc/shorewall/snat: #ACTION SOURCE DEST PROTO PORT SNAT(130.151.100.69) 192.168.1.0/24 eth1:192.168.1.5 tcp www In /etc/shorewall/rules: #ACTION SOURCE DEST PROTO DPORT SPORT ORIGDEST ?SECTION ALL ?SECTION ESTABLISHED ?SECTION RELATED ?SECTION INVALID ?SECTION UNTRACKED ?SECTION NEW DNAT loc loc:192.168.1.5 tcp www - 130.151.100.69 That rule (and the second one in the previous bullet) only works of course if you have a static external IP address. If you have a dynamic IP address then include this in /etc/shorewall/params. ETH0_IP=$(find_first_interface_address eth0) and make your DNAT rule: #ACTION SOURCE DEST PROTO DPORT SPORT ORIGDEST ?SECTION ALL ?SECTION ESTABLISHED ?SECTION RELATED ?SECTION INVALID ?SECTION UNTRACKED ?SECTION NEW DNAT loc loc:192.168.1.5 tcp www - $ETH0_IP Using this technique, you will want to configure your DHCP/PPPoE/PPTP/… client to automatically restart Shorewall each time that you get a new IP address. If your local interface is a bridge, see FAQ 2e for additional configuration steps. For optional interfaces, use the function find_first_interface_address_if_any() rather than find_first_interface_address(). The former will return 0.0.0.0 if the interface has no configured IP address; the latter terminates the calling program. If you run Shorewall-lite on your firewall, you must use the following in the firewall's configuration directory params file: ETH0_IP=$(ssh root@firewall "/sbin/shorewall-lite call find_first_interface_address eth0")
(FAQ 2a) I have a zone <quote>Z</quote> with an RFC1918 subnet and I use one-to-one NAT to assign non-RFC1918 addresses to hosts in Z. Hosts in Z cannot communicate with each other using their external (non-RFC1918 addresses) so they can't access each other using their DNS names. If the ALL INTERFACES column in /etc/shorewall/nat is empty or contains Yes, you will also see log messages like the following when trying to access a host in Z from another host in Z using the destination host's public address: 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 Answer: This is another problem that is best solved using split DNS. It allows both external and internal clients to access a NATed host using the host's DNS name. Another good way to approach this problem is to switch from one-to-one NAT to Proxy ARP. That way, the hosts in Z have non-RFC1918 addresses and can be accessed externally and internally using the same address. If you don't like those solutions and prefer to route all Z->Z traffic through your firewall then: Set the routeback option on the interface to Z. Set the ALL INTERFACES column in the nat file to Yes. Example: Zone: dmz, Interface: eth2, Subnet: 192.168.2.0/24, Address of server 192.168.2.2 In /etc/shorewall/interfaces: ?FORMAT 2 #ZONE INTERFACE OPTIONS dmz eth2 routeback In /etc/shorewall/masq: #INTERFACE SOURCE eth2:192.168.1.2 192.168.2.0/24 When running Shorewall 5.0.14 or later, the equivalent /etc/shorewall/snat is: #ACTION SOURCE DEST PROTO PORT MASQUERADE 192.168.1.0/24 eth2:192.168.1.2 tcp www In /etc/shorewall/nat, be sure that you have Yes in the ALL INTERFACES column.
(FAQ 2b) I have a web server in my DMZ and I use port forwarding to make that server accessible from the Internet as www.mydomain.com. That works fine but when my local users try to connect to www.mydomain.com, it doesn't work. Answer: Let's assume the following: External IP address is 206.124.146.176 on eth0 (www.mydomain.com). Server's IP address is 192.168.2.4 You can enable access to the server from your local network using the firewall's external IP address by adding this rule: #ACTION SOURCE DEST PROTO DPORT SPORT ORIGDEST ?SECTION ALL ?SECTION ESTABLISHED ?SECTION RELATED ?SECTION INVALID ?SECTION UNTRACKED ?SECTION NEW DNAT loc dmz:192.168.2.4 tcp 80 - 206.124.146.176 If your external IP address is dynamic, then you must do the following: In /etc/shorewall/params: ETH0_IP=`find_first_interface_address eth0` and make your DNAT rule: #ACTION SOURCE DEST PROTO DPORT SPORT ORIGDEST ?SECTION ALL ?SECTION ESTABLISHED ?SECTION RELATED ?SECTION INVALID ?SECTION UNTRACKED ?SECTION NEW DNAT loc dmz:192.168.2.4 tcp 80 - $ETH0_IP With dynamic IP addresses, you probably don't want to use shorewall[-lite] save and shorewall[-lite] restore. For optional interfaces, use the function find_first_interface_address_if_any() rather than find_first_interface_address(). The former will return 0.0.0.0 if the interface has no configured IP address; the latter terminates the calling program. If you use Shorewall-lite, then you need to configure the params file in the firewall's configuration directory as described above.
(FAQ 2c) I tried to apply the answer to FAQ 2 to my external interface and the net zone and it didn't work. Why? Answer: Did you set IP_FORWARDING=On in shorewall.conf?
(FAQ 2d) Does Shorewall support hairpinning NAT? Answer: Yes. In the case of simple masquerade/SNAT, see FAQ 2. For one-to-one (static), NAT, simply place 'Yes' in the ALL INTERFACES column of each entry in /etc/shorewall/nat.
(FAQ 2e) I have the situation in FAQ 2 but my local interface is a bridge and the solution in FAQ 2 doesn't work Answer: Assume that the bridge is br0 and that eth2 is the bridge port that connects to the LAN containing 192.168.1.5 In addition to the steps in FAQ 2 (replacing eth1 with br0), you also need to: Set the hairpin option on eth2. brctl hairpin br0 eth2 on On Debian and derivitives, you can place that command in /etc/network/interfaces as a post-up command: auto br0 iface br0 inet static bridge_ports eth2 bridge_fd 0 bridge_maxwait 0 address 192.168.1.1 netmask 255.255.255.0 post-up /sbin/brctl hairpin br0 eth2 on Install ebtables if it is not already installed. Be sure that all traffic going out of eth2 has the correct MAC address. ebtables -t nat -A POSTROUTING -o eth2 -j snat --to-source br0-MAC-address where br0-MAC-address is the MAC address of br0. Here's a working example of /etc/shorewall/start that executes the above command. if [ $(ebtables -t nat -L POSTROUTING | wc -l) -lt 4 ]; then ebtables -t nat -A POSTROUTING -o eth2 -j snat --to-source 0:19:21:d0:61:65 fi
Blacklisting
(FAQ 63) I just blacklisted IP address 206.124.146.176 and I can still ping it. What did I do wrong? Answer: Nothing. Blacklisting an IP address blocks incoming traffic from that IP address. And if you set BLACKLISTNEWONLY=Yes in shorewall.conf, then only new connections from that address are disallowed; traffic from that address that is part of an established connection (such as ping replies) is allowed. Beginning with Shorewall 4.4.13, you can use the option in /etc/shorewall/interfaces to implement blacklisting by destination IP address. Beginning with Shorewall 4.4.26, you can use /etc/shorewall/blrules to implement arbitrary blacklist rules.
(FAQ 84) I put some IPs in the blacklist file in /etc/shorewall to block the ips but i'm still getting reports from PSAD from those ips saying they're port scanning. Shouldn't being on the blacklist drop all packets from those ips? Answer: You probably forgot to specify the blacklist option for your external interface(s) in /etc/shorewall/interfaces.
Netmeeting/MSN
(FAQ 3) I want to use Netmeeting or MSN Instant Messenger with Shorewall. What do I do? Answer: There is an H.323 connection tracking/NAT module that helps with Netmeeting. Look here for a solution for MSN IM but be aware that there are significant security risks involved with this solution. Also check the Netfilter mailing list archives at http://www.netfilter.org.
Open Ports
(FAQ 100) With Shorewall started, the output of 'iptables -L' looks like my firewall is wide open! Answer: The problem here is that a bare iptables -L command produces totally useless output. Use shorewall show instead. The shorewall show command is a wrapper around iptables -L -n -v.
(FAQ 51) How do I Open Ports in Shorewall? Answer: No one who has installed Shorewall using one of the Quick Start Guides should have to ask this question. Regardless of which guide you used, all outbound communication is open by default. So you do not need to 'open ports' for output. For input: If you installed using the Standalone Guide, then please re-read this section. If you installed using the Two-interface Guide, then please re-read these sections: Port Forwarding (DNAT), and Other Connections If you installed using the Three-interface Guide, then please re-read these sections: Port Forwarding (DNAT) and Other Connections If you installed using the Shorewall Setup Guide then you had better read the guide again -- you clearly missed a lot. Also please see the Port Forwarding section of this FAQ.
(FAQ 4) I just used an online port scanner to check my firewall and it shows some ports as <quote>closed</quote> rather than <quote>blocked</quote>. Why? Answer: The default Shorewall setup invokes the Drop action prior to enforcing a DROP policy and the default policy to all zones from the Internet is DROP. The Drop action is defined in /usr/share/shorewall/action.Drop which in turn invokes the Auth macro (defined in /usr/share/shorewall/macro.Auth) specifying the REJECT action (i.e., Auth(REJECT)). This is necessary to prevent outgoing connection problems to services that use the Auth mechanism for identifying requesting users. That is the only service which the default setup rejects. If you are seeing closed TCP ports other than 113 (auth) then either you have added rules to REJECT those ports or a router outside of your firewall is responding to connection requests on those ports. If you would prefer to 'stealth' port 113, then: If you are running Shorewall 4.4.20 or earlier, copy /usr/share/shorewall/action.Drop to /etc/shorewall/ and modify the invocation of Auth to Auth(DROP). If you are running Shorewall 4.4.21 or later, in shorewall.conf, set DROP_DEFAULT="Drop(-,DROP)". See the Action HOWTO to learn how that magic works.
(FAQ 4a) I just ran an nmap UDP scan of my firewall and it showed 100s of ports as open!!!! Answer: Take a deep breath and read the nmap manpage section about UDP scans. If nmap gets nothing back from your firewall then it reports the port as open. If you want to see which UDP ports are really open, temporarily change your net->all policy to REJECT, restart Shorewall and run the nmap UDP scan again.
(FAQ 4b) I have a port that I can't close no matter how I change my rules. I had a rule that allowed telnet from my local network to my firewall; I removed that rule and restarted Shorewall but my telnet session still works!!! Answer: Rules only govern the establishment of new connections. Once a connection is established through the firewall it will be usable until disconnected (tcp) or until it times out (other protocols). If you stop telnet and try to establish a new session your firewall will block that attempt.
(FAQ 4c) How do I use Shorewall with PortSentry? Answer: Here's a writeup describing a nice integration of Shorewall and PortSentry.
Connection Problems
Why are these packets being Dropped/Rejected? How do I decode Shorewall log messages? Please see FAQ 17.
(FAQ 5) I've installed Shorewall and now I can't ping through the firewall Answer: For a complete description of Shorewall ping management, see this page.
(FAQ 15) My local systems can't see out to the net Answer: Every time I read systems can't see out to the net, I wonder where the poster bought computers with eyes and what those computers will see when things are working properly :-). That aside, the most common causes of this problem are: The default gateway on each local system isn't set to the IP address of the local firewall interface. You can test this by: At a root shell prompt, type 'shorewall clear'. From a local system, attempt to ping the IP address of the Shorewall system's internet (external) interface. If that doesn't work, then the default gateway on the system from which you pinged is not set correctly. Be sure to 'shorewall start' after the test. The entry for the local network in the /etc/shorewall/masq file is wrong or missing. The DNS settings on the local systems are wrong or the user is running a DNS server on the firewall and hasn't enabled UDP and TCP port 53 from the local net to the firewall or from the firewall to the Internet. Forwarding is not enabled (This is often the problem for Debian users). Enter this command: cat /proc/sys/net/ipv4/ip_forward If the value displayed is 0 (zero) then set IP_FORWARDING=On in /etc/shorewall/shorewall.conf and restart Shorewall.
(FAQ 29) FTP Doesn't Work Answer: See the Shorewall and FTP page.
(FAQ 33) From clients behind the firewall, connections to some sites fail. Connections to the same sites from the firewall itself work fine. What's wrong? Answer: Most likely, you need to set CLAMPMSS=Yes in /etc/shorewall/shorewall.conf.
(FAQ 35) I have two Ethernet interfaces to my local network which I have bridged. When Shorewall is started, I'm unable to pass traffic through the bridge. I have defined the bridge interface (br0) as the local interface in <filename>/etc/shorewall/interfaces</filename>; the bridged Ethernet interfaces are not defined to Shorewall. How do I tell Shorewall to allow traffic through the bridge? Answer: Add the option to br0 in /etc/shorewall/interfaces. For more information on this type of configuration, see the Shorewall Simple Bridge documentation.
(FAQ 64) I just upgraded my kernel to 2.6.20 (or later) and my bridge/firewall stopped working. What is wrong? Answer: In kernel 2.6.20, the Netfilter physdev match feature was changed such that it is no longer capable of matching the output device of non-bridged traffic. You will see messages such as the following in your log: Apr 20 15:03:50 wookie kernel: [14736.560947] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore. This kernel change, while necessary, means that Shorewall zones may no longer be defined in terms of bridge ports. See the Shorewall-perl bridging documentation for information about how to configure bridge/firewalls. Following the instructions in the new bridging documentation will not prevent the above message from being issued.
(FAQ 85) Shorewall is rejecting connections from my local lan because it thinks they are coming from the 'net' zone. I'm seeing this in my log: Aug 31 16:51:24 fw22 kernel: Shorewall:net2fw:DROP:IN=eth5 OUT= MAC=00:0c:29:74:9c:0c:08:00:20:b2:5f:db:08:00 SRC=10.1.50.14 DST=10.1.50.7 LEN=57 TOS=0x00 PREC=0x00 TTL=255 ID=32302 DF PROTO=UDP SPT=53289 DPT=53 LEN=37 Answer: This occurs when the external interface and an internal interface are connected to the same switch or hub. See this article for details. The solution is to never connect more than one firewall interface to the same hub or switch (an obvious exception is that when you have a switch that supports VLAN tagging and the interfaces are associated with different VLANs).
Logging
(FAQ 91) I changed the shorewall.conf file in /etc/shorewall/ to spit out logs to /var/log/shorewall.log and it's not happening after I restart shorewall. LOGFILE=/var/log/shorewall.log <-- that should be the correct line, right? Answer: No, that is not correct. The LOGFILE setting tells Shorewall where to find the log; it does not determine where messages are written. See the next FAQ.
(FAQ 6) Where are the log messages written and how do I change the destination? Answer: NetFilter uses the kernel's equivalent of syslog (see man syslog) to log messages. It always uses the LOG_KERN (kern) facility (see man openlog) and you get to choose the log level (again, see man syslog) in your policies and rules. The destination for messages logged by syslog is controlled by /etc/syslog.conf (see man syslog.conf). When you have changed /etc/syslog.conf, be sure to restart syslogd (on a RedHat system, service syslog restart). It is also possible to set up Shorewall to log all of Netfilter's messages to a separate file.
(FAQ 6a) Are there any log parsers that work with Shorewall? Answer: Here are several links that may be helpful: http://www.shorewall.net/pub/shorewall/parsefw/ http://aaron.marasco.com/linux.html http://cert.uni-stuttgart.de/projects/fwlogwatch http://www.logwatch.org I personally use fwlogwatch. It emails me a report each day from my various systems with each report summarizing the logged activity on the corresponding system; here's a sample:
fwlogwatch summary Generated Tuesday March 02 08:14:37 PST 2010 by root. 362 (and 455 older than 86400 seconds) of 817 entries in the file "/var/log/ulog/syslogemu.log" are packet logs, 138 have unique characteristics. First packet log entry: Mar 01 08:16:06, last: Mar 02 08:06:21. All entries were logged by the same host: "gateway". All entries have the same target: "-". Only entries with a count of at least 5 are shown. net-dmz DROP eth2 36 packets from 61.158.162.9 to 206.124.146.177 net-fw DROP eth0 21 packets from 89.163.162.13 to 76.104.233.98 net-fw DROP eth0 19 packets from 61.184.101.46 to 76.104.233.98 net-fw DROP eth0 12 packets from 81.157.214.103 to 76.104.233.98 net-fw DROP eth0 11 packets from 174.37.159.222 to 76.104.233.98 net-fw DROP eth0 10 packets from 221.195.73.86 to 76.104.233.98 net-dmz DROP eth2 9 packets from 202.199.158.6 to 206.124.146.177 net-fw DROP eth2 9 packets from 202.199.158.6 to 206.124.146.176 net-dmz DROP eth2 9 packets from 202.199.158.6 to 206.124.146.178 net-fw DROP eth0 6 packets from 221.192.199.35 to 76.104.233.98 net-fw DROP eth2 5 packets from 61.158.162.9 to 206.124.146.177
Fwlogwatch contains a built-in web server that allows monitoring recent activity in summary fashion.
(FAQ 6b) DROP messages on port 10619 are flooding the logs with their connect requests. Can I exclude these error messages for this port temporarily from logging in Shorewall? Answer: Temporarily add the following rule: #ACTION SOURCE DEST PROTO DPORT ?SECTION ALL ?SECTION ESTABLISHED ?SECTION RELATED ?SECTION INVALID ?SECTION UNTRACKED ?SECTION NEW DROP net $FW udp 10619 Alternatively, if you do not set BLACKLIST_LOGLEVEL you can blacklist the port. In /etc/shorewall/blrules: #ACTION SOURCE DEST PROTO DPORT DROP net $FW udp 10619
(FAQ 6d) Why is the MAC address in Shorewall log messages so long? I thought MAC addresses were only 6 bytes in length. Answer: What is labeled as the MAC address in a Netfilter (Shorewall) log message is actually the Ethernet frame header. It contains: the destination MAC address (6 bytes) the source MAC address (6 bytes) the Ethernet frame type (2 bytes) Example MAC=00:04:4c:dc:e2:28:00:b0:8e:cf:3c:4c:08:00 Destination MAC address = 00:04:4c:dc:e2:28 Source MAC address = 00:b0:8e:cf:3c:4c Ethernet Frame Type = 08:00 (IP Version 4)
(FAQ 16) Shorewall is writing log messages all over my console making it unusable! Answer: Just to be clear, it is not Shorewall that is writing all over your console. Shorewall issues a single log message during each start, restart, stop, etc. It is rather your logging daemon that is writing messages to your console. Shorewall itself has no control over where a particular class of messages are written. See the Shorewall logging documentation. The max log level to be sent to the console is available in /proc/sys/kernel/printk:teastep@ursa:~$ cat /proc/sys/kernel/printk 6 6 1 7 teastep@ursa:~$ The first number determines the maximum log level (syslog priority) sent to the console. Messages with priority less than this number are sent to the console. On the system shown in the example above, priorities 0-5 are sent to the console. Since Shorewall defaults to using 'info' (6), the Shorewall-generated Netfilter rule set will generate log messages that will not appear on the console. The second number is the default log level for kernel printk() calls that do not specify a log level. The third number specifies the minimum console log level while the fourth gives the default console log level. If, on your system, the first number is 7 or greater, then the default Shorewall configurations will cause messages to be written to your console. The simplest solution is to add this to your /etc/sysctl.conf file:kernel.printk = 4 4 1 7 thensysctl -p /etc/sysctl.conf
(FAQ 16a) cat /proc/sys/kernel/prink returns '4 4 1 7' and still I get dmesg filled up Answer: While we would argue that 'dmesg filled up' is not necessarily a problem, the only way to eliminate that is to set up Shorewall to log all of Netfilter's messages to a separate file.
(FAQ 16b) Why can't I see any Shorewall messages in /var/log/messages? Some people who ask this question report that the only Shorewall messages that they see in /var/log/messages are 'started', 'restarted' and 'stopped' messages. Answer: First of all, it is important to understand that Shorewall itself does not control where Netfilter log messages are written. The LOGFILE setting in shorewall.conf simply tells the /sbin/shorewall[-lite] program where to look for the log. Also, it is important to understand that a log level of "debug" will generally cause Netfilter messages to be written to fewer files in /var/log than a log level of "info". The log level does not control the number of log messages or the content of the messages. The actual log file where Netfilter messages are written is not standardized and will vary by distribution and distribution version. But anytime you see no logging, it's time to look outside the Shorewall configuration for the cause. As an example, recent SUSE releases use syslog-ng by default and write Shorewall messages to /var/log/firewall. Please see the Shorewall logging documentation for further information.
(FAQ 16c) Shorewall messages are flooding the output of 'dmesg'; how to I stop that? Answer: Switch to using ulogd.
(FAQ 16d) I set LOGFILE=/var/log/shorewall but log messages are still going to /var/log/messages. Answer: See the answer to FAQ 16b above.
(FAQ 17) Why are these packets being Dropped/Rejected? How do I decode Shorewall log messages? Answer: Logging of dropped/rejected packets occurs out of a number of chains (as indicated in the log message) in Shorewall: zone2all, zone-all, all2zone, all-zone, all2all or all-all You have a policy that specifies a log level and this packet is being logged under that policy. If you intend to ACCEPT this traffic then you need a rule to that effect. Packets logged out of these chains may have a source and/or destination that is not in any defined zone (see the output of shorewall[-lite] show zones). Remember that zone membership involves both a firewall interface and an ip address. zone12zone2 or zone1-zone2 Either you have a policy for zone1 to zone2 that specifies a log level and this packet is being logged under that policy or this packet matches a rule that includes a log level. @zone12zone2 or @zone1-zone2 You have a policy for traffic from zone1 to zone2 that specifies TCP connection rate limiting (value in the LIMIT column). The logged packet exceeds that limit and was dropped. Note that these log messages themselves are severely rate-limited so that a syn-flood won't generate a secondary DOS because of excessive log message. These log messages were added in Shorewall 2.2.0 Beta 7. zone12zone2~, zone1-zone2~ or ~blacklistnn These are the result of entries in the /etc/shorewall/blrules file. interface_mac or interface_rec The packet is being logged under the maclist interface option. blacklist The packet is being logged because the source IP is blacklisted in the /etc/shorewall/blacklist file. INPUT or FORWARD The packet has a source IP address that isn't in any of your defined zones (shorewall[-lite] show zones and look at the printed zone definitions) or the chain is FORWARD and the destination IP isn't in any of your defined zones. If the chain is FORWARD and the IN and OUT interfaces are the same or they match the same wildcard entry in /etc/shorewall/interfaces, then you probably need the routeback option on that interface in /etc/shorewall/interfaces , you need the routeback option in the relevant entry in /etc/shorewall/hosts or you've done something silly like define a default route out of an internal interface. With OPTIMIZE=1 in shorewall.conf, such packets may also be logged out of a <zone>2all chain or the all2all chain. OUTPUT The packet has a destination IP address that isn't in any of your defined zones(shorewall[-lite] show zones and look at the printed zone definitions). With OPTIMIZE=1 in shorewall.conf, such packets may also be logged out of the fw2all chain or the all2all chain. logflags The packet is being logged because it failed the checks implemented by the tcpflags interface option. sfilter On systems running Shorewall 4.4.20 or later, either the packet matched the interface option or it is being routed out of the same interface on which it arrived and the interface does not have the or interface option. Here is an example: 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 Let's look at the important parts of this message: all2all:REJECT This packet was REJECTed out of the all2all chain -- the packet was rejected under the all->all REJECT policy (all2all above). IN=eth2 the packet entered the firewall via eth2. If you see IN= with no interface name, the packet originated on the firewall itself. OUT=eth1 if accepted, the packet would be sent on eth1. If you see OUT= with no interface name, the packet would be processed by the firewall itself. When a DNAT rule is logged, there will never be an OUT= shown because the packet is being logged before it is routed. Also, DNAT logging will show the original destination IP address and destination port number. When a REDIRECT rule is logged, the message will also show the original destination IP address and port number. SRC=192.168.2.2 the packet was sent by 192.168.2.2 DST=192.168.1.3 the packet is destined for 192.168.1.3 PROTO=UDP UDP Protocol DPT=53 The destination port is 53 (DNS) In this case, 192.168.2.2 was in the dmz zone and 192.168.1.3 is in the loc zone. I was missing the rule: ACCEPT dmz loc udp 53
(FAQ 21) I see these strange log entries occasionally; what are they? 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 is external on my firewall... 172.16.0.0/24 is my internal LAN Answer: First of all, please note that the above is a very specific type of log message dealing with ICMP port unreachable packets (PROTO=ICMP TYPE=3 CODE=3). Do not read this answer and assume that all Shorewall log messages have something to do with ICMP (hint -- see FAQ 17). While most people associate the Internet Control Message Protocol (ICMP) with ping, ICMP is a key piece of IP. ICMP is used to report problems back to the sender of a packet; this is what is happening here. Unfortunately, where NAT is involved (including SNAT, DNAT and Masquerade), there are many broken implementations. That is what you are seeing with these messages. When Netfilter displays these messages, the part before the "[" describes the ICMP packet and the part between the "[" and "]" describes the packet for which the ICMP is a response. Here is my interpretation of what is happening -- to confirm this analysis, one would have to have packet sniffers placed a both ends of the connection. Host 172.16.1.10 behind NAT gateway 206.124.146.179 sent a UDP DNS query to 192.0.2.3 and your DNS server tried to send a response (the response information is in the brackets -- note source port 53 which marks this as a DNS reply). When the response was returned to to 206.124.146.179, it rewrote the destination IP TO 172.16.1.10 and forwarded the packet to 172.16.1.10 who no longer had a connection on UDP port 2857. This causes a port unreachable (type 3, code 3) to be generated back to 192.0.2.3. As this packet is sent back through 206.124.146.179, that box correctly changes the source address in the packet to 206.124.146.179 but doesn't reset the DST IP in the original DNS response similarly. When the ICMP reaches your firewall (192.0.2.3), your firewall has no record of having sent a DNS reply to 172.16.1.10 so this ICMP doesn't appear to be related to anything that was sent. The final result is that the packet gets logged and dropped in the all2all chain.
(FAQ 52) When I blacklist an IP address with "shorewall[-lite] drop www.xxx.yyy.zzz", why does my log still show REDIRECT and DNAT entries from that address? I blacklisted the address 130.252.100.59 using shorewall drop 130.252.100.59 but I am still seeing these log messages: 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 Answer: Please refer to the Shorewall Netfilter Documentation. Logging of REDIRECT and DNAT rules occurs in the nat table's PREROUTING chain where the original destination IP address is still available. Blacklisting occurs out of the filter table's INPUT and FORWARD chains which aren't traversed until later.
(FAQ 81) logdrop and logreject don't log. I love the ability to type 'shorewall logdrop ww.xx.yy.zz' and completely block a particular IP address. However, the log part doesn't happen. When I look in the logdrop chain, there is no LOG prefix. Answer: You haven't set a value for BLACKLIST_LOGLEVEL in shorewall.conf (5).
(FAQ 36) My log is filling up with these BANDWIDTH messages! Dec 15 16:47:30 heath-desktop kernel: [17182740.184000] BANDWIDTH_IN:IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:01:5c:23:79:02:08:00 SRC=10.119.248.1 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=64 ID=62081 PROTO=UDP SPT=67 DPT=68 LEN=308 Dec 15 16:47:30 heath-desktop last message repeated 2 times Dec 15 16:47:30 heath-desktop kernel: [17182740.188000] BANDWIDTH_IN:IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:01:5c:23:79:02:08:00 SRC=10.112.70.1 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=64 ID=62082 PROTO=UDP SPT=67 DPT=68 LEN=308 Dec 15 16:47:30 heath-desktop last message repeated 2 times Answer: The Webmin 'bandwidth' module adds commands to /etc/shorewall/start that creates rules to log every packet to/from/through the firewall. DON'T START THE BANDWIDTH SERVICE IN WEBMIN! To correct this situation once it occurs, edit /etc/shorewall/start and insert 'return 0' prior to the BANDWIDTH rules.
Routing
(FAQ 32) My firewall has two connections to the Internet from two different ISPs. How do I set this up in Shorewall? Answer: See this article about Shorewall and Multiple ISPs.
(FAQ 49) When I start Shorewall, my routing table gets blown away. Why does Shorewall do that? Answer: This is usually the consequence of a one-to-one nat configuration blunder: Specifying the primary IP address for an interface in the EXTERNAL column of /etc/shorewall/nat even though the documentation (and the comments in the file) warn you not to do that. Specifying ADD_IP_ALIASES=Yes and RETAIN_ALIASES=No in /etc/shorewall/shorewall.conf. This combination causes Shorewall to delete the primary IP address from the network interface specified in the INTERFACE column which usually causes all routes out of that interface to be deleted. The solution is to not specify the primary IP address of an interface in the EXTERNAL column.
Starting and Stopping
(FAQ 94) After I start Shorewall, ps doesn't show any shorewall process running. What is the Shorewall daemon called? Answer: Shorewall is not a daemon. It is a configuration tool that configures your kernel based on the contents of /etc/shorewall/. Once the start command completes, Shorewall has done its job and there are no Shorewall processes remaining in the system.
(FAQ 7) When I stop Shorewall using <quote>shorewall[-lite] stop</quote>, I can't connect to anything. Why doesn't that command work? Answer: The stop command places the firewall in a safe state; connections that are allowed are governed by the setting of ADMINISABSENTMINDED in shorewall.conf (5) and the contents of shorewall-stoppedrules (5). To totally open the firewall, use the clear command.
(FAQ 9) Why can't Shorewall detect my interfaces properly at startup? I just installed Shorewall and when I issue the start command, I see the following: 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... ... Why can't Shorewall detect my interfaces properly? Answer: The above output is perfectly normal. The Net zone is defined as all hosts that are connected through eth0 and the local zone is defined as all hosts connected through eth1. You can set the routefilter option on an internal interface if you wish to guard against 'Martians' (a Martian is a packet with a source IP address that is not routed out of the interface on which the packet was received). If you do that, it is a good idea to also set the logmartians option.
(FAQ 22) I have some iptables commands that I want to run when Shorewall starts. Which file do I put them in? Answer:You can place these commands in one of the Shorewall Extension Scripts. Be sure that you look at the contents of the chain(s) that you will be modifying with your commands so that the commands will do what is intended. Many iptables commands published in HOWTOs and other instructional material use the -A command which adds the rules to the end of the chain. Most chains that Shorewall constructs end with an unconditional DROP, ACCEPT or REJECT rule and any rules that you add after that will be ignored. Check man iptables and look at the -I (--insert) command.
(FAQ 43) I just installed the Shorewall RPM and Shorewall doesn't start at boot time. Answer: When you install using the "rpm -U" command, Shorewall doesn't run your distribution's tool for configuring Shorewall startup. You will need to run that tool (insserv, chkconfig, run-level editor, …) to configure Shorewall to start in the the default run-levels of your firewall system.
(FAQ 59) After I start Shorewall, there are lots of unused Netfilter modules loaded. How do I avoid that? Answer: Copy /usr/share/shorewall[-lite]/modules to /etc/shorewall/modules and modify the copy to include only the modules that you need. An alternative is to set LOAD_HELPERS_ONLY=Yes in shorewall.conf (5).
(FAQ 68) I have a VM under an OpenVZ system. I can't get rid of the following message: ERROR: Command "/sbin/iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT" failed. Answer: See the Shorewall OpenVZ article.
(FAQ 73) When I stop Shorewall, the firewall is wide open. Isn't that a security risk? It is important to understand that the scripts in /etc/init.d are generally provided by your distribution and not by the Shorewall developers. These scripts must meet the requirements of the distribution's packaging system which may conflict with the requirements of a tight firewall. So when you say "…when I stop Shorewall…" it is necessary to distinguish between the commands /sbin/shorewall stop and /etc/init.d/shorewall stop. /sbin/shorewall stop places the firewall in a safe state, the details of which depend on your /etc/shorewall/stoppedrules file (shorewall-stoppedrules(5)) and on the setting of ADMINISABSENTMINDED in /etc/shorewall/shorewall.conf (shorewall.conf(5)). /etc/init.d/shorewall stop may or may not do the same thing. In the case of Debian systems for example, that command actually executes /sbin/shorewall clear which opens the firewall completely. In other words, in the init script, stop reverses the effect of start. Beginning with Shorewall 4.4, when the Shorewall tarballs are installed on a Debian (or derivative) system, the /etc/init.d/shorewall file is the same as would be installed by the .deb. The behavior of /etc/init.d/shorewall stop is controlled by the setting of SAFESTOP in /etc/default/shorewall. When set to 0 (the default), the firewall is cleared; when set to 1, the firewall is placed in a safe state.
(FAQ 78) After restart and bootup of my Debian firewall, all traffic is blocked for hosts behind the firewall trying to connect out onto the net or through the vpn (although i can reach the internal firewall interface and obtain dumps etc). Once I issue 'shorewall clear' followed by 'shorewall start' it then works, despite the config not changing Answer: Set IP_FORWARDING=On in /etc/shorewall/shorewall.conf.
(FAQ 86) My distribution (Ubuntu) uses NetworkManager to manage my interfaces. I want to specify the upnpclient option for my interfaces which requires them to be up and configured when Shorewall starts but Shorewall is being started before NetworkManager. Answer: I faced a similar problem which I solved as follows: Don't start Shorewall at boot time (Debian and Ubuntu users may simply set startup=0 in /etc/default/shorewall). In /etc/network/ip-up.d, I added a shorewall script as follows: #!/bin/sh shorewall status > /dev/null 2>&1 || shorewall start # Start Shorewall if it isn't already running Be sure to secure the script for execute access. Update: Beginning with Shorewall 4.4.10, there is a new Shorewall Init Package that is designed to handle this case.
(FAQ 90) Shorewall starts fine but after several minutes, it stops. Why is it doing that? Answer: Shorewall uses the presence of a chain named shorewall to indicate whether is started or stopped. That chain is created during execution of a successful start, restart or restore command and is removed during stop and clear. If shorewall status indicates that Shorewall is stopped, then something has deleted that chain. Look at the output of shorewall status; if it looks like this:
gateway:~# shorewall status Shorewall-4.4.11 Status at gateway - Wed Jul 21 13:21:41 PDT 2010 Shorewall is stopped State:Started (Tue Jul 20 16:01:49 PDT 2010) gateway:~#
then it means that something outside of Shorewall has deleted the chain. This usually means that you were running another firewall package before you installed Shorewall and that other package has replaced Shorewall's Netfilter configuration with its own. You must remove (or at least disable) the other firewall package and restart Shorewall.
gateway:~# shorewall status Shorewall-4.4.11 Status at gateway - Wed Jul 21 13:26:29 PDT 2010 Shorewall is stopped State:Stopped (Wed Jul 21 13:26:26 PDT 2010) gateway:~#
then a shorewall stop command has been executed (if the State shown in the output is Cleared, then a shorewall clear command was executed). Most likely, you have installed and configured the shorewall-init package and a required interface has gone down.
(FAQ 99) My /var/lib/shorewall-init.log shows that Shorewall is running at boot but after boot 'iptables -L' shows an empty configuration Answer: This is caused by your failure to disable your distributions default iptables configuration tool when you installed Shorewall. Look for a service called 'iptables' that is being started after Shorewall and disable it.
(FAQ 101) How can I speed up 'shorewall start' and 'shorewall restart' on my slow hardware? Answer: There are several steps that you can take: If your kernel supports module autoloading (and distribution default kernels almost always do), then set LOAD_HELPERS_ONLY=Yes in shorewall.conf. Set AUTOMAKE=Yes in shorewall.conf. This will avoid the compilation phase in cases where the configuration has not changed since the last time that the configuration was compiled. Don't set optimization option 8. For example, if you currently set OPTIMIZE=31, then change that to OPTIMIZE=23. Optimization option 8 combines identical chains which can result in a smaller ruleset, but it slows down the compilation of large rulesets.
(FAQ 103) Shorewall fails to start at boot but will start immediately after Answer: This is usually associated with SELinux. Here is an example.
(FAQ 104) I see <emphasis>kernel</emphasis> messages in my log when I start or restart Shorewall or Shorewall6 Example: > Oct 1 13:04:39 deb kernel: [ 9570.619744] xt_addrtype: ipv6 does not support BROADCAST matching Answer: These are harmless. Shorewall attempts to execute various commands to determine the capabiities of your system. If you system doesn't support a command, it will generally issue a kernel log message.
Multiple ISPs
(FAQ 57) I configured two ISPs in Shorewall but when I try to use the second one, it doesn't work. Answer: The Multi-ISP Documentation strongly recommends that you use the balance option on all providers even if you want to manually specify which ISP to use. If you don't do that so that your main routing table only has one default route, then you must disable route filtering. Do not specify the routefilter option on the other interface(s) in /etc/shorewall/interfaces and disable any IP Address Spoofing protection that your distribution supplies.
(FAQ 58) But if I specify 'balance' then won't Shorewall balance the traffic between the interfaces? I don't want that! Answer: Suppose that you want all traffic to go out through ISP1 (mark 1) unless you specify otherwise. Then simply add these two rules as the first marking rules in your /etc/shorewall/mangle (was tcrules) file: #ACTION SOURCE DEST MARK(1):P 0.0.0.0/0 MARK(1) $FW other MARK rules Now any traffic that isn't marked by one of your other MARK rules will have mark = 1 and will be sent via ISP1. That will work whether balance is specified or not!
Using DNS Names
(FAQ 79) Can I use DNS names in Shorewall configuration file entries in place of IP addresses? Answer: Yes, but we advise strongly against it.
Traffic Shaping
(FAQ 67) I just configured Shorewall's builtin traffic shaping and now Shorewall fails to Start. The error I receive is as follows:RTNETLINK answers: No such file or directory We have an error talking to the kernel ERROR: Command "tc filter add dev eth2 parent ffff: protocol ip prio 50 u32 match ip src 0.0.0.0/0 police rate 500kbit burst 10k drop flowid :1" FailedAnswer: This message indicates that your kernel doesn't have 'traffic policing' support. If your kernel is modularized, you may be able to resolve the problem by loading the act_police kernel module. Other kernel modules that you will need include: cls_basic cls_fw cls_u32 sch_htb sch_ingress sch_sfq
(FAQ 97) I enable Shorewall traffic shaping and now my upload rate is way below what I specified Answer: This is likely due to TCP Segmentation Offload (TSO) and/or Generic Segmentation Offload (GSO) being enabled in the network adapter. To verify, install the ethtool package and use the -k command: root@gateway:~# ethtool -k eth1 Offload parameters for eth1: rx-checksumming: on tx-checksumming: on scatter-gather: on tcp-segmentation-offload: on udp-fragmentation-offload: off generic-segmentation-offload: on generic-receive-offload: off large-receive-offload: off ntuple-filters: off receive-hashing: off root@gateway:~# If that is the case, you can correct the problem by adjusting the minburst setting in /etc/shorewall/tcinterfaces (simple traffic shaping) or /etc/shorewall/tcdevices (complex traffic shaping). We suggest starting at 10-12kb and adjust as necessary. Example (simple traffic shaping): #INTERFACE TYPE IN_BANDWIDTH OUT_BANDWIDTH eth0 External 50mbit:200kb 5.0mbit:100kb:200ms:100mbit:10kb Alternatively, you can turn off TSO and GSO using this command in /etc/shorewall/init: ethtool -K ethN tso off gso off
(FAQ 97a) I enable Shorewall traffic shaping and now my download rate is way below what I specified Answer: This is likely due to Generic Receive Offload (GRO) being enabled in the network adapter. To verify, install the ethtool package and use the -k command: root@gateway:/etc/shorewall# ethtool -k eth1 Offload parameters for eth1: rx-checksumming: on tx-checksumming: on scatter-gather: on tcp-segmentation-offload: on udp-fragmentation-offload: off generic-segmentation-offload: on generic-receive-offload: on large-receive-offload: off ntuple-filters: off receive-hashing: off root@gateway:/etc/shorewall# To work around the issue, use this command: ethtool -K ethN gro off Beginning with Shorewall 4.4.25, another option is available in the form of a rate-estimated policing filter. Example from /etc/shorewall/tcdevices: #INTERFACE IN_BANDWITH OUT_BANDWIDTH OPTIONS 1:COMB_IF ~20mbit:250ms:4sec ${UPLOAD}kbit hfsc,linklayer=ethernet,overhead=0 To create a rate-estimated filter, precede the bandwidth with a tilde ("~"). The optional interval and decay_interval determine how often the rate is estimated and how many samples are retained for estimating. Please see http://ace-host.stuart.id.au/russell/files/tc/doc/estimators.txt for details.
About Shorewall
(FAQ 10) What Distributions does Shorewall work with? Answer: Shorewall works with any GNU/Linux distribution that includes the proper prerequisites.
(FAQ 11) What Features does Shorewall have? Answer: See the Shorewall Feature List.
(FAQ 12) Is there a GUI? Answer: Yes! Shorewall support is available in Webmin. See http://www.webmin.com. But beware of the issue described in FAQ 36.
(FAQ 13) Why do you call it <quote>Shorewall</quote>? Answer: Shorewall is a concatenation of Shoreline (the city where I live) and Firewall . The full name of the product is actually Shoreline Firewall but Shorewall is much more commonly used.
(FAQ 23) Why do you use such ugly fonts on your web site? Answer: The Shorewall web site is almost font neutral (it doesn't explicitly specify fonts except on a few pages) so the fonts you see are largely the default fonts configured in your browser. If you don't like them then reconfigure your browser.
(FAQ 25) How do I tell which version of Shorewall or Shorewall Lite I am running? Answer: At the shell prompt, type: /sbin/shorewall[-lite] version -a
(FAQ 25a) It says 4.4.7.5; how do I know if it is Shorewall-shell or Shorewall-perl? Answer: It is Shorewall-perl. Shorewall-shell is discontinued in Shorewall 4.4.
(FAQ 31) Does Shorewall provide protection against.... IP Spoofing: Sending packets over the WAN interface using an internal LAP IP address as the source address? Answer: Yes. Tear Drop: Sending packets that contain overlapping fragments? Answer: This is the responsibility of the IP stack, not the Netfilter-based firewall since fragment reassembly occurs before the stateful packet filter ever touches each packet. Smurf and Fraggle: Sending packets that use the WAN or LAN broadcast address as the source address? Answer: Shorwall filters these packets under the nosmurfs interface option in /etc/shorewall/interfaces. Land Attack: Sending packets that use the same address as the source and destination address? Answer: Yes, if the routefilter interface option is selected. DOS: - SYN Dos - ICMP Dos - Per-host Dos protection Answer: Yes.
(FAQ 65) How do I accomplish failover with Shorewall? Answer: This article by Paul Gear should help you get started.
Alias IP Addresses/Virtual Interfaces
(FAQ 18) Is there any way to use aliased ip addresses with Shorewall, and maintain separate rule sets for different IPs? Answer: Yes. See Shorewall and Aliased Interfaces.
(FAQ 83) Is there no way to nest the firewall zone or create subzones? I've got a system with Linux-VServers, it's one interface (eth0) with multiple IPs Answer: Beginning with Shorewall 4.4.11 Beta 2, you can create vserver zones that are nested within the firewall zone. Prior to 4.4.11 Beta 2, there is no way to create sub-zones of the firewall zone. But you can use shell variables to make vservers easier to deal with. /etc/shorewall/params: VS1=fw:192.168.2.12 VS2=fw:192.168.2.13 VS3=fw:192.168.2.14 /etc/shorewall/rules: #ACTION SOURCE DEST PROTO DPORT ?SECTION ALL ?SECTION ESTABLISHED ?SECTION RELATED ?SECTION INVALID ?SECTION UNTRACKED ?SECTION NEW ACCEPT $VS1 net tcp 25 DNAT net $VS1 tcp 25 etc...
Shorewall Lite
(FAQ 53) What is Shorewall Lite? Answer: Shorewall Lite is a companion product to Shorewall and is designed to allow you to maintain all Shorewall configuration information on a single system within your network. See the Compiled Firewall script documentation for details.
(FAQ 54) If I want to use Shorewall Lite, do I also need to install Shorewall on the same system? Answer: No. In fact, we recommend that you do NOT install Shorewall on systems where you wish to use Shorewall Lite. You must have Shorewall installed on at least one system within your network in order to use Shorewall Lite.
(FAQ 55) How do I decide which product to use - Shorewall or Shorewall Lite? Answer: If you plan to have only a single firewall system, then Shorewall is the logical choice. I also think that Shorewall is the appropriate choice for laptop systems that may need to have their firewall configuration changed while on the road. In the remaining cases, Shorewall Lite will work very well. At shorewall.net, the two laptop systems have the full Shorewall product installed as does my personal Linux desktop system. All other Linux systems that run a firewall use Shorewall Lite and have their configuration directories on my desktop system.
(FAQ 60) What are the compatibility restrictions between Shorewall and Shorewall Lite Answer: There are no compatibility constraints between Shorewall and Shorewall-lite.
VOIP
(FAQ 77) Shorewall is eating my Asterisk egress traffic! Somehow, my firewall config is causing a one-way audio problem in Asterisk. If a person calls into the PBX, they cannot hear me speaking, but I can hear them. If I plug the Asterisk server directly into the router, bypassing the firewall, the problem goes away. Answer: There are two things to try when VOIP problems are encountered. Both begin with executing two rmmod commands. If your kernel version is 2.6.20 or earlier:rmmod ip_nat_sip rmmod ip_conntrack_sipIf your kernel version is 2.6.21 or later:rmmod nf_nat_sip rmmod nf_conntrack_sip The first alternative seems to work for those running recent kernels (2.6.26 or later): Copy /usr/share/shorewall/modules to /etc/shorewall (/usr/share/shorewall/helpers if you have LOAD_HELPERS_ONLY in shorewall.conf). Edit the copy and change this line:
loadmodule nf_conntrack_sip
to
loadmodule nf_conntrack_sip sip_direct_media=0
shorewall restart The second alternative is to not load the sip helpers: If you are running kernel 2.6.20 or earlier, then change the DONT_LOAD specification in your shorewall.conf to:DONT_LOAD=ip_nat_sip,ip_conntrack_sip If you are running kernel 2.6.21 or later, then change Then change the DONT_LOAD specification in your shorewall.conf to:DONT_LOAD=nf_nat_sip,nf_conntrack_sip
IPv6
(FAQ 80) Does Shorewall support IPV6? Answer: Shorewall IPv6 support is currently available in Shorewall 4.2.4 and later.
(FAQ 80a) Why does Shorewall lPv6 Support Require Kernel 2.6.24 or later? Answer: Shorewall implements a stateful firewall which requires connection tracking be present in ip6tables and in the kernel. Linux kernels before 2.6.20 didn't support connection tracking for IPv6. So we could not even start to develop Shorewall IPv6 support until 2.6.20 and there were significant problems with the facility until at least kernel 2.6.23. When distributions began offering IPv6 connection tracking support, it was with kernel 2.6.25. So that is what we developed IPv6 support on and that's all that we initially tested on. Subsequently, we have tested Shorewall6 on Ubuntu Hardy with kernel 2.6.24. If you are running 2.6.20 or later, you can try to run Shorewall6 by hacking /usr/share/shorewall/prog.footer6 and changing the kernel version test to check for your kernel version rather than 2.6.24 (20624). But after that, you are on your own. kernel=$(printf "%2d%02d%02d\n" $(echo $(uname -r) 2> /dev/null | sed 's/-.*//' | tr '.' ' ' ) | head -n1) if [ $kernel -lt 20624 ]; then error_message "ERROR: $PRODUCT requires Linux kernel 2.6.24 or later" status=2 else Update: The above logic is found in /usr/share/shorewall/prog.footer in later Shorewall releases.
(FAQ 40) I have an interface that gets its IPv6 configuration from radvd. When I start Shorewall6, I immediately loose my default route. Why? Answer: You have configured forwarding on the interface which disables autoconfiguration of the interface. To retain autoconfiguration on the interface when Shorewall6 starts, specify forwarding=0 in the OPTIONS column on the interface's entry in shorewall6-interfaces (5).
(FAQ 96) I am starting to use ipv6, but on my ipv4 FW, when restarting Shorewall . it puts in ip6tables rules. How do i dissable that ? Answer: This is a two-step process. Set DISABLE_IPV6=No in shorewall.conf (5) and restart Shorewall. Execute these commands at a root shell prompt: ip6tables -P INPUT ACCEPT ip6tables -P OUTPUT ACCEPT ip6tables -P FORWARD ACCEPT You will probably want to soon install Shorewall6 so that you have an IPv6 firewall as well as one for IPv4.
Wifidog
(FAQ 105) Can Shorewall work with Wifidog? Answer: Yes, with a couple of restrictions: Wifidog must be started after Shorewall. If Shorewall is restarted/reloaded, then wifidog must be restarted. FORWARD_CLEAR_MARK must be set to in shorewall.conf.
Miscellaneous
(FAQ 20) I have just set up a server. Do I have to change Shorewall to allow access to my server from the Internet? Answer: Yes. Consult the QuickStart guide that you used during your initial setup for information about how to set up rules for your server.
(FAQ 24) How can I allow connections to, let's say, the ssh port only from specific IP Addresses on the Internet? Answer: In the SOURCE column of the rule, follow net by a colon and a list of the host/subnet addresses as a comma-separated list. net:<ip1>,<ip2>,... Example: ACCEPT net:192.0.2.16/28,192.0.2.44 fw tcp 22
(FAQ 26) When I try to use any of the SYN options in nmap on or behind the firewall, I get <quote>operation not permitted</quote>. How can I use nmap with Shorewall? Answer: Temporarily remove any rejNotSyn, dropNotSyn, dropInvalid, NotSyn(...) and Invalid(...) rules from /etc/shorewall/rules and restart Shorewall.
(FAQ 27) I'm compiling a new kernel for my firewall. What should I look out for? Answer: First take a look at the Shorewall kernel configuration page. You probably also want to be sure that you have selected the NAT of local connections (READ HELP) on the Netfilter Configuration menu. Otherwise, DNAT rules with your firewall as the source zone won't work with your new kernel.
(FAQ 28) How do I use Shorewall as a Bridging Firewall? Answer: Shorewall Bridging Firewall support is available — check here for details.
(FAQ 39) How do I block connections to a particular domain name? I tried this rule to block Google's Adsense that you'll find on everyone's site. Adsense is a Javascript that people add to their Web pages. So I entered the rule: #ACTION SOURCE DEST PROTO REJECT fw net:pagead2.googlesyndication.com all However, this also sometimes restricts access to "google.com". Why is that? Using dig, I found these IPs for domain googlesyndication.com:216.239.37.99 216.239.39.99And this for google.com:216.239.37.99 216.239.39.99 216.239.57.99So my guess is that you are not actually blocking the domain, but rather the IP being called. So how in the world do you block an actual domain name? Answer: Packet filters like Netfilter base their decisions on the contents of the various protocol headers at the front of each packet. Stateful packet filters (of which Netfilter is an example) use a combination of header contents and state created when the packet filter processed earlier packets. Netfilter (and Shorewall's use of Netfilter) also consider the network interface(s) where each packet entered and/or where the packet will leave the firewall/router. When you specify a domain name in a Shorewall rule, the iptables program resolves that name to one or more IP addresses and the actual Netfilter rules that are created are expressed in terms of those IP addresses. So the rule that you entered was equivalent to: #ACTION SOURCE DEST PROTO REJECT $FW net:216.239.37.99 all REJECT $FW net:216.239.39.99 allGiven that name-based multiple hosting is a common practice (another example: lists.shorewall.net and www1.shorewall.net are both hosted on the same system with a single IP address), it is not possible to filter connections to a particular name by examination of protocol headers alone. While some protocols such as FTP require the firewall to examine and possibly modify packet payload, parsing the payload of individual packets doesn't always work because the application-level data stream can be split across packets in arbitrary ways. This is one of the weaknesses of the 'string match' Netfilter extension available in later Linux kernel releases. The only sure way to filter on packet content is to proxy the connections in question -- in the case of HTTP, this means running something like Squid. Proxying allows the proxy process to assemble complete application-level messages which can then be accurately parsed and decisions can be made based on the result.
(FAQ 42) How can I tell which features my kernel and iptables support? Answer: Use the shorewall[-lite] show capabilities command at a root prompt. gateway:~# shorewall show capabilities 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 Extended Connection Tracking Match Support: Available Old Connection Tracking Match Syntax: Not available Packet Type Match: Available Policy Match: Available Physdev Match: Available Physdev-is-bridged Support: Available Packet length Match: Available IP range Match: Available Recent Match: Available Owner Match: Available Ipset Match: Available CONNMARK Target: Available Extended CONNMARK Target: Available Connmark Match: Available Extended Connmark Match: Available Raw Table: Available IPP2P Match: Available Old IPP2P Match Syntax: Not available CLASSIFY Target: Available Extended REJECT: Available Repeat match: Available MARK Target: Available Extended MARK Target: Available Mangle FORWARD Chain: Available Comments: Available Address Type Match: Available TCPMSS Match: Available Hashlimit Match: Available Old Hashlimit Match: Not available NFQUEUE Target: Available Realm Match: Available Helper Match: Available Connlimit Match: Available Time Match: Available Goto Support: Available LOGMARK Target: Available IPMARK Target: Available LOG Target: Available Persistent SNAT: Available gateway:~#
(FAQ 19) How do I open the firewall for all traffic to/from the LAN? Answer: Add these two policies: #SOURCE DEST POLICY LOGLEVEL LIMIT CONNLIMIT $FW loc ACCEPT loc $FW ACCEPT You should also delete any ACCEPT rules from $FW->loc and loc->$FW since those rules are redundant with the above policies.
(FAQ 88) Can I run Snort with Shorewall? Answer: Yes. In Network Intrusion Detection System (NIDS) mode, Snort is libpcap based (like tcpdump) so it doesn't interfere with Shorewall. We have had reports that users have also been successful in using Snort in inline more with Shorewall, but no HOWTO exists at this time.
(FAQ 89) How do I connect to the web server in my aDSL modem from my local LAN? Answer: Here's what I did: My local network is 172.20.1.0/24, so I set the IP address in the modem to 172.20.1.2. The IP address of my firewall's interface to the LAN is 172.20.1.254. The logical name of the DSL interface is EXT_IF and my LAN interface is INT_IF. I added the following two configuration entries: /etc/shorewall/masq: #INTERFACE SOURCE ADDRESS ?COMMENT DSL Modem EXT_IF:172.20.1.2 0.0.0.0/0 172.20.1.254 When running Shorewall 5.0.14 or later, the equivalent /etc/shorewall/snat is: #ACTION SOURCE DEST PROTO PORT SNAT(172.20.1.254) 0.0.0.0/0 EXT_IF:192.168.1.2 tcp www /etc/shorewall/proxyarp: #ADDRESS INTERFACE EXTERNAL HAVEROUTE PERSISTENT 172.20.1.2 EXT_IF INT_IF no yes If you can't change the IP address of your modem and its current address isn't in your local network, then you need to change this slightly; assuming that the modem IP address is 192.168.1.1: Do not include an entry in /etc/shorewall/proxyarp. Add an IP address in 192.168.1.0/24 to your external interface using your configuration's network management tools. For Debian-based systems, that means adding this to the interface's stanza in /etc/network/interfaces: post-up /sbin/ip addr add 192.168.1.254/24 dev external-interface Your entry in /etc/shorewall/masq would then be: #INTERFACE SOURCE ADDRESS COMMENT DSL Modem EXT_IF:192.168.1.1 0.0.0.0/0 192.168.1.254 When running Shorewall 5.0.14 or later, the equivalent /etc/shorewall/snat is: #ACTION SOURCE DEST PROTO PORT SNAT(192.168.1.254) 0.0.0.0/0 EXT_IF:192.168.1.1 tcp www
(FAQ 93) I'm not able to use Shorewall to manage a bridge. I get the following error: ERROR: BRIDGING=Yes is not supported by Shorewall 4.4.13.3. Answer: If you want to apply firewall rules to the traffic passing between bridge ports, see http://www.shorewall.net/bridge-Shorewall-perl.html. If you simply want to allow all traffic between ports, then see http://www.shorewall.net/SimpleBridge.html.
(FAQ 95) What is this $FW that I see in the configuration files and documentation? Answer: FW is a shell variable that expands to the name that you gave to the firewall zone in shorewall-zones(5). The default name for the firewall zone is fw: #ZONE TYPE OPTIONS fw firewall So, using the default or sample configurations, writing $FW is the same as writing fw. If you give the firewall zone a different name, gate for example, then writing $FW would be the same as writing gate. #ZONE TYPE OPTIONS gate firewall
Why was that done? Answer: The firewall zone has special semantics, so having a way to refer to it in a configuration-independent way makes writing the documentation, examples, macros, etc. easier.
(FAQ 98) How do I Unsubscribe from the Mailing List Answer: There are two ways: On the web Go to https://lists.sourceforge.net/lists/listinfo/shorewall-users. At the bottom of the form is a section entitled "Shorewall-users Subscribers". At the bottom of that section find:
"To unsubscribe from Shorewall-users, get a password reminder, or change your subscription options enter your subscription email address:".
Enter your email address in the box provided and click on the "Unsubscribe or edit options" button. That will take you to a second form. At the top of the second form is a box to enter your password -- enter it there then click the Unsubscribe button in the center of the form. You will be unsubscribed. If you don't remember your password, click on the Remind button at the bottom of the form and your password will be emailed to you. Via email using this link: mailto:shorewall-users-request@lists.sourceforge.net?subject=unsubscribe. You will receive a confirmation email shortly; follow the instructions in that email.
(FAQ 102) What is 'qt'? I see it in some of the older documentation. Answer: 'qt' stands for 'quiet'; qt() is a shell function that accepts a command with arguments as parameters. It redirects both standard out and standard error to /dev/null. It is defined in the Shorewall-core shell library lib.common.
shorewall-docs-xml-5.0.15/6to4.xml0000644000000000000000000006174013020330134015337 0ustar rootroot
6to4 and 6in4 Tunnels Eric de Thouars Tom Eastep 2003-2004 2008 2009 2012 Eric de Thouars and Tom Eastep 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. 6to4 tunneling with Shorewall can be used to connect your IPv6 network to another IPv6 network over an IPv4 infrastructure. It can also allow you to experiment with IPv6 even if your ISP doesn't provide IPv6 connectivity. More information on Linux and IPv6 can be found in the Linux IPv6 HOWTO. Details on how to setup a 6to4 tunnels are described in the section Setup of 6to4 tunnels.
Getting your Feet Wet with IPv6, by Tom Eastep 6to4 tunnels provide a good way to introduce yourself to IPv6. Shorewall6 was developed on a network whose only IPv6 connectivity was an 6to4 Tunnel; that network is described in the remainder of this section. What is shown here requires Shorewall6 4.2.4 or later.
Configuring IPv6 using my script I have created an init script to make the job of configuring your firewall for IPv6 easier. The script is installed in /etc/init.d and configures ipv6, including a 6to4 tunnel, at boot time. Note that the script is included in the Shorewall6 distribution but is not installed in /etc/init.d by default. The RPMs from shorewall.net, install the file in the package documentation directory. The script works on OpenSuSE 11.0 and may need modification for other distributions. On OpenSuSE, the script is installed by copying it to /etc/init.d/ then running the command 'chkconfig --add ipv6'. At the top of the script, you will see several variables: SIT - The name of the tunnel device. Usually 'sit1' INTERFACES - local interfaces that you want to configure for IPv6 ADDRESS4 - A static IPv4 address on your firewall that you want to use for the tunnel. SLA - The identity of the first local sub-network that you want to assign to the interfaces listed in INTERFACES. Normally one (0001). GATEWAY - The default IPv6 gateway. For 6to4, this is ::192.88.99.1. Here is the file from my firewall:
SIT="sit1" ADDRESS4=206.124.146.180 INTERFACES="eth2 eth4" SLA=1 GATEWAY=::192.88.99.1
eth2 is the interface to my local network (both wired and wireless). eth4 goes to my DMZ which holds a single server. Here is a diagram of the IPv4 network: Here is the configuration after IPv6 is configured; the part in bold font is configured by the /etc/init.d/ipv6 script.
gateway:~ # ip -6 addr ls 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 inet6 ::1/128 scope host valid_lft forever preferred_lft forever 1: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000 inet6 fe80::202:e3ff:fe08:484c/64 scope link valid_lft forever preferred_lft forever 2: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000 inet6 2002:ce7c:92b4:1::1/64 scope global valid_lft forever preferred_lft forever inet6 fe80::202:e3ff:fe08:55fa/64 scope link valid_lft forever preferred_lft forever 3: eth4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000 inet6 2002:ce7c:92b4:2::1/64 scope global valid_lft forever preferred_lft forever inet6 fe80::2a0:ccff:fed2:353a/64 scope link valid_lft forever preferred_lft forever 4: sit1@NONE: <NOARP,UP,LOWER_UP> mtu 1480 inet6 ::206.124.146.180/128 scope global valid_lft forever preferred_lft forever inet6 2002:ce7c:92b4::1/128 scope global valid_lft forever preferred_lft forever gateway:~ # ip -6 route ls ::/96 via :: dev sit1 metric 256 expires 21333315sec mtu 1480 advmss 1420 hoplimit 4294967295 2002:ce7c:92b4::1 dev sit1 metric 256 expires 21333315sec mtu 1480 advmss 1420 hoplimit 4294967295 2002:ce7c:92b4:1::/64 dev eth2 metric 256 expires 21333315sec mtu 1500 advmss 1440 hoplimit 4294967295 2002:ce7c:92b4:2::/64 dev eth4 metric 256 expires 21333315sec mtu 1500 advmss 1440 hoplimit 4294967295 fe80::/64 dev eth1 metric 256 expires 20748424sec mtu 1500 advmss 1440 hoplimit 4294967295 fe80::/64 dev eth2 metric 256 expires 20748431sec mtu 1500 advmss 1440 hoplimit 4294967295 fe80::/64 dev eth4 metric 256 expires 20748431sec mtu 1500 advmss 1440 hoplimit 4294967295 fe80::/64 dev sit1 metric 256 expires 21333315sec mtu 1480 advmss 1420 hoplimit 4294967295 default via ::192.88.99.1 dev sit1 metric 1 expires 21333315sec mtu 1480 advmss 1420 hoplimit 4294967295 gateway:~ #
You will notice that sit1, eth2 and eth4 each have an IPv6 address beginning with 2002: -- All 6to4 IPv6 addresses have that in their most significant 16 bits. The next 32-bits (ce7c:92b4) encode the IPv4 ADDRESS (206.124.146.180). So once you start the 6to4 tunnel, you are the proud owner of 280 IPv6 addresses! In the case shown here, 2002:ce7c:92b4::/48. The SLA is used to assign each interface in INTERFACES, a subnet of 264 addresses; in the case of eth2, 2002:ce7c:92b4:1::/64. I run radvd on the firewall to allow hosts conntected to eth2 and eth4 to automatically perform their own IPv6 configuration. Here is my /etc/radvd.conf file:
interface eth2 { AdvSendAdvert on; MinRtrAdvInterval 3; MaxRtrAdvInterval 10; prefix 2002:ce7c:92b4:1::/64 { AdvOnLink on; AdvAutonomous on; AdvRouterAddr off; }; RDNSS 2002:ce7c:92b4:2:2a0:ccff:fedb:31c4 { AdvRDNSSOpen on; AdvRDNSSPreference 2; }; }; interface eth4 { AdvSendAdvert on; MinRtrAdvInterval 3; MaxRtrAdvInterval 10; prefix 2002:ce7c:92b4:2::/64 { AdvOnLink on; AdvAutonomous on; AdvRouterAddr off; }; RDNSS 2002:ce7c:92b4:2:2a0:ccff:fedb:31c4 { AdvRDNSSOpen on; AdvRDNSSPreference 2; }; };
radvd terminates immediately if IPv6 forwarding is not enabled. So it is a good idea to include this in /etc/sysctl.conf: net.ipv6.conf.all.forwarding = 1 That way, if radvd starts before Shorewall6, it will continue to run. An alternative is to modify /etc/init.d/radvd so that radvd starts after Shorewall6: # Should-Start: shorewall6 Here is the automatic IPv6 configuration on my server attached to eth4:
webadmin@lists:~/ftpsite/contrib/IPv6> /sbin/ip -6 addr ls 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000 inet6 2002:ce7c:92b4:2:2a0:ccff:fedb:31c4/64 scope global dynamic valid_lft 2591995sec preferred_lft 604795sec inet6 fe80::2a0:ccff:fedb:31c4/64 scope link valid_lft forever preferred_lft forever webadmin@lists:~/ftpsite/contrib/IPv6> /sbin/ip -6 route ls 2002:ce7c:92b4:2::/64 dev eth2 proto kernel metric 256 expires 2592161sec mtu 1500 advmss 1440 hoplimit 4294967295 fe80::/64 dev eth2 metric 256 expires 20746963sec mtu 1500 advmss 1440 hoplimit 4294967295 fe80::/64 dev ifb0 metric 256 expires 20746985sec mtu 1500 advmss 1440 hoplimit 4294967295 default via fe80::2a0:ccff:fed2:353a dev eth2 proto kernel metric 1024 expires 29sec mtu 1500 advmss 1440 hoplimit 64 webadmin@lists:~/ftpsite/contrib/IPv6>
You will note that the public IPv6 address of eth2 (2002:ce7c:92b4:2:2a0:ccff:fedb:31c4) was formed by concatenating the prefix for eth2 shown in radvd.conf (2002:ce7c:92b4:2) and the lower 64 bits of the link level address of eth2 (2a0:ccff:fedb:31c4). You will also notice that the address 2002:ce7c:92b4:2:2a0:ccff:fedb:31c4 appears in the RDNSS clauses in radvd.conf; that causes my server to be automatically configured as a DNS server. The default route is described using the link level address of eth2 on the firewall (fe80::2a0:ccff:fed2:353a). On my laptop, ursa:
ursa:~ # ip -6 addr ls dev eth0 3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000 inet6 2002:ce7c:92b4:1:21a:24ff:fecb:2bcc/64 scope global dynamic valid_lft 2591996sec preferred_lft 604796sec inet6 fe80::21a:73ff:fedb:8c35/64 scope link valid_lft forever preferred_lft forever ursa:~ # ip -6 route ls dev eth0 2002:ce7c:92b4:1::/64 proto kernel metric 256 expires 2592160sec mtu 1500 advmss 1440 hoplimit 4294967295 fe80::/64 metric 256 expires 21314573sec mtu 1500 advmss 1440 hoplimit 4294967295 default via fe80::202:e3ff:fe08:55fa proto kernel metric 1024 expires 28sec mtu 1500 advmss 1440 hoplimit 64 ursa:~ #
Here is the resulting simple IPv6 Network:
Configuring IPv6 the Debian Way In May 2009, I rebuilt the above firewall using Debian GNU/Linux and decided to configure IPv6 using the /etc/network/interfaces file. When I installed Debian Lenny on the system, the network interfaces were reunmbered as follows: Interface Renaming Old Configuration New Configuration eth0 (Avvanta Interface) eth3 eth3 (Comcast Interface) eth0 eth2 (Local Interface) eth1 eth4 (DMZ Interface) eth2
So the IPv4 network was transformed to this: To implement the same IPv6 network as described above, I used this /etc/shorewall/interfaces file:
auto lo iface lo inet loopback auto eth0 iface eth0 inet dhcp hwaddress ether 00:11:85:89:da:9b auto eth1 iface eth1 inet static address 172.20.1.254 netmask 255.255.255.0 network 172.20.1.0 broadcast 172.20.1.255 iface eth1 inet6 static address 2002:ce7c:92b4:1::1 netmask 64 auto eth2 iface eth2 inet static address 206.124.146.176 netmask 255.255.255.255 up ip route add 206.124.146.177/32 dev eth2 iface eth2 inet6 static address 2002:ce7c:92b4:2::1 netmask 64 auto eth3 eth3:0 eth3:1 eth3:2 iface eth3 inet static address 206.124.146.176 netmask 255.255.255.0 network 206.124.146.0 broadcast 206.124.146.255 iface eth3:0 inet static address 206.124.146.178 netmask 255.255.255.0 broadcast 206.124.146.255 iface eth3:1 inet static address 206.124.146.179 netmask 255.255.255.0 broadcast 206.124.146.255 iface eth3:2 inet static address 206.124.146.180 netmask 255.255.255.0 broadcast 206.124.146.255 auto sit1 iface sit1 inet6 v4tunnel address 2002:ce7c:92b4::1 netmask 64 endpoint 192.88.99.1 local 206.124.146.180 gateway ::192.88.99.1 ttl 64 post-up echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
That file produces the following IPv6 network.
Configuring Shorewall We need to add an entry in /etc/shorewall/tunnels and restart Shorewall:
#TYPE ZONE GATEWAY GATEWAY_ZONE 6to4 net
Configuring Shorewall6 STOP -- If you have followed the instructions above, you should have a completely functional IPv6 network. Try: ping6 www.kame.net ping6 ipv6.chat.eu.freenode.net If neither of those work from your firewall and from any local IPv6 systems that you have behind your firewall, do not go any further until one of them does work. If you ask for help from the Shorewall team, the first question we will ask is 'With Shorewall6 cleared, can you ping6 kame or freenode?'. The Shorewall6 configuration on my firewall is a very basic three-interface one. Key entry in /etc/shorewall6/shorewall6.conf:
IP_FORWARDING=On
/etc/shorewall6/zones:
#ZONE TYPE OPTIONS IN_OPTIONS OUT_OPTIONS fw firewall net ipv6 loc ipv6 dmz ipv6
/etc/shorewall6/interfaces:
?FORMAT 2 #ZONE INTERFACE OPTIONS net sit1 tcpflags,forward=1,nosmurfs loc eth0 tcpflags,forward=1 dmz eth2 tcpflags,forward=1
/etc/shorewall6/policy:
#SOURCE DEST POLICY LOGLEVEL LIMIT net all DROP info loc net ACCEPT dmz net ACCEPT all all REJECT info
/etc/shorewall6/rules:
#ACTION SOURCE DEST PROTO DPORT SPORT ORIGDEST RATE USER MARK CONNLIMIT TIME HEADERS SWITCH HELPER ?SECTION ALL ?SECTION ESTABLISHED ?SECTION RELATED ?SECTION INVALID ?SECTION UNTRACKED ?SECTION NEW # # Accept DNS connections from the firewall to the network # DNS(ACCEPT) $FW net # # Accept SSH connections from the local network for administration # SSH(ACCEPT) loc $FW # # Allow Ping everywhere # Ping(ACCEPT) all all
6in4 Tunnel 6in4 is very similar to 6to4: Both Tunnel IPv6 traffic over IPv4 using Protocol 41 Both allow you access to the IPv6 network even though your ISP doesn't offer native IPv6 connectivity. The differences are: 6in4 gives you a /64 prefix outside of the 2002::0/16 network You have a dedicated fixed endpoint for the tunnel rather than the nebulous anycast endpoint 192.88.99.1. This is: Much more reliable Much easier to troubleshoot (there is ONE host and one company to call on the other end of the tunnel rather than an indefinite cloud with noone in charge) I converted to a 6in4 Tunnel from Hurricane Electric in April of 2010. Converting from the 6to4 tunnel configuration above to a 6in4 tunnel from HE took less than an hour. When I signed up for a tunnel with HE, I received these assignments:
Server IPv4 address: 216.218.226.238 Server IPv6 address: 2001:470:a:227::1/64 Client IPv4 address: 206.124.146.180 (Same as the 6to4 tunnel) Client IPv6 address: 2001:470:a:227::2/64
I also took advantage of their offer for a /48 prefix routed via 2001:470:a:227::2. The prefix I was assigned is
2001:470:e857::/48
Here are the key changes: /etc/network/interfaces: iface eth1 inet6 static address 2001:470:e857:1::1 netmask 64 auto eth2 ... iface eth2 inet6 static address 2001:470:e857:2::1 netmask 64 auto sit1 iface sit1 inet6 v4tunnel address 2001:470:a:227::2 netmask 64 endpoint 216.218.226.238 local 206.124.146.180 gateway 2001:470:a:227::1 ttl 64 post-up echo 1 > /proc/sys/net/ipv6/conf/all/forwarding /etc/radvd.conf (I'm currently not using RDNSS so I've simply commented out the existing entries): interface eth1 { AdvSendAdvert on; MinRtrAdvInterval 60; MaxRtrAdvInterval 600; AdvDefaultLifetime 9000; prefix 2001:470:e857:1::/64 { AdvOnLink on; AdvAutonomous on; AdvRouterAddr off; }; route ::/0 { AdvRouteLifetime infinity; }; # RDNSS 2002:ce7c:92b4:2:221:5aff:fe22:ace0 { # AdvRDNSSOpen on; # AdvRDNSSPreference 2; # }; }; interface eth2 { AdvSendAdvert on; MinRtrAdvInterval 60; MaxRtrAdvInterval 600; prefix 2001:470:e857:2::/64 { AdvOnLink on; AdvAutonomous on; AdvRouterAddr off; }; # RDNSS 2002:ce7c:92b4:2:221:5aff:fe22:ace0 { # AdvRDNSSOpen on; # AdvRDNSSPreference 2; # }; };
Connecting two IPv6 Networks, by Eric de Thouars Suppose that we have the following situation: We want systems in the 2002:100:333::/64 subnetwork to be able to communicate with the systems in the 2002:488:999::/64 network. This is accomplished through use of the /etc/shorewall/tunnels file and the ip utility for network interface and routing configuration. Unlike GRE and IPIP tunneling, the /etc/shorewall/policy, /etc/shorewall/interfaces and /etc/shorewall/zones files are not used. There is no need to declare a zone to represent the remote IPv6 network. This remote network is not visible on IPv4 interfaces and to iptables. All that is visible on the IPv4 level is an IPv4 stream which contains IPv6 traffic. Separate IPv6 interfaces and ip6tables rules need to be defined to handle this traffic. In /etc/shorewall/tunnels on system A, we need the following: #TYPE ZONE GATEWAY GATEWAY_ZONE 6to4 net 134.28.54.2 This entry in /etc/shorewall/tunnels opens the firewall so that the IPv6 encapsulation protocol (41) will be accepted to/from the remote gateway. Use the following commands to setup system A: >ip tunnel add tun6to4 mode sit ttl 254 remote 134.28.54.2 >ip link set dev tun6to4 up >ip addr add 3ffe:8280:0:2001::1/64 dev tun6to4 >ip route add 2002:488:999::/64 via 3ffe:8280:0:2001::2 Similarly, in /etc/shorewall/tunnels on system B we have: #TYPE ZONE GATEWAY GATEWAY_ZONE 6to4 net 206.191.148.9 And use the following commands to setup system B: >ip tunnel add tun6to4 mode sit ttl 254 remote 206.191.148.9 >ip link set dev tun6to4 up >ip addr add 3ffe:8280:0:2001::2/64 dev tun6to4 >ip route add 2002:100:333::/64 via 3ffe:8280:0:2001::1 On both systems, restart Shorewall and issue the configuration commands as listed above. The systems in both IPv6 subnetworks can now talk to each other using IPv6.
shorewall-docs-xml-5.0.15/configuration_file_basics.xml0000644000000000000000000035106313020330134021735 0ustar rootroot
Configuration Files Tips and Hints Tom Eastep 2001-2016 Thomas M. Eastep 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. This article applies to Shorewall 5.0 and later. If you are running a version of Shorewall earlier than Shorewall 5.0.0 then please see the documentation for that release. If you copy or edit your configuration files on a system running Microsoft Windows, you must run them through dos2unix before you use them with Shorewall.
Introduction This article offers hints about how to accomplish common tasks with Shorewall. The Introduction to Shorewall is required reading for being able to use this article effectively. For information about setting up your first Shorewall-based firewall, see the Quickstart Guides.
Files /etc/shorewall/shorewall.conf - used to set global firewall parameters. /etc/shorewall/params - use this file to set shell variables that you will expand in other files. It is always processed by /bin/sh or by the shell specified through SHOREWALL_SHELL in /etc/shorewall/shorewall.conf. /etc/shorewall/zones - partition the firewall's view of the world into zones. /etc/shorewall/policy - establishes firewall high-level policy. /etc/shorewall/initdone - An optional Perl script that will be invoked by the Shorewall rules compiler when the compiler has finished it's initialization. /etc/shorewall/interfaces - describes the interfaces on the firewall system. /etc/shorewall/hosts - allows defining zones in terms of individual hosts and subnetworks. /etc/shorewall/masq - directs the firewall where to use many-to-one (dynamic) Network Address Translation (a.k.a. Masquerading) and Source Network Address Translation (SNAT). /etc/shorewall/mangle - supersedes /etc/shorewall/tcrules in Shorewall 4.6.0. Contains rules for packet marking, TTL, TPROXY, etc. /etc/shorewall/rules - defines rules that are exceptions to the overall policies established in /etc/shorewall/policy. /etc/shorewall/nat - defines one-to-one NAT rules. /etc/shorewall/proxyarp - defines use of Proxy ARP. /etc/shorewall/routestopped - defines hosts accessible when Shorewall is stopped. Superseded in Shorewall 4.6.8 by /etc/shorewall/stoppedrules. Not supported in Shorewall 5.0.0 and later versions. /etc/shorewall/tcrules - The file has a rather unfortunate name because it is used to define marking of packets for later use by both traffic control/shaping and policy routing. This file is superseded by /etc/shorewall/mangle in Shorewall 4.6.0. Not supported in Shorewall 5.0.0 and later releases. /etc/shorewall/tos - defines rules for setting the TOS field in packet headers. Superseded in Shorewall 4.5.1 by the TOS target in /etc/shorewall/tcrules (which file has since been superseded by /etc/shorewall/mangle). Not supported in Shorewall 5.0.0 and later versions. /etc/shorewall/tunnels - defines tunnels (VPN) with end-points on the firewall system. /etc/shorewall/blacklist - Deprecated in favor of /etc/shorewall/blrules. Lists blacklisted IP/subnet/MAC addresses. Not supported in Shorewall 5.0.0 and later releases. /etc/shorewall/blrules — Added in Shorewall 4.5.0. Define blacklisting and whitelisting. /etc/shorewall/init - commands that you wish to execute at the beginning of a shorewall start, "shorewall reload" or shorewall restart. /etc/shorewall/start - commands that you wish to execute near the completion of a shorewall start, "shorewall reload" or shorewall restart /etc/shorewall/started - commands that you wish to execute after the completion of a shorewall start, "shorewall reload" or shorewall restart /etc/shorewall/stop - commands that you wish to execute at the beginning of a shorewall stop. /etc/shorewall/stopped - commands that you wish to execute at the completion of a shorewall stop. /etc/shorewall/ecn - disable Explicit Congestion Notification (ECN - RFC 3168) to remote hosts or networks. /etc/shorewall/accounting - define IP traffic accounting rules /etc/shorewall/actions and /usr/share/shorewall/action.template allow user-defined actions. /etc/shorewall/providers - defines an alternate routing table. /etc/shorewall/rtrules - Defines routing rules to be used in conjunction with the routing tables defined in /etc/shorewall/providers. /etc/shorewall/tcdevices, /etc/shorewall/tcclasses, /etc/shorewall/tcfilters - Define complex traffic shaping. /etc/shorewall/tcrules - Mark or classify traffic for traffic shaping or multiple providers. Deprecated in Shorewall 4.6.0 in favor of /etc/shorewall/mangle. Not supported in Shorewall 5.0.0 and later releases. /etc/shorewall/tcinterfaces and /etc/shorewall-tcpri - Define simple traffic shaping. /etc/shorewall/secmarks - Added in Shorewall 4.4.13. Attach an SELinux context to selected packets. /etc/shorewall/vardir - Determines the directory where Shorewall maintains its state. /usr/share/shorewall/actions.std - Actions defined by Shorewall. /usr/share/shorewall/action.* - Details of actions defined by Shorewall. /usr/share/shorewall/macro.* - Details of macros defined by Shorewall. /usr/share/shorewall/modules — Specifies the kernel modules to be loaded during shorewall start/restart. /usr/share/helpers — Added in Shorewall 4.4.7. Specifies the kernel modules to be loaded during shorewall start/restart when LOAD_HELPERS_ONLY=Yes in shorewall.conf. /usr/share/arprules — Added in Shorewall 4.5.12. Allows specification of arptables rules. /etc/shorewall/mangle -- Added in Shorewall 4.6.0. Supersedes /etc/shorewall/tcrules. If you need to change a file in /usr/share/shorewall/, copy it to /etc/shorewall and modify the copy
Man Pages Man pages are provided in section 5 for each of the Shorewall configuration files. The name of the page is formed by prefixing the file name with "shorewall-". Example — To view the manual page for /etc/shorewall/interfaces: man shorewall-interfaces The /etc/shorewall/shorewall.conf file is an exception -- the man page for that file is 'shorewall.conf': man shorewall.conf
Comments You may place comments in configuration files by making the first non-whitespace character a pound sign (#). You may also place comments at the end of any line, again by delimiting the comment from the rest of the line with a pound sign. Comments in a Configuration File # This is a comment ACCEPT net $FW tcp www #This is an end-of-line comment If a comment ends with a backslash ("\"), the next line will also be treated as a comment. See Line Continuation below.
Names When you define an object in Shorewall (Zone, Logical Interface, ipsets, Actions, etc., you give it a name. Shorewall names start with a letter and consist of letters, digits or underscores ("_"). Except for Zone names, Shorewall does not impose a limit on name length. When an ipset is referenced, the name must be preceded by a plus sign ("+"). The last character of an interface may also be a plus sign to indicate a wildcard name. Physical interface names match names shown by 'ip link ls'; if the name includes an at sign ("@"), do not include that character or any character that follows. For example, "sit1@NONE" is referred to as simply 'sit1".
Zone and Chain Names For a pair of zones, Shorewall creates two Netfilter chains; one for connections in each direction. The names of these chains are formed by separating the names of the two zones by either "2" or "-". Example: Traffic from zone A to zone B would go through chain A2B (think "A to B") or "A-B". In Shorewall 4.6, the default separator is "-" but you can override that by setting ZONE_SEPARATOR="2" in shorewall.conf (5). Prior to Shorewall 4.6, the default separator was "2". Zones themselves have names that begin with a letter and are composed of letters, numerals, and "_". The maximum length of a name is dependent on the setting of LOGFORMAT in shorewall.conf (5). See shorewall-zones (5) for details.
Capabilities Shorewall probes your system to determine the features that it supports. The result of this probing is a set of capabilities. This probing is normally done each time that the compiler is run but can also be done by executing the shorewall show capabilities command. Regardless of whether the compiler or the command does the probing, this probing may produce error messages in your system log. These log messages are to be expected and do not represent a problem; they merely indicate that capabilities that are being probed are not supported on your system. Probing may be suppressed by using a capabilities file. A capabilities file may be generated using this command: shorewall show -f capabilities > /etc/shorewall/capabilities If you use a capabilities file, be sure to regenerate it after you have performed a Shorewall upgrade to ensure that all current capabilities have been recorded in your file.
"Blank" Columns If you don't want to supply a value in a column but want to supply a value in a following column, simply enter '-' to make the column appear empty. Example:#INTERFACE BROADCAST OPTIONS br0 - routeback
Line Continuation You may continue lines in the configuration files using the usual backslash (\) followed immediately by a new line character (Enter key). Line Continuation ACCEPT net $FW tcp \↵ smtp,www,pop3,imap #Services running on the firewall In certain cases, leading white space is ignored in continuation lines: The continued line ends with a colon (":") The continued line ends with a comma (",") Example (/etc/shorewall/rules): #ACTION SOURCE DEST PROTO DPORT ACCEPT net:\ 206.124.146.177,\ 206.124.146.178,\ 206.124.146.180\ dmz tcp 873 The leading white space on the first through third continuation lines is ignored so the SOURCE column effectively contains "net:206.124.146.177,206.124.147.178,206.124.146.180". Because the third continuation line does not end with a comma or colon, the leading white space in the last line is not ignored. A trailing backslash is not ignored in a comment. So the continued rule above can be commented out with a single '#' as follows: #ACTION SOURCE DEST PROTO DPORT #ACCEPT net:\ 206.124.146.177,\ 206.124.146.178,\ 206.124.146.180\ dmz tcp 873
Alternate Specification of Column Values - Shorewall 4.4.24 and Later Some of the configuration files now have a large number of columns. That makes it awkward to specify a value for one of the right-most columns as you must have the correct number of intervening '-' columns. This problem is addressed by allowing column values to be specified as column-name/value pairs. There is considerable flexibility in how you specify the pairs: At any point, you can enter a left curly bracket ('{') followed by one or more specifications of the following forms: column-name=value column-name=>value column-name:value The pairs must be followed by a right curly bracket ("}"). The value may optionally be enclosed in double quotes. The pairs must be separated by white space, but you can add a comma adjacent to the values for readability as in: { proto=>udp, port=1024 } You can also separate the pairs from columns by using a semicolon: ; proto:udp, port:1024 This form is incompatible with INLINE_MATCHES=Yes. See the INLINE_MATCHES option in shorewall.conf(5). In Shorewall 5.0.3, the sample configuration files and the man pages were updated to use the same column names in both the column headings and in the alternate specification format. The following table shows the column names for each of the table-oriented configuration files. Column names are case-insensitive. File Column names accounting action,chain, source, dest, proto, dport, sport, user, mark, ipsec, headers conntrack (formerly notrack) source,dest,proto,dport,sport,user,switch blacklist networks,proto,port,options blrules action,source,dest,proto,dport,sport,origdest,rate,user,mark,connlimit,time,headers,switch,helper ecn interface,hosts. Beginning with Shorewall 4.5.4, 'host' is a synonym for 'hosts'. hosts zone,hosts,options. Beginning with Shorewall 4.5.4, 'host' is a synonym for 'hosts'. interfaces zone,interface,broadcast,options maclist disposition,interface,mac,addresses mangle action,source,dest,proto,dport,sport,user,test,length,tos,connbytes,helper,headers masq interface,source,address,proto,port,ipsec,mark,user,switch nat external,interface,internal,allints,local netmap type,net1,interface,net2,net3,proto,dport,sport notrack source,dest,proto,dport,sport,user policy source,dest,policy,loglevel,limit,connlimit providers table,number,mark,duplicate,interface,gateway,options,copy proxyarp and proxyndp address,interface,external,haveroute,persistent rtrules source,dest,provider,priority routes provider,dest,gateway,device routestopped interface,hosts,options,proto,dport,sport rules action,source,dest,proto,dport,sport,origdest,rate,user,mark,connlimit,time,headers,switch,helper secmarks secmark,chain,source,dest,proto,dport,sport,user,mark tcclasses interface,mark,rate,ceil,prio,options tcdevices interface,in_bandwidth,out_bandwidth,options,redirect tcfilters class,source,dest,proto,dport,sport,tos,length tcinterfaces interface,type,in_bandwidth,out_bandwidth tcpri band,proto,port,address,interface,helper tcrules mark,source,dest,proto,dport,sport,user,test,length,tos,connbytes,helper,headers. Beginning with Shorewall 4.5.3, 'action' is a synonym for 'mark'. tos source,dest,proto,dport,sport,tos,mark tunnels type,zone,gateway,gateway_zone. Beginning with Shorewall 4.5.3, 'gateways' is a synonym for 'gateway'. Beginning with Shorewall 4.5.4, 'gateway_zones' is a synonym for 'gateway_zone'. zones zone,type,options,in_options,out_options Example (rules file): #ACTION SOURCE DEST PROTO DPORT DNAT net loc:10.0.0.1 tcp 80 ; mark="88" Here's the same line in several equivalent formats: { action=>DNAT, source=>net, dest=>loc:10.0.0.1, proto=>tcp, dport=>80, mark=>88 } ; action:"DNAT" source:"net" dest:"loc:10.0.0.1" proto:"tcp" dport:"80" mark:"88" DNAT { source=net dest=loc:10.0.0.1 proto=tcp dport=80 mark=88 } Beginning with Shorewall 5.0.11, ip[6]table comments can be attached to individual rules using the keyword. Example from the rules file: ACCEPT net $FW { proto=tcp, dport=22, comment="Accept \"SSH\"" } As shown in that example, when the comment contains whitespace, it must be enclosed in double quotes and any embedded double quotes must be escaped using a backslash ("\").
Using Netfilter Features not Directly Supported by Shorewall Shorewall doesn't contain built-in support for all ip[6]tables targets and matches. Nevertheless, you can still use the unsupported ip[6]tables features through several Shorewall facilities. INLINE INLINE, added in Shorewall 4. is available in the mangle, masq and rules files and allows you to specify ip[6]table text following a semicolon to the right of the column-oriented specifications. INLINE takes one optional parameter which, if present, must be a valid entry for the first column of the file. If the parameter is omitted, then you can specify the target of the rule in the text. Examples from the rules file: #ACTION SOURCE DEST ?COMMENT Drop DNS Amplification Attack Packets INLINE(DROP):info net $FW ; udp 53 ; -m u32 --u32 "0>>22&0x3C\@8&0xffff=0x0100 && 0>>22&0x3C\@12&0xffff0000=0x00010000" ?COMMENT ?COMMENT Rule generated by the IfEvent action INLINE net $FW ; -m recent --rcheck 10 --hitcount 5 --name SSH -s 1.2.3.4 -j MARK --or-mark 0x4000 ?COMMENT IPTABLES and IP6TABLES These are very similar to INLINE. The difference is that the parameter to IPTABLES and IP6TABLES is the ip[6]tables target of the Rule rather than a Shorewall-defined action or target. Example from the mangle file: IPTABLES(MARK --set-mark 0x4):P eth0 1.2.3.4 Inline Matches In Shorewall 4.6.0 and later, setting INLINE_MATCHES=Yes in shorewall[6].conf allows you to include ip[6]tables matches following a semicolon on any rule in the mangle, masq and rules files. Note that this is incompatible with the Alternate Input form that uses a semicolon to delimit column-oriented specifications from column=value specifications. In Shorewall 5.0.0 and later, inline matches are allowed in mangle, masq and rules following two adjacent semicolons (";;"). If alternate input is present, the adjacent semicolons should follow that input. Example from the masq file that spits outgoing SNAT between two public IP addresses COMB_IF !70.90.191.120/29 70.90.191.121 ;; -m statistic --mode random --probability 0.50 COMB_IF !70.90.191.120/29 70.90.191.123
Addresses In both Shorewall and Shorewall6, there are two basic types of addresses: Host Address This address type refer to a single host. In IPv4, the format is i.j.k.l where i through l are decimal numbers between 1 and 255. In IPv6, the format is a:b:c:d:e:f:g:h where a through h consist of 1 to 4 hexidecimal digits (leading zeros may be omitted). a single series of 0 addresses may be omitted. For example 2001:227:e857:1:0:0:0:0:1 may be written 2001:227:e857:1::1. Network Address A network address refers to 1 or more hosts and consists of a host address followed by a slash ("/") and a Variable Length Subnet Mask (VLSM). This is known as Classless Internet Domain Routing (CIDR) notation. The VLSM is a decimal number. For IPv4, it is in the range 0 through 32. For IPv6, the range is 0 through 128. The number represents the number of leading bits in the address that represent the network address; the remainder of the bits are a host address and are generally given as zero. Examples: IPv4: 192.168.1.0/24 IPv6: 2001:227:e857:1:0:0:0:0:1/64 In the Shorewall documentation and manpages, we have tried to make it clear which type of address is accepted in each specific case. Because Shorewall uses a colon (":") as a separator in many contexts, IPv6 addresses are best written using the standard convention in which the address itself is enclosed in square brackets: [2001:227:e857:1::1] [2001:227:e857:1:0:0:0:0:1]/64 For more information about addressing, see the Setup Guide.
Specifying SOURCE and DEST Entries in Shorewall configuration files often deal with the source (SOURCE) and destination (DEST) of connections and Shorewall implements a uniform way for specifying them. A SOURCE or DEST consists of one to three parts separated by colons (":"): ZONE — The name of a zone declared in /etc/shorewall/zones or /etc/shorewall6/zones. This part is only available in the rules file (/etc/shorewall/rules, /etc/shorewall/blrules, /etc/shorewall6/rules and /etc/shorewall6/blrules). INTERFACE — The name of an interface that matches an entry in /etc/shorewall/interfaces (/etc/shorewall6/interfaces). ADDRESS LIST — A list of one or more addresses (host or network) or address ranges, separated by commas. In an IPv6 configuration, this list must be included in square or angled brackets ("[...]" or "<...>"). The list may have exclusion. Examples. All hosts in the net zone — net Subnet 192.168.1.0/29 in the loc zone — loc:192.168.1.0/29 All hosts in the net zone connecting through ppp0 — net:ppp0 All hosts interfaced by eth3 — eth3 Subnet 10.0.1.0/24 interfacing through eth2 — eth2:10.0.1.0/24 Host 2002:ce7c:92b4:1:a00:27ff:feb1:46a9 in the loc zone — loc:[2002:ce7c:92b4:1:a00:27ff:feb1:46a9] The primary IP address of eth0 in the $FW zone - $FW:&eth0 (see Run-time Address Variables below) All hosts in Vatican City - net:^VA (Shorwall 4.5.4 and later - See this article).
INCLUDE Directive Any configuration file may contain INCLUDE directives. An INCLUDE directive consists of the word INCLUDE followed by a path name and causes the contents of the named file to be logically included into the file containing the INCLUDE. Relative path names given in an INCLUDE directive are resolved using the current CONFIG_PATH setting (see shorewall.conf(5)). INCLUDE's may be nested to a level of 3 -- further nested INCLUDE directives are ignored with a warning message. Beginning with Shorewall 4.4.17, the INCLUDE directive may also appear in the following extension scripts: clear findgw init isusable refresh refreshed restore restored start started stop stopped tcclear When used in these scripts, the INCLUDEd files are copied into the compiled firewall script. Prior to Shorewall 4.4.17, if you are using Shorewall Lite , it is not advisable to use INCLUDE in the params file in an export directory if you set EXPORTPARAMS=Yes in shorewall.conf (5). If you do that, you must ensure that the included file is also present on the firewall system's /etc/shorewall-lite/ directory. If you only need the params file at compile time, you can set EXPORTPARAMS=No in shorewall.conf. That prevents the params file from being copied into the compiled script. With EXPORTPARAMS=No, it is perfectly okay to use INCLUDE in the params file. Note that with Shorewall 4.4.17 and later: The variables set at compile time are available at run-time even with EXPORTPARAMS=No. The INCLUDE directive in the params file is processed at compile time and the INCLUDEd file is copied into the compiled script. Use of INCLUDE shorewall/params.mgmt:    MGMT_SERVERS=1.1.1.1,2.2.2.2,3.3.3.3    TIME_SERVERS=4.4.4.4    BACKUP_SERVERS=5.5.5.5    ----- end params.mgmt -----    shorewall/params:    # Shorewall 1.3 /etc/shorewall/params    [..]    #######################################      INCLUDE params.mgmt         # params unique to this host here       ----- end params -----    shorewall/rules.mgmt:    ACCEPT net:$MGMT_SERVERS   $FW    tcp    22    ACCEPT $FW          net:$TIME_SERVERS    udp    123    ACCEPT $FW          net:$BACKUP_SERVERS  tcp    22    ----- end rules.mgmt -----    shorewall/rules:    # Shorewall version 1.3 - Rules File    [..]    #######################################      INCLUDE rules.mgmt          # rules unique to this host here       ----- end rules ----- You may include multiple files in one command using an embedded shell command. Example (include all of the files ending in ".rules" in a directory:):gateway:/etc/shorewall # ls rules.d ALL.rules DNAT.rules FW.rules NET.rules REDIRECT.rules VPN.rules gateway:/etc/shorewall # /etc/shorewall/rules:?SECTION NEW SHELL cat /etc/shorewall/rules.d/*.rules If you are the sort to put such an entry in your rules file even though /etc/shorewall/rules.d might not exist or might be empty, then you probably want: ?SECTION NEW SHELL cat /etc/shorewall/rules.d/*.rules 2> /dev/null || true Beginning with Shorewall 4.5.2, in files other than /etc/shorewall/params and /etc/shorewall/conf, INCLUDE may be immediately preceded with '?' to signal that the line is a compiler directive and not configuration data. Example: ?INCLUDE common.rules
?FORMAT Directive A number of configuration files support multiple formats. Prior to Shorewall 4.5.11, the format was specified by a line having 'FORMAT' as the first token. This requires each of the file processors to handle FORMAT separately. In Shorewall 4.5.11, the ?FORMAT directive was created to centralize processing of FORMAT directives. The old entries, while still supported in Shorewall 4.5-4.6, are now deprecated. They are no longer supported in Shorewall 5.0 and later versions. The ?FORMAT directive is as follows: ?FORMAT format Where format is an integer. In all cases, the default format is 1. The following table shows the files that have different formats and the supported formats for each. FILE FORMATS action files (action.*) 1 and 2 conntrack 1, 2 and 3 interfaces 1 and 2 macro files (macro.*) 1 and 2 tcrules 1 and 2
?COMMENT Directive A number of files allow attaching comments to generated Netfilter rules: accounting action.* files blrules conntrack macro.* files masq nat rules secmarks tcrules tunnels Prior to Shorewall 4.5.11, comments were specified by a line having COMMENT as the first token. The remainder of the line is treated as a comment to be attached to rules. In Shorewall 4.5.11, the ?COMMENT directive was created to centralize processing of COMMENT directives. The old entries, while still supported in Shorewall 4.5 and 4.6, are now deprecated. They are no longer supported in Shorewall 5.0 and later versions. Use of this directive requires Comment support in your kernel and iptables - see the output of shorewall show capabilities. The ?COMMENT directive is as follows: ?COMMENT [ comment ] If comment is present, it will appear enclosed in /*....*/ in the output of the shorewall show and shorewall dump commands. If no comment is present, the rules generated by following entries will not have comments attached. Example (/etc/shorewall/rules): ?COMMENT Stop NETBIOS noise REJECT loc net tcp 137,445 REJECT loc net udp 137:139 ?COMMENT Stop my idiotic work laptop from sending to the net with an HP source/dest IP address DROP loc:!192.168.0.0/22 net ?COMMENT Here's the corresponding output from /sbin/shorewall-lite: gateway:~ # shorewall-lite show loc-net Shorewall Lite 4.3.3 Chains loc2net at gateway - Mon Oct 16 15:04:52 PDT 2008 Counters reset Mon Oct 16 14:52:17 PDT 2006 Chain loc-net (1 references) pkts bytes target prot opt in out source destination 0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:25 LOG flags 0 level 6 prefix `FW:loc2net:REJECT:' 0 0 reject tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:25 0 0 LOG udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:1025:1031 LOG flags 0 level 6 prefix `FW:loc2net:REJECT:' 0 0 reject udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:1025:1031 0 0 reject tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 137,445 /* Stop NETBIOS noise */ 0 0 reject udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:137:139 /* Stop NETBIOS noise */ 0 0 DROP all -- * * !192.168.0.0/22 0.0.0.0/0 /* Stop my idiotic work laptop from sending to the net with an HP source/dest IP address */ 5 316 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 gateway:~ # ?COMMENT lines in macro files work somewhat differently from other files. ?COMMENT lines in macros are ignored if COMMENT support is not available or if there was a COMMENT in use when the top-level macro was invoked. This allows the following: /usr/share/shorewall/macro.SSH: #ACTION SOURCE DEST PROTO DPORT SPORT RATE USER ?COMMENT SSH PARAM - - tcp 22 /etc/shorewall/rules:?COMMENT Allow SSH from home SSH(ACCEPT) net:$MYIP $FW ?COMMENTThe comment line in macro.SSH will not override the ?COMMENT line in the rules file and the generated rule will show /* Allow SSH from home */ when displayed through the Shorewall show and dump commands. Beginning with Shorewall 5.0.11, the alternate input format allows attaching comments to individual rules in the files listed above.
CONFIG_PATH The CONFIG_PATH option in shorewall.conf determines where the compiler searches for configuration files. The default setting is CONFIG_PATH=/etc/shorewall:/usr/share/shorewall which means that the compiler first looks in /etc/shorewall and if it doesn't find the file, it then looks in /usr/share/shorewall. You can change this setting to have the compiler look in different places. For example, if you want to put your own versions of standard macros in /etc/shorewall/Macros, then you could set CONFIG_PATH=/etc/shorewall:/etc/shorewall/Macros:/usr/share/shorewall and the compiler will use your versions rather than the standard ones.
Using Shell Variables You may use the /etc/shorewall/params file to set shell variables that you can then use in the other configuration files. It is suggested that variable names begin with an upper case letter to distinguish them from variables used internally within the Shorewall programs The following variable names must be avoided. Those in bold font must be avoided in all Shorewall versions; those in regular font must be avoided in versions prior to 4.4.8. Any option from shorewall.conf (5) COMMAND CONFDIR DEBUG ECHO_E ECHO_N EXPORT FAST FILEMODE HOSTNAME IPT_OPTIONS NOROUTES PREVIEW PRODUCT PROFILE PURGE RECOVERING RESTOREPATH RING_BELL SHAREDIR Any name beginning with SHOREWALL_ or SW_ STOPPING TEST TIMESTAMP USE_VERBOSITY VARDIR VARLIB VERBOSE VERBOSE_OFFSET VERSION Example:
    /etc/shorewall/params NET_IF=eth0 NET_BCAST=130.252.100.255 NET_OPTIONS=routefilter,routefilter     /etc/shorewall/interfaces record: net $NET_IF $NET_BCAST $NET_OPTIONS     The result will be the same as if the record had been written net eth0 130.252.100.255 routefilter,routefilter
Variables may be used anywhere in the other configuration files. If you use "$FW" on the right side of assignments in the /etc/shorewall/params file, you must also set the FW variable in that file. Example:/etc/shorewall/zones: #ZONE TYPE OPTIONS fw firewall /etc/shorewall/params: FW=fw BLARG=$FW:206.124.146.176 Because the /etc/shorewall/params file is simply sourced into the shell, you can place arbitrary shell code in the file and it will be executed each time that the file is read. Any code included should follow these guidelines: The code should not have side effects, especially on other shorewall configuration files. The code should be safe to execute multiple times without producing different results. Should not depend on where the code is called from. Should not assume anything about the state of Shorewall. The names of any functions or variables declared should begin with an upper case letter. The /etc/shorewall/params file is processed by the compiler at compile-time and by the compiled script at run-time. If you have set EXPORTPARAMS=No in shorewall.conf, then the params file is only processed by the compiler; it is not run by the compiled script. Beginning with Shorewall 4.4.17, the values of the variables set at compile time are available at run time with EXPORTPRARMS=No. If you are using Shorewall Lite and if the params script needs to set shell variables based on the configuration of the firewall system, you can use this trick: EXT_IP=$(ssh root@firewall "/sbin/shorewall-lite call find_first_interface_address eth0") The shorewall-lite call command allows you to call interactively any Shorewall function that you can call in an extension script. Within your configuration files, only the $VAR and ${VAR} forms of variable expansion are supported. You may not use the more exotic forms supported by the shell (${VAR:=val}, ${VAR:-val}, ...) Beginning with Shorewall 4.4.27, you may also use options in shorewall.conf (5) (e.g., $BLACKLIST_LOGLEVEL). When an option is set to 'No' in shorewall.conf, the corresponding shell variable will be empty. Options that were not set in shorewall.conf will expand to their default value. Beginning with Shorewall 4.5.2, configuration files can access variables defined in the shorewallrc file. Beginning with Shorewall 4.5.11, variables can be altered by compiler directives. ?SET variable value The variable can be specified either with or without a leading '$' to allow using both Perl and Shell variable representation. The ${...} form (e.g. ${foo}) is not allowed. The value is a Perl-compatible expression. The Shorewall compiler performs variable expansion within the expression. So variables are expanded even when they appear in single quotes. If a variable within the expression can contain a non-numeric value, it is a good idea to enclose it in quotes. Otherwise, the Shorewall compiler has to guess whether to enclose the variable's value in quotes or not. ?RESET variable Removes the named variable from the compiler's variable table. Action variables are read-only and cannot be ?SET (although you can change their values using embedded Perl). Beginning with Shorewall 4.5.13, Shorewall Variables may be set. When setting a Shorewall Variable, the variable must include the leading '@' and the @{...} form is not allowed.
Address Variables Prior to Shorewall 5.0.14, if you use address variables that refer to an optional interface, the enable command will not change/insert the rules that use the variable. Therefore, to be completely safe, if you use such address variables then you must follow a successful enable command with a reload command. Beginning with Shorewall 5.0.14, if a Shorewall-defined address variable's value has changed since the Netfilter ruleset was instantiated, then a successful enable command will automatically reload the ruleset. Given that shell variables are expanded at compile time, there is no way to cause such variables to be expanded at run time. Prior to Shorewall 4.4.17, this made it difficult (to impossible) to include dynamic IP addresses in a Shorewall-lite configuration. Version 4.4.17 implemented Run-time address variables. In configuration files, these variables are expressed as an apersand ('&') followed by the logical name of an interface defined in shorewall-interfaces (5). Wildcard interfaces (those ending in '+') are not supported and will cause a compilation error. Example: &eth0 would represent the primary IP address of eth0. Beginning with Shorewall 4.5.11, you can define your own address variables by using this syntax: &{variable} where variable is a valid shell variable name. The generated script will verify that the variable contains a valid host or network address, either from the environment or from it being assigned in your init extension script, and will raise an error if it does not. In the error case, the state of the firewall will remain unchanged. Example: /etc/shorewall/init: SMC_ADDR=10.1.10.11 /etc/shorewall/rules: test:debug net:&{SMC_ADDR} fw A second form is also available beginning with Shorewall 4.5.11 %{variable} Unlike with the first form, this form does not require the variable to be set. If the variable is empty, the generated script will supply the all-zeros address (0.0.0.0 in IPv4 and :: in IPv6). In most cases, the compiler simply omits rules containing matches on the all-zeros address. Example: /etc/shorewall/init: SMC_ADDR=10.1.10.11 /etc/shorewall/rules: test:debug net:%{SMC_ADDR} fw For a particular address variable, all references must use the same prefix character ('&' or '%'). Otherwise, the following error message is raised: ERROR: Mixed required/optional usage of address variable variable Run-time address variables may be used in the SOURCE and DEST column of the following configuration files: shorewall-accounting (5) Action files shorewall-blrules (5) Macro files shorewall-mangle (5) shorewall-nat(5) shorewall-rules (5) They may also appear in the ORIGDEST column of: shorewall-accounting (5) Macro files Action files shorewall-rules (5) For optional interfaces, if the interface is not usable at the time that the firewall starts, one of two approaches are taken, depending on the context: the all-zero address will be used (0.0.0.0 in IPv4 and :: in IPv6), resulting in no packets matching the rule (or all packets if used with exclusion). the entire rule is omitted from the ruleset. Beginning with Shorewall 4.5.1, Run-time Gateway Variables in the form of a percent sign ('%') followed by a logical interface name are also supported. These are expanded at run-time to the gateway through the named interface. For optional interfaces, if the interface is not usable at the time that the firewall starts, the nil address will be used (0.0.0.0 in IPv4 and :: in IPv6), resulting in no packets matching the rule. Run-time gateway variables may be used in the SOURCE and DEST columns of the following configuration files: shorewall-accounting (5) Action files shorewall-blrules (5) Macro files shorewall-mangle (5) shorewall-nat(5) (As a qualifier to the INTERFACE). shorewall-routes (5) shorewall-rules (5) Example: %eth0 would represent the IP address of the gateway out of eth0. If there is no gateway out of the named interface, rules containing the intefaces's run-time gateway variable are omitted.
Action Variables Action variables were introduced in Shorewall 4.4.16 and may be accessed within the body of an action. Parameter variables Parameter variables expand to the value of the corresponding action parameter. $1 is the first parameter, $2 is the second parameter and so on. Chain name Beginning with Shorewall 4.5.10, $0 expands to the name of the action chain. Shorewall generates a separate chain for each unique (action,log-level,log-tag,parameters) tupple. The first such chain has the same name as the action itself. Subsequent chains are formed by prepending '%' to the action name and appending a number to insure uniqueness. For an action called 'Action', the chains would be Action, %Action, %Action0, %Action1 and so on.
Shorewall Variables Shorewall Variables were introduced in Shorewall 4.5.11. To insure uniqueness, these variables start with the character @; the name of the variable must be enclosed in {...} when the following character is alphanumeric or is an underscore ("_"). With the exception of @0 (or it's alias @chain), Shorewall variables may only be used within an action body. Prior to Shorewall 4.5.13, Shorewall variables are read-only. Beginning with Shorewall 4.5.13, their values may be altered using the ?SET directive. The Shorewall variables are: @0 and @chain (@{0} and @{chain}) Expands to the name of the current chain. Unlike $0, @0 has all non-alphanumeric characters except underscore removed. Also unlike $0, @0 may be used in SWITCH columns in configuration files. @1, @2, ... (@{1}, @{2}, ... These are synonyms for the Action parameter variables $1, $2, etc. @loglevel (@{loglevel}) Expands to the log level specified when the action was invoked. @logtag (@{logtag}) Expands to the log tag specified when the action was invoked. @disposition (@{disposition}) Added in Shorewall 4.5.13. When a non-inlined action is entered, this variable is set to the empty value. When an inline action is entered, the variable's value is unchanged. @caller (@{caller}) Added in Shorewall 4.5.13. Within an action, expands to the name of the chain that invoked the action. Beginning with Shorewall 4.5.13, the values of @chain and @disposition are used to generated the --log-prefix in logging rules. When either is empty, the historical value is used to generate the --log-prefix. Within an action body, if a parameter is omitted in a DEFAULTS statement, then the value of the corresponding action and Shorewall variables is '-', while if the parameter is specified as '-' in the parameter list, the value of the action/Shorewall variable is '', if it is expanded before the DEFAULTS statement. Additionally, when an expression is evaluated, the value 0 evaluates as false, so '?IF @n' and '?IF $n' fail if the nth parameter is passed with value zero. To make testing of the presense of parameters more efficient and uniform, an new function has been added in Shorewall 5.0.7 for use in ?IF and ?ELSEIF: ?IF [!] passed(<variable>) where <variable> is an action or Shorewall variable. 'passed(@n)' and 'passed($n)' evaluate to true if the nth parameter is not empty and its contents are other than '-'. If '!' is present, the result is inverted. In this simple form, the expression is evaluated by the compiler without having to invoke the (expensive) Perl exec() function. The 'passed' function may also be used in more complex expressions, but exec() will be invoked to evaluate those expressions.
Conditional Entries Beginning with Shorewall 4.5.2, lines in configuration files may be conditionally included or omitted based on the setting of Shell variables. The general form is: ?IF $variable <lines to be included if $variable is non-empty and non-zero> ?ELSE <lines to be omitted if $variable is non-empty and non-zero> ?ENDIF The compiler predefines two special variables that may only be used in ?IF lines: __IPV4 True if this is an IPv4 compilation __IPV6 True if this is an IPv6 compilation. Unless variable is one of these pre-defined ones, it is searched for in the following places in the order listed. the compiler's environmental variables. variables set in /etc/shorewall/params. options set in /etc/shorewall/shorewall.conf. options set in the shorewallrc file when Shorewall Core was installed. Beginning with Shorewall 4.5.11, the compiler's environmental variables are search last rather than first. If the variable is still not found: if it begins with '__', then those leading characters are stripped off. the variable is then searched for in the defined capabilities. The current set of capabilities may be obtained by the command shorewall show capabilities (the capability names are in parentheses). If it is not found in any of those places, the variable is assumed to have a value of 0 (false) in Shorewall versions prior to 4.5.11. In 4.5.11 and later, it is assumed to have the value '' (an empty string, which also evaluates to false). The setting in /etc/shorewall/params may be overridden at runtime, provided the setting in /etc/shorewall/params is done like this: [ -n "${variable:=0}" ] or like this: [ -n "${variable}" ] || variable=0 Either of those will set variable to 0 if it is not set to a non-empty value in the environment. The setting can be overridden at runtime: variable=1 shorewall restart -c # use -c to force recompilation if AUTOMAKE=Yes in /etc/shorewall/shorewall.conf The ?ELSE may be omitted if there are no lines to be omitted. The test may also be inverted using '!': ?IF ! $variable <lines to be omitted if $variable is non-empty and non-zero> ?ELSE <lines to be included if $variable is non-empty and non-zero> ?ENDIF Conditional entries may be nested but the number of ?IFs must match the number of ?ENDs in any give file. INCLUDE directives are ignored in omitted lines. ?IF $variable1 <lines to be included if $variable1 is non-empty and non-zero> ?IF $variable2 <lines to be included if $variable1 and $variable2 are non-empty and non-zero> ?ELSE <lines to be omitted if $variable1 is non-empty and non-zero and if $variable2 is empty or zero> ?ENDIF <lines to be included if $variable1 is non-empty and non-zero> ?ELSE <lines to be omitted if $variable is non-empty and non-zero> ?ENDIF Beginning with Shorewall 4.5.6, rather than a simple variable in ?IF directives, Perl-compatible expressions are allowed (after the Shorewall compiler expands all variables, the resulting expression is then evaluated by Perl). Variables in the expressions are as described above. Example: ?IF $BLACKLIST_LOGLEVEL == 6 && ! __LOG_OPTIONS Additionally, a ?ELSIF directive is supported. Example: ?IF expression-1 <lines to be included if expression-1 evaluates to true (non-empty and non-zero) ?ELSIF expression1-2 <lines to be included if expression-1 evaluates to false (zero or empty) and expression-2 evaluates to true ?ELSIF expression-3 <lines to be included if expression-1 and expression-2 both evalute to false and expression-3 evalutes to true ?ELSE <lines to be included if all three expressions evaluate to false. ?ENDIF Beginning in Shorewall 5.0.7, an error can be raised using the ?ERROR directive: ?ERROR message Variables in the message are evaluated and the result appears in a standard Shorewall ERROR: message. Example from the 5.0.7 action.GlusterFS: ?if @1 !~ /^\d+/ || ! @1 || @1 > 1024 ?error Invalid value for Bricks (@1) ?elsif @2 !~ /^[01]$/ ?error Invalid value for IB (@2) ?endif The above code insures that the first action paramater is a non-zero number <= 1024 and that the second parameter is either 0 or 1. If 2000 is passed for the first parameter, the following error message is generated: ERROR: Invalid value for Bricks (2000) /usr/share/shorewall/action.GlusterFS (line 15) from /etc/shorewall/rules (line 45) In Shorewall 5.0.8, ?WARNING and ?INFO directives were added. ?WARNING message ?INFO message ?WARNING message produces a standard Shorewall WARNING: message, while ?INFO produces a similar message which is prefaced by INFO: rather than WARNING:. Both write the message to STDERR. The message is also written to the STARTUP_LOG, if any, provided that the command is start, try, restart, reload, refresh, or one of the safe-* commands.
Embedded Shell and Perl Earlier versions of Shorewall offered extension scripts to allow users to extend Shorewall's functionality. Extension scripts were designed to work under the limitations of the Bourne Shell. With the current Perl-based compiler, Embedded scripts offer a richer and more flexible extension capability. While inline scripts may be written in either Shell or Perl, those written in Perl have a lot more power. They may be used in all configuration files except /etc/shorewall/params and /etc/shorewall/shorewall.conf. Note:In this section, '[' and ']' are meta-characters which indicate that what they enclose is optional and may be omitted. Single line scripts take one of the following forms: [?]PERL <perl script> [?]SHELL <shell script> The optional leading question mark (?) is allowed in Shorewall 4.5.5 and later. Shell scripts run in a child shell process and their output is piped back to the compiler which processes that output as if it were embedded at the point of the script. Example: The following entries in /etc/shorewall/rules are equivalent:SHELL for z in net loc dmz; do echo "ACCEPT $z fw tcp 22"; doneACCEPT net fw tcp 22 ACCEPT loc fw tcp 22 ACCEPT dmz fw tcp 22 Perl scripts run in the context of the compiler process using Perl's eval() function. Perl scripts are implicitly prefixed by the following: package Shorewall::User; use Shorewall::Config ( qw/shorewall/ ); To produce output that will be processed by the compiler as if it were embedded in the file at the point of the script, pass that output to the Shorewall::Config::shorewall() function. The Perl equivalent of the above SHELL script would be:PERL for ( qw/net loc dmz/ ) { shorewall "ACCEPT $_ fw tcp 22"; }A couple of more points should be mentioned: Compile-time extension scripts are also implicitly prefixed by "package Shorewall::User;". A compile extension script is supported. That script is run early in the compilation process and allows users to load additional modules and to define data and functions for use in subsequent embedded scripts and extension scripts. Manual Chains may be added in the compile extension script.. Multi-line scripts use one of the following forms:[?]BEGIN SHELL <shell script> [?]END [ SHELL ][?]BEGIN PERL [;] <perl script> [?]END [ PERL ] [;] The optional leading question mark (?) is allowed in Shorewall 4.5.5 and later.
Using DNS Names I personally recommend strongly against using DNS names in Shorewall configuration files. If you use DNS names and you are called out of bed at 2:00AM because Shorewall won't start as a result of DNS problems then don't say that you were not forewarned. Host addresses in Shorewall configuration files may be specified as either IP addresses or DNS Names. DNS names in iptables rules aren't nearly as useful as they first appear. When a DNS name appears in a rule, the iptables utility resolves the name to one or more IP addresses and inserts those addresses into the rule. So changes in the DNS->IP address relationship that occur after the firewall has started have absolutely no effect on the firewall's rule set. For some sites, using DNS names is very risky. Here's an example: teastep@ursa:~$ dig pop.gmail.com ; <<>> DiG 9.4.2-P1 <<>> pop.gmail.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1774 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 7, ADDITIONAL: 0 ;; QUESTION SECTION: ;pop.gmail.com. IN A ;; ANSWER SECTION: pop.gmail.com. 300 IN CNAME gmail-pop.l.google.com. gmail-pop.l.google.com. 300 IN A 209.85.201.109 gmail-pop.l.google.com. 300 IN A 209.85.201.111 Note that the TTL is 300 -- 300 seconds is only 5 minutes. So five minutes later, the answer may change! So this rule may work for five minutes then suddently stop working: #ACTION SOURCE DEST PROTO DPORT POP(ACCEPT) loc net:pop.gmail.com If your firewall rules include DNS names then: If your /etc/resolv.conf is wrong then your firewall won't start. If your /etc/nsswitch.conf is wrong then your firewall won't start. If your Name Server(s) is(are) down then your firewall won't start. If your startup scripts try to start your firewall before starting your DNS server then your firewall won't start. Factors totally outside your control (your ISP's router is down for example), can prevent your firewall from starting. You must bring up your network interfaces prior to starting your firewall. Each DNS name must be fully qualified and include a minimum of two periods (although one may be trailing). This restriction is imposed by Shorewall to insure backward compatibility with existing configuration files. Valid DNS Names mail.shorewall.net shorewall.net. (note the trailing period). Invalid DNS Names mail (not fully qualified) shorewall.net (only one period) DNS names may not be used as: The server address in a DNAT rule (/etc/shorewall/rules file) In the ADDRESS column of an entry in /etc/shorewall/masq. In the /etc/shorewall/nat file. These restrictions are imposed by Netfilter and not by Shorewall.
Comma-separated Lists Comma-separated lists are allowed in a number of contexts within the configuration files. A comma separated list: Must not have any embedded white space.+ Valid: routefilter,dhcp,arpfilter Invalid: routefilter,     dhcp,     arpfilter If you use line continuation to break a comma-separated list, the comma must be the last thing on the continued line before '\' unless the continuation line has no leading white space. Entries in a comma-separated list may appear in any order.
Complementing an Address, Subnet, Protocol or Port List Where specifying an IP address, a subnet or an interface, you can precede the item with ! to specify the complement of the item. For example, !192.168.1.4 means any host but 192.168.1.4. There must be no white space following the !. Similarly, in columns that specify an IP protocol, you can precede the protocol name or number by "!". For example, !tcp means "any protocol except tcp". This also works with port lists, providing that the list contains 15 or fewer ports (where a port range counts as two ports). For example !ssh,smtp means "any port except 22 and 25". In Shorewall 4.4.19 and later, icmp type lists are supported but complementing an icmp type list is not supported. You may, however, complement a single icmp (icmp6) type.
Exclusion Lists Where a comma-separated list of addresses is accepted, an exclusion list may also be included. An exclusion list is a comma-separated list of addresses that begins with "!". Example: !192.168.1.3,192.168.1.12,192.168.1.32/27 The above list refers to "All addresses except 192.168.1.3, 192.168.1.12 and 192.168.1.32-192.168.1.63. Exclusion lists can also be added after a network address. Example: 192.168.1.0/24!192.168.1.3,192.168.1.12,192.168.1.32/27 The above list refers to "All addresses in 192.168.1.0-192.168.1.255 except 192.168.1.3, 192.168.1.12 and 192.168.1.32-192.168.1.63.
IP Address Ranges If you kernel and iptables have iprange match support, you may use IP address ranges in Shorewall configuration file entries; IP address ranges have the syntax <low IP address>-<high IP address>. Example: 192.168.1.5-192.168.1.12. To see if your kernel and iptables have the required support, use the shorewall show capabilities command: >~ shorewall show capabilities ... Shorewall has detected the following iptables/netfilter capabilities: NAT: Available Packet Mangling: Available Multi-port Match: Available Connection Tracking Match: Available Packet Type Match: Not available Policy Match: Available Physdev Match: Available IP range Match: Available <--------------
Protocol Number/Names and Port Numbers/Service Names Unless otherwise specified, when giving a protocol number you can use either an integer or a protocol name from /etc/protocols. Similarly, when giving a port number you can use either an integer or a service name from /etc/services. The rules compiler translates protocol names to protocol numbers and service names to port numbers itself. Also, unless otherwise documented, a protocol number/name can be preceded by '!' to specify "All protocols except this one" (e.g., "!tcp").
Port Ranges If you need to specify a range of ports, the proper syntax is <low port number>:<high port number>. For example, if you want to forward the range of tcp ports 4000 through 4100 to local host 192.168.1.3, the entry in /etc/shorewall/rules is: #ACTION SOURCE DESTINATION PROTO DPORT DNAT net loc:192.168.1.3 tcp 4000:4100 If you omit the low port number, a value of zero is assumed; if you omit the high port number, a value of 65535 is assumed. Also, unless otherwise documented, a port range can be preceded by '!' to specify "All ports except those in this range" (e.g., "!4000:4100"). Beginning with Shorewall 5.0.14, a hyphen ("-") may also be used to separate the two port numbers; when using service names, the colon must still be used. #ACTION SOURCE DESTINATION PROTO DPORT DNAT net loc:192.168.1.3 tcp 4000-4100
Port Lists In most cases where a port or port range may appear, a comma-separated list of ports or port ranges may also be entered. Shorewall requires the Netfilter multiport match capability if ports lists are used (see the output of "shorewall show capabilities"). Also, unless otherwise documented, a port list can be preceded by '!' to specify "All ports except these" (e.g., "!80,443"). Prior to Shorewall 4.4.4, port lists appearing in the shorewall-routestopped (5) file may specify no more than 15 ports; port ranges appearing in a list count as two ports each.
ICMP and ICMP6 Types and Codes When dealing with ICMP, the DEST PORT specifies the type or type and code. You may specify the numeric type, the numeric type and code separated by a slash (e.g., 3/4) or you may use a type name. Type names for IPv4 and their corresponding type or type/code are: echo-reply' => 0 destination-unreachable => 3 network-unreachable => 3/0 host-unreachable => 3/1 protocol-unreachable => 3/2 port-unreachable => 3/3 fragmentation-needed => 3/4 source-route-failed => 3/5 network-unknown => 3/6 host-unknown => 3/7 network-prohibited => 3/9 host-prohibited => 3/10 TOS-network-unreachable => 3/11 TOS-host-unreachable => 3/12 communication-prohibited => 3/13 host-precedence-violation => 3/14 precedence-cutoff => 3/15 source-quench => 4 redirect => 5 network-redirect => 5/0 host-redirect => 5/1 TOS-network-redirect => 5/2 TOS-host-redirect => 5/3 echo-request => 8 router-advertisement => 9 router-solicitation => 10 time-exceeded => 11 ttl-zero-during-transit => 11/0 ttl-zero-during-reassembly=> 11/1 parameter-problem => 12 ip-header-bad => 12/0 required-option-missing => 12/1 timestamp-request => 13 timestamp-reply => 14 address-mask-request => 17 address-mask-reply => 18 Type names for IPv6 and their corresponding type or type/code are: destination-unreachable => 1 no-route' => 1/0 communication-prohibited => 1/1 address-unreachable' => 1/3 port-unreachable' => 1/4 packet-too-big => 2 time-exceeded' => 3 ttl-exceeded' => 3 ttl-zero-during-transit => 3/0 ttl-zero-during-reassembly => 3/1 parameter-problem => 4 bad-header => 4/0 unknown-header-type => 4/1 unknown-option => 4/2 echo-request => 128 echo-reply => 129 router-solicitation => 133 router-advertisement => 134 neighbour-solicitation => 135 neighbour-advertisement => 136 redirect => 137 Shorewall 4.4 does not accept lists if ICMP (ICMP6) types prior to Shorewall 4.4.19.
Using MAC Addresses Media Access Control (MAC) addresses can be used to specify packet source in several of the configuration files. In order to control traffic to/from a host by its MAC address, the host must be on the same network as the firewall. To use this feature, your kernel must have MAC Address Match support (CONFIG_IP_NF_MATCH_MAC) included. MAC addresses are 48 bits wide and each Ethernet Controller has a unique MAC address. In GNU/Linux, MAC addresses are usually written as a series of 6 hex numbers separated by colons. MAC Address of an Ethernet Controller gateway:~ # ip link ls dev eth0 4: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc htb qlen 1000 link/ether 02:00:08:E3:FA:55 brd ff:ff:ff:ff:ff:ff gateway:~ # Because Shorewall uses colons as a separator for address fields, Shorewall requires MAC addresses to be written in another way. In Shorewall, MAC addresses begin with a tilde (~) and consist of 6 hex numbers separated by hyphens. In Shorewall, the MAC address in the example above would be written ~02-00-08-E3-FA-55. It is not necessary to use the special Shorewall notation in the /etc/shorewall/maclist file.
Rate Limiting (Rate and Burst) Shorewall supports rate limiting in a number of ways. When specifying a rate limit, both a rate and a burst value are given. Example from shorewall.conf (5): LOGLIMIT=10/minute:5 For each logging rule, the first time the rule is reached, the packet will be logged; in fact, since the burst is 5, the first five packets will be logged. After this, it will be 6 seconds (1 minute divided by the rate of 10) before a message will be logged from the rule, regardless of how many packets reach it. Also, every 6 seconds which passes, one of the bursts will be regained; if no packets hit the rule for 30 seconds, the burst will be fully recharged; back where we started. Shorewall also supports per-IP rate limiting. Another example from shorewall.conf (5): LOGLIMIT="s:5/min:5" Here, the leading "s:" indicates that logging is to be limited by source IP address ("d:" would indicate limiting by destination IP address). "s:" is followed by the rate (5 messages per minute) and the burst (5). The rate and limit arguments have the same meaning as in the example above.
TIME Columns Several of the files include a TIME colum that allows you to specify times when the rule is to be applied. Contents of this column is a list of timeelements separated by apersands (&). Each timeelement is one of the following: timestart=hh:mm[:ss] Defines the starting time of day. timestop=hh:mm[:ss] Defines the ending time of day. contiguous Added in Shoreawll 5.0.12. When timestop is smaller than timestart value, match this as a single time period instead of distinct intervals. See the Examples below. utc Times are expressed in Greenwich Mean Time. localtz Deprecated by the Netfilter team in favor of kerneltz. Times are expressed in Local Civil Time (default). kerneltz Added in Shorewall 4.5.2. Times are expressed in Local Kernel Time (requires iptables 1.4.12 or later). weekdays=ddd[,ddd]... where ddd is one of , , , , , or monthdays=dd[,dd],... where dd is an ordinal day of the month datestart=yyyy[-mm[-dd[hh[:mm[:ss]]]]] Defines the starting date and time. datestop=yyyy[-mm[-dd[hh[:mm[:ss]]]]] Defines the ending date and time. Examples: To match on weekends, use: weekdays=Sat,Sun Or, to match (once) on a national holiday block: datestart=2016-12-24&datestop=2016-12-27 Since the stop time is actually inclusive, you would need the following stop time to not match the first second of the new day: datestart=2016-12-24T17:00&datestop=2016-12-27T23:59:59 During Lunch Hour The fourth Friday in the month: weekdays=Fri&monthdays=22,23,24,25,26,27,28 Matching across days might not do what is expected. For instance, weekdays=Mon&timestart=23:00&timestop=01:00 Will match Monday, for one hour from midnight to 1 a.m., and then again for another hour from 23:00 onwards. If this is unwanted, e.g. if you would like 'match for two hours from Montay 23:00 onwards' you need to also specify the contiguous option in the example above.
Switches There are times when you would like to enable or disable one or more rules in the configuration without having to do a shorewall reload or shorewall restart. This may be accomplished using the SWITCH column in shorewall-rules (5) or shorewall6-rules (5). Using this column requires that your kernel and iptables include Condition Match Support and you must be running Shorewall 4.4.24 or later. See the output of shorewall show capabilities and shorewall version to determine if you can use this feature. The SWITCH column contains the name of a switch. Each switch is initially in the off position. You can turn on the switch named switch1 by: echo 1 > /proc/net/nf_condition/switch1 You can turn it off again by: echo 0 > /proc/net/nf_condition/switch1 If you simply include the switch name in the SWITCH column, then the rule is enabled only when the switch is on. If you precede the switch name with ! (e.g., !switch1), then the rule is enabled only when the switch is off. Switch settings are retained over shorewall restart. Shorewall requires that switch names: begin with a letter and be composed of letters, digits, underscore ('_') or hyphen ('-'); and be 30 characters or less in length. Multiple rules can be controlled by the same switch. Example:
Forward port 80 to dmz host $BACKUP if switch 'primary_down' is on. #ACTION SOURCE DEST PROTO DPORT SPORT ORIGDEST RATE USER MARK CONNLIMIT TIME HEADERS SWITCH DNAT net dmz:$BACKUP tcp 80 - - - - - - - - primary_down
Logical Interface Names When dealing with a complex configuration, it is often awkward to use physical interface names in the Shorewall configuration. You need to remember which interface is which. If you move the configuration to another firewall, the interface names might not be the same. Beginning with Shorewall 4.4.4, you can use logical interface names which are mapped to the actual interface using the option in shorewall-interfaces (5). Here is an example: #ZONE INTERFACE OPTIONS net COM_IF dhcp,blacklist,tcpflags,optional,upnp,routefilter=0,nosmurfs,logmartians=0,physical=eth0 net EXT_IF dhcp,blacklist,tcpflags,optional,routefilter=0,nosmurfs,logmartians=0,proxyarp=1,physical=eth2 loc INT_IF dhcp,logmartians=1,routefilter=1,tcpflags,nets=172.20.1.0/24,physical=eth1 dmz VPS_IF logmartians=1,routefilter=0,routeback,physical=venet0 loc TUN_IF physical=tun+ In this example, COM_IF is a logical interface name that refers to Ethernet interface eth0, EXT_IF is a logical interface name that refers to Ethernet interface eth2, and so on. Here are a couple of more files from the same configuration: shorewall-masq (5): #INTERFACE SOURCE ADDRESS COMMENT Masquerade Local Network COM_IF 0.0.0.0/0 EXT_IF !206.124.146.0/24 206.124.146.179:persistent shorewall-providers (5) #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS COPY Avvanta 1 0x10000 main EXT_IF 206.124.146.254 loose,fallback INT_IF,VPS_IF,TUN_IF Comcast 2 0x20000 main COM_IF detect balance INT_IF,VPS_IF,TUN_IF Note in particular that Shorewall translates TUN_IF to tun* in the COPY column.
Optional and Required Interfaces Normally, Shorewall assumes that all interfaces described in shorewall-interfaces (5) are going to be in an up and usable state when Shorewall starts or restarts. You can alter that assumption by specifying the optional option in the OPTIONS column. When an interface is marked as optional, Shorewall will determine the interface state at start, reload and restart and adjust its configuration accordingly. The arp_filter, arp_ignore, routefilter, logmartians, proxyarp and sourceroute options are not enforced when the interface is down, thus avoiding an error message such as:WARNING: Cannot set Martian logging on ppp0 If the interface is associated with a provider in shorewall-providers (5), start, reload and restart will not fail if the interface is not usable. When DETECT_DNAT_IPADDRS=Yes in shorewall.conf (5), DNAT rules in shorewall-rules (5) involving the interface will be omitted when the interface does not have an IP address. If detect is specified in the ADDRESS column of an entry in shorewall-masq (5) then the firewall still startS if the optional interface in the INTERFACE column does not have an IP address. If you don't want the firewall to start unless a given interface is usable, then specify required in the OPTIONS column of shorewall-interfaces (5). If you have installed and configured the Shorewall-init package, then when the interface becomes available, an automatic attempt will be made to start the firewall.
Shorewall Configurations Shorewall allows you to have configuration directories other than /etc/shorewall. The shorewall check, start, reload and restart commands allow you to specify an alternate configuration directory and Shorewall will use the files in the alternate directory rather than the corresponding files in /etc/shorewall. The alternate directory need not contain a complete configuration; those files not in the alternate directory will be read from /etc/shorewall. Shorewall requires that the file /etc/shorewall/shorewall.conf to always exist. Certain global settings are always obtained from that file. If you create alternative configuration directories, do not remove /etc/shorewall/shorewall.conf. This facility permits you to easily create a test or temporary configuration by copying the files that need modification from /etc/shorewall to a separate directory; modify those files in the separate directory; and specifying the separate directory in a shorewall start, shorewall reload or shorewall restart command (e.g., shorewall restart /etc/testconfig )
Saved Configurations Shorewall allows you to save the currently-running configuration in a form that permits it to be re-installed quickly. When you save the configuration using the shorewall save command, the running configuration is saved in a file in the /var/lib/shorewall directory. The default name of that file is /var/lib/shorewall/restore but you can specify a different name as part of the command. For example, the command shorewall save standard will save the running configuration in /var/lib/shorewall/standard. A saved configuration is re-installed using the shorewall restore command. Again, that command normally will restore the configuration saved in /var/lib/shorewall/restore but as with the save command, you can specify a different file name in the command. For example, shorewall restore standard will re-install the configuration saved in /var/lib/shorewall/standard. By permitting you to save different configurations under different names, Shorewall provides a means for quickly switching between these different saved configurations. As mentioned above, the default configuration is called 'restore' but like most things in Shorewall, that default can be changed. The default name is specified using the RESTOREFILE option in /etc/shorewall/shorewall.conf. The default saved configuration is used by Shorewall in a number of ways besides in the restore command; to avoid surprises, I recommend that you read the Shorewall Operations documentation section about saved configurations before creating one.
shorewall-docs-xml-5.0.15/survey-200603.xml0000644000000000000000000005076613020330134016636 0ustar rootroot
The Shorewall Environment Survey 2006 Paul Gear 2006 Paul D. Gear 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.
Background In early March 2006, i embarked on the journey of surveying Shorewall users. Initially this sprang from my own curiosity: i thought that some of the systems at work on which i use Shorewall may be bigger and more complex than most others, and i wanted to find out if there are people out there who use Shorewall like i do. As started thinking about the questions i would ask, i realised that if i asked the right questions, i could create a survey that might help the Shorewall project better to understand its users. I used Zoomerang to create the survey. It has a number of tools that make it easy to create useful surveys. To get the most benefit out of Zoomerang, you have to subscribe to their professional version. In the long term, it would be great to have a practical free software alternative that could be self-hosted. A number of free content management systems such as Drupal have a survey module, but when i last looked at them, they were more limited and harder to use than Zoomerang.
Survey and results links The survey is still open as of this writing, and can be accessed at the Zoomerang survey page. Further participation is encouraged. The figures quoted in this document reflect the results at the time of writing. The public results of the survey are available. If you complete the survey, a link to the results is provided on the thank you page.
Sample size An important note about this survey is that it has a small sample size (103 complete responses at the time of writing), so any conclusions drawn should be considered tentative. To speculate on the overall number of users that this sample represents, the Debian popularity contest reports 478 installations of Shorewall, 285 of which are in active use. Assuming that the popularity contest represents 30% of the Debian installed base (likely ridiculously optimistic), this would make the number of active Shorewall systems approximately: 285 / 0.3 (percentage of Debian systems) / 0.26 (percentage Debian holds of all distributions) = 3654 (rounding up the numbers to the nearest whole, and assuming the percentages extrapolate regularly) This means that our survey represents a maximum of 2.8% of the installed base, likely far less.
Other possible inaccuracies Additionally, since the survey was open to multiple responses, it could be that some people answered the questions about themselves more than once, despite instructions to the contrary in the introduction page. There is an error in the released version of the survey for question 15 (RAM size): it was a multiple choice question rather than single choice, and thus there were more results than expected. The number of errors doesn't seem to be significant. If you notice any errors in this analysis, or have any suggestions about how to improve it, please contact the author at pgear@shorewall.net.
Results analysis
Organisations Small organisations dominate the spectrum of Shorewall users. The largest group (44%) was 1-10 users - mostly SOHO LANs based on the comments in that section. Ninety percent (90%) of Shorewall installations are in organisations with less than 500 users. The results for the questions about organisational size and the number of users serviced by Shorewall match fairly closely, which seems to indicate that the majority of Shorewall systems are servicing the entire organisation in question. The vast majority (84%) of Shorewall systems are administered by only one person. One question that needs to be asked is, "Why?" Possible reasons for this might be: Most of the organisations in which it is used are small, thus most of them will only have one person skilled in the area of packet filtering firewalls. This seems a likely scenario, but a cross correlation of the results of questions 1 and 2 with question 3 indicates that the number of administrators is fairly uniform across all sizes of organisation and user base. Shorewall works so well that people don't have to touch it much. Obviously, this is the preferred interpretation of the Shorewall project team. :-) Shorewall is too hard for new users to comprehend, so one skilled person in an organisation tends to get the job maintaining it. Equally obviously, this is a non-preferred interpretation. :-) However, being a firewall generator, Shorewall is not likely to attract the same sort of users as a web browser or music player. Shorewall administrators are a closed bunch and don't like sharing their job around. Given the nature of firewalls and packet filtering, this doesn't seem far-fetched. There doesn't seem to be an easy answer to thus question. In retrospect, since there were no responses indicating 10 or more administrators, i could have made the granularity of this question better. A question about a person's role in the organisation may also have been helpful. Possibly we could follow up with a smaller survey, specifically about the people and organisations who use Shorewall.
Users Unsurprisingly, 97% of survey respondents were male. Or to put it another way: surprisingly, there are actually 3 female Shorewall users. :-) Being male seems to be an occupational hazard of life in the IT industry, and even more so in the more "nerdy" specialisations like Linux and security. The largest age group of users is 25-34 years (42% of all respondents). There were no retirees (65 and over) or minors (under 18) in the responses. The distribution of the remaining age groups was fairly even. The largest group of users in terms of education was those with a Bachelor's degree, followed by those with a high school education. Fifty-seven percent (57%) of Shorewall users have a Bachelor's degree or better. Many users' highest qualifications are not in an IT-related discipline (42%). This remains fairly constant across the spectrum when correlated with the highest level of qualifications. Those who do not claim IT as their highest discipline come from a wide variety of other fields, including agriculture, art, business, chemistry, education, various forms of engineering, law, mathematics, physics, and theology. Almost two-thirds of users (62%) use Shorewall as part of their paid employment. Of these, 12% (7 of 58) do not use Shorewall as part of their official duties. Cross correlation with level of education revealed no major variance in this trend depending on level of education. The majority of users (73%) began using the Internet in the 1990s. A smaller majority (61%) have been using the Internet for more than 12 years (1994 or earlier). (The single response indicating use of the Internet (then ARPANET) since the 1960s seems to be an error.) The majority of users (70%) began using Linux after it reached a certain stage of maturity - around or after the release of kernel 2.0 (1996). However, nearly all respondents (97%) have been using Linux for 5 years or more, with almost half (47%) having 10 or more years experience with it. It seems fair to say that as a rule, Shorewall attracts people with plenty of experience. Around one third of users (30%) have been using Shorewall for more than 5 years, with two-thirds (66%) having used it since the 1.x series (2003 or earlier). It seems fair to say that Shorewall users seem to stick with the product once they are familiar with it. On the other hand, it seems that Shorewall is not attracting large numbers of new users, which is a concern for the future of the project.
Hardware Ninety-three percent (93%) of users run Shorewall on i386 family hardware, with a further 6% running it on x86-64/EM64T platforms. One response was received indicating use of Shorewall on MIPS (Linksys WRT platform). No responses were received for any other hardware platform. While it is not surprising that Intel would be dominant, given their market share, it seems a little skewed not to have any representatives of other architectures. A good spread of CPU power is shown in the survey responses. The largest group was 400-999 MHz (30%), with only 16% of responses indicating less than 400 MHz, and the same number greater than 2500 MHz. A number of responses in the field for additional information suggested that the machines used were either recycled desktops, or systems that were specifically built to do the job, and had been running in that role for a number of years. RAM configuration seemed to mostly mirror CPU power, with a slight bias towards higher RAM figures. The majority (52%) of systems have between 256 and 1023 MB; only 11% of systems have less than 128 MB; 28% have 1024 MB or more. This reflects the more server-oriented workload that many Shorewall systems run (see the section on server roles below). Shorewall systems on the whole tend toward smaller OS hard disks, with 42% having disks 39 GB or smaller. The largest group by a small margin was 80-159 GB at 23%, with 10-39 GB and 0-9 GB coming in a close second and third at 22% and 20% respectively.
Network The majority of Shorewall systems (82%) use between two and four network interfaces. The number of devices connected to systems closely mirrors the size of the organisations in which they are used, with 95% of systems connecting less than 500 devices, and the largest group (41%) connecting 2-10 other devices. Ninety percent (90%) of Shorewall systems are connected to 100 Mbps or faster local networks. Most systems have a broadband Internet connection or better, with only 7% having 512 Kbps or less, and 51% having 10 Mbps or better. DSL is the most common form of Internet connection, with over half the responses (51%).
Software The most popular Linux distribution on which users run Shorewall is Debian (26% of respondents), followed by a group consisting of Fedora Core (16%), Red Hat 9 and earlier (13%) and Red Hat Enterprise and derivatives (12%). The next group consists of SUSE (9%), Slackware (8%), Gentoo (6%), and LEAF/Bering (5%). The message about maintaining an up-to-date Shorewall system seems to have gotten through, with 61% of respondents running the latest stable version (3.0), and an additional 22% running the previous stable version (2.4). Only 14% of users are running unsupported older versions (2.2 and previous). The most common roles played by Shorewall systems are: External firewall/router (78%) DNS name server (61%) DHCP server (59%) Internal firewall/router (56%) Time server (55%)
Comments from users Following is a sample of the comments we received about the survey - they have been carefully sanitised to make us look good. ;-) More power to Shorewall! Shorewall Rocks! I'm amazed how easy it is every time I need to do something, even if it's been 6+ months since the last change! :) Good job and a great product. Shorewall is good, I have recommended it to several people, mostly working in the University & academic areas. Thanks to everyone who contributes to Shorewall. That's a *great* piece of software! Shorewall has been incredible. Tom has given so much of himself to this project, I can only say thank you from one person, I look up to people like him. I have used Shorewall for many systems, I am a contractor that "set up shop" all over the world. Depending on the available ISP services, this project has been flexible in every situation to date. Also, depending on my needs, it has done the same. "IP Tables made easy" is really an accurate description. I'm quite interested in seeing what the 'cross section' of Shorewall users are like. It's made my life a lot easier over the years. Thank you.
Lessons learned about survey technique
Treat surveys like releasing free software test on a small group before you go public release early and often make branches (copies) when you release alpha and beta versions merge the changes from branches (lessons you learned in those versions) into the main trunk
Start small and work towards what you want to know with specific, concrete questions I tried to do everything in one survey, and ended up confusing some people. For example, despite the fact that the survey's start page clearly says "Please answer the questions for only ONE SYSTEM running Shorewall", i received multiple comments saying that they couldn't answer accurately because they ran more than one Shorewall system. It would have been better to have two surveys: one about the people who use Shorewall, and another about the systems they run it on. Better still would be for Shorewall to automatically collect appropriate information about systems and request permission to send it to a central location for statistical analysis. How to do this and maintain users' privacy and obtain their permission efficiently is not an easy problem with a product like Shorewall, which doesn't actually stay running on user systems, and doesn't present a user interface per se.
Be prepared beforehand Within hours of the survey's release, 50% of the results were in. Within 3 days, it hit the Zoomerang basic survey limit of 100 responses. I had not planned for such an enthusiastic response, and also was too busy to download all of the results before the survey's time limit expired. Fortunately, i was able to obtain funding to allow a Zoomerang "pro" subscription to be purchased and thus provide advanced analysis, and complete downloads of the results.
Incrementally improve your surveys The final version of this survey was released still with a few bugs. The released version was just a copy of my master survey, and i continued to maintain the master after the final survey was released (and during this analysis), and i'm sure the next version will be even better.
Possible implications for the Shorewall project The users we have seem, on the whole, rather experienced, and very loyal. However, we don't seem to be attracting new users, despite new features such as multi-ISP support and integrated traffic shaping. The question about a GUI comes up frequently, and one wonders whether this is would make a significant difference in Shorewall's uptake with new users. Shorewall seems to be predominantly used in small, i386-based environments such as home LANs and small businesses. It seems to be frequently combined with a number of other basic functions, such as DNS, DHCP, NTP, VPN. Integration with (or perhaps providing a plug-in module for) a dedicated gateway distribution such as ipcop, Smoothwall, or Clark Connect might be a good way to serve the needs of our users.
Possible implications for other free software projects The essence of free software is software by the people, for the people. Knowing who the people are and what their needs are is critical to this process. If at all possible, build statistics gathering into your application, and find a way to encourage people to use it. This concrete data will help confirm the results of any surveys you might conduct.
shorewall-docs-xml-5.0.15/SimpleBridge.xml0000644000000000000000000001313013020330134017077 0ustar rootroot
Shorewall and a Simple Bridge Tom Eastep 2004 2005 2006 Thomas M. Eastep 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.
Background Systems where Shorewall runs normally function as routers. In the context of the Open System Interconnect (OSI) reference model, a router operates at layer 3. Shorewall may also be deployed on a GNU Linux System that acts as a bridge. Bridges are layer-2 devices in the OSI model (think of a bridge as an Ethernet switch). Some differences between routers and bridges are: Routers determine packet destination based on the destination IP address while bridges route traffic based on the destination MAC address in the Ethernet frame. As a consequence of the first difference, routers can be connected to more than one IP network while a bridge may be part of only a single network. A router cannot forward broadcast packets while a bridge can.
Application There are cases where you want to create a bridge to join two or more LAN segments and you don't need to restrict the traffic between those segments. This is the environment that is described in this article. If you do need to restrict traffic through the bridge, please refer to the Shorewall Bridge/Firewall documentation. Also please refer to that documentation for information about how to create a bridge. The following diagram shows a firewall for two bridged LAN segments. This is fundamentally the Two-interface Firewall described in the Two-interface Quickstart Guide. The bridge-specific changes are restricted to the /etc/shorewall/interfaces file. Older configurations that specify an interface name in the SOURCE column of /etc/shorewall/masq will also need to change that file. This example illustrates the bridging of two Ethernet devices but the types of the devices really isn't important. What is shown here would apply equally to bridging an Ethernet device to an OpenVPN tap device (e.g., tap0) or to a wireless device (ath0 or wlan0). /etc/shorewall/interfaces: ?FORMAT 2 #ZONE INTERFACE OPTIONS net eth0 ... loc br0 routeback,bridge,... So the key points here are: The loc interface is br0. Neither eth1 nor eth2 have IP addresses and neither are mentioned in the Shorewall configuration. The routeback and bridge options is specified for br0. The default gateway for hosts in the local segments will be 10.0.1.254 — the IP address of the bridge itself. Your entry in /etc/shorewall/masq should be unchanged: #INTERFACE SOURCE ADDRESS eth0 10.0.1.0/24 ... # 10.0.1.0/24 is the local network on LAN A and LAN B When running Shorewall 5.0.14 or later, the equivalent /etc/shorewall/snat is: #ACTION SOURCE DEST PROTO PORT MASQUERADE 10.0.1.0/24 eth0
shorewall-docs-xml-5.0.15/two-interface.xml0000644000000000000000000017245313020330134017316 0ustar rootroot
Basic Two-Interface Firewall Tom Eastep 2002-2009 Thomas M. Eastep 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. This article applies to Shorewall 4.4 and later. If you are running a version of Shorewall earlier than Shorewall 4.4.0 then please see the documentation for that release.
Introduction Setting up a Linux system as a firewall for a small network is a fairly straight-forward task if you understand the basics and follow the documentation. This guide doesn't attempt to acquaint you with all of the features of Shorewall. It rather focuses on what is required to configure Shorewall in its most common configuration: Linux system used as a firewall/router for a small local network. Single public IP address. If you have more than one public IP address, this is not the guide you want -- see the Shorewall Setup Guide instead. Internet connection through cable modem, DSL, ISDN, Frame Relay, dial-up ... Here is a schematic of a typical installation:
Common two interface firewall configuration
If you edit your configuration files on a Windows system, you must save them as Unix files if your editor supports that option or you must run them through dos2unix before trying to use them. Similarly, if you copy a configuration file from your Windows hard drive to a floppy disk, you must run dos2unix against the copy before using it with Shorewall. Windows Version of dos2unix Linux Version of dos2unix
System Requirements Shorewall requires that you have the iproute/iproute2 package installed (on RedHat, the package is called iproute). You can tell if this package is installed by the presence of an ip program on your firewall system. As root, you can use the which command to check for this program: [root@gateway root]# which ip /sbin/ip [root@gateway root]# I recommend that you first read through the guide to familiarize yourself with what's involved then go back through it again making your configuration changes.
Conventions Points at which configuration changes are recommended are flagged with . Configuration notes that are unique to Debian and it's derivatives are marked with .
PPTP/ADSL If you have an ADSL Modem and you use PPTP to communicate with a server in that modem, you must make the changes recommended here in addition to those detailed below. ADSL with PPTP is most commonly found in Europe, notably in Austria.
Shorewall Concepts The configuration files for Shorewall are contained in the directory /etc/shorewall -- for simple setups, you will only need to deal with a few of these as described in this guide. After you have installed Shorewall, locate the two-interfaces samples: If you installed using an RPM, the samples will be in the Samples/two-interfaces/ subdirectory of the Shorewall documentation directory. If you don't know where the Shorewall documentation directory is, you can find the samples using this command: ~# rpm -ql shorewall | fgrep two-interfaces /usr/share/doc/packages/shorewall/Samples/two-interfaces /usr/share/doc/packages/shorewall/Samples/two-interfaces/interfaces /usr/share/doc/packages/shorewall/Samples/two-interfaces/masq /usr/share/doc/packages/shorewall/Samples/two-interfaces/policy /usr/share/doc/packages/shorewall/Samples/two-interfaces/rules /usr/share/doc/packages/shorewall/Samples/two-interfaces/zones ~# When running Shorewall 5.0.14 or later: ~# rpm -ql shorewall | fgrep three-interfaces /usr/share/doc/packages/shorewall/Samples/three-interfaces /usr/share/doc/packages/shorewall/Samples/three-interfaces/interfaces /usr/share/doc/packages/shorewall/Samples/three-interfaces/policy /usr/share/doc/packages/shorewall/Samples/three-interfaces/rules /usr/share/doc/packages/shorewall/Samples/three-interfaces/snat /usr/share/doc/packages/shorewall/Samples/three-interfaces/zones ~# If you installed using the tarball, the samples are in the Samples/two-interfaces directory in the tarball. If you installed using a Shorewall 3.x .deb, the samples are in /usr/share/doc/shorewall/examples/two-interfaces. You must install the shorewall-doc package. If you installed using a Shorewall 4.x .deb, the samples are in /usr/share/doc/shorewall/examples/two-interfaces. You do not need the shorewall-doc package to have access to the samples. Note to Debian and Ubuntu Users If you install using the .deb, you will find that your /etc/shorewall directory is practially empty. This is intentional. The released configuration file skeletons may be found on your system in the directory /usr/share/doc/shorewall/default-config. Simply copy the files you need from that directory to /etc/shorewall and modify the copies. As each file is introduced, I suggest that you look at the actual file on your system and that you look at the man page for that file. For example, to look at the man page for the /etc/shorewall/zones file, type man shorewall-zones at a shell prompt. Note: Beginning with Shorewall 4.4.20.1, there are versions of the sample files that are annotated with the corresponding manpage contents. These files have names ending in '.annotated'. You might choose to look at those files instead. Shorewall views the network where it is running as being composed of a set of zones. In the two-interface sample configuration, the following zone names are used: #ZONE TYPE OPTIONS IN_OPTIONS OUT_OPTIONS fw firewall net ipv4 loc ipv4Zones are defined in the /etc/shorewall/zones file. Note that Shorewall recognizes the firewall system as its own zone - when the /etc/shorewall/zones file is processed, the name of the firewall zone is stored in the shell variable $FW which may be used to refer to the firewall zone throughout the Shorewall configuration. Rules about what traffic to allow and what traffic to deny are expressed in terms of zones. You express your default policy for connections from one zone to another zone in the /etc/shorewall/policy file. You define exceptions to those default policies in the /etc/shorewall/rules file. For each connection request entering the firewall, the request is first checked against the /etc/shorewall/rules file. If no rule in that file matches the connection request then the first policy in /etc/shorewall/policy that matches the request is applied. If there is a common action defined for the policy in /etc/shorewall/actions or /usr/share/shorewall/actions.std then that action is performed before the action is applied. The purpose of the common action is two-fold: It silently drops or rejects harmless common traffic that would otherwise clutter up your log — Broadcasts for example. If ensures that traffic critical to correct operation is allowed through the firewall — ICMP fragmentation-needed for example. The /etc/shorewall/policy file included with the two-interface sample has the following policies: #SOURCE DEST POLICY LOGLEVEL LIMIT loc net ACCEPT net all DROP info all all REJECT infoIn the two-interface sample, the line below is included but commented out. If you want your firewall system to have full access to servers on the Internet, uncomment that line. #SOURCE DEST POLICY LOGLEVEL LIMIT $FW net ACCEPT The above policy will: Allow all connection requests from your local network to the Internet Drop (ignore) all connection requests from the Internet to your firewall or local network Optionally accept all connection requests from the firewall to the Internet (if you uncomment the additional policy) reject all other connection requests. The word info in the LOG LEVEL column for the DROP and REJECT policies indicates that packets dropped or rejected under those policies should be logged at that level. It is important to note that Shorewall policies (and rules) refer to connections and not packet flow. With the policies defined in the /etc/shorewall/policy file shown above, connections are allowed from the loc zone to the net zone even though connections are not allowed from the loc zone to the firewall itself. Some people want to consider their firewall to be part of their local network from a security perspective. If you want to do this, add these two policies: #SOURCE DEST POLICY LOGLEVEL LIMIT loc $FW ACCEPT $FW loc ACCEPT At this point, edit your /etc/shorewall/policy and make any changes that you wish.
Network Interfaces The firewall has two network interfaces. Where Internet connectivity is through a cable or DSL Modem, the External Interface will be the Ethernet adapter that is connected to that Modem (e.g., eth0) unless you connect via Point-to-Point Protocol over Ethernet (PPPoE) or Point-to-Point Tunneling Protocol (PPTP) in which case the External Interface will be a ppp interface (e.g., ppp0). If you connect via a regular modem, your External Interface will also be ppp0. If you connect via ISDN, your external interface will be ippp0. Be sure you know which interface is your external interface. Many hours have been spent floundering by users who have configured the wrong interface. If you are unsure, then as root type ip route ls at the command line. The device listed in the last (default) route should be your external interface. Example: root@lists:~# ip route ls 192.168.1.1 dev eth0 scope link 192.168.2.2 dev tun0 proto kernel scope link src 192.168.2.1 192.168.3.0/24 dev br0 proto kernel scope link src 192.168.3.254 10.13.10.0/24 dev tun1 scope link 192.168.2.0/24 via 192.168.2.2 dev tun0 192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.254 206.124.146.0/24 dev eth0 proto kernel scope link src 206.124.146.176 10.10.10.0/24 dev tun1 scope link default via 206.124.146.254 dev eth0 root@lists:~# In that example, eth0 is the external interface. If your external interface is ppp0 or ippp0 then you will want to set CLAMPMSS=yes in /etc/shorewall/shorewall.conf. Your Internal Interface will be an Ethernet adapter (eth1 or eth0) and will be connected to a hub or switch. Your other computers will be connected to the same hub/switch (note: If you have only a single internal system, you can connect the firewall directly to the computer using a cross-over cable). Do not connect the internal and external interface to the same hub or switch except for testing.You can test using this kind of configuration if you specify the arp_filter option or the arp_ignore option in /etc/shorewall/interfaces for all interfaces connected to the common hub/switch. Using such a setup with a production firewall is strongly recommended against. Do not configure a default route on your internal interface. Your firewall should have exactly one default route via your ISP's Router. The Shorewall two-interface sample configuration assumes that the external interface is eth0 and the internal interface is eth1. If your configuration is different, you will have to modify the sample /etc/shorewall/interfaces file accordingly. While you are there, you may wish to review the list of options that are specified for the interfaces. Some hints: If your external interface is ppp0 or ippp0, you can replace the detect in the second column with a - (minus the quotes). If your external interface is ppp0 or ippp0 or if you have a static IP address, you can remove dhcp from the option list. If your internal interface is a bridge create using the brctl utility then you must add the routeback option to the option list.
IP Addresses Before going further, we should say a few words about Internet Protocol (IP) addresses. Normally, your ISP will assign you a single Public IP address. This address may be assigned via the Dynamic Host Configuration Protocol (DHCP) or as part of establishing your connection when you dial in (standard modem) or establish your PPP connection. In rare cases, your ISP may assign you a static IP address; that means that you configure your firewall's external interface to use that address permanently. However your external address is assigned, it will be shared by all of your systems when you access the Internet. You will have to assign your own addresses in your internal network (the Internal Interface on your firewall plus your other computers). RFC 1918 reserves several Private IP address ranges for this purpose: 10.0.0.0 - 10.255.255.255 172.16.0.0 - 172.31.255.255 192.168.0.0 - 192.168.255.255You will want to assign your addresses from the same sub-network (subnet). For our purposes, we can consider a subnet to consists of a range of addresses x.y.z.0 - x.y.z.255. Such a subnet will have a Subnet Mask of 255.255.255.0. The address x.y.z.0 is reserved as the Subnet Address and x.y.z.255 is reserved as the Subnet Broadcast Address. In Shorewall, a subnet is described using Classless InterDomain Routing (CIDR) notation with consists of the subnet address followed by /24. The 24 refers to the number of consecutive leading 1 bits from the left of the subnet mask. Range: 10.10.10.0 - 10.10.10.255 Subnet Address: 10.10.10.0 Broadcast Address: 10.10.10.255 CIDR Notation: 10.10.10.0/24 It is conventional to assign the internal interface either the first usable address in the subnet (10.10.10.1 in the above example) or the last usable address (10.10.10.254). One of the purposes of subnetting is to allow all computers in the subnet to understand which other computers can be communicated with directly. To communicate with systems outside of the subnetwork, systems send packets through a gateway (router). Your local computers (computer 1 and computer 2 in the above diagram) should be configured with their default gateway to be the IP address of the firewall's internal interface. The foregoing short discussion barely scratches the surface regarding subnetting and routing. If you are interested in learning more about IP addressing and routing, I highly recommend IP Fundamentals: What Everyone Needs to Know about Addressing & Routing, Thomas A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0 (link). The remainder of this guide will assume that you have configured your network as shown here: The default gateway for computer's 1 & 2 would be 10.10.10.254. Your ISP might assign your external interface an RFC 1918 address. If that address is in the 10.10.10.0/24 subnet then you will need to select a DIFFERENT RFC 1918 subnet for your local network.
IP Masquerading (SNAT) The addresses reserved by RFC 1918 are sometimes referred to as non-routable because the Internet backbone routers don't forward packets which have an RFC-1918 destination address. When one of your local systems (let's assume computer 1 in the above diagram) sends a connection request to an Internet host, the firewall must perform Network Address Translation (NAT). The firewall rewrites the source address in the packet to be the address of the firewall's external interface; in other words, the firewall makes it appear to the destination Internet host as if the firewall itself is initiating the connection. This is necessary so that the destination host will be able to route return packets back to the firewall (remember that packets whose destination address is reserved by RFC 1918 can't be routed across the Internet so the remote host can't address its response to computer 1). When the firewall receives a return packet, it rewrites the destination address back to 10.10.10.1 and forwards the packet on to computer 1. On Linux systems, the above process is often referred to as IP Masquerading but you will also see the term Source Network Address Translation (SNAT) used. Shorewall follows the convention used with Netfilter: Masquerade describes the case where you let your firewall system automatically detect the external interface address. SNAT refers to the case when you explicitly specify the source address that you want outbound packets from your local network to use. In Shorewall, both Masquerading and SNAT are configured with entries in the /etc/shorewall/masq file (/etc/shorewall/snat when running Shorewall 5.0.14 or later). You will normally use Masquerading if your external IP is dynamic and SNAT if the IP is static. If your external firewall interface is eth0, you do not need to modify the file provided with the sample. Otherwise, edit /etc/shorewall/masq or /etc/shorewall/snat and change it to match your configuration. If your external IP is static then, if you are running Shorewall 5.0.13 or earlier, you can enter our static IP in the third column in the /etc/shorewall/masq entry if you like although your firewall will work fine if you leave that column empty (Masquerade). Entering your static IP in column 3 (SNAT) makes the processing of outgoing packets a little more efficient. When running Shorewall 5.0.14 or later, the rule in /etc/shorewall/snat must be change from a MASQUERADE rule to an SNAT rule. #ACTION SOURCE DEST PROTO PORT SNAT(static-ip) ... If you are using the Debian package, please check your shorewall.conf file to ensure that the following is set correctly; if it is not, change it appropriately: IP_FORWARDING=On
Logging Shorewall does not maintain a log itself but rather relies on your system's logging configuration. The following commands rely on knowing where Netfilter messages are logged: shorewall show log (Displays the last 20 netfilter log messages) shorewall logwatch (Polls the log at a settable interval shorewall dump (Produces an extensive report for inclusion in Shorewall problem reports) It is important that these commands work properly because when you encounter connection problems when Shorewall is running, the first thing that you should do is to look at the Netfilter log; with the help of Shorewall FAQ 17, you can usually resolve the problem quickly. The Netfilter log location is distribution-dependent: Debian and its derivatives log Netfilter messages to /var/log/kern.log. Recent SuSE/OpenSuSE releases come preconfigured with syslog-ng and log netfilter messages to /var/log/firewall. For other distributions, Netfilter messages are most commonly logged to /var/log/messages. If you are running a distribution that logs netfilter messages to a log other than /var/log/messages, then modify the LOGFILE setting in /etc/shorewall/shorewall.conf to specify the name of your log. The LOGFILE setting does not control where the Netfilter log is maintained -- it simply tells the /sbin/shorewall utility where to find the log.
Kernel Module Loading Beginning in Shorewall 4.4.7, /etc/shorewall/shorewall.conf contains a LOAD_HELPERS_ONLY option which is set to in the samples. This causes Shorewall to attempt to load the modules listed in /usr/share/shorewall/helpers. In addition, it sets sip_direct_media=0 when loading the nf_conntrack_sip module. That setting is somewhat less secure than sip_direct_media=1, but it generally makes VOIP through the firewall work much better. The modules in /usr/share/shorewall/helpers are those that are not autoloaded. If your kernel does not support module autoloading and you want Shorewall to attempt to load all netfilter modules that it might require, then set LOAD_HELPERS_ONLY=No. That will cause Shorewall to try to load the modules listed in /usr/share/shorewall/modules. That file does not set sip_direct_media=0. If you need to modify either /usr/share/shorewall/helpers or /usr/share/shorewall/modules then copy the file to /etc/shorewall and modify the copy. Modify the setting of LOAD_HELPER_ONLY as necessary.
Port Forwarding (DNAT) One of your goals may be to run one or more servers on your local computers. Because these computers have RFC-1918 addresses, it is not possible for clients on the Internet to connect directly to them. It is rather necessary for those clients to address their connection requests to the firewall who rewrites the destination address to the address of your server and forwards the packet to that server. When your server responds, the firewall automatically performs SNAT to rewrite the source address in the response. The above process is called Port Forwarding or Destination Network Address Translation (DNAT). You configure port forwarding using DNAT rules in the /etc/shorewall/rules file. For forwarding connections from the net zone to a server in the loc zone, the general form of a simple port forwarding rule in /etc/shorewall/rules is: #ACTION SOURCE DEST PROTO DPORT DNAT net loc:<server local ip address>[:<server port>] <protocol> <port> If you want to forward traffic from the loc zone to a server in the loc zone, see Shorewall FAQ 2. Be sure to add your rules after the line that reads SECTION NEW. The server must have a static IP address. If you assign IP addresses to your local system using DHCP, you need to configure your DHCP server to always assign the same IP address to systems that are the target of a DNAT rule. Shorewall has macros for many popular applications. Look at the output of shorewall show macros to see what is available in your release. Macros simplify creating DNAT rules by supplying the protocol and port(s) as shown in the following examples. Web Server You run a Web Server on computer 2 in the above diagram and you want to forward incoming TCP port 80 to that system: #ACTION SOURCE DEST PROTO DPORT Web(DNAT) net loc:10.10.10.2 FTP Server You run an FTP Server on computer 1 so you want to forward incoming TCP port 21 to that system: #ACTION SOURCE DEST PROTO DPORT FTP(DNAT) net loc:10.10.10.1 For FTP, you will also need to have FTP connection tracking and NAT support in your kernel. For vendor-supplied kernels, this means that the ip_conntrack_ftp and ip_nat_ftp modules (nf_conntrack_ftp and nf_nat_ftp in later 2.6 kernels) must be loaded. Shorewall will automatically load these modules if they are available and located in the standard place under /lib/modules/<kernel version>/kernel/net/ipv4/netfilter. See the Shorewall FTP documentation for more information. A couple of important points to keep in mind: The Shorewall-provided macros assume that the service is using its standard port and will not work with a service listening on a non-standard port. You must test the above rule from a client outside of your local network (i.e., don't test from a browser running on computers 1 or 2 or on the firewall). If you want to be able to access your web server and/or FTP server from inside your firewall using the IP address of your external interface, see Shorewall FAQ #2. Many ISPs block incoming connection requests to port 80. If you have problems connecting to your web server, try the following rule and try connecting to port 5000. #ACTION SOURCE DEST PROTO DPORT DNAT net loc:10.10.10.2:80 tcp 5000 At this point, modify /etc/shorewall/rules to add any DNAT rules that you require. When testing DNAT rules like those shown above, you must test from a client OUTSIDE YOUR FIREWALL (in the 'net' zone). You cannot test these rules from inside the firewall! For DNAT troubleshooting tips, see FAQs 1a and 1b. For information about DNAT when there are multiple external IP addresses, see the Shorewall Aliased Interface documentation and the Shorewall Setup Guide.
Domain Name Server (DNS) Normally, when you connect to your ISP, as part of getting an IP address your firewall's Domain Name Service (DNS) resolver will be automatically configured (e.g., the /etc/resolv.conf file will be written). Alternatively, your ISP may have given you the IP address of a pair of DNS name servers for you to manually configure as your primary and secondary name servers. Regardless of how DNS gets configured on your firewall, it is your responsibility to configure the resolver in your internal systems. You can take one of two approaches: You can configure your internal systems to use your ISP's name servers. If your ISP gave you the addresses of their servers or if those addresses are available on their web site, you can configure your internal systems to use those addresses. If that information isn't available, look in /etc/resolv.conf on your firewall system -- the name servers are given in "nameserver" records in that file. You can configure a Caching Name Server on your firewall. Red Hat has an RPM for a caching name server (the RPM also requires the bindRPM) and for Bering users, there is dnscache.lrp. If you take this approach, you configure your internal systems to use the firewall itself as their primary (and only) name server. You use the internal IP address of the firewall (10.10.10.254 in the example above) for the name server address. To allow your local systems to talk to your caching name server, you must open port 53 (both UDP and TCP) from the local network to the firewall; you do that by adding the following rules in /etc/shorewall/rules. #ACTION SOURCE DEST PROTO DPORT DNS(ACCEPT)loc $FW
Other Connections The two-interface sample includes the following rules: #ACTION SOURCE DEST PROTO DPORT DNS(ACCEPT) $FW netThis rule allows DNS access from your firewall and may be removed if you uncommented the line in /etc/shorewall/policy allowing all connections from the firewall to the Internet. In the rule shown above, DNS(ACCEPT)is an example of a macro invocation. Shorewall includes a number of macros (command shorewall show macros) and you can add your own. You don't have to use defined macros when coding a rule in /etc/shorewall/rules; Shorewall will start slightly faster if you code your rules directly rather than using macros. The the rule shown above could also have been coded as follows:#ACTION SOURCE DEST PROTO DPORT ACCEPT $FW net udp 53 ACCEPT $FW net tcp 53 In cases where Shorewall doesn't include a defined macro to meet your needs, you can either define the macro yourself or you can simply code the appropriate rules directly. The sample also includes: #ACTION SOURCE DEST PROTO DPORT SSH(ACCEPT) loc $FW That rule allows you to run an SSH server on your firewall and connect to that server from your local systems. If you wish to enable other connections from your firewall to other systems, the general format using a macro is: #ACTION SOURCE DEST PROTO DPORT <macro>(ACCEPT) $FW <destination zone>The general format when not using defined macros is:#ACTION SOURCE DEST PROTO DPORT ACCEPT $FW <destination zone> <protocol> <port> Web Server on Firewall You want to run a Web Server on your firewall system: #ACTION SOURCE DEST PROTO DPORT Web(ACCEPT) net $FW Web(ACCEPT) loc $FW Those two rules would of course be in addition to the rules listed above under You can configure a Caching Name Server on your firewall. If you don't know what port and protocol a particular application uses, look here. I don't recommend enabling telnet to/from the Internet because it uses clear text (even for login!). If you want shell access to your firewall from the Internet, use SSH: #ACTION SOURCE DEST PROTO DPORT SSH(ACCEPT) net $FW Bering users will want to add the following two rules to be compatible with Jacques's Shorewall configuration.#ACTION SOURCE DEST PROTO DPORT ACCEPT loc $FW udp 53 #Allow DNS Cache to work ACCEPT loc $FW tcp 80 #Allow Weblet to work Now edit your /etc/shorewall/rules file to add or delete other connections as required.
Some Things to Keep in Mind You cannot test your firewall from the inside. Just because you send requests to your firewall external IP address does not mean that the request will be associated with the external interface or the net zone. Any traffic that you generate from the local network will be associated with your local interface and will be treated as loc->fw traffic. IP addresses are properties of systems, not of interfaces. It is a mistake to believe that your firewall is able to forward packets just because you can ping the IP address of all of the firewall's interfaces from the local network. The only conclusion you can draw from such pinging success is that the link between the local system and the firewall works and that you probably have the local system's default gateway set correctly. All IP addresses configured on firewall interfaces are in the $FW (fw) zone. If 192.168.1.254 is the IP address of your internal interface then you can write $FW:192.168.1.254 in a rule but you may not write loc:192.168.1.254. Similarly, it is nonsensical to add 192.168.1.254 to the loc zone using an entry in /etc/shorewall/hosts. Reply packets do NOT automatically follow the reverse path of the one taken by the original request. All packets are routed according to the routing table of the host at each step of the way. This issue commonly comes up when people install a Shorewall firewall parallel to an existing gateway and try to use DNAT through Shorewall without changing the default gateway of the system receiving the forwarded requests. Requests come in through the Shorewall firewall where the destination IP address gets rewritten but replies go out unmodified through the old gateway. Shorewall itself has no notion of inside or outside. These concepts are embodied in how Shorewall is configured.
Starting and Stopping Your Firewall The installation procedure configures your system to start Shorewall at system boot but startup is disabled so that your system won't try to start Shorewall before configuration is complete. Once you have completed configuration of your firewall, you must edit /etc/shorewall/shorewall.conf and set STARTUP_ENABLED=Yes. Users of the .deb package must edit /etc/default/shorewall and set startup=1. While you are editing shorewall.conf, it is a good idea to check the value of the SUBSYSLOCK option. You can find a description of this option by typing 'man shorewall.conf' at a shell prompt and searching for SUBSYSLOCK. The firewall is started using the shorewall start command and stopped using shorewall stop. When the firewall is stopped, routing is enabled on those hosts that have an entry in /etc/shorewall/routestopped (Shorewall 4.5.7 and earlier) or in /etc/shorewall/stoppedrules. A running firewall may be restarted using the shorewall reload command. If you want to totally remove any trace of Shorewall from your Netfilter configuration, use shorewall clear. The two-interface sample assumes that you want to enable routing to/from eth1 (the local network) when Shorewall is stopped. If your local network isn't connected to eth1 or if you wish to enable access to/from other hosts, change /etc/shorewall/routestopped accordingly. If you are connected to your firewall from the Internet, do not issue a shorewall stop command unless you have either: Used ADMINISABSENTMINDED=Yes in /etc/shorewall/shorewall.conf; or added an entry for the IP address that you are connected from to /etc/shorewall/routestopped. Also, I don't recommend using shorewall reload; it is better to create an alternate configuration and test it using the shorewall try command. The firewall will start after your network interfaces have been brought up. This leaves a small window between the time that the network interfaces are working and when the firewall is controlling connections through those interfaces. If this is a concern, you can close that window by installing the Shorewall Init Package.
If it Doesn't Work Re-check each of the items flagged with a red arrow above. Check your log. Check the Troubleshooting Guide. Check the FAQ.
Disabling your existing Firewall Before starting Shorewall for the first time, it's a good idea to stop your existing firewall. On older Redhat/CentOS/Fedora: service iptables stop On recent Fedora systems that run systemd, the command is: systemctl stop iptables.service If you are running SuSE, use Yast or Yast2 to stop SuSEFirewall. On other systems that use a classic SysV init system: /etc/init.d/iptables stop Once you have Shorewall running to your satisfaction, you should totally disable your existing firewall. On older Redhat/CentOS/Fedora: chkconfig --del iptables On Debian systems: update-rc.d iptables disable On recent Fedora system running systemd: systemctl disable iptables.service At this point, disable your existing firewall service.
Additional Recommended Reading I highly recommend that you review the Common Configuration File Features page -- it contains helpful tips about Shorewall features than make administering your firewall easier. Also, Operating Shorewall and Shorewall Lite contains a lot of useful operational hints.
Adding a Wireless Segment to your Two-Interface Firewall Once you have the two-interface setup working, the next logical step is to add a Wireless Network. The first step involves adding an additional network card to your firewall, either a Wireless card or an Ethernet card that is connected to a Wireless Access Point. When you add a network card, it won't necessarily be detected as the next highest Ethernet interface. For example, if you have two Ethernet cards in your system (eth0 and eth1) and you add a third card that uses the same driver as one of the other two, that third card won't necessarily be detected as eth2; it could rather be detected as eth0 or eth1! You can either live with that or you can shuffle the cards around in the slots until the new card is detected as eth2. Update: Distributions are getting better about this. SuSE now associates a unique interface name with each MAC address. Other distributions have add-on packages to manage the relationship between MAC addresses and device names. Your new network will look similar to what is shown in the following figure. The first thing to note is that the computers in your wireless network will be in a different subnet from those on your wired local LAN. In the above example, we have chosen to use the network 10.10.11.0/24. Computers 3 and 4 would be configured with a default gateway IP address of 10.10.11.254. Second, we have chosen to include the wireless network as part of the local zone. Since Shorewall allows intra-zone traffic by default, traffic may flow freely between the local wired network and the wireless network. There are only two changes that need to be made to the Shorewall configuration: An entry needs to be added to /etc/shorewall/interfaces for the wireless network interface. If the wireless interface is wlan0, the entry might look like: #ZONE INTERFACE OPTIONS loc wlan0 maclist As shown in the above entry, I recommend using the maclist option for the wireless segment. By adding entries for computers 3 and 4 in /etc/shorewall/maclist, you help ensure that your neighbors aren't getting a free ride on your Internet connection. Start by omitting that option; when you have everything working, then add the option and configure your /etc/shorewall/maclist file. You may need to add an entry to the /etc/shorewall/masq file to masquerade traffic from the wireless network to the Internet. If you file looks like this: #INTERFACE SOURCE ADDRESS PROTO DPORT IPSEC MARK eth0 10.0.0.0/8,\ 169.254.0.0/16,\ 172.16.0.0/12,\ 192.168.0.0/16 or of you are running Shorewall 5.0.14 or later, then you do not need to change the contents. Otherwise, if your Internet interface is eth0 and your wireless interface is wlan0, the entry would be: #INTERFACE SOURCE ADDRESS eth0 10.10.11.0/24 One other thing to note. To get Microsoft networking working between the wireless and wired networks, you will need either a WINS server or a PDC. I personally use Samba configured as a WINS server running on my firewall. Running a WINS server on your firewall requires the rules listed in the Shorewall/Samba documentation.
shorewall-docs-xml-5.0.15/Introduction.xml0000644000000000000000000005011413020330134017215 0ustar rootroot shorewall-docs-xml-5.0.15/traffic_shaping.xml0000644000000000000000000027073713020330134017702 0ustar rootroot
Complex Traffic Shaping/Control Tom Eastep Arne Bernin 2001-2013 Thomas M. Eastep 2005 Arne Bernin & Thomas M. Eastep 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. Traffic shaping is complex and the Shorewall community is not well equipped to answer traffic shaping questions. So if you are the type of person who needs "insert tab A into slot B" instructions for everything that you do, then please don't try to implement traffic shaping using Shorewall. You will just frustrate yourself and we won't be able to help you. Said another way, reading just Shorewall documentation is not going to give you enough background to use this material. At a minimum, you will need to refer to at least the following additional information: The LARTC HOWTO: http://www.lartc.org The HTB User's Guide: http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm HFSC Scheduling with Linux: http://linux-ip.net/articles/hfsc.en/ Some of the documents listed at http://www.netfilter.org/documentation/index.html#documentation-howto. The tutorial by Oskar Andreasson is particularly good. The output of man iptables
Introduction Beginning with Shorewall 4.4.6, Shorewall includes two separate implementations of traffic shaping. This document describes the original implementation which is complex and difficult to configure. A much simpler version is described in Simple Traffic Shaping/Control and is highly recommended unless you really need to delay certain traffic passing through your firewall. Shorewall has builtin support for traffic shaping and control. This support does not cover all options available (and especially all algorithms that can be used to queue traffic) in the Linux kernel but it should fit most needs. If you are using your own script for traffic control and you still want to use it in the future, you will find information on how to do this, later in this document. But for this to work, you will also need to enable traffic shaping in the kernel and Shorewall as covered by the next sections.
Linux traffic shaping and control This section gives a brief introduction of how controlling traffic with the Linux kernel works. Although this might be enough for configuring it in the Shorewall configuration files, we strongly recommend that you take a deeper look into the Linux Advanced Routing and Shaping HOWTO. At the time of writing this, the current version is 1.0.0. Since kernel 2.2, Linux has extensive support for controlling traffic. You can define different algorithms that are used to queue the traffic before it leaves an interface. The standard one is called pfifo and is (as the name suggests) of the type First In First out. This means, that it does not shape anything, if you have a connection that eats up all your bandwidth, this queuing algorithm will not stop it from doing so. For Shorewall traffic shaping we use three algorithms: HTB (Hierarchical Token Bucket), HFSC (Hierarchical Fair Service Curves) and SFQ (Stochastic Fairness Queuing). SFQ is easy to explain: it just tries to track your connections (tcp or udp streams) and balances the traffic between them. This normally works well. HTB and HFSC allow you to define a set of classes, and you can put the traffic you want into these classes. You can define minimum and maximum bandwidth settings for those classes and order them hierarchically (the less prioritized classes only get bandwidth if the more important have what they need). Additionally, HFSC allows you to specify the maximum queuing delay that a packet may experience. Shorewall builtin traffic shaping allows you to define these classes (and their bandwidth limits), and it uses SFQ inside these classes to make sure, that different data streams are handled equally. If SFQ's default notion of a 'stream' doesn't work well for you, you can change it using the flow option described below. You can shape incoming traffic through use of an Intermediate Functional Block (IFB) device. See below. But beware: using an IFB can result in queues building up both at your ISPs router and at your own. You shape and control outgoing traffic by assigning the traffic to classes. Each class is associated with exactly one network interface and has a number of attributes: PRIORITY - Used to give preference to one class over another when selecting a packet to send. The priority is a numeric value with 1 being the highest priority, 2 being the next highest, and so on. RATE - The minimum bandwidth this class should get, when the traffic load rises. Classes with a higher priority (lower PRIORITY value) are served even if there are others that have a guaranteed bandwidth but have a lower priority (higher PRIORITY value). CEIL - The maximum bandwidth the class is allowed to use when the link is idle. MARK - Netfilter has a facility for marking packets. Packet marks have a numeric value which is limited in Shorewall to the values 1-255 (1-16383 if you set WIDE_TC_MARKS=Yes in shorewall.conf (5) ). You assign packet marks to different types of traffic using entries in the /etc/shorewall/mangle file (Shorewall 4.6.0 or later) or /etc/shorewall/tcrules (Prior to Shorewall 4.6.0). In Shorewall 4.4.26, WIDE_TC_MARKS was superseded by TC_BITS which specifies the width in bits of the traffic shaping mark field. The default is based on the setting of WIDE_TC_MARKS so as to provide upward compatibility. See the Packet Marking using /etc/shorewall/mangle article. One class for each interface must be designated as the default class. This is the class to which unmarked traffic (packets to which you have not assigned a mark value in /etc/shorewall/mangle) is assigned. Netfilter also supports a mark value on each connection. You can assign connection mark values in /etc/shorewall/mangle (/etc/shorewall/tcrules), you can copy the current packet's mark to the connection mark (SAVE), or you can copy the connection mark value to the current packet's mark (RESTORE). For more information, see this article.
Linux Kernel Configuration You will need at least kernel 2.4.18 for this to work, please take a look at the following screenshot for what settings you need to enable. For builtin support, you need the HTB scheduler, the Ingress scheduler, the PRIO pseudoscheduler and SFQ queue. The other scheduler or queue algorithms are not needed. This screen shot shows how I configured QoS in a 2.6.16 Kernel: And here's my recommendation for a 2.6.21 kernel:
Enable TC support in Shorewall You need this support whether you use the builtin support or whether you provide your own tcstart script. To enable the builtin traffic shaping and control in Shorewall, you have to do the following: Set TC_ENABLED to "Internal" in /etc/shorewall/shorewall.conf. Setting TC_ENABLED=Yes causes Shorewall to look for an external tcstart file (See a later section for details). Setting CLEAR_TC parameter in /etc/shorewall/shorewall.conf to Yes will clear the traffic shaping configuration during Shorewall [re]start and Shorewall stop. This is normally what you want when using the builtin support (and also if you use your own tcstart script) The other steps that follow depend on whether you use your own script or the builtin solution. They will be explained in the following sections.
Using builtin traffic shaping/control Shorewall's builtin traffic shaping feature provides a thin layer on top of the ingress qdesc, HTB and SFQ. That translation layer allows you to: Define HTB and/or HFSC classes using Shorewall-style column-oriented configuration files. Integrate the reloading of your traffic shaping configuration with the reloading of your packet-filtering and marking configuration. Assign traffic to HTB or HFSC classes by TOS value. Assign outgoing TCP ACK packets to an HTB or HFSC class. Assign traffic to HTB and/or HFSC classes based on packet mark value or based on packet contents. Those few features are really all that builtin traffic shaping/control provides; consequently, you need to understand HTB and/or HFSC and Linux traffic shaping as well as Netfilter packet marking in order to use the facility. Again, please see the links at top of this article. For defining bandwidths (for either devices or classes) please use kbit or kbps (for Kilobytes per second) and make sure there is NO space between the number and the unit (it is 100kbit not 100 kbit). Using mbit, mbps or a raw number (which means bytes) could be used, but note that only integer numbers are supported (0.5 is not valid). To properly configure the settings for your devices you need to find out the real up- and downstream rates you have. This is especially the case, if you are using a DSL connection or one of another type that do not have a guaranteed bandwidth. Don't trust the values your provider tells you for this; especially measuring the real download speed is important! There are several online tools that help you find out; search for "dsl speed test" on google (For Germany you can use arcor speed check). Be sure to choose a test site located near you.
/etc/shorewall/tcdevices This file allows you to define the incoming and outgoing bandwidth for the devices you want traffic shaping to be enabled. That means, if you want to use traffic shaping for a device, you have to define it here. For additional information, see shorewall-tcdevices (5). Columns in the file are as follows: INTERFACE - Name of interface. Each interface may be listed only once in this file. You may NOT specify the name of an alias (e.g., eth0:0) here; see FAQ #18. You man NOT specify wildcards here, e.g. if you have multiple ppp interfaces, you need to put them all in here! Shorewall will determine if the device exists and will only configure the device if it does exist. If it doesn't exist or it is DOWN, the following warning is issued: WARNING: Device <device name> is not in the UP state -- traffic-shaping configuration skipped Shorewall assigns a sequential interface number to each interface (the first entry in /etc/shorewall/tcdevices is interface 1, the second is interface 2 and so on) You can also explicitly specify the interface number by prefixing the interface name with the number and a colon (":"). Example: 1:eth0. Device numbers are expressed in hexidecimal. So the device following 9 is A, not 10. IN-BANDWIDTH - The incoming Bandwidth of that interface. Please note that when you use this column, you are not traffic shaping incoming traffic, as the traffic is already received before you could do so. This Column allows you to define the maximum traffic allowed for this interface in total, if the rate is exceeded, the excess packets are dropped. You want this mainly if you have a DSL or Cable Connection to avoid queuing at your providers side. If you don't want any traffic to be dropped set this to a value faster than your interface maximum rate (or to 0 (zero). To determine the optimum value for this setting, we recommend that you start by setting it significantly below your measured download bandwidth (20% or so). While downloading, measure the ping response time from the firewall to the upstream router as you gradually increase the setting.The optimal setting is at the point beyond which the ping time increases sharply as you increase the setting. For fast lines, the actually download speed may be well below what you specify here. If you have this problem, then follow the bandwidth with a ":" and a burst size. The default burst is 10kb, but on my 50mbit line, I specify 200kb. (50mbit:200kb). OUT-BANDWIDTH - Specify the outgoing bandwidth of that interface. This is the maximum speed your connection can handle. It is also the speed you can refer as "full" if you define the tc classes. Outgoing traffic above this rate will be dropped. OPTIONS — A comma-separated list of options from the following list: classify If specified, classification of traffic into the various classes is done by CLASSIFY entries in /etc/shorewall/mangle (/etc/shorewall/tcrules) or by entries in /etc/shorewall/tcfilters. No MARK value will be associated with classes on this interface. hfsc Shorewall normally uses the Hierarchical Token Bucket (HTB) queuing discipline. When is specified, the Hierarchical Fair Service Curves (HFSC) discipline is used instead. linklayer Added in Shorewall 4.5.6. Type of link (ethernet, atm, adsl). When specified, causes scheduler packet size manipulation as described in tc-stab (8). When this option is given, the following options may also be given after it: mtu=mtu The device MTU; default 2048 (will be rounded up to a power of two) mpu=mpubytes Minimum packet size used in calculations. Smaller packets will be rounded up to this size tsize=tablesize Size table entries; default is 512 overhead=overheadbytes Number of overhead bytes per packet REDIRECTED INTERFACES — Entries are appropriate in this column only if the device in the INTERFACE column names a Intermediate Functional Block (IFB). It lists the physical interfaces that will have their input shaped using classes defined on the IFB. Neither the IFB nor any of the interfaces listed in this column may have an IN-BANDWIDTH specified. You may specify zero (0) or a dash ("-:) in the IN-BANDWIDTH column. IFB devices automatically get the classify option. <para>Suppose you are using PPP over Ethernet (DSL) and ppp0 is the interface for this. The device has an outgoing bandwidth of 500kbit and an incoming bandwidth of 6000kbit</para> <programlisting>#INTERFACE IN-BANDWITH OUT-BANDWIDTH ppp0 6000kbit 500kbit</programlisting> </example> </section> <section id="tcclasses"> <title>/etc/shorewall/tcclasses This file allows you to define the actual classes that are used to split the outgoing traffic. For additional information, see shorewall-tcclasses (5). INTERFACE - Name of interface. Users may also specify the interface number. Must match the name (or number) of an interface with an entry in /etc/shorewall/tcdevices. If the interface has the classify option in /etc/shorewall/tcdevices, then the interface name or number must be followed by a colon and a class number. Examples: eth0:1, 4:9. Class numbers must be unique for a given interface. Normally, all classes defined here are sub-classes of a root class that is implicitly defined from the entry in shorewall-tcdevices(5). You can establish a class hierarchy by specifying a parent class (e.g., interface:parent-class:class) -- the number of a class that you have previously defined. The sub-class may borrow unused bandwidth from its parent. Class numbers are expressed in hexidecimal. So the class following class 9 is A, not 10. MARK - The mark value which is an integer in the range 1-255 (1-16383 if you set WIDE_TC_MARKS=Yes or set TC_BITS=14 in shorewall.conf (5) ). You define these marks in the mangle or tcrules file, marking the traffic you want to go into the queuing classes defined in here. You can use the same marks for different Interfaces. You must specify "-' in this column if the device specified in the INTERFACE column has the classify option in /etc/shorewall/tcdevices. In Shorewall 4.5.0, WIDE_TC_MARKS was superseded by TC_BITS which specifies the width in bits of the traffic shaping mark field. The default is based on the setting of WIDE_TC_MARKS so as to provide upward compatibility. RATE - The minimum bandwidth this class should get, when the traffic load rises. Please note that first the classes which equal or a lesser priority value are served even if there are others that have a guaranteed bandwidth but a lower priority. If the sum of the RATEs for all classes assigned to an INTERFACE exceed that interfaces's OUT-BANDWIDTH, then the OUT-BANDWIDTH limit will not be honored. When using HFSC, this column may contain 1, 2 or 3 pieces of information separated by colons (":"). In addition to the minimum bandwidth, leaf classes may specify realtime criteria: DMAX (maximum delay in milliseconds) and optionally UMAX (the largest packet expected in the class). See below for details. CEIL - The maximum bandwidth this class is allowed to use when the link is idle. Useful if you have traffic which can get full speed when more important services (e.g. interactive like ssh) are not used. You can use the value "full" in here for setting the maximum bandwidth to the defined output bandwidth of that interface. PRIORITY - you have to define a priority for the class. packets in a class with a higher priority (=lesser value) are handled before less prioritized ones. You can just define the mark value here also, if you are increasing the mark values with lesser priority. OPTIONS - A comma-separated list of options including the following: default - this is the default class for that interface where all traffic should go, that is not classified otherwise. defining default for exactly one class per interface is mandatory! tos-<tosname> - this lets you define a filter for the given <tosname> which lets you define a value of the Type Of Service bits in the ip package which causes the package to go in this class. Please note, that this filter overrides all mark settings, so if you define a tos filter for a class all traffic having that mark will go in it regardless of the mark on the package. You can use the following for this option: tos-minimize-delay (16) tos-maximize-throughput (8) tos-maximize-reliability (4) tos-minimize-cost (2) tos-normal-service (0) Each of this options is only valid for one class per interface. tcp-ack - if defined causes an tc filter to be created that puts all tcp ack packets on that interface that have an size of <=64 Bytes to go in this class. This is useful for speeding up downloads. Please note that the size of the ack packets is limited to 64 bytes as some applications (p2p for example) use to make every package an ack package which would cause them all into here. We want only packets WITHOUT payload to match, so the size limit. Bigger packets just take their normal way into the classes. This option is only valid for class per interface. occurs=number - Typically used with an IPMARK entry in mangle or tcrules. Causes the rule to be replicated for a total of number rules. Each rule has a successively class number and mark value. When 'occurs' is used: The associated device may not have the 'classify' option. The class may not be the default class. The class may not have any 'tos=' options (including 'tcp-ack'). The class should not specify a MARK value. If one is specified, it will be ignored with a warning message. The 'RATE' and 'CEIL' parameters apply to each instance of the class. So the total RATE represented by an entry with 'occurs' will be the listed RATE multiplied by number. For additional information, see mangle (5) or tcrules (5). flow=keys - Shorewall attaches an SFQ queuing discipline to each leaf HTB and HFSC class. SFQ ensures that each flow gets equal access to the interface. The default definition of a flow corresponds roughly to a Netfilter connection. So if one internal system is running BitTorrent, for example, it can have lots of 'flows' and can thus take up a larger share of the bandwidth than a system having only a single active connection. The classifier (module cls_flow) works around this by letting you define what a 'flow' is. The clasifier must be used carefully or it can block off all traffic on an interface! The flow option can be specified for an HTB or HFSC leaf class (one that has no sub-classes). We recommend that you use the following: Shaping internet-bound traffic: flow=nfct-src Shaping traffic bound for your local net: flow=dst These will cause a 'flow' to consists of the traffic to/from each internal system. When more than one key is give, they must be enclosed in parenthesis and separated by commas. To see a list of the possible flow keys, run this command:
tc filter add flow help
Those that begin with "nfct-" are Netfilter connection tracking fields. As shown above, we recommend flow=nfct-src; that means that we want to use the source IP address before SNAT as the key. Shorewall cannot determine ahead of time if the flow classifier is available in your kernel (especially if it was built into the kernel as opposed to being loaded as a module). Consequently, you should check ahead of time to ensure that both your kernel and 'tc' utility support the feature. You can test the 'tc' utility by typing (as root):
tc filter add flow help
If flow is supported, you will see: Usage: ... flow ... [mapping mode]: map key KEY [ OPS ] ... [hashing mode]: hash keys KEY-LIST ... ... If 'flow' is not supported, you will see: Unknown filter "flow", hence option "help" is unparsable If your kernel supports module autoloading, just type (as root):
modprobe cls_flow
If 'flow' is supported, no output is produced; otherwise, you will see: FATAL: Module cls_flow not found. If your kernel is not modularized or does not support module autoloading, look at your kernel configuration (either /proc/config.gz or the .config file in /lib/modules/<kernel-version>/build/ If 'flow' is supported, you will see: NET_CLS_FLOW=m or NET_CLS_FLOW=y. For modularized kernels, Shorewall will attempt to load /lib/modules/<kernel-version>/net/sched/cls_flow.ko by default. pfifo - When specified for a leaf class, the pfifo queing discipline is applied to the class rather than the sfq queuing discipline. limit=number - Added in Shorewall 4.4.3. When specified for a leaf class, specifies the maximum number of packets that may be queued within the class. The number must be > 2 and less than 128. If not specified, the value 127 is assumed red=(redoption,...) - Added in Shorewall 4.5.6. When specified on a leaf class, causes the class to use the red queuing discipline rather than SFQ. See tc-red (8) for additional information. See shorewall-tcdevices (5) for a description of the allowable redoptions. fq_codel[=(codeloption,...)] - Added in Shorewall 4.5.12. When specified on a leaf class, causes the class to use the FQ CODEL (Fair-queuing Controlled-delay) queuing discipline rather than SFQ. See tc-fq_codel (8) for additional information. See shorewall-tcclasses (5) for a description of the allowable codloptions.
/etc/shorewall/mangle and /etc/shorewall/rules Unlike rules in the shorewall-rules(5) file, evaluation of rules in this file will continue after a match. So the final mark for each packet will be the one assigned by the LAST tcrule that matches. Also unlike rules in the shorewall-rules(5) file, the mangle (tcrules) file is not stateful. So every packet that goes into, out of or through your firewall is subject to entries in the mangle (tcrules) file. Because mangle (tcrules) entries are not stateful, it is necessary to understand basic IP socket operation. Here is an edited excerpt from a post on the Shorewall Users list:
For the purposes of this discussion, the world is separated into clients and servers. Servers provide services to clients. When a server starts, it creates a socket and binds the socket to an address. For AF_INET (IPv4) and AF_INET6 (IPv6) sockets, that address is an ordered triple consisting of an IPv4 or IPv6 address, a protocol, and possibly a port number. Port numbers are only used when the protocol is TCP, UDP, SCTP or DCCP. The protocol and port number used by a server are typically well-known so that clients will be able to connect to it or send datagrams to it. So SSH servers bind to TCP port 22, SMTP servers bind to TCP port 25, etc. We will call this port the SERVER PORT. When a client want to use the service provided by a server, it also creates a socket and, like the server's socket, the client's socket must be bound to an address. But in the case of the client, the socket is usually given an automatic address binding. For AF_INET and AF_INET6 sockets. the IP address is the IP address of the client system (loose generalization) and the port number is selected from a local port range. On Linux systems, the local port range can be seen by cat /proc/sys/net/ipv4/ip_local_port_range. So it is not possible in advance to determine what port the client will be using. Whatever it is, we'll call it the CLIENT PORT. Now:
Packets sent from the client to the server will have:
SOURCE PORT = CLIENT PORT DEST PORT = SERVER PORT
Packets sent from the server to the client will have:
SOURCE PORT = SERVER PORT DEST PORT = CLIENT PORT
Since the SERVER PORT is generally the only port known ahead of time, we must categorize traffic from the server to the client using the SOURCE PORT.
The fwmark classifier provides a convenient way to classify packets for traffic shaping. The /etc/shorewall/mangle (/etc/shorewall/tcrules) file is used for specifying these marks in a tabular fashion. For an in-depth look at the packet marking facility in Netfilter/Shorewall, please see this article. For marking forwarded traffic, you must either set MARK_IN_FORWARD_CHAIN=Yes shorewall.conf or by using the :F qualifier (see below). See shorewall-mangle(5) and shorewall-tcrules(5) for a description of the entries in these files. Note that the mangle file superseded the tcrules file in Shorewall 4.6.0. The following examples are for the mangle file. <para>All packets arriving on eth1 should be marked with 1. All packets arriving on eth2 and eth3 should be marked with 2. All packets originating on the firewall itself should be marked with 3.</para> <programlisting>#ACTION SOURCE DEST PROTO DPORT MARK(1) eth1 0.0.0.0/0 all MARK(2) eth2 0.0.0.0/0 all MARK(2) eth3 0.0.0.0/0 all MARK(3) $FW 0.0.0.0/0 all</programlisting> </example> <example id="Example2"> <title/> <para>All GRE (protocol 47) packets destined for 155.186.235.151 should be marked with 12.</para> <programlisting>#ACTION SOURCE DEST PROTO DPORT MARK(12):T 0.0.0.0/0 155.182.235.151 47</programlisting> </example> <example id="Example3"> <title/> <para>All SSH request packets originating in 192.168.1.0/24 and destined for 155.186.235.151 should be marked with 22.</para> <programlisting>#ACTION SOURCE DEST PROTO DPORT MARK(22):T 192.168.1.0/24 155.182.235.151 tcp 22</programlisting> </example> <example id="Example4"> <title/> <para>All SSH packets packets going out of the first device in in /etc/shorewall/tcdevices should be assigned to the class with mark value 10.</para> <programlisting>#ACTION SOURCE DEST PROTO DPORT SPORT CLASSIFY(1:110) 0.0.0.0/0 0.0.0.0/0 tcp 22 CLASSIFY(1:110) 0.0.0.0/0 0.0.0.0/0 tcp - 22</programlisting> </example> <example id="Example5"> <title/> <para>Mark all ICMP echo traffic with packet mark 1. Mark all peer to peer traffic with packet mark 4.</para> <para>This is a little more complex than otherwise expected. Since the ipp2p module is unable to determine all packets in a connection are P2P packets, we mark the entire connection as P2P if any of the packets are determined to match. We assume packet/connection mark 0 to means unclassified. Traffic originating on the firewall is not covered by this example.</para> <programlisting>#ACTION SOURCE DEST PROTO DPORT SPORT USER TEST MARK(1) 0.0.0.0/0 0.0.0.0/0 icmp echo-request MARK(1) 0.0.0.0/0 0.0.0.0/0 icmp echo-reply RESTORE 0.0.0.0/0 0.0.0.0/0 all - - - 0 CONTINUE 0.0.0.0/0 0.0.0.0/0 all - - - !0 MARK(4) 0.0.0.0/0 0.0.0.0/0 ipp2p:all SAVE 0.0.0.0/0 0.0.0.0/0 all - - - !0</programlisting> <para>The last four rules can be translated as:</para> <blockquote> <para>"If a packet hasn't been classified (packet mark is 0), copy the connection mark to the packet mark. If the packet mark is set, we're done. If the packet is P2P, set the packet mark to 4. If the packet mark has been set, save it to the connection mark."</para> </blockquote> </example> <example> <title/> <para>Mark all forwarded VOIP connections with connection mark 1 and ensure that all VOIP packets also receive that mark (assumes that nf_conntrack_sip is loaded).</para> <programlisting>#ACTION SOURCE DEST PROTO DPORT SPORT USER TEST CONNBYTES TOS HELPER RESTORE 0.0.0.0/0 0.0.0.0/0 all - - - 0 CONTINUE 0.0.0.0/0 0.0.0.0/0 all - - - !0 1 0.0.0.0/0 0.0.0.0/0 all - - - - - - sip SAVE 0.0.0.0/0 0.0.0.0/0 all - - - !0</programlisting> </example> </section> <section id="ppp"> <title>ppp devices If you use ppp/pppoe/pppoa) to connect to your Internet provider and you use traffic shaping you need to restart shorewall traffic shaping. The reason for this is, that if the ppp connection gets restarted (and it usually does this at least daily), all tc filters/qdiscs related to that interface are deleted. The easiest way to achieve this, is just to restart shorewall once the link is up. To achieve this add a small executable script to/etc/ppp/ip-up.d. #! /bin/sh /sbin/shorewall refresh
Sharing a TC configuration between Shorewall and Shorewall6 Beginning with Shorewall 4.4.15, the traffic-shaping configuration in the tcdevices, tcclasses and tcfilters files can be shared between Shorewall and Shorewall6. Only one of the products can control the configuration but the other can configure CLASSIFY rules in its own mangle or tcrules file that refer to the shared classes. To defined the configuration in Shorewall and shared it with Shorewall6: Set TC_ENABLED=Internal in shorewall.conf (5). Set TC_ENABLED=Shared in shorewall6.conf (5). Create symbolic links from /etc/shorewall6 to /etc/shorewall/tcdevices and /etc/shorewall/tcclasses: ln -s ../shorewall/tcdevices /etc/shorewall6/tcdevices ln -s ../shorewall/tcclasses /etc/shorewall6/tcclasses If you need to define IPv6 tcfilter entries, do so in /etc/shorewall/tcfilters. That file now allows entries that apply to IPv6. Shorewall6 compilations to have access to the tcdevices and tcclasses files although it will create no output. That access allows CLASSIFY rules in /etc/shorewall6/mangle to be validated against the TC configuration. In this configuration, it is Shorewall that controls TC configuration (except for IPv6 mangle). You can reverse the settings in the files if you want to control the configuration using Shorewall6.
Per-IP Traffic Shaping Some network administrators feel that they have to divy up their available bandwidth by IP address rather than by prioritizing the traffic based on the type of traffic. This gets really awkward when there are a large number of local IP addresses. This section describes the Shorewall facility for making this configuration less tedious (and a lot more efficient). Note that it requires that you install xtables-addons. So before you try this facility, we suggest that first you add the following OPTION to each external interface described in /etc/shorewall/tcdevices: flow=nfct-src If you shape traffic on your internal interface(s), then add this to their entries: flow=dst You may find that this simple change is all that is needed to control bandwidth hogs like Bit Torrent. If it doesn't, then proceed as described in this section. The facility has two components: An IPMARK MARKing command in /etc/shorewall/mangle (/etc/shorewall/tcrules). An occurs OPTION in /etc/shorewall/tcclasses. The facility is currently only available with IPv4. In a sense, the IPMARK target is more like an IPCLASSIFY target in that the mark value is later interpreted as a class ID. A packet mark is 32 bits wide; so is a class ID. The major class occupies the high-order 16 bits and the minor class occupies the low-order 16 bits. So the class ID 1:4ff (remember that class IDs are always in hex) is equivalent to a mark value of 0x104ff. Remember that Shorewall uses the interface number as the major number where the first interface in tcdevices has major number 1, the second has major number 2, and so on. The IPMARK target assigns a mark to each matching packet based on the either the source or destination IP address. By default, it assigns a mark value equal to the low-order 8 bits of the source address. The syntax is as follows:
IPMARK[([{src|dst}][,[mask1][,[mask2][,[shift]]]])]
Default values are: src mask1 = 0xFF mask2 = 0x00 shift = 0 src and dst specify whether the mark is to be based on the source or destination address respectively. The selected address is first shifted right by shift, then LANDed with mask1 and then LORed with mask2. The shift argument is intended to be used primarily with IPv6 addresses. Example: IPMARK(src,0xff,0x10100) Source IP address is 192.168.4.3 = 0xc0a80403 0xc0a80403 >> 0 = 0xc0a80403 0xc0a80403 LAND 0xFF = 0x03 0x03 LOR 0x10100 = 0x10103 So the mark value is 0x10103 which corresponds to class id 1:103. It is important to realize that, while class IDs are composed of a major and a minor value, the set of minor values must be unique. You must keep this in mind when deciding how to map IP addresses to class IDs. For example, suppose that your internal network is 192.168.1.0/29 (host IP addresses 192.168.1.1 - 192.168.1.6). Your first notion might be to use IPMARK(src,0xFF,0x10000) so as to produce class IDs 1:1 through 1:6. But 1:1 is the class ID of the base HTB class on interface 1. So you might chose instead to use IPMARK(src,0xFF,0x10100) as shown in the example above so as to avoid minor class 1. The occurs option in /etc/shorewall/tcclasses causes the class definition to be replicated many times. The synax is:
occurs=number
When occurs is used: The associated device may not have the classify option. The class may not be the default class. The class may not have any tos= options (including tcp-ack). The class should not specify a MARK value. Any MARK value given is ignored with a warning. The RATE and CEIL parameters apply to each instance of the class. So the total RATE represented by an entry with occurs will be the listed RATE multiplied by number. Example: /etc/shorewall/tcdevices: #INTERFACE IN_BANDWIDTH OUT_BANDWIDTH eth0 100mbit 100mbit /etc/shorewall/tcclasses: #DEVICE MARK RATE CEIL PRIORITY OPTIONS eth0:101 - 1kbit 230kbit 4 occurs=6 The above defines 6 classes with class IDs 0x101-0x106. Each class has a guaranteed rate of 1kbit/second and a ceiling of 230kbit. /etc/shoreall/mangle or /etc/shoreall/tcrules: #ACTION SOURCE DEST IPMARK(src,0xff,0x10100):F 192.168.1.0/29 eth0 This facility also alters the way in which Shorewall generates a class number when none is given. Prior to the implementation of this facility, the class number was constructed by concatinating the MARK value with the either '1' or '10'. '10' was used when there were more than 10 devices defined in /etc/shorewall/tcdevices. With this facility, a new method is added; class numbers are assigned sequentially beginning with 2. The WIDE_TC_MARKS option in shorewall.conf selects which construction to use. WIDE_TC_MARKS=No (the default) produces pre-Shorewall 4.4 behavior. WIDE_TC_MARKS=Yes (TC_BITS >= 14 in Shorewall 4.4.26 and later) produces the new behavior.
Real life examples
A Shorewall User's Experience Chuck Kollars has provided an excellent writeup about his traffic shaping experiences.
Configuration to replace Wondershaper You are able to fully replace the wondershaper script by using the buitin traffic control.. In this example it is assumed that your interface for your Internet connection is ppp0 (for DSL), if you use another connection type, you have to change it. You also need to change the settings in the tcdevices.wondershaper file to reflect your line speed. The relevant lines of the config files follow here. Please note that this is just a 1:1 replacement doing exactly what wondershaper should do. You are free to change it...
tcdevices file #INTERFACE IN_BANDWITH OUT_BANDWIDTH ppp0 5000kbit 500kbit
tcclasses file #INTERFACE MARK RATE CEIL PRIORITY OPTIONS ppp0 1 5*full/10 full 1 tcp-ack,tos-minimize-delay ppp0 2 3*full/10 9*full/10 2 default ppp0 3 2*full/10 8*full/10 2
mangle file #ACTION SOURCE DEST PROTO DPORT SPORT USER MARK(1):F 0.0.0.0/0 0.0.0.0/0 icmp echo-request MARK(1):F 0.0.0.0/0 0.0.0.0/0 icmp echo-reply # mark traffic which should have a lower priority with a 3: # mldonkey MARK(3):F 0.0.0.0/0 0.0.0.0/0 udp - 4666 Wondershaper allows you to define a set of hosts and/or ports you want to classify as low priority. To achieve this , you have to add these hosts to tcrules and set the mark to 3 (true if you use the example configuration files).
Setting hosts to low priority lets assume the following settings from your old wondershaper script (don't assume these example values are really useful, they are only used for demonstrating ;-): # low priority OUTGOING traffic - you can leave this blank if you want # low priority source netmasks NOPRIOHOSTSRC="192.168.1.128/25 192.168.3.28" # low priority destination netmasks NOPRIOHOSTDST=60.0.0.0/24 # low priority source ports NOPRIOPORTSRC="6662 6663" # low priority destination ports NOPRIOPORTDST="6662 6663" This would result in the following additional settings to the mangle file: #ACTION SOURCE DEST PROTO DPORT SPORT USER MARK(3) 192.168.1.128/25 0.0.0.0/0 all MARK(3) 192.168.3.28 0.0.0.0/0 all MARK(3) 0.0.0.0/0 60.0.0.0/24 all MARK(3) 0.0.0.0/0 0.0.0.0/0 udp 6662,6663 MARK(3) 0.0.0.0/0 0.0.0.0/0 udp - 6662,6663 MARK(3) 0.0.0.0/0 0.0.0.0/0 tcp 6662,6663 MARK(3) 0.0.0.0/0 0.0.0.0/0 tcp - 6662,6663
A simple setup This is a simple setup for people sharing an Internet connection and using different computers for this. It just basically shapes between 2 hosts which have the ip addresses 192.168.2.23 and 192.168.2.42
tcdevices file #INTERFACE IN_BANDWITH OUT_BANDWIDTH ppp0 6000kbit 700kbit We have 6mbit down and 700kbit upstream.
tcclasses file #INTERFACE MARK RATE CEIL PRIORITY OPTIONS ppp0 1 10kbit 50kbit 1 tcp-ack,tos-minimize-delay ppp0 2 300kbit full 2 ppp0 3 300kbit full 2 ppp0 4 90kbit 200kbit 3 default We add a class for tcp ack packets with highest priority, so that downloads are fast. The following 2 classes share most of the bandwidth between the 2 hosts, if the connection is idle, they may use full speed. As the hosts should be treated equally they have the same priority. The last class is for the remaining traffic.
mangle file #ACTION SOURCE DEST PROTO DPORT SPORT USER MARK(1):F 0.0.0.0/0 0.0.0.0/0 icmp echo-request MARK(1):F 0.0.0.0/0 0.0.0.0/0 icmp echo-reply MARK(2):F 192.168.2.23 0.0.0.0/0 all MARK(3):F 192.168.2.42 0.0.0.0/0 all Corresponding tcrules file: #ACTION SOURCE DEST PROTO DPORT SPORT USER 1:F 0.0.0.0/0 0.0.0.0/0 icmp echo-request 1:F 0.0.0.0/0 0.0.0.0/0 icmp echo-reply 2:F 192.168.2.23 0.0.0.0/0 all 3:F 192.168.2.42 0.0.0.0/0 all We mark icmp ping and replies so they will go into the fast interactive class and set a mark for each host.
A Warning to Xen Users If you are running traffic shaping in your dom0 and traffic shaping doesn't seem to be limiting outgoing traffic properly, it may be due to "checksum offloading" in your domU(s). Check the output of "shorewall show tc". Here's an excerpt from the output of that command: class htb 1:130 parent 1:1 leaf 130: prio 3 quantum 1500 rate 76000bit ceil 230000bit burst 1537b/8 mpu 0b overhead 0b cburst 1614b/8 mpu 0b overhead 0b level 0 Sent 559018700 bytes 75324 pkt (dropped 0, overlimits 0 requeues 0) rate 299288bit 3pps backlog 0b 0p requeues 0 lended: 53963 borrowed: 21361 giants: 90174 tokens: -26688 ctokens: -14783 There are two obvious problems in the above output: The rate (299288) is considerably larger than the ceiling (230000). There are a large number (90174) of giants reported. This problem will be corrected by disabling "checksum offloading" in your domU(s) using the ethtool utility. See the one of the Xen articles for instructions.
An HFSC Example As mentioned at the top of this article, there is an excellent introduction to HFSC at http://linux-ip.net/articles/hfsc.en/. At the end of that article are 'tc' commands that implement the configuration in the article. Those tc commands correspond to the following Shorewall traffic shaping configuration. /etc/shorewall/tcdevices: #INTERFACE IN_BANDWITH OUT_BANDWIDTH OPTIONS eth0 - 1000kbit hfsc /etc/shorewall/tcclasses: #INTERFACE MARK RATE CEIL PRIORITY OPTIONS 1:10 1 500kbit full 1 1:20 2 500kbit full 1 1:10:11 3 400kbit:53ms:1500b full 2 1:10:12 4 100kbit:30ms:1500b full 2 The following sub-section offers some notes about the article.
Where Did all of those Magic Numbers come from? As you read the article, numbers seem to be introduced out of thin air. I'll try to shed some light on those. There is very clear development of these numbers: 12ms to transfer a 1500b packet at 1000kbits/second. 100kbits per second with 1500b packets, requires 8 packets per second. A packet from class 1:12 must be sent every 120ms. Total transmit delay can be no more than 132ms (120 + 12). We then learn that the queuing latency can be reduced to 30ms if we use a two-part service curve whose first part is 400kbits/second. Where did those come from? The latency is calculated from the rate. If it takes 12ms to transmit a 1500 byte packet at 1000kbits/second, it takes 30ms to transmit a 1500b at 400kbits/second. For the slope of the first part of the service curve, in theory we can pick any number between 100 (the rate of class 1:12) and 500 (the rate of the parent class) with higher numbers providing lower latency. The final curious number is the latency for class 1:11 - 52.5ms. It is a consequence of everything that has gone before. To acheive 400kbits/second with 1500-byte packets, 33.33 packets per second are required. So a packet from class 1:11 must be sent every 30 ms. As the article says, "...the maximum transmission delay of this class increases from 30ms to a total of 52.5 ms.". So we are looking for an additional 22.5 ms. Assume that both class 1:11 and 1:12 transmit for 30 ms at 400kbits/second. That is a total of 800kbits/second for 30ms. So Class 1:11 is punished for the excess. How long is the punishment? The two classes sent 24,000 bits in 30ms; they are only allowed 0.030 * 500,000 = 15,000. So they are 9,000 bits over their quota. The amount of time required to transmit 9,000 bits at 400,000 bits/second is 22.5ms!.
Intermediate Functional Block (IFB) Devices The principles behind an IFB is fairly simple: It looks like a network interface although it is never given an IPv4 configuration. Because it is a network interface, queuing disciplines can be associated with an IFB. The magic of an IFB comes in the fact that a filter may be defined on a real network interface such that each packet that arrives on that interface is queued for the IFB! In that way, the IFB provides a means for shaping input traffic. To use an IFB, you must have IFB support in your kernel (configuration option CONFIG_IFB). Assuming that you have a modular kernel, the name of the IFB module is 'ifb' and may be loaded using the command modprobe ifb (if you have modprobe installed) or insmod /path/to/module/ifb. By default, two IFB devices (ifb0 and ifb1) are created. You can control that using the numifbs option (e.g., modprobe ifb numifbs=1). To create a single IFB when Shorewall starts, place the following two commands in /etc/shorewall/init: modprobe ifb numifbs=1 ip link set ifb0 up Entries in /etc/shorewall/mangle or /etc/shorewall/tcrules have no effect on shaping traffic through an IFB. To allow classification of such traffic, the /etc/shorewall/tcfilters file has been added. Entries in that file create u32 classification rules.
/etc/shorewall/tcfilters While this file was created to allow shaping of traffic through an IFB, the file may be used for general traffic classification as well. The file is similar to shorewall-mangle(5) with the following key exceptions: The first match determines the classification, whereas in the mangle file, the last match determines the classification. ipsets are not supported DNS Names are not supported Address ranges and lists are not supported Exclusion is not supported. filters are applied to packets as they appear on the wire. So incoming packets will not have DNAT applied yet (the destination IP address will be the external address) and outgoing packets will have had SNAT applied. The last point warrants elaboration. When looking at traffic being shaped by an IFB, there are two cases to consider: Requests — packets being sent from remote clients to local servers. These packets may undergo subsequent DNAT, either as a result of entries in /etc/shorewall/nat or as a result of DNAT or REDIRECT rules. Example: /etc/shorewall/rules: #ACTION SOURCE DEST PROTO DPORT SPORT ORIGDEST DNAT net dmz:192.168.4.5 tcp 80 - 206.124.146.177 Requests redirected by this rule will have destination IP address 206.124.146.177 and destination port 80. Responses — packets being sent from remote servers to local clients. These packets may undergo subsequent DNAT as a result of entries in /etc/shorewall/nat or in /etc/shorewall/masq. The packet's destination IP address will be the external address specified in the entry. Example: /etc/shorewall/masq:#INTERFACE SOURCE ADDRESS eth0 192.168.1.0/24 206.124.146.179 When running Shorewall 5.0.14 or later, the equivalent /etc/shorewall/snat would be: #ACTION SOURCE DEST ... SNAT(206.124.146.179) 192.168.1.0/24 eth0 HTTP response packets corresponding to requests that fall under that rule will have destination IP address 206.124.146.179 and source port 80. Beginning with Shorewall 4.4.15, both IPv4 and IPv6 rules can be defined in this file. See shorewall-tcfilters (5) for details. Columns in the file are as follow. As in all Shorewall configuration files, a hyphen ("-") may be used to indicate that no value is supplied in the column. CLASS The interface name or number followed by a colon (":") and the class number. SOURCE SOURCE IP address (host or network). DNS names are not allowed. DEST DESTINATION IP address (host or network). DNS names are not allowed. PROTO Protocol name or number. DPORT Comma-separated list of destination port names or numbers. May only be specified if the protocol is TCP, UDP, SCTP or ICMP. Port ranges are supported except for ICMP. SPORT Comma-separated list of source port names or numbers. May only be specified if the protocol is TCP, UDP or SCTP. Port ranges are supported. TOS Specifies the value of the TOS field. The value can be any of the following: hex-number hex-number/hex-number The hex-numbers must be exactly two digits (e.g., 0x04). LENGTH Must be a power of 2 between 32 and 8192 inclusive. Packets with a total length that is strictly less than the specified value will match the rule. Example: I've used this configuration on my own firewall. The IFB portion is more for test purposes rather than to serve any well-reasoned QOS strategy. /etc/shorewall/init:qt modprobe ifb numifbs=1 qt ip link set dev ifb0 up /etc/shorewall/interfaces: #ZONE INTERFACE BROADCAST - ifb0 /etc/shorewall/tcdevices: #INTERFACE IN_BANDWITH OUT_BANDWIDTH OPTIONS REDIRECT 1:eth0 - 384kbit classify 2:ifb0 - 1300kbit - eth0 /etc/shorewall/tcclasses:#INTERFACE MARK RATE CEIL PRIORITY OPTIONS 1:110 - 5*full/10 full 1 tcp-ack,tos-minimize-delay 1:120 - 2*full/10 6*full/10 2 default 1:130 - 2*full/10 6*full/10 3 2:110 - 5*full/10 full 1 tcp-ack,tos-minimize-delay 2:120 - 2*full/10 6*full/10 2 default 2:130 - 2*full/10 6*full/10 3/etc/shorewall/tcfilters:#INTERFACE: SOURCE DEST PROTO DPORT SPORT # # OUTGOING TRAFFIC # 1:130 206.124.146.178 - tcp - 49441,49442 #BITTORRENT on wookie 1:110 206.124.146.178 #wookie 1:110 206.124.146.179 #SNAT of internal systems 1:110 206.124.146.180 #Work Laptop 1:110 - - icmp echo-request,echo-reply 1:110 - - icmp echo-reply 1:130 206.124.146.177 - tcp - 873,25 #Bulk Traffic # # INCOMING TRAFFIC # 2:110 - 206.124.146.178 #Wookie 2:110 - 206.124.146.179 #SNAT Responses 2:110 - 206.124.146.180 #Work Laptop 2:130 - 206.124.146.177 tcp 25 #Incoming Email. You can examine the installed filters with the shorewall show filters command. What follows shows the output for eth0 with the filters shown above. Bold font are comments explaining the rules.gateway:~ # shorewall-lite show filters Shorewall Lite 4.1.6 Classifiers at gateway - Fri Mar 21 08:06:47 PDT 2008 Device eth1: Device eth2: Device eth0: filter parent 1: protocol ip pref 10 u32 filter parent 1: protocol ip pref 10 u32 fh 3: ht divisor 1 <========= Start of table 3. parses TCP header filter parent 1: protocol ip pref 10 u32 fh 3::800 order 2048 key ht 3 bkt 0 flowid 1:130 (rule hit 102 success 0) match 03690000/ffff0000 at nexthdr+0 (success 0 ) <========= SOURCE PORT 873 goes to class 1:130 filter parent 1: protocol ip pref 10 u32 fh 2: ht divisor 1 <========= Start of table 2. parses ICMP header filter parent 1: protocol ip pref 10 u32 fh 2::800 order 2048 key ht 2 bkt 0 flowid 1:110 (rule hit 0 success 0) match 08000000/ff000000 at nexthdr+0 (success 0 ) <========= ICMP Type 8 goes to class 1:110 filter parent 1: protocol ip pref 10 u32 fh 2::801 order 2049 key ht 2 bkt 0 flowid 1:110 (rule hit 0 success 0) match 00000000/ff000000 at nexthdr+0 (success 0 ) <========= ICMP Type 0 goes to class 1:110 filter parent 1: protocol ip pref 10 u32 fh 1: ht divisor 1 <========= Start of table 1. parses TCP header filter parent 1: protocol ip pref 10 u32 fh 1::800 order 2048 key ht 1 bkt 0 flowid 1:130 (rule hit 0 success 0) match c1210000/ffff0000 at nexthdr+0 (success 0 ) <========= SOURCE PORT 49441 goes to class 1:130 filter parent 1: protocol ip pref 10 u32 fh 1::801 order 2049 key ht 1 bkt 0 flowid 1:130 (rule hit 0 success 0) match c1220000/ffff0000 at nexthdr+0 (success 0 ) <========= SOURCE PORT 49442 goes to class 1:130 filter parent 1: protocol ip pref 10 u32 fh 800: ht divisor 1 <========= Start of Table 800. Packets start here! =============== The following 2 rules are generated by the class definition in /etc/shorewall/classes ================== filter parent 1: protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:110 (rule hit 2204 success 138) match 00060000/00ff0000 at 8 (success 396 ) <========= TCP match 05000000/0f00ffc0 at 0 (success 250 ) <========= Header length 20 and Packet Length < 64 match 00100000/00ff0000 at 32 (success 138 ) <========= ACK filter parent 1: protocol ip pref 10 u32 fh 800::801 order 2049 key ht 800 bkt 0 flowid 1:110 (rule hit 2066 success 0) match 00100000/00100000 at 0 (success 0 ) <========= Minimize-delay goes to class 1:110 =============== Jump to Table 1 if the matches are met ================== filter parent 1: protocol ip pref 10 u32 fh 800::802 order 2050 key ht 800 bkt 0 link 1: (rule hit 2066 success 0) match ce7c92b2/ffffffff at 12 (success 1039 ) <========= SOURCE 206.124.146.178 match 00060000/00ff0000 at 8 (success 0 ) <========= PROTO TCP offset 0f00>>6 at 0 eat filter parent 1: protocol ip pref 10 u32 fh 800::803 order 2051 key ht 800 bkt 0 flowid 1:110 (rule hit 2066 success 1039) match ce7c92b2/ffffffff at 12 (success 1039 ) <========= SOURCE 206.124.146.178 goes to class 1:110 filter parent 1: protocol ip pref 10 u32 fh 800::804 order 2052 key ht 800 bkt 0 flowid 1:110 (rule hit 1027 success 132) match ce7c92b3/ffffffff at 12 (success 132 ) <========= SOURCE 206.124.146.179 goes to class 1:110 filter parent 1: protocol ip pref 10 u32 fh 800::805 order 2053 key ht 800 bkt 0 flowid 1:110 (rule hit 895 success 603) match ce7c92b4/ffffffff at 12 (success 603 ) <========= SOURCE 206.124.146.180 goes to class 1:110 =============== Jump to Table 2 if the matches are met ================== filter parent 1: protocol ip pref 10 u32 fh 800::806 order 2054 key ht 800 bkt 0 link 2: (rule hit 292 success 0) match 00010000/00ff0000 at 8 (success 0 ) <========= PROTO ICMP offset 0f00>>6 at 0 eat =============== Jump to Table 3 if the matches are met ================== filter parent 1: protocol ip pref 10 u32 fh 800::807 order 2055 key ht 800 bkt 0 link 3: (rule hit 292 success 0) match ce7c92b1/ffffffff at 12 (success 265 ) <========= SOURCE 206.124.146.177 match 00060000/00ff0000 at 8 (success 102 ) <========= PROTO TCP offset 0f00>>6 at 0 eat
Understanding the output of 'shorewall show tc' The shorewall show tc (shorewall-lite show tc) command displays information about the current state of traffic shaping. For each device, it executes the following commands: echo Device $device: tc -s -d qdisc show dev $device echo tc -s -d class show dev $device echo So, the traffic-shaping output is generated entirely by the tc utility. Here's the output of for eth0. The configuration is the one shown in the preceding section (the output was obtained almost 24 hours later than the shorewall show filters output shown above). Device eth0: ============== The primary queuing discipline is HTB (Hierarchical Token Bucket) ==================== qdisc htb 1: r2q 10 default 120 direct_packets_stat 9 ver 3.17 Sent 2133336743 bytes 4484781 pkt (dropped 198, overlimits 4911403 requeues 21) <=========== Note the overlimits and dropped counts rate 0bit 0pps backlog 0b 8p requeues 21 ============== The ingress filter. If you specify IN-BANDWIDTH, you can see the 'dropped' count here. ========= In this case, the packets are being sent to the IFB for shaping qdisc ingress ffff: ---------------- Sent 4069015112 bytes 4997252 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 ============ Each of the leaf HTB classes has an SFQ qdisc to ensure that each flow gets its turn ============ qdisc sfq 110: parent 1:110 limit 128p quantum 1514b flows 128/1024 perturb 10sec Sent 613372519 bytes 2870225 pkt (dropped 0, overlimits 0 requeues 6) rate 0bit 0pps backlog 0b 0p requeues 6 qdisc sfq 120: parent 1:120 limit 128p quantum 1514b flows 128/1024 perturb 10sec Sent 18434920 bytes 60961 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 qdisc sfq 130: parent 1:130 limit 128p quantum 1514b flows 128/1024 perturb 10sec Sent 1501528722 bytes 1553586 pkt (dropped 198, overlimits 0 requeues 15) rate 0bit 0pps backlog 11706b 8p requeues 15 ============= Class 1:110 -- the high-priority class =========== Note the rate and ceiling calculated from 'full' class htb 1:110 parent 1:1 leaf 110: prio 1 quantum 4800 rate 192000bit ceil 384000bit burst 1695b/8 mpu 0b overhead 0b cburst 1791b/8 mpu 0b overhead 0b level 0 Sent 613372519 bytes 2870225 pkt (dropped 0, overlimits 0 requeues 0) rate 195672bit 28pps backlog 0b 0p requeues 0 <=========== Note the current rate of traffic. There is no queuing (no packet backlog) lended: 2758458 borrowed: 111773 giants: tokens: 46263 ctokens: 35157 ============== The root class ============ class htb 1:1 root rate 384000bit ceil 384000bit burst 1791b/8 mpu 0b overhead 0b cburst 1791b/8 mpu 0b overhead 0b level 7 Sent 2133276316 bytes 4484785 pkt (dropped 0, overlimits 0 requeues 0) <==== Total output traffic since last 'restart' rate 363240bit 45pps backlog 0b 0p requeues 0 lended: 1081936 borrowed: 0 giants: 0 tokens: -52226 ctokens: -52226 ============= Bulk Class (outgoing rsync, email and bittorrent) ============ class htb 1:130 parent 1:1 leaf 130: prio 3 quantum 1900 rate 76000bit ceil 230000bit burst 1637b/8 mpu 0b overhead 0b cburst 1714b/8 mpu 0b overhead 0b level 0 Sent 1501528722 bytes 1553586 pkt (dropped 198, overlimits 0 requeues 0) rate 162528bit 14pps backlog 0b 8p requeues 0 <======== Queuing is occurring (8 packet backlog). The rate is still below the ceiling. lended: 587134 borrowed: 966459 giants: 0 During peak activity, the rate tops out at around 231000 (just above ceiling). tokens: -30919 ctokens: -97657 ================= Default class (mostly serving web pages) =============== class htb 1:120 parent 1:1 leaf 120: prio 2 quantum 1900 rate 76000bit ceil 230000bit burst 1637b/8 mpu 0b overhead 0b cburst 1714b/8 mpu 0b overhead 0b level 0 Sent 18434920 bytes 60961 pkt (dropped 0, overlimits 0 requeues 0) rate 2240bit 2pps backlog 0b 0p requeues 0 lended: 57257 borrowed: 3704 giants: 0 tokens: 156045 ctokens: 54178
Using your own tc script
Replacing builtin tcstart file If you prefer your own tcstart file, just install it in /etc/shorewall/tcstart. In your tcstart script, when you want to run the tc utility, use the run_tc function supplied by Shorewall if you want tc errors to stop the firewall. Set TC_ENABLED=Yes and CLEAR_TC=Yes Supply an /etc/shorewall/tcstart script to configure your traffic shaping rules. Optionally supply an /etc/shorewall/tcclear script to stop traffic shaping. That is usually unnecessary. If your tcstart script uses the fwmark classifier, you can mark packets using entries in /etc/shorewall/mangle or /etc/shorewall/tcrules.
Traffic control outside Shorewall To start traffic shaping when you bring up your network interfaces, you will have to arrange for your traffic shaping configuration script to be run at that time. How you do that is distribution dependent and will not be covered here. You then should: Set TC_ENABLED=No and CLEAR_TC=No If your script uses the fwmark classifier, you can mark packets using entries in /etc/shorewall/mangle or /etc/shorewall/tcrules.
Testing Tools At least one Shorewall user has found this tool helpful: http://e2epi.internet2.edu/network-performance-toolkit.html
shorewall-docs-xml-5.0.15/upgrade_issues.xml0000644000000000000000000016732513020330134017573 0ustar rootroot
Upgrade Issues Tom Eastep 2002 2003 2004 2005 2006 2007 2008 2009 2012 2013 2015 Thomas M. Eastep 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.
Important It is important that you read all of the sections on this page where the version number mentioned in the section title is later than what you are currently running. In the descriptions that follows, the term group refers to a particular network or subnetwork (which may be 0.0.0.0/0 or it may be a host address) accessed through a particular interface. Examples: eth0:0.0.0.0/0 eth2:192.168.1.0/24 eth3:192.0.2.123 You can use the shorewall show zones command to see the groups associated with each of your zones.
Version >= 5.0.0 See the Shorewall 5 documentation.
Version >= 4.6.0 Beginning with Shorewall 4.6.0, section headers are now preceded by '?' (e.g., '?SECTION ...'). If your configuration contains any bare 'SECTION' entries, the following warning is issued: WARNING: 'SECTION' is deprecated in favor of '?SECTION' - consider running 'shorewall update -D' ... As mentioned in the message, running 'shorewall[6] update -D' will eliminate the warning. Beginning with Shorewall 4.6.0, the 'tcrules' file has been superseded by the 'mangle' file. Existing 'tcrules' files will still be processed, with the restriction that TPROXY is no longer supported in FORMAT 1. If your 'tcrules' file has non-commentary entries, the following warning message is issued: WARNING: Non-empty tcrules file (...); consider running 'shorewall update -t' See shorewall(8) for limitations of 'update -t'. The default value LOAD_HELPERS_ONLY is now 'Yes'. Beginning with Shorewall 4.5.0, FORMAT-1 actions and macros are deprecated and a warning will be issued for each FORMAT-1 action or macro found. WARNING: FORMAT-1 actions are deprecated and support will be dropped in a future release. WARNING: FORMAT-1 macros are deprecated and support will be dropped in a future release. To eliminate these warnings, add the following line before the first rule in the action or macro: ?FORMAT 2 and adjust the columns appropriately. FORMAT-1 actions have the following columns: TARGET SOURCE DEST PROTO DEST PORT(S) SOURCE PORT(S) RATE/LIMIT USER/GROUP MARK while FORMAT-2 actions have these columns: TARGET SOURCE DEST PROTO DEST PORT(S) SOURCE PORT(S) ORIGINAL DEST RATE/LIMIT USER/GROUP MARK CONLIMIT TIME HEADERS (Used in IPv6 only) CONDITION HELPER FORMAT-1 macros have the following columns: TARGET SOURCE DEST PROTO DEST PORT(S) SOURCE PORT(S) RATE/LIMIT USER/GROUP while FORMAT-2 macros have the following columns: TARGET SOURCE DEST PROTO DEST PORT(S) SOURCE PORT(S) ORIGINAL DEST RATE/LIMIT USER/GROUP MARK CONLIMIT TIME HEADERS (Used in IPv6 only) CONDITION HELPER
Versions >= 4.5.0 Shorewall, Shorewall6, Shorewall-lite and Shorewall6-lite now depend on the new package Shorewall-core. If you use the Shorewall installers, you must install Shorewall-core prior to installing or upgrading any of the other packages. The BLACKLIST section of the rules file has been eliminated. If you have entries in that file section, you must move them to the blrules file. This version of Shorewall requires the Digest::SHA1 or the Digest:SHA Perl module. Debian: libdigest-sha-perl Fedora: perl-Digest-SHA1 OpenSuSE: perl-Digest-SHA1 The generated firewall script now maintains the /var/lib/shorewall[6][-lite]/interface.status files used by SWPING and by LSM. Beginning with Shorewall 4.5.2, using /etc/shorewall-lite/vardir and /etc/shorewall6-lite/vardir to specify VARDIR is deprecated in favor of the VARDIR setting in shorewallrc. NOTE: While the name of the variable remains VARDIR, the meaning is slightly different. When set in shorewallrc, each product (shorewall-lite, and shorewall6-lite) will create a directory under the specified path name to hold state information. Example:
VARDIR=/opt/var/ The state directory for shorewall-lite will be /opt/var/shorewall-lite/ and the directory for shorewall6-lite will be /opt/var/shorewall6-lite.
When VARDIR is set in /etc/shorewall[6]/vardir, the product will save its state directly in the specified directory. Begining with Shorewall 4.5.6, the tcrules file is processed if MANGLE_ENABLED=Yes, independent of the setting of TC_ENABLED. This allows actions like TTL and TPROXY to be used without enabling traffic shaping. If you have rules in your tcrules file that you only want processed when TC_ENABLED is other than 'No', then enclose them in
?IF $TC_ENABLED ... ?ENDIF
If they are to be processed only if TC_ENABLED=Internal, then enclose them in
?IF TC_ENABLED eq 'Internal' ... ?ENDIF.
Beginning with Shorewall 4.5.7, the deprecated /etc/shorewall[6]/blacklist files are no longer installed. Existing files are still processed by the compiler. Note that blacklist files may be converted to equivalent blrules files using shorewall[6] update -b. In Shorewall 4.5.7, the /etc/shorewall[6]/notrack file was renamed /etc/shorewall[6]/conntrack. When upgrading to a release >= 4.5.7, the conntrack file will be installed along side of an existing notrack file. If the 'notrack' file is non-empty, a warning message is issued during compilation:
WARNING: Non-empty notrack file (...); please move its contents to the conntrack file
This warning can be eliminated by removing the notrack file (if it has no entries), or by moving its entries to the conntrack file and removing the notrack file. Note that the conntrack file is always populated with rules In Shorewall 4.5.8, the /etc/shorewall[6]/routestopped files were deprecated if favor of new /etc/shorewall[6]/stoppedrules counterparts. The new files have much more familiar and straightforward semantics. Once a stoppedrules file is populated, the compiler will process that file and will ignore the corresponding routestopped file. In Shorewall 4.5.8, a new variable (VARLIB) was added to the shorewallrc file. This variable assumes the role formerly played by VARDIR, and VARDIR now designates the configuration directory for a particular product. This change should be transparent to all users: If VARDIR is set in an existing shorewallrc file and VARLIB is not, then VARLIB is set to ${VARDIR} and VARDIR is set to ${VARLIB}/${PRODUCT}. If VARLIB is set in a shorewallrc file and VARDIR is not, then VARDIR is set to ${VARLIB}/${PRODUCT}. The Shorewall-core installer will automatically update ~/.shorewallrc and save the original in ~/.shorewallrc.bak. Previously, the macro.SNMP macro opened both UDP ports 161 and 162 from SOURCE to DEST. This is against the usual practice of opening these ports in the opposite direction. Beginning with Shorewall 4.5.8, the SNMP macro opens port 161 from SOURCE to DEST as before, and a new SNMPTrap macro is added that opens port 162 (from SOURCE to DEST). Beginning with Shorewall 4.5.11, ?FORMAT is preferred over FORMAT for specifying the format of records in these configuration files: action.* files conntrack interface macro.* files tcrules The first instance of 'FORMAT' (without the '?') will generate this warning: WARNING: FORMAT is deprecated in favor of ?FORMAT; consider running 'shorewall update -D' As the warning suggests, 'shorewall[6] update -D' will convert all instances of FORMAT to ?FORMAT in files on the CONFIG_PATH. Also beginning with Shorewalll 4.5.11, ?COMMENT is preferred over COMMENT for specifying comments to be attached to generated Netfilter rules in the following files: accounting action.* files blrules conntrack macro.* files masq nat rules secmarks tcrules tunnels The first instance of 'COMMENT' (without the '?') will generate this warning: WARNING: COMMENT is deprecated in favor of ?COMMENT; consider running 'shorewall update -D' As the warning suggests, 'shorewall[6] update -D' will convert all instances of COMMENT to ?COMMENT in files on the CONFIG_PATH. Also beginning with Shorewalll 4.5.11, ?COMMENT is preferred over COMMENT for specifying comments to be attached to generated Netfilter rules in the following files: accounting action.* files blrules conntrack macro.* files masq nat rules secmarks tcrules tunnels To allow finer-grained selection of the connection-tracking states that are passed through blacklists (both dynamic and static), a BLACKLIST option was added to shorewall.conf and shorewall6.conf in Shorewall 4.5.13. The BLACKLISTNEWONLY option was deprecated at that point. A 'shorewall update' ( 'shorewall6 update' ) will replace the BLACKLISTNEWONLY option with the equivalent BLACKLIST option. In Shorewall 4.5.14, the BLACKLIST_LOGLEVEL option was renamed BLACKLIST_LOG_LEVEL to be consistent with the other log-level option names. BLACKLIST_LOGLEVEL continues to be accepted as a synonym for BLACKLIST_LOG_LEVEL, but a 'shorewall update' or 'shorewall6 update' command will replace BLACKLIST_LOGLEVEL with BLACKLIST_LOG_LEVEL in the new .conf file.
Versions >= 4.4.0 If you are using Shorewall-perl, there are no additional upgrade issues. If you are using Shorewall-shell or are upgrading from a Shorewall version earlier than 4.0.0 then you will need to migrate to Shorewall-perl. Shorewall-4.3.5 and later only use the perl-based compiler. If you have specified "SHOREWALL_COMPILER=shell" in shorewall.conf, then you must either: change that specification to "SHOREWALL_COMPILER=perl"; or change that specification to "SHOREWALL_COMPILER="; or delete the specification altogether. Failure to do so will result in the following warning:
WARNING: SHOREWALL_COMPILER=shell ignored. Support for Shorwall-shell has been removed in this release.
The shorewall stop, shorewall clear, shorewall6 stop and shorewall6 clear commands no longer read the routestopped file. The routestopped file used is the one that was present at the last start, restart or restore command. If you modify the routestopped file, you must restart Shorewall before the changes to that file will take effect. The old macro parameter syntax (e.g., SSH/ACCEPT) is now deprecated in favor of the new syntax (e.g., SSH(ACCEPT)). The 4.3 documentation uses the new syntax exclusively, although the old syntax continues to be supported. Support for the SAME target in /etc/shorewall/masq and /etc/shorewall/rules has been removed, following the removal of the underlying support in the Linux kernel. Supplying an interface name in the SOURCE column of /etc/shorewall/masq is now deprecated. Entering the name of an interface there will result in a compile-time warning: WARNING: Using an interface as the masq SOURCE requires the interface to be up and configured when Shorewall starts/restarts To avoid this warning, replace interface names by the corresponding netwok(s) in CIDR format (e.g., 192.168.144.0/24). Previously, Shorewall has treated traffic shaping class IDs as decimal numbers (or pairs of decimal numbers). That worked fine until IPMARK was implemented. IPMARK requires Shorewall to generate class Ids in numeric sequence. In 4.3.9, that didn't work correctly because Shorewall was generating the sequence "..8,9,10,11..." when the correct sequence was "...8,9,a,b,...". Shorewall now treats class IDs as hex, like 'tc' and 'iptables' do. This should only be an issue if you have more than 9 interfaces defined in /etc/shorewall/tcdevices and if you use class IDs in /etc/shorewall/tcrules. You will need to renumber the class IDs for devices 10 and greater. Support for the 'norfc1918' interface and host option has been removed. If 'norfc1918' is specified for an entry in either the interfaces or the hosts file, a warning is issued and the option is ignored. Simply remove the option to avoid the warning. Similarly, if RFC1918_STRICT=Yes or a non-empty RFC1918_LOG_LEVEL is given in shorewall.conf, a warning will be issued and the option will be ignored. You may simply delete the RFC1918-related options from your shorewall.conf file if you are seeing warnings regarding them. Users who currently use 'norfc1918' are encouraged to consider using NULL_ROUTE_RFC1918=Yes instead. The install.sh scripts in the Shorewall and Shorewall6 packages no longer create a backup copy of the existing configuration. If you want your configuration backed up prior to upgrading, you will need to do that yourself. As part of this change, the fallback.sh scripts are no longer released. Previously, if an ipsec zone was defined as a sub-zone of an ipv4 or ipv6 zone using the special <child>:<parent>,... syntax, CONTINUE policies for the sub-zone did not work as expected. Traffic that was not matched by a sub-zone rule was not compared against the parent zone(s) rules. In 4.4.0, such traffic IS compared against the parent zone rules. The name any is now reserved and may not be used as a zone name. Perl module initialization has changed in Shorewall 4.4.1. Previously, each Shorewall Perl package would initialize its global variables for IPv4 in an INIT block. Then, if the compilation turned out to be for IPv6, Shorewall::Compiler::compiler() would reinitialize them for IPv6. Beginning in Shorewall 4.4.1, the modules do not initialize themselves in an INIT block. So if you use Shorewall modules outside of the Shorewall compilation environment, then you must explicitly call the module's 'initialize' function after the module has been loaded. Checking for zone membership has been tighened up. Previously, a zone could contain <interface>:0.0.0.0/0 along with other hosts; now, if the zone has <interface>:0.0.0.0/0 (even with exclusions), then it may have no additional members in /etc/shorewall/hosts. ADD_IP_ALIASES=No is now the setting in the released shorewall.conf and in all of the samples. This will not affect you during upgrade unless you choose to replace your current shorewall.conf with the one from the release (not recommended). The names of interface configuration variables in generated scripts have been changed to ensure uniqueness. These names now begin with SW_. This change will only affect you if your extension scripts are using one or more of these variables. Old Variable Name New Variable Name iface_address SW_iface_ADDRESS iface_BCASTS SW_iface_BCASTS iface_ACASTS SW_iface_CASTS iface_GATEWAY SW_iface_NETWORKS iface_ADDRESSES SW_iface_ADDRESSES iface_NETWORKS SW_iface_NETWORKS iface_MAC SW_iface_MAC provider_IS_USABLE SW_provider_IS_USABLE were iface is a capitalized interface name (e.g., ETH0) and provider is the capitalized name of a provider. If your /etc/shorewall/params (or /etc/shorewall6/params) file sends output to Standard Output, you need to be aware that the output will be redirected to Standard Error beginning with Shorewall 4.4.16. Beginning with Shorewall 4.4.17, the EXPORTPARAMS option is deprecated. With EXPORTPARAMS=No, the variables set by /etc/shorewall/params (/etc/shorewall6/params) at compile time are now available in the compiled firewall script. The iprange and ipaddr commands require the 'bc' utility. Beginning with Shorewall 4.4.26, the WIDE_TC_MARKS and HIGH_ROUTE_MARKS options are deprecated in favor of TC_BITS, MASK_BITS, PROVIDER_BITS and PROVIDER_OFFSET. See the Packet Marking using /etc/shorewall/tcrules article. The shorewall update (shorewall6 update) command will automatically generate the correct values for these new options depending on your settings of WIDE_TC_MARKS and HIGH_ROUTE_MARKS. Be sure to check the latest 4.4 Release Notes linked from the home page.
Versions >= 4.2.0 Previously, when HIGH_ROUTE_MARKS=Yes, Shorewall allowed non-zero mark values < 256 to be assigned in the OUTPUT chain. This has been changed so that only high mark values may be assigned there. Packet marking rules for traffic shaping of packets originating on the firewall must be coded in the POSTROUTING table. Previously, Shorewall did not range-check the value of the VERBOSITY option in shorewall.conf. Beginning with Shorewall 4.2: a) A VERBOSITY setting outside the range -1 through 2 is rejected. b) After the -v and -q options are applied, the resulting value is adjusted to fall within the range -1 through 2. Specifying a destination zone in a NAT-only rule now generates a warning and the destination zone is ignored. NAT-only rules are: NONAT REDIRECT- DNAT- The default value for LOG_MARTIANS has been changed. Previously, the defaults were: Shorewall-perl - 'Off' Shorewall-shell - 'No' The new default values are: Shorewall-perl 'On. Shorewall-shell 'Yes' Shorewall-perl users may: Accept the new default -- martians will be logged from all interfaces with route filtering except those with log_martians=0 in /etc/shorewall/interfaces. Explicitly set LOG_MARTIANS=Off to maintain compatibility with prior versions of Shorewall. Shorewall-shell users may: Accept the new default -- martians will be logged from all interfaces with the route filtering enabled. Explicitly set LOG_MARTIANS=No to maintain compatibility with prior versions of Shorewall. The value of IMPLICIT_CONTINUE in shorewall.conf (and samples) has been changed from Yes to No. If you are a Debian or Ubuntu user and you select replacement of shorewall.conf during upgrade to Shorewall 4.2, you will want to change IMPLICIT_CONTINUE back to 'Yes' if you have nested zones that rely on IMPLICIT_CONTINUE=Yes for proper operation. The 'norfc1918' option is deprecated. Use explicit rules instead. Note that there is a new 'Rfc1918' macro that acts on addresses reserved by RFC 1918. DYNAMIC_ZONES=Yes is no longer supported by Shorewall-perl. Use ipset-based zones instead.
Versions >= 4.0.0-Beta7 Beginning with Shorewall 4.0.0, there is no single 'shorewall' package. Rather there are two compiler packages (shorewall-shell and shorewall-perl) and a set of base files (shorewall-common) required by either compiler package. Although the names of the packages are changing, you can upgrade without having to uninstall/reinstall. To repeat: You do not need to uninstall any existing package. If you attempt to upgrade using the shorewall-common RPM, you get this result:gateway:~ # rpm -Uvh shorewall-common-4.0.0.noarch.rpm error: Failed dependencies: shorewall_compiler is needed by shorewall-common-4.0.0-1.noarch gateway:~ #You must either:rpm -Uvh shorewall-shell-4.0.0.noarch.rpm shorewall-common-4.0.0.noarch.rpmorrpm -Uvh shorewall-shell-4.0.0.noarch.rpm shorewall-perl-4.0.0.noarch.rpm shorewall-common-4.0.0.noarch.rpmIf you don't want shorewall-shell, you must use the second command (installing both shorewall-shell and shorewall-perl) then remove shorewall-shell using this command:rpm -e shorewall-shellIf you are upgrading using the tarball, you must install shorewall-shell and/or shorewall-perl before you upgrade using shorewall-common. Otherwise, the install.sh script fails with: ERROR: No Shorewall compiler is installed The shorewall-shell and shorewall-perl packages are installed from the tarball in the expected way; untar the package, and run the install.sh script. Example 1: You have 'shorewall' installed and you want to continue to use the shorewall-shell compiler.tar -jxf shorewall-common-4.0.0.tar.bz2 tar -jxf shorewall-shell-4.0.0.tar.bz2 pushd shorewall-shell-4.0.0 ./install.sh popd pushd shorewall-common-4.0.0 ./install.sh shorewall check shorewall restartExample 2: You have shorewall 3.4.4 and shorewall-perl 4.0.0-Beta7 installed and you want to upgrade to 4.0. You do not need the shell-based compiler.tar -jxf shorewall-common-4.0.0.tar.bz2 tar -jxf shorewall-perl-4.0.0.tar.bz2 pushd shorewall-perl-4.0.0 ./install.sh popd pushd /shorewall-common-4.0.0 ./install.sh shorewall check shorewall restart The RPMs are set up so that if you upgrade an existing Shorewall installation as part of a distribution upgrade and you have not already installed shorewall-perl, then you will end up with Shorewall-common and Shorewall-shell installed. The ROUTE_FILTER and LOG_MARTIANS options in shorewall.conf work slightly differently in Shorewall 4.0.0. In prior releases, leaving these options empty was equivalent to setting them to 'No' which caused the corresponding flag in /proc to be reset for all interfaces. Beginning in Shorewall 4.0.0, leaving these options empty causes Shorewall to leave the flags in /proc as they are. You must set the option to 'No' in order to obtain the old behavior. The option is now the default for ipsec tunnels. Tunnels that use AH (protocol 51) must specify in the TYPE column. Users upgrading from Debian Etch (Shorewall 3.2.6) to Debian Lenny (Shoreall 4.0.15) report finding an issue with VOIP (Asterisk) traffic. See Shorewall FAQ 77 for details.
Versions >= 3.4.0-Beta1 Shorewall supports the notion of "default actions". A default action defines a set of rules that are applied before a policy is enforced. Default actions accomplish two goals: Relieve log congestion. Default actions typically include rules to silently drop or reject traffic that would otherwise be logged when the policy is enforced. Insure correct operation. Default actions can also avoid common pitfalls like dropping connection requests on TCP port 113. If these connections are dropped (rather than rejected) then you may encounter problems connecting to Internet services that utilize the AUTH protocol of client authentication. In prior Shorewall versions, default actions (action.Drop and action.Reject) were defined for DROP and REJECT policies in /usr/share/shorewall/actions.std. These could be overridden in /etc/shorewall/actions. This approach has two drawbacks: All DROP policies must use the same default action and all REJECT policies must use the same default action. Now that we have modularized action processing, we need a way to define default rules for a policy that does not involve actions. If you have not overridden the defaults using entries in /etc/shorewall/actions then you need make no changes to migrate to Shorewall version 3.4. If you have overridden either of these entries, then please read on. The change in version 3.4 is two-fold: Four new options have been added to the /etc/shorewall/shorewall.conf file that allow specifying the default action for DROP, REJECT, ACCEPT and QUEUE. The options are DROP_DEFAULT, REJECT_DEFAULT, ACCEPT_DEFAULT and QUEUE_DEFAULT. DROP_DEFAULT describes the rules to be applied before a connection request is dropped by a DROP policy; REJECT_DEFAULT describes the rules to be applied if a connection request is rejected by a REJECT policy. The other two are similar for ACCEPT and QUEUE policies. The value assigned to these may be: The name of an action. The name of a macro. 'None' or 'none' The default values are: DROP_DEFAULT="Drop" REJECT_DEFAULT="Reject" ACCEPT_DEFAULT=none QUEUE_DEFAULT=none If USE_ACTIONS=Yes, then these values refer to action.Drop and action.Reject respectively. If USE_ACTIONS=No, then these values refer to macro.Drop and macro.Reject. If you set the value of either option to "None" then no default action will be used and the default action or macro (if any) must be specified in /etc/shorewall/policy. The POLICY column in /etc/shorewall/policy has been extended. In /etc/shorewall/policy, when the POLICY is DROP, REJECT, ACCEPT or QUEUE then the policy may be followed by ":" and one of the following: The word "None" or "none". This causes any default action defined in /etc/shorewall/shorewall.conf to be omitted for this policy. The name of an action (requires that USE_ACTIONS=Yes in shorewall.conf). That action will be invoked before the policy is enforced. The name of a macro. The rules in that macro will be applied before the policy is enforced. This does not require USE_ACTIONS=Yes. Example: #SOURCE DEST POLICY LOGLEVEL loc net ACCEPT net all DROP:MyDrop info # # THE FOLLOWING POLICY MUST BE LAST # all all REJECT:MyReject info The 'Limit' action is now a builtin. If you have 'Limit' listed in /etc/shorewall/actions, remove the entry. Also remove the files /etc/shorewall/action.Limit and/or /etc/shorewall/Limit if you have them. This issue only applies if you have entries in /etc/shorewall/providers. Previously, Shorewall has not attempted to undo the changes it has made to the firewall's routing as a result of entries in /etc/shorewall/providers and /etc/shorewall/routes. Beginning with this release, Shorewall will attempt to undo these changes. This change can present a migration issue in that the initial routing configuration when this version of Shorewall is installed has probably been changed by Shorewall already. Hence, when Shorewall restores the original configuration, it will be installing a configuration that the previously-installed version has already modified. The steps to correcting this after you have installed version 3.4 or later of Shorewall are as follows: shorewall[-lite] stop Remove the files /var/lib/shorewall[-lite]/default_route and /var/lib/shorewall[-lite]/undo_routing if they exist. Either restart networking or reboot. shorewall[-lite] start This issue only applies if you run Shorewall Lite. The /etc/shorewall-lite/shorewall.conf file has been renamed /etc/shorewall-lite/shorewall-lite.conf. When you upgrade, your shorewall.conf file will be renamed shorewall-lite.conf.
Version >= 3.2.0 If you are upgrading from version 2.4 or earlier, please read the 3.0.0 upgrade considerations below. A number of macros have been split into two. The macros affected are: IMAP LDAP NNTP POP3 SMTP Each of these macros now handles only traffic on the native (plaintext) port. There is a corresponding macro with S added to the end of the name for the SSL version of the same protocol. Thus each macro results in the insertion of only one port per invocation. The Web macro has not been split, but two new macros, HTTP and HTTPS have been created. The Web macro is deprecated in favour of these new macros, and may be removed from future Shorewall releases. These changes have been made to ensure no unexpected ports are opened due to the use of macros. In previous Shorewall releases, DNAT and REDIRECT rules supported a special syntax for exclusion of a subnet from the effect of the rule. Example:
Z2 is a subzone of Z1: DNAT Z1!Z2 loc:192.168.1.4 ...
That feature has never worked correctly when Z2 is a dynamic zone. Furthermore, now that Shorewall supports exclusion lists, the capability is redundant since the above rule can now be written in the form: DNAT Z1:!<list of exclusions> loc:192.168.1.4 ... Beginning with Shorewall 3.2.0, the special exclusion syntax will no longer be supported. Important if you use the QUEUE target. In the /etc/shorewall/rules file and in actions, you may now specify 'tcp:syn' in the PROTO column. 'tcp:syn' is equivalent to 'tcp' but also requires that the SYN flag is set and the RST, FIN and ACK flags be off ("--syn" is added to the iptables rule). As part of this change, Shorewall no longer adds the "--syn" option to TCP rules that specify QUEUE as their target. Extension Scripts may require change In previous releases, extension scripts were executed during [re]start by using the Bourne Shell "." operator. In addition to executing commands during [re]start, these scripts had to "save" the commands to be executed during shorewall restore. This clumsiness has been eliminated in Shorewall 3.2. In Shorewall 3.2, extension scripts are copied in-line into the compiled program and are executed in-line during start, restart and restore. This applies to all extension scripts except those associated with a chain or action -- those extension scripts continue to be processed at compile time. This new approach has two implications for existing scripts. It is no longer necessary to save the commands; so functions like 'save_command', 'run_and_save_command' and 'ensure_and_save_command' need no longer be called. The generated program will contain functions with these names: save_command() - does nothing run_and_save_command() - runs the passed command ensure_and_save_command() - runs the passed command and stops the firewall if the command fails. These functions should provide for transparent migration of scripts that use them until you can get around to eliminating their use completely. When the extension script is copied into the compiled program, it is indented to line up with the surrounding code. If you have 'awk' installed on your system, the Shorewall compiler will correctly handle line continuation (last character on the line = "\"). If you do not have awk, it will not be possible to use line-continuation in your extension scripts. In no case is it possible to continue a quoted string over multiple lines without having additional whitespace inserted into the string. Beginning with this release, the way in which packet marking in the PREROUTING chain interacts with the 'track' option in /etc/shorewall/providers has changed in two ways: Packets arriving on a tracked interface are now passed to the PREROUTING marking chain so that they may be marked with a mark other than the 'track' mark (the connection still retains the 'track' mark). When HIGH_ROUTE_MARKS=Yes, you can still clear the mark on packets in the PREROUTING chain (i.e., you can specify a mark value of zero). Kernel version 2.6.16 introduces 'xtables', a new common packet filtering and connection tracking facility that supports both IPv4 and IPv6. Because a different set of kernel modules must be loaded for xtables, Shorewall now includes two 'modules' files: /usr/share/shorewall/modules -- the former /etc/shorewall/modules /usr/share/shorewall/xmodules -- a new file that support xtables. If you wish to use the new file, then simply execute this command: cp -f /usr/share/shorewall/xmodules /etc/shorewall/modules (Versions >= 3.2.3) Previously, CLASSIFY tcrules were always processed out of the POSTROUTING chain. Beginning with this release, they are processed out of the POSTROUTING chain *except* when the SOURCE is $FW[:<address>] in which case the rule is processed out of the OUTPUT chain. With correctly-coded rulesets, this change should have no effect. Users having incorrectly-coded tcrules may need to change them. Example:
#MARK/ SOURCE DEST PROTO DEST SOURCE #CLASSIFY PORTS(S) PORT(S) 1:110 $FW eth3 tcp - 22
While the user may have expected this rule to only affect traffic from the firewall itself, the rule was really equivalent to this one:
#MARK/ SOURCE DEST PROTO DEST SOURCE #CLASSIFY PORTS(S) PORT(S) 1:110 0.0.0.0/0 eth3 tcp - 22
So after this change, the second rule will be required rather than the first if that is what was really wanted.
Version >= 3.0.0 The "monitor" command has been eliminated. The "DISPLAY" and "COMMENTS" columns in the /etc/shorewall/zones file have been removed and have been replaced by the former columns of the /etc/shorewall/ipsec file. The latter file has been removed. Additionally the FW option in shorewall.conf has been deprecated and is no longer set to 'fw' by default. New users are expected to define the firewall zone in /etc/shorewall/zones. Adhering to the principle of least astonishment, the old /etc/shorewall/ipsec file will continue to be supported. A new IPSECFILE variable in /etc/shorewall/shorewall.conf determines the name of the file that Shorewall looks in for IPSEC information. If that variable is not set or is set to the empty value then IPSECFILE=ipsec is assumed. So if you simply upgrade and don't do something idiotic like replace your current shorewall.conf file with the new one, your old configuration will continue to work. A dummy 'ipsec' file is included in the release so that your package manager (e.g., rpm) won't remove your existing file. The shorewall.conf file included in this release sets IPSECFILE=zones so that new users are expected to use the new zone file format. The DROPINVALID option has been removed from shorewall.conf. The behavior will be as if DROPINVALID=No had been specified. If you wish to drop invalid state packets, use the dropInvalid built-in action. The 'nobogons' interface and hosts option as well as the BOGON_LOG_LEVEL option have been eliminated. Most of the standard actions have been replaced by parameterized macros (see below). So for example, the action.AllowSMTP and action.DropSMTP have been removed an a parameterized macro macro.SMTP has been added to replace them. In order that current users don't have to immediately update their rules and user-defined actions, Shorewall can substitute an invocation of the a new macro for an existing invocation of one of the old actions. So if your rules file calls AllowSMTP, Shorewall will replace that call with SMTP(ACCEPT). Because this substitution is expensive, it is conditional based on the setting of MAPOLDACTIONS in shorewall.conf. If this option is set to YES or if it is not set (such as if you are using your old shorewall.conf file) then Shorewall will perform the substitution. Once you have converted to use the new macros, you can set MAPOLDACTIONS=No and invocations of those actions will go much quicker during 'shorewall [re]start'. The STATEDIR variable in /etc/shorewall/shorewall.conf has been removed. STATEDIR is now fixed at /var/lib/shorewall. If you have previously set STATEDIR to another directory, please copy the files from that directory to /var/lib/shorewall/ before [re]starting Shorewall after the upgrade to this version. The "shorewall status" command now just gives the status of Shorewall (started or not-started). The previous status command has been renamed "dump". The command also shows the state relative to the state diagram at http://shorewall.net/starting_and_stopping_shorewall.htm. In addition to the state, the time and date at which that state was entered is shown. Note that at least one "shorewall [re]start" must be issued after upgrading to this release before "shorewall status" will show anything but "Unknown" for the state. The "shorewall forget" command now removes the dynamic blacklist save file (/var/lib/shorewall/save). In previous versions of Shorewall, the rules generated by entries in /etc/shorewall/tunnels preceded those rules generated by entries in /etc/shorewall/rules. Beginning with this release, the rules generated by entries in the tunnels file will appear *AFTER* the rules generated by the rules file. This may cause you problems if you have REJECT, DENY or CONTINUE rules in your rules file that would cause the tunnel transport packets to not reach the rules that ACCEPT them. See http://www.shorewall.net/VPNBasics.html for information on the rules generated by entries in the tunnels file. The NEWNOTSYN and LOGNEWNOTSYN options in shorewall.conf have been removed as have the 'newnotsyn' options in /etc/shorewall/interfaces and /etc/shorewall/hosts. TCP new-not-syn packets may be blocked using the 'dropNotSyn' or 'rejNotSyn' built-in actions. Example: Reject all new-not-syn packets from the net and log them at the 'info' level. #ACTION SOURCE DEST PROTO SECTION NEW rejNotSyn:info net all tcp Note that the rule is added at the front of the NEW section of the rules file. A new TC_SCRIPT option replaces TC_ENABLED in shorewall.conf. If the option is not set then the internal shaper (tc4shorewall by Arne Bernin) is used. Otherwise, the script named in the variable is used. Users who currently use an /etc/shorewall/tcstart file and wish to continue to do so should set TC_SCRIPT=/etc/shorewall/tcstart in shorewall.conf.
Version >= 2.4.0 Shorewall now enforces the restriction that mark values used in /etc/shorewall/tcrules are less than 256. If you are using mark values >= 256, you must change your configuration before you upgrade. The value "ipp2p" is no longer accepted in the PROTO column of the /etc/shorewall/rules file. This support has never worked as intended and cannot be made to work in a consistent way. A "Howto" article on filtering P2P with Shorewall and ipp2p will be forthcoming. LEAF/Bering packages for 2.4.0 and later releases are not available from shorewall.net. See the LEAF site for those packages.
shorewall-docs-xml-5.0.15/Laptop.xml0000644000000000000000000000470013020330134015773 0ustar rootroot
Shorewall on a Laptop Tom Eastep 2009 Thomas M. Eastep 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.
Overview Laptop computers generally have several network interfaces, one of which will be used at a time. Ethernet interface ‒ Used when the computer is on the desktop at home or at work. Wireless interface ‒ Used when the laptop is being used in a cafe, train or airline terminal. Point-to-point (PPP) interface ‒ Used when neither wired nor wireless service are available. Shorewall can be configured to treat these interfaces the same and to be able to switch between them without having to reconfigure.
Configuration The key to configuring Shorewall on a laptop is to define multiple optional interfaces for the 'net' zone in /etc/shorewall/interfaces. #ZONE INTERFACE OPTIONS net eth0 optional,… net wlan0 optional,… net ppp0 optional,… With this configuration, access to the 'net' zone is possible regardless of which of the interfaces is being used.
shorewall-docs-xml-5.0.15/ports.xml0000644000000000000000000005301113020330134015702 0ustar rootroot
Ports Required for Various Services/Applications Tom Eastep Cristian Rodriguez R. 2001- Thomas M. Eastep 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. In addition to those applications described in the /etc/shorewall/rules documentation, here are some other services/applications that you may need to configure your firewall to accommodate. This article applies to Shorewall 3.0 and later. If you are running a version of Shorewall earlier than Shorewall 3.0.0 then please see the documentation for that release
Important Notes Shorewall distribution contains a library of user-defined macros that allow for easily allowing or blocking a particular application. ls /usr/share/shorewall/macro.* for the list of macros in your distribution. If you find what you need, you simply use the macro in a rule. For example, to allow DNS queries from the dmz zone to the net zone: #ACTION SOURCE DEST DNS(ACCEPT) dmz net In the rules that are shown in this document, the ACTION is shown as ACCEPT. You may need to use DNAT (see FAQ 30) or you may want DROP or REJECT if you are trying to block the application. Example: You want to port forward FTP from the net to your server at 192.168.1.4 in your DMZ. The FTP section below gives you: #ACTION SOURCE DEST PROTO DPORT FTP(ACCEPT) <source> <destination> You would code your rule as follows: #ACTION SOURCE DESTINATION PROTO DPORT FTP(DNAT) net dmz:192.168.1.4
Auth (identd) It is now the 21st Century ; don't use identd in production anymore. #ACTION SOURCE DESTINATION PROTO DPORT Auth(ACCEPT) <source> <destination>
BitTorrent This information is valid only for Shorewall 3.2 or later. This rule assumes that your BitTorrent client listens on the default port(s) #ACTION SOURCE DESTINATION PROTO DPORT BitTorrent(ACCEPT)<source> <destination>
DNS #ACTION SOURCE DESTINATION PROTO DPORT DNS(ACCEPT) <source> <destination> Note that if you are setting up a DNS server that supports recursive resolution, the server is the <destination> for resolution requests (from clients) and is also the <source> of recursive resolution requests (usually to other servers in the 'net' zone). So for example, if you have a public DNS server in your DMZ that supports recursive resolution for local clients then you would need: #ACTION SOURCE DESTINATION PROTO DPORT DNS(ACCEPT) all dmz DNS(ACCEPT) dmz net Recursive Resolution means that if the server itself can't resolve the name presented to it, the server will attempt to resolve the name with the help of other servers.
Emule This information is valid only for Shorewall 3.2 or later. In contrast to how the rest of this article is organized, for emule I will give you the rules necessary to run emule on a single machine in your loc network (since that's what 99.99% of you want to do). Assume that: The internal machine running emule has IP address 192.168.1.4. You use Masquerading or SNAT for the local network. The zones are named as they are in the two- and three-interface QuickStart guides). Your loc->net policy is ACCEPT /etc/shorewall/rules: #ACTION SOURCE DESTINATION PROTO DPORT Edonkey(DNAT) net loc:192.168.1.4 #if you wish to enable the Emule webserver, add this rule too. DNAT net loc:192.168.1.4 tcp 4711
FTP #ACTION SOURCE DESTINATION PROTO DPORT FTP(ACCEPT) <source> <destination> Look here for much more information.
Gnutella The internal machine running a Gnutella Client has IP address 192.168.1.4. You use Masquerading or SNAT for the local network. The zones are named as they are in the two- and three-interface QuickStart guides). Your loc->net policy is ACCEPT #ACTION SOURCE DESTINATION PROTO DPORT Gnutella(DNAT) net loc:192.168.1.4
ICQ/AIM #ACTION SOURCE DESTINATION PROTO DPORT ICQ(ACCEPT) <source> net
IMAP When accessing your mail from the Internet, use only IMAP over SSL. This information is valid only for Shorewall 3.2 or later. #ACTION SOURCE DESTINATION PROTO DPORT IMAP(ACCEPT) <source> <destination> # Unsecure IMAP IMAPS(ACCEPT) <source> <destination> # IMAP over SSL.
IPSEC #ACTION SOURCE DESTINATION PROTO DPORT ACCEPT <source> <destination> 50 ACCEPT <source> <destination> 51 ACCEPT <source> <destination> udp 500 ACCEPT <destination> <source> 50 ACCEPT <destination> <source> 51 ACCEPT <destination> <source> udp 500 Lots more information here and here.
LDAP This information is valid only for Shorewall 3.2 or later. #ACTION SOURCE DESTINATION PROTO DPORT LDAP(ACCEPT) <source> <destination> #Insecure LDAP LDAPS(ACCEPT) <source> <destination> # LDAP over SSL
<trademark>My\SQL</trademark> This information is valid only for Shorewall 3.2 or later. Allowing access from untrusted hosts to your MySQL server represents a severe security risk. DO NOT USE THIS if you don't know how to deal with the consequences, you have been warned. #ACTION SOURCE DESTINATION PROTO DPORT MySQL(ACCEPT) <source> <destination>
NFS #ACTION SOURCE DESTINATION PROTO DPORT ACCEPT <z1>:<list of client IPs> <z2>:a.b.c.d tcp 111 ACCEPT <z1>:<list of client IPs> <z2>:a.b.c.d udp For more NFS information, see http://lists.shorewall.net/~kb/.
NTP (Network Time Protocol) #ACTION SOURCE DESTINATION PROTO DPORT NTP(ACCEPT) <source> <destination>
<trademark>PCAnywhere</trademark> #ACTION SOURCE DESTINATION PROTO DPORT PCA(ACCEPT) <source> <destination>
POP3 If Possible , Avoid this protocol , use IMAP instead. This information is valid only for Shorewall 3.2 or later #ACTION SOURCE DESTINATION PROTO DPORT POP3(ACCEPT) <source> <destination> # Secure POP3S(ACCEPT) <source> <destination> #Unsecure Pop3
PPTP #ACTION SOURCE DESTINATION PROTO DPORT ACCEPT <source> <destination> 47 ACCEPT <source> <destination> tcp 1723 Lots more information here and here.
rdate #ACTION SOURCE DESTINATION PROTO DPORT Rdate(ACCEPT) <source> <destination>
rsync #ACTION SOURCE DESTINATION PROTO DPORT Rsync(ACCEPT) <source> <destination>
Siproxd This assumes siproxd is running on the firewall and is using the default ports. #ACTION SOURCE DESTINATION PROTO DPORT REDIRECT loc 5060 udp 5060 ACCEPT net fw udp 5060 ACCEPT net fw udp 7070:7089
SSH/SFTP #ACTION SOURCE DESTINATION PROTO DPORT SSH(ACCEPT)<source> <destination>
SMB/NMB (Samba/<trademark>Windows</trademark> Browsing/File Sharing) #ACTION SOURCE DESTINATION PROTO DPORT SMB(ACCEPT) <source> <destination> SMB(ACCEPT) <destination> <source> Also, see this page.
SMTP This information is valid only for Shorewall 3.2 or later. #ACTION SOURCE DESTINATION PROTO DPORT SMTP(ACCEPT) <source> <destination> #Insecure SMTP SMTPS(ACCEPT) <source> <destination> #SMTP over SSL (TLS)
SNMP #ACTION SOURCE DESTINATION PROTO DPORT SNMP(ACCEPT) <source> <destination>
SVN This information is valid only for Shorewall 3.2 or later. This rule is for Subversion running in svnserve mode only. #ACTION SOURCE DESTINATION PROTO DPORT SVN(ACCEPT) <source> <destination>
Telnet The telnet protocol is very insecure, don't use it. #ACTION SOURCE DESTINATION PROTO DPORT Telnet(ACCEPT) <source> <destination>
TFTP You must have TFTP connection tracking support in your kernel. If modularized, the modules are ip_conntrack_tftp (and ip_nat_tftp if any form of NAT is involved) These modules may be loaded using entries in /etc/shorewall/modules. The ip_conntrack_tftp module must be loaded first. Note that the /etc/shorewall/modules file released with recent Shorewall versions contains entries for these modules. #ACTION SOURCE DESTINATION PROTO DPORT ACCEPT <source> <destination> udp 69
Traceroute #ACTION SOURCE DESTINATION PROTO DPORT Trcrt(ACCEPT) <source> <destination> #Good for 10 hops UDP traceroute uses ports 33434 through 33434+<max number of hops>-1. Note that for the firewall to respond with a TTL expired ICMP reply, you will need to allow ICMP 11 outbound from the firewall. The standard Shorewall sample configurations all set this up for you automatically since those sample configurations enable all ICMP packet types originating on the firewall itself. #ACTION SOURCE DESTINATION PROTO DPORT ACCEPT fw net icmp ACCEPT fw loc icmp ACCEPT fw ...
Usenet (NNTP) #ACTION SOURCE DESTINATION PROTO DPORT NNTP(ACCEPT) <source> <destination> NNTPS(ACCEPT) <source> <destination> # secure NNTP TCP Port 119
VNC This information is valid only for Shorewall 3.2 or later. Vncviewer to Vncserver -- TCP port 5900 + <display number>. the following rule handles VNC traffic for VNC displays 0 - 9. #ACTION SOURCE DESTINATION PROTO DPORT VNC(ACCEPT) <source> <destination> Vncserver to Vncviewer in listen mode -- TCP port 5500. #ACTION SOURCE DESTINATION PROTO DPORT VNCL(ACCEPT) <source> <destination>
<trademark>Vonage</trademark> The standard Shorewall loc->net ACCEPT policy is all that is required for Vonage IP phone service to work, provided that you have loaded the tftp helper modules (add the following entries to /etc/shorewall/modules if they are not there already):
Web Access This information is valid for Shorewall 3.2 or later. #ACTION SOURCE DESTINATION PROTO DPORT HTTP(ACCEPT) <source> <destination> #Insecure HTTP HTTPS(ACCEPT) <source> <destination> #Secure HTTP
Webmin #ACTION SOURCE DESTINATION PROTO DPORT Webmin(ACCEPT) <source> <destination> Webmin use TCP port 10000.
Whois #ACTION SOURCE DESTINATION PROTO DPORT Whois(ACCEPT) <source> <destination>
X/XDMCP Assume that the Chooser and/or X Server are running at <chooser> and the Display Manager/X applications are running at <apps>. #ACTION SOURCE DESTINATION PROTO DPORT ACCEPT <chooser> <apps> udp 177 #XDMCP ACCEPT <apps> <chooser> tcp 6000:6009 #X Displays 0-9
Other Source of Port Information Didn't find what you are looking for -- have you looked in your own /etc/services file? Still looking? Try http://www.networkice.com/advice/Exploits/Ports
shorewall-docs-xml-5.0.15/support.xml0000644000000000000000000004652413020330134016262 0ustar rootroot
Shorewall Support Guide 2001-2011 Thomas M. Eastep 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. This article applies to Shorewall 4.0 and later. If you are running a version of Shorewall earlier than Shorewall 4.0.0 then please see the documentation for that release.
Before Reporting a Problem or Asking a Question There are a number of sources of Shorewall information. Please try these before you post. The currently-supported Shorewall major releases are 4.5 and 4.6. Shorewall versions earlier than 4.5.0 are no longer supported; we will try to help but we will not spend time reading earlier code to try to help you solve a problem and we will not release a patch to correct any defect found. More than half of the questions posted on the support list have answers directly accessible from the Documentation Index The FAQ has solutions to more than 100 common problems. The Troubleshooting Information contains a number of tips to help you solve common problems. The Shorewall Users Mailing List Archives are a good source of information.
Problem Reporting Guidelines Please refer to the following flowchart to guide you through the problem reporting process. It will ensure that you provide us with the information we need to solve your problem as quickly as possible. Please don't use distribution specific programs like "service" or init scripts to start/restart Shorewall while trying to solve a problem, just follow carefully the instructions below. As a general matter, please do not edit the diagnostic information in an attempt to conceal your IP address, netmask, nameserver addresses, domain name, etc. These aren't secrets, and concealing them often misleads us (and 80% of the time, a cracker could derive them anyway from information contained in the SMTP headers of your post). If your problem is that an error occurs when you try to shorewall start or if Shorewall is otherwise failing to start properly, then please do the following.
If your VERBOSITY setting in shorewall.conf is less than 2 and you are running the Shorewall-shell compiler, then try running with a higher verbosity level by using the "-vv" option:
shorewall -vv [re]start
That will give you additional progress messages that may make it clear which entry in which file is generating the error. If that didn't solve your problem, then please /sbin/shorewall trace start > /tmp/trace 2>&1 Forward the /tmp/trace file as an attachment compressed with gzip or bzip2. If compilation succeeds but the compiled program fails, then please include the compiled program with your report. The compiled program will be named /var/lib/shorewall/.start if the command is shorewall start and it will be named /var/lib/shorewall/.restart if the command is shorewall restart. If you are running Shorewall-perl 4.0.5 or later, you may also include the word debug as the first argument to the /sbin/shorewall and /sbin/shorewall-lite commands.shorewall debug restartIn most cases, debug is a synonym for trace. The exceptions are: debug is ignored by the Shorewall-perl compiler. debug causes altered behavior of scripts generated by the Shorewall-perl compiler. These scripts normally use iptables-restore to install the Netfilter ruleset but with debug, the commands normally passed to iptables-restore in its input file are passed individually to iptables. This is a diagnostic aid which allows identifying the individual command that is causing iptables-restore to fail; it should be used when iptables-restore fails when executing a COMMIT command. The debug feature is strictly for problem analysis. When debug is used: The firewall is made 'wide open' before the rules are applied. The routestopped file is not consulted. The rules are applied in the canonical iptables-restore order. So if you need critical hosts to be always available during start/restart, you may not be able to use debug.
If you are unsure if Shorewall is starting successfully or not then first note that if Shorewall starts successfully, the last message produced by Shorewall 3.0 is "Shorewall Started" and the last message produced by Shorewall is "done.":
… Activating Rules... done. gateway:~#
If you are seeing this message then Shorewall is starting successfully. If you are still unsure if Shorewall is starting or not, enter the following command:
/sbin/shorewall status
If Shorewall has started successfully, you will see output similar to this:
Shorewall-4.0.6 Status at gateway - Thu Mar 30 14:07:29 PDT 2008 Shorewall is running State:Started (Thu Mar 30 14:07:29 PDT 2006)
If Shorewall has not started properly, you will see output similar to this:
Shorewall-4.0.6 Status at gateway - Thu Mar 30 14:08:11 PDT 2008 Shorewall is stopped State:Stopped (Thu Mar 30 14:08:11 PDT 2006)
The "State:" refers to the Shorewall State Diagram. If Shorewall is starting successfully and your problem is that some set of connections to/from or through your firewall isn't working (examples: local systems can't access the Internet, you can't send email through the firewall, you can't surf the web from the firewall, connections that you are certain should be rejected are mysteriously accepted, etc.) or you are having problems with traffic shaping then please perform the following six steps: Be sure that the LOGFILE setting in /etc/shorewall/shorewall.conf is correct (that it names the file where 'Shorewall' messages are being logged). See shorewall.conf (5) and the Shorewall Logging Article. If you are running Ubuntu Precise with Shorewall 4.4.26.1, then please edit /sbin/shorewall and change the first line to: #!/bin/bash If your problem has anything to do with IPSEC, be sure that the ipsec-tools package is installed. If Shorewall isn't started then /sbin/shorewall start. Otherwise /sbin/shorewall reset. Try making the connection that is failing. /sbin/shorewall dump > /tmp/shorewall_dump.txt Post the /tmp/shorewall_dump.txt file as an attachment compressed with gzip or bzip2. Describe where you are trying to make the connection from (IP address) and what host (IP address) you are trying to connect to. Otherwise: Shorewall is starting successfully and you have no connection problems and you have no traffic shaping problems. Your problem is with performance, logging, etc. Please include the following: the exact version of Shorewall you are running. /sbin/shorewall version the complete exact output of ip addr show the complete exact output of ip route show A detailed description of your problem. Please remember we only know what is posted in your message. Do not leave out any information that appears to be correct, or was mentioned in a previous post. There have been countless posts by people who were sure that some part of their configuration was correct when it actually contained a small error. We tend to be skeptics where detail is lacking. Please keep in mind that you're asking for free technical support. Any help we offer is an act of generosity, not an obligation. Try to make it easy for us to help you. Follow good, courteous practices in writing and formatting your e-mail. Provide details that we need if you expect good answers. Exact quoting of error messages, log entries, command output, and other output is better than a paraphrase or summary. Please give details about what doesn't work. Reports that say I followed the directions and it didn't work may elicit sympathy but probably little in the way of help. Again -- if ping from A to B fails, say so (and see below for information about reporting ping problems). If Computer B doesn't show up in Network Neighborhood then say so. If access by IP address works but by DNS names it doesn't then say so. Please don't describe your environment and then ask us to send you custom configuration files. We're here to answer your questions but we can't do your job for you. Please do NOT include the output of iptables -L — the output of shorewall show or shorewall dump is much more useful to us. Do you see any Shorewall messages (/sbin/shorewall show log) when you exercise the function that is giving you problems? If so, include the message(s) in your post. Please do not include Shorewall configuration files unless you have been specifically asked to do so. The output of shorewall dump collected as described above is much more useful. The list server limits the size of posts to the lists, so don't post graphics of your network layout, etc. to the Mailing List -- your post will be rejected. The author gratefully acknowledges that the above list was heavily plagiarized from the excellent LEAF document by Ray Olszewski found here.
Where to Send your Problem Report or to Ask for Help If you haven't read the Problem Reporting Guidelines above, please read them now — Failure to supply the information that we need will just delay a solution to your problem. If you run the current development release and your question involves a feature that is only available in the development release (see the Shorewall Release Model page) then please post your question or problem to the Shorewall Development Mailing List. Otherwise, please post your question or problem report to the Shorewall users mailing list. IMPORTANT: You must subscribe to the mailing lists before you will be able to post to them (see links below). For quick questions, there is also a #shorewall channel at irc.freenode.net.
Subscribing to the Users Mailing List To Subscribe to the users mailing list go to https://lists.sourceforge.net/lists/listinfo/shorewall-users.
Subscribing to the Announce Mailing List To Subscribe to the announce mailing list (low-traffic,read only) go to: https://lists.sourceforge.net/lists/listinfo/shorewall-announce
Subscribing to the Development Mailing List To Subscribe to the development mailing list go to https://lists.sourceforge.net/lists/listinfo/shorewall-devel.
Unsubscribing from Shorewall Mailing Lists See Shorewall FAQ 98.
Other Mailing Lists For information on other Shorewall mailing lists, go to http://sourceforge.net/mail/?group_id=22587 .
shorewall-docs-xml-5.0.15/Shorewall_and_Routing.xml0000644000000000000000000002077213020330134021034 0ustar rootroot
Shorewall and Routing Tom Eastep 2005 2006 2007 Thomas M. Eastep 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.
Routing vs. Firewalling. One of the most misunderstood aspects of Shorewall is its relationship with routing. This article attempts to clear some of the fog that surrounds this issue. As a general principle: Routing determines where packets are to be sent. Once routing determines where the packet is to go, the firewall (Shorewall) determines if the packet is allowed to go there. There are ways that Shorewall can affect routing which are described in the following sections.
Routing and Netfilter The following diagram shows the relationship between routing decisions and Netfilter. The light blue boxes indicate where routing decisions are made. Upon exit from one of these boxes, if the packet is being sent to another system then the interface and the next hop have been uniquely determined. The green boxes show where Netfilter processing takes place (as directed by Shorewall). You will notice that there are two different paths through this maze, depending on where the packet originates. We will look at each of these separately.
Packets Entering the Firewall from Outside When a packet arrives from outside, it first undergoes Netfilter PREROUTING processing. In Shorewall terms: Packets may be marked using entries in the /etc/shorewall/mangle (/etc/shorewall/tcrules) file. Entries in that file containing ":P" in the mark column are applied here as are rules that default to the MARK_IN_FORWARD_CHAIN=No setting in /etc/shorewall/shorewall.conf. These marks may be used to specify that the packet should be routed using an alternate routing table; see the Shorewall Squid documentation for examples. Marking packets then using the fwmark selector in your "ip rule add" commands should NOT be your first choice. In most cases, you can use the from or dev selector instead. The destination IP address may be rewritten as a consequence of: DNAT[-] rules. REDIRECT[-] rules. Entries in /etc/shorewall/nat. So the only influence that Shorewall has over where these packets go is via NAT or by marking them so that they may be routed using an alternate routing table.
Packets Originating on the Firewall Processing of packets that originate on the firewall itself are initially routed using the default routing table then passed through the OUTPUT chains. Shorewall can influence what happens here: Packets may be marked using entries in the /etc/shorewall/mangle (/etc/shorewall/tcrules) file (rules with "$FW" in the SOURCE column). These marks may be used to specify that the packet should be re-routed using an alternate routing table. The destination IP address may be rewritten as a consequence of: DNAT[-] rules that specify $FW as the SOURCE. Entries in /etc/shorewall/nat that have "Yes" in LOCAL column. So again in this case, the only influence that Shorewall has over the packet destination is NAT or marking.
Alternate Routing Table Configuration The Shorewall 2.x Shorewall Squid documentation shows how alternate routing tables can be created and used. That documentation shows how you can use logic in /etc/shorewall/init to create and populate an alternate table and to add a routing rule for its use. It is fine to use that technique so long as you understand that you are basically just using the Shorewall init script (/etc/init.d/shorewall) to configure your alternate routing table at boot time and that other than as described in the previous section, there is no connection between Shorewall and routing when using Shorewall versions prior to 2.3.2.
Routing and Proxy ARP There is one instance where Shorewall creates main routing table entries. When an entry in /etc/shorewall/proxyarp contains "No" in the HAVEROUTE column then Shorewall will create a host route to the IP address listed in the ADDRESS column through the interface named in the INTERFACE column. This is the only case where Shorewall directly manipulates the main routing table. Example: /etc/shorewall/proxyarp: #ADDRESS INTERFACE EXTERNAL HAVEROUTE PERSISTENT 206.124.146.177 eth1 eth0 No The above entry will cause Shorewall to execute the following command: ip route add 206.124.146.177 dev eth1
Multiple Internet Connection Support in Shorewall 2.4.2 and Later Beginning with Shorewall 2.3.2, support is included for multiple Internet connections. If you wish to use this feature, we recommend strongly that you upgrade to version 2.4.2 or later. Shorewall multi-ISP support is now covered in a separate article.
shorewall-docs-xml-5.0.15/ConnectionRate.xml0000644000000000000000000000677613020330134017466 0ustar rootroot
Connection Rate Limiting Tom Eastep 2008 2009 Thomas M. Eastep 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.
Introduction Shorewall supports several mechanisms for limiting connection rates. These are described in the following sections. Rates are expressed in terms of a connections per unit time and a burst. An interval is calculated by dividing the unit of time by the number of connections allowed in that unit of time (connections/{||||week|month}[:burst] Example: 4/min:5 Connections = 4 Unit of time = 1 minute Interval = 1 minute/4 = 15 seconds. Burst = 5 As each connection arrives,if the burst count is > 0 the burst count is reduced by one and the connection is accepted. After each interval (15 seconds) that passes without a connection arriving, the burst count is incremented by 1 but is not allowed to exceed its initial setting (5). By default, the aggregate connection rate is limited. If the specification is preceded by "" or "", then the rate is limited per SOURCE or per DESTINATION IP address respectively.
Policy Rate Limiting The LIMIT column in the /etc/shorewall/policy file applies to TCP connections that are subject to the policy. The limiting is applied BEFORE the connection request is passed through the rules generated by entries in /etc/shorewall/rules. Those connections in excess of the limit are logged and dropped.
Rules Rate Limiting The RATE LIMIT column in the /etc/shorewall/rules file allows limiting of ACCEPT, DNAT and Action rules.
Limit Action The Limit Action is a legacy mechanism that limits connections per source IP. It does not support the notion of a burst size.
shorewall-docs-xml-5.0.15/images/0000755000000000000000000000000013020331007015256 5ustar rootrootshorewall-docs-xml-5.0.15/images/openlogo-nd-25.png0000644000000000000000000000063113020330134020431 0ustar rootrootPNG  IHDR2E3PLTE6@hCꟳ` O揧0\pPuK_bKGDH pHYs  ~tIMEIDATm r0y_ ?m ŽR7 TEastepHewlett-Packard738201805738201805 AQAAAIwAAAAAAAAAAAAAAF0AAABIAAAAAAAAAAAAAACYCQAAagcAACBFTUYAAAEAKFIAAAMAAAABA AAADwAAAGwAAAAAAAAAAAUAAAAEAABSAQAADgEAAAAAAAAAAAAAAAAAAFAoBQCwHgQAVgBJAFMASQ BPAAAARAByAGEAdwBpAG4AZwAAAAAAAABMAAAAiFEAAAAAAAAAAAAAXQAAAEgAAAAAAAAAAAAAAF4 AAABJAAAAIADMAAAAAAAAAAAAAACAPwAAAAAAAAAAAACAPwAAAAAAAAAA////AAAAAABkAAAAKAAA AIwAAAD8UAAAKAAAAF4AAABJAAAAAQAYAAAAAAD8UAAAAAAAAAAAAAAAAAAAAAAAAP/////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////wAA////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////AAD//////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////8AAP////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////////////////////////////wAA///////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////AAD////////////39/e/v7+/v7+/v7+/v7+/v7+/v7+/v7 +/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+ /v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7/n5+f////////////////////// ///////////////////////////////////////////////////////////////////////////// ////////////////////////8AAP///////////4eHhyAgCEBAEEBAEEBAEEBAEEBAEEBAEEBAEEB AEEBAEEBAEEBAEEBAEEBAEEBAEEBAEEBAEEBAEEBAEEBAEEBAEEBAEEBAEEBAEEBAEEBAEEBAEEBA EEBAEEBAEEBAEEBAEEBAEEBAEEBAEEBAEEBAEEBAEEBAEEBAEEBAEEBAEEBAEEBAEEBAEEBAEEBAE EBAEEBAEEBAEEBAEEBAEEBAEEBAEEBAEEBAEEBAEDAwDEhIOv//////////////////////////// ///////////////////////////////////////////////////////////////////////////// //////////////////wAA////////////f39/f38A//8A//8A//8A//8A//8A//8A//8A//8A//8A //8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A/ /8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A// 8A//8A//8A//8A//8A//8A//8A//8A//8Av78AQEAw/////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////////////AAD///////////9/f39/fwD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD// wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//w D//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD //wD//wD//wD//wD//wD//wD//wC/vwBAQDDPz89/f39/f39/f39/f39/f39/f39/f39/f39/f39/ f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f3+fn5/////////// /////8AAP///////////39/f39/AL+/AH9/AH9/AH9/AH9/AH9/AH9/AH9/AH9/AH9/AH9/AH9/AH 9/AH9/AH9/AH9/AH9/AH9/AH9/AH9/AH9/AH9/AJ+fAP//AP//AP//AP//AP//AP//AP//AP//AP/ /AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP// AP//AP//AP//AP//AP//AL+/AEBAMH9/fzk0MnFoY3FoY3FoY3FoY3FoY3FoY3FoY3FoY3FoY3FoY 3FoY3FoY3FoY3Fo Y3FoY3FoY3FoY3FoY3FoY3FoY3FoY3FoY3FoY2RcVx8eHf///////////////wAA////////////f 39/f38AHx4JZFxXcWhjcWhjcWhjcWhjcWhjcWhjcWhjcWhjcWhjcWhjcWhjcWhjcWhjcWhjcWhjcW hjcWhjcWhjcWhjcWhjDw4I398A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8 A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A v78AQEAwf39/cWhj49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG4 9HG49HG49HG49HG49HG49HG49HG49HGx7etHx4d////////////////AAD///////////9/f39/fw AfHgnHt63j0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cb j0cbj0cbj0cYeHBDf3wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD/ /wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wC/vwBAQ DB/f39xaGPj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0c bj0cbj0cbj0cbj0cbj0cbj0cbHt60fHh3///////////////8AAP///////////39/f39/AB8eCce 3rePRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPR xuPRxh4cEN/fAP//AP//AP//AP//AP//AP//AP//AP//AAAAAP//AAAAAP//AAAAAP//AAAAAP//A AAAAP//AAAAAP//AAAAAP//AAAAAP//AP//AP//AP//AP//AP//AP//AP//AP//AL+/AEBAMH9/f3 FoY+PRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuP RxuPRxuPRxuPRxuPRxse3rR8eHf///////////////wAA////////////f39/f38AHx4Jx7et49HG 49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HGH hwQ398A//8A//8A//8A//8A//8A//8A//8A//8A//8AAAAA//8AAAAA//8AAAAA//8AAAAA//8AAA AA//8AAAAA//8AAAAA//8AAAAA//8A//8A//8A//8A//8A//8A//8A//8Av78AQEAwf39/cWhj49H G49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG 49HG49HG49HGx7etHx4d////////////////AAD///////////9/f39/fwAfHgnHt63j0cbj0cbj0 cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cYeHBDf3w D//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD //wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wC/vwBAQDB/f39xaGPj0cbj0cbj 0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0 cbj0cbHt60fHh3///////////////8AAP///////////39/f39/AB8eCce3rePRxuPRxuPRxuPRxu PRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxh4cEN/fAP//AP/ /AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP// AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AL+/AEBAMH9/f3FoY+PRxuPRxuPRxuPRx uPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxs e3rR8eHf///////////////wAA////////////f39/f38AHx4Jx7et49HG49HG49HG49HG49HG49H G49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HGHhwQ398A//8A//8A//8A //8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A/ /8A//8A//8A//8A//8A//8A//8A//8A//8A//8Av78AQEAwf39/cWhj49HG49HG49HG49HG49HG49 HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HGx7etHx4 d////////////////AAD///////////9/f39/fwAfHgnHt63j0cbj0cbj0cbj0cbj0cbj0cbj0cbj 0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cYeHBDf3wD//wD//wD//wD//wD// wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//w D//wD//wD//wD//wD//wD//wD//wD//wC/vwBAQDB/f39xaGPj0cbj0cbj0cbj0cbj0cbj0cbj0cb j0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbHt60fHh3///// //////////8AAP///////////39/f39/AB8eCce3rePRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRx uPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxh4cEN/fAP//AP//AP//AP//AP//AP//AP //AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP/ /AP//AP//AP//AP//AP//AP//AL+/AEBAMH9/f3FoY+PRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPR xuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxse3rR8eHf/////////// ////wAA////////////f39/f38AHx4Jx7et49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49 HG49HG49HG49HG49HG49HG49HG49HG49HG49HGHhwQ398A//8A//8A//8A//8A//8A//8A//8A//8 A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A //8A//8A//8A//8A//8Av78AQEAwf39/cWhj49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG4 9HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HGx7etHx4d////////////////AA D///////////9/f39/fwAfHgnHt63j0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cb j0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cYeHBDf3wD//wD//wD//wD//wD//wD//wD//wD//wD//wD/ /wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD// wD//wD//wD//wC/ vwBAQDB/f39xaGPj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0 cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbHt60fHh3///////////////8AAP///////////39/f39/AB 8eCce3rePRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuP RxuPRxuPRxh4cEN/fAP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP// AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AL+/AEBAM H9/f3FoY+PRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxu PRxuPRxuPRxuPRxuPRxuPRxse3rR8eHf///////////////wAA////////////f39/f38AHx4Jx7e t49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG 49HGHhwQ398A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A/ /8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8Av78AQEAwf39/cW hj49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49H G49HG49HG49HG49HGx7etHx4d////////////////AAD///////////9/f39/fwAfHgnHt63j0cbj 0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cYeH BDf3wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//w D//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wC/vwBAQDB/f39xaGPj0cb j0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj 0cbj0cbj0cbHt60fHh3///////////////8AAP///////////39/f39/AB8eCce3rePRxuPRxuPRx uPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxh4cEN/fAP //AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP/ /AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AL+/AEBAMH9/f3FoY+PRxuPRxuPR xuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRx uPRxse3rR8eHf///////////////wAA////////////f39/f38AHx4Jx7et49HG49HG49HG49HG49 HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HGHhwQ398A//8A//8 A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A //8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8Av78AQEAwf39/cWhj49HG49HG49HG49HG4 9HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HGx7 etHx4d////////////////AAD///////////9/f39/fwAfHgnHt63j0cbj0cbj0cbj0cbj0cbj0cb j0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cYeHBDf3wD//wD//wD//wD/ /wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD// wD//wD//wD//wD//wD//wD//wD//wD//wD//wC/vwBAQDB/f39xaGPj0cbj0cbj0cbj0cbj0cbj0c bj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbHt60fHh3 ///////////////8AAP///////////39/f39/AB8eCce3rePRxuPRxuPRxuPRxuPRxuPRxuPRxuPR xuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxh4cEN/fAP//AP//AP//AP//AP//A P//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP //AP//AP//AP//AP//AP//AP//AP//AL+/AEBAMH9/f3FoY+PRxuPRxuPRxuPRxuPRxuPRxuPRxuP RxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxse3rR8eHf////// /////////wAA////////////f39/f38AHx4Jx7et49HG49HG49HG49HG49HG49HG49HG49HG49HG4 9HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HGHhwQ398A//8A//8A//8A//8A//8A//8A// 8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8 A//8A//8A//8A//8A//8A//8Av78AQEAwf39/cWhj49HG49HG49HG49HG49HG49HG49HG49HG49HG 49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HGx7etHx4d///////////// ///AAD///////////9/f39/fwAfHgnHt63j0cbj0cbj0cbj0cbj0cYAAADj0cYAAADj0cYAAADj0c YAAADj0cYAAADj0cbj0cbj0cbj0cbj0cbj0cYeHBDf3wD//wD//wD//wD//wD//wD//wD//wD//wD //wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD/ /wD//wD//wD//wD//wC/vwBAQDB/f39xaGPj0cbj0cbj0cbj0cbj0cbj0cbj0cYAAADj0cYAAADj0 cYAAADj0cYAAADj0cYAAADj0cbj0cbj0cbj0cbj0cbj0cbj0cbHt60fHh3///////////////8AAP ///////////39/f39/AB8eCce3rePRxuPRxuPRxuPRxgAAAOPRxgAAAOPRxgAAAOPRxgAAAOPRxgA AAOPRxgAAAOPRxuPRxuPRxuPRxuPRxh4cEN/fAP//AP//AP//AP//AP//AP//AP//AP//AP//AP// AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//A P//AP//AP//AL+/AEBAMH9/f3FoY+PRxuPRxuPRxuPRxuPRxuPRxgAAAOPRxgAAAOPRxgAAAOPRxg AAAOPRxgAAAOPRxgAAAOPRxuPRxuPRxuPRxuPRxuPRxse3rR8eHf///////////////wAA/////// /////f39/f38AHx4Jx7et49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG 49HG49HG49HG49HG49HG49HGHhwQ398A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A/ /8A//8A//8A//8A //8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8Av78AQEAwf 39/cWhj49HG49HG49HGAAAA49HGAAAA49HGAAAA49HGAAAA49HGAAAA49HGAAAA49HGAAAA49HGAA AA49HGAAAA49HG49HG49HGx7etHx4d////////////////AAD///////////9/f39/fwAfHgnHt63 j0cbj0cYAAADj0cYAAADj0cYAAADj0cYAAADj0cYAAADj0cYAAADj0cYAAADj0cYAAADj0cbj0cbj 0cYeHBDf3wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD// wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wC/vwBAQDB/f39xaG Pj0cbj0cbj0cbj0cYAAADj0cYAAADj0cYAAADj0cYAAADj0cYAAADj0cYAAADj0cYAAADj0cYAAAD j0cbj0cbj0cbj0cbHt60fHh3///////////////8AAP///////////39/f39/AB8eCce3rePRxgAA AOPRxgAAAOPRxgAAAOPRxgAAAOPRxgAAAOPRxgAAAOPRxgAAAOPRxgAAAOPRxgAAAOPRxuPRxh4cE N/fAP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP //AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AL+/AEBAMH9/f3FoY+PRxuP RxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPR xuPRxuPRxse3rR8eHf///////////////wAA////////////f39/f38AHx4Jx7et49HG49HG49HG4 9HG49HG49HG49HG49HGAAAA49HGAAAA49HG49HG49HG49HG49HG49HG49HG49HG49HGHhwQ398A// 8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8 A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8Av78AQEAwf39/cWhj49HG49HG49HG 49HG49HG49HG49HG49HG49HG49HGAAAA49HGAAAA49HG49HG49HG49HG49HG49HG49HG49HG49HG4 9HGx7etHx4d////////////////AAD///////////9/f39/fwAfHgnHt63j0cbj0cbj0cbj0cbj0c bj0cbj0cYAAADj0cYAAADj0cYAAADj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cYeHBDf3wD//wD//wD //wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD/ /wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wC/vwBAQDB/f39xaGPj0cbj0cbj0cbj0cbj0 cbj0cbj0cbj0cbj0cYAAADj0cYAAADj0cYAAADj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbHt6 0fHh3///////////////8AAP///////////39/f39/AB8eCce3rePRxuPRxuPRxuPRxuPRxuPRxuP RxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxh4cEN/fAP//AP//AP//AP// AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//A P//AP//AP//AP//AP//AP//AP//AP//AP//AL+/AEBAMH9/f3FoY+PRxuPRxuPRxuPRxuPRxuPRxu PRxuPRxgAAAOPRxgAAAOPRxgAAAOPRxgAAAOPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxse3rR8eHf/ //////////////wAA////////////f39/f38AHx4Jx7et49HG49HG49HG49HG49HG49HG49HGAAAA 49HGAAAA49HGAAAA49HG49HG49HG49HG49HG49HG49HG49HGHhwQ398A//8A//8A//8A//8A//8A/ /8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A// 8A//8A//8A//8A//8A//8A//8A//8Av78AQEAwf39/cWhj49HG49HG49HG49HG49HG49HG49HG49H G49HGAAAA49HGAAAA49HGAAAA49HG49HG49HG49HG49HG49HG49HG49HG49HGx7etHx4d//////// ////////AAD///////////9/f39/fwAfHgnHt63j0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cYAAADj0 cYAAADj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cYeHBDf3wD//wD//wD//wD//wD//wD//wD//w D//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wDDwwZoaCf39wj//wD//wD//wD//wD //wD//wD//wD//wD//wD//wC/vwBAQDB/f39xaGPj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj 0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbHt60fHh3////////////// /8AAP///////////39/f39/AB8eCce3rePRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxu PRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxh4cEN/fAP//AP//AP//AP//AP//AP//AP//AP//AP/ /AP//AP//AP//AP//AP//AP//AP//AP//AODgADExAAQEARkZGScnJ5+fn93d3d3d3eDgyOnpkfj4 Kf//AP//AP//AP//AL+/AEBAMH9/f3FoY+PRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRx uPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxse3rR8eHf///////////////wAA// //////////f39/f38AHx4Jx7et49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49H G49HG49HG49HG49HG49HG49HG49HGHhwQ398A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A //8A//8A//8A//8A//8A//8AUFAABAQAPz8/jIyMOzs7n5+fSEhINjY2srKy3d3d3d3d3d3d8vJT/ /8A//8A//8Av78AQEAwf39/cWhj49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49 HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HGx7etHx4d////////////////AAD//////// ///9/f39/fwAfHgnHt63j0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj 0cbj0cbj0cbj0cbj0cbj0cYeHBDf3wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD// wD//wD//wB4eAAEBAAoKCi1tbXOzs6ampo7Ozu3t7e3t7ebm5s2NjZUVFTFxcXd3d3d3d3z80z//w D//wC/vwBAQDB/f39xaGPj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cb j0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbHt60fHh3///////////////8AAP///////////39/ f39/AB8eCce3rePRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRx uPRxuPRxuPRxuPR xh4cEN/fAP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AJubABAQABUVFaGhodLS0 tLS0tLS0peQkDw8PL6+vr6+vr6+vr6+voiIiCcnJ5mZmd3d3eDgyP7+B///AL+/AEBAMH9/f3FoY+ PRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuP RxuPRxuPRxuPRxse3rR8eHf///////////////wAA////////////f39/f38AHx4Jx7et49HG49HG 49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HGHhwQ3 98A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A0dEAHh4ACgoKeHh41tbW1tbW1tbWw7m5i1 1dczc3QTs7ycnJycnJycnJwcHBt7e3kZGRJycn3d3d3d3d+/sc//8Av78AQEAwf39/cWhj49HG49H G49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG 49HG49HGx7etHx4d////////////////AAD///////////9/f39/fwAfHgnHt63j0cbj0cbj0cbj0 cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cYeHBDf3wD//w D//wD//wD//wD//wD//wD//wD//wDg4AA4OAAEBABdXV3b29vb29vb29vRy8uRaGh0OTl2Pj4/Jia fn5/z8/Pb29vQ0NDBwcG3t7esrKwAAADd3d3l5a3//wD//wC/vwBAQDB/f39xaGPj0cbj0cbj0cbj 0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0 cbHt60fHh3///////////////8AAP///////////39/f39/AB8eCce3rePRxuPRxuPRxuPRxuPRxu PRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxh4cEN/fAP//AAAAAP/ /AAAAAP//AP//AP//AFBQAAYGADs7O8jIyNnZ2d3d3djU1KqMjH1GRnc+PlEzM1lVVeLi4vr6+vz8 /Pn5+ezs7MfHx7e3t6ysrAAAAO7ubwAAAP//AAAAAL+/AEBAMH9/f3FoY+PRxuPRxuPRxuPRxuPRx uPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxse3rR 8eHf///////////////wAA////////////f39/f38AHx4Jx7et49HG49HG49HG49HG49HG49HG49H G49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HGHhwQ398AAAAA//8AAAAA//8A //8A0dEABgYAJycnqamp0tLS1dXV1tTUsJaWfklJeEBAYD09RD4+w8PD+Pj4+Pj4+Pj4+Pj4+Pj4/ f399fX129vbr6+vAAAA//8A//8AAAAA//8AAAAAQEAwf39/cWhj49HG49HG49HG49HG49HG49HG49 HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HGx7etHx4d/// /////////////AAD///////////9/f39/fwAfHgnHt63j0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj 0cbj0cbj0cbj0cbj0cbj0cbj0cYAAADj0cYAAADj0cbj0cYVFBAAAAAAAAAAAAAAAAAAAAAAAAAAA AAcHBzKysrMysrS0tLV1dWGVlZzOT1vQ0MtJiaqqqr19fX19fX19fX19fX19fX19fX19fX19fX39/ f9/f319fUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABxaGPj0cYAAADj0cYAAADj0cbj0cbj0cbj0cb j0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbHt60fHh3///////// //////8AAP///////////39/f39/AB8eCce3rePRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRx uPRxuPRxuPRxuPRxuPRxuPRxgAAAOPRxgAAAOPRxh0cEN/fAP//AP//AP//AP//AP//ACQkAE1NTZ +BgXlBQb2wsNXV1XdVVTEiIouLi+rq6vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8ri4uDA wMHBwVP//AP//AP//AP//AL+/AEBAMHt7e3FoY+PRxuPRxgAAAOPRxuPRxuPRxuPRxuPRxuPRxuPR xuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxse3rR8eHf/////////////// wAA////////////f39/f38AHx4Jx7et49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49 HG49HG49HG49HG49HG49HG49HG49HG49HGHhwQ398A//8A//8A//8A//8A//8AJCQASz4+iDw8gjg 4iXp6GxsbbW1t4uLi8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDwzMzMTk5OQEAwz88n//8A //8A//8A//8A//8Av78AQEAwf39/cWhj49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG4 9HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HGx7etHx4d////////////////AAD/// ////////9/f39/fwAfHgnHt63j0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cb j0cbj0cbj0cbj0cbj0cbj0cbj0cYeHBDf3wD//wD//wD//wD//wD//wAkJABLPz96OztUNjZOTk7S 0tLu7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7g4OBtbW0oKCKvrzf//wD//wD//wD//wD// wD//wD//wC/vwBAQDB/f39xaGPj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0c bj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbHt60fHh3///////////////8AAP///////// //39/f39/AB8eCce3rePRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPR xuPRxuPRxuPRxuPRxuPRxh4cEN/fAP//AP//AP//AP//AP//ACQkAhcXFzIwMLS0tAAAAOvr6wAAA Ovr6wAAAOvr6+vr6+vr6+vr6+vr6+Xl5YmJiSAgII+PP///AP//AP//AP//AP//AP//AP//AP//AP //AL+/AEBAMH9/f3FoY+PRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuP RxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxse3rR8eHf///////////////wAA////////////f39/ f38AHx4Jx7et49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG4 9HG49HG49HG49HGHhwQ398A//8A//8A//8A//8A//8Ag4MhFBQUiIiIAAAA6enpAAAA6enpAAAA6e npAAAA6enp6enp6enppaWlKCgocHA/7+8P//8A//8A//8A//8A//8A//8A//8A//8A//8A//8Av78 AQEAwf39/cWhj49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG 49HG49HG49HG49HG49HG49HG49HGx7etHx4d////////////////AAD///////////9/f39/fwAfH gnHt63j0cbj0cbj 0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cYeHBDf3 wD//wD//wD//wD//wD//wD//wDv7w9wcD8nJyekpKTn5+fn5+fn5+fn5+fn5+fn5+e4uLg+Pj5QUD ff3xz//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wC/vwBAQDB/f39xaGPj0cbj0cb j0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj 0cbj0cbHt60fHh3///////////////8AAP///////////39/f39/AB8eCce3rePRxuPRxuPRxuPRx uPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxh4cEN/fAP//AP //AP//AP//AP//AP//AP//AP//AN/fHFBQNzc3N7e3t+Tk5OTk5NHR0VVVVS8vLJubMP//AP//AP/ /AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AL+/AEBAMH9/f3FoY+PRxuPRxuPRxuPR xuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRx se3rR8eHf///////////////wAA////////////f39/f38AHx4Jx7et49HG49HG49HG49HG49HG49 HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HGHhwQ398A//8A//8A//8 A//8A//8A//8A//8A//8A//8A//8Ax8csODgsTU1NcXFxHx8fp6c6QEAAv78A//8A//8A//8A//8A //8A//8A//8A//8A//8A//8A//8A//8A//8A//8Av78AQEAwf39/cWhj49HG49HG49HG49HG49HG4 9HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HGx7etHx 4d////////////////AAD///////////9/f39/fwAfHgnHt63j0cbj0cbj0cbj0cbj0cbj0cbj0cb j0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cYeHBDf3wD//wD//wD//wD//wD/ /wD//wD//wD//wD//wD//wD//wD//wCvrzeHh0D39wj//wBAQAC/vwAAAAD//wAAAAD//wD//wD// wD//wD//wD//wD//wD//wD//wD//wD//wC/vwBAQDB/f39xaGPj0cbj0cbj0cbj0cbj0cbj0cbj0c bj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbHt60fHh3//// ///////////8AAP///////////39/f39/AE5NDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB8eCO/vAP//AP//AP//AP//AP//AP//A P//AP//AP//AP//AP//AP//AP//AP//AP//AP//AEBAAL+/AP//AP//AP//AP//AP//AP//AP//AP //AP//AP//AP//AP//AP//AP//AL+/AEBAMH9/fzk0MnFoY3FoY3FoY3FoY3FoY3FoY3FoY3FoY3F oY3FoY3FoY3FoY3FoY3FoY3FoY3FoY3FoY3FoY3FoY3FoY3FoY3FoY3FoY2RcVx8eHf////////// /////wAA////////////f39/f38A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A/ /8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A// 8A//8A//8A//8A//8A//8A//8A//8A//8AQEAAv78A//8A//8A//8A//8A//8A//8A//8A//8A//8 A//8A//8A//8A//8A//8Av78AQEAw7+/vf39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/ f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/v7+/////////////////A AD///////////+Pj48gIAhAQBBAQBBAQBBAQBBAQBBAQBBAQBBAQBBAQBBAQBBAQBBAQBBAQBBAQB BAQBBAQBBAQBBAQBBAQBBAQBBAQBBAQBBAQBBAQBBAQBBAQBBAQBBAQBBAQBBAQBBAQBBAQBBAQBB AQBBAQBBAQBBAQBBAQBBAQBBAQBAQEAQwMAxAQBBAQBBAQBBAQBBAQBBAQBBAQBBAQBBAQBBAQBBA QBBAQBBAQBBAQBAwMAxQUEH////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////8AAP//// ///////////7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+ /v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v6CHh7iysr+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/vzAwMI+Pj7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v6CHh7iysr+/v7+/v 7+/v7+/v7+/v+/v7///////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////wAA/////////// ///////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////lmlp3M3N///////////////// ///////////////QEBAv7+/////////////////////////////////lmlp3M3N////////////// ///////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////AAD///////////////// ///////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////+WaWnczc3/////////////////////// ////////9AQEC/v7////////////////////////////////+WaWnczc3//////////////////// ///////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////8AAP/////////////////////// ////////////////////////////////////////9vW1qWamqWamqWamqWamqWamqWamqWamqWamq WamqWamqWamqWamqWamqWamqWamqWamqWamqWammpGRpF+fqWamqWamqWamqWamqWamqWamqWamqW amjouLoF2dqWamqWamqWamqWamqWamqWamqWamqWammpGRpF+fqWamqWamqWamqWamqWamqWamqWa mqWamqWamqWamqWamqWamqWamqWamqWamqWamqWamqWamv/////////////////////////////// /////////////// /////////////////////////////wAA///////////////////////////////////////////// ///////////////urCwFQ0NIxUSIxUSIxUSIxUSIxUSIxUSIxUSIxUSIxUSIxUSIxUSIxUSIxUSIx USIxUSIxUSIxUSIxUSIxUSIxUSIxUSIxUSIxUSIxUSIxUSIxUSIxUSIxUSIxUSIxUSIxUSIxUSIxU SIxUSIxUSIxUSIxUSIxUSIxUSIxUSIxUSIxUSIxUSIxUSIxUSIxUSIxUSIxUSIxUSIxUSIxUSIxUS IxUSIxUSIxUSIxUSIxUSHhAPLCAg8/Hx///////////////////////////////////////////// ///////////////////////AAD/////////////////////////////////////////////////// ////////9OPz9gSUHavqTavqTavqTavqTavqTavqTavqTavqTavqTavqTavqTavqTavqTavqTavqT avqTavqTavqTavqTavqTavqTavqTavqTavqTavqTavqTavqQAAADavqQAAADavqTavqTavqTavqTa vqTavqTavqTavqTavqTavqTavqTavqTavqTavqTavqTavqTavqTavqTavqTavqTavqTavqTavqTav qTavqTavqTXuqF3PT0WCgq6sLD/////////////////////////////////////////////////// ////////////////8AAP///////////////////////////////////////////////////////// //z8xMXJcV+HMveHMveHMveHMveHMveHMveHMveHMveHMveHMveHMveHMveHMveHMveHMveHMveHM veHMveHMveHMveHMveHMveHMveHMveHMveHMveHMveHMvQAAAOHMveHMveHMveHMveHMveHMveHMv eHMveHMveHMveHMveHMveHMveHMveHMveHMveHMveHMveHMveHMveHMveHMveHMveHMveHMveHMve HMvdrCtHxERBkMDK+lpf///////////////////////////////////////////////////////// //////////wAA////////////////////////////////////////////////////////////kYSE HhIQUjsyUjsyUjsyUjsyUjsyUjsyUjsyUjsyUjsyUjsyUjsyUjsyUjsyUjsyUjsyUjsyUjsyUjsyU jsyUjsyUjsyUjsyUjsyUjsyUjsyUjsyUjsyUjsyUjsyUjsyUjsyUjsyUjsyUjsyUjsyUjsyUjsyUj syUjsyUjsyUjsyUjsyUjsyUjsyUjsyUjsyUjsyUjsyUjsyUjsyUjsyUjsyUjsyUjsyUjsyUjsyUjs yPB8eHxQU8/Hx//////////////////////////////////////////////////////////////// ////AAD///////////////////////////////////////////////////////////////+lmppcT U1cTU1cTU1cTU1cTU1cTU1cTU1cTU1CKChUQUFcTU1cTU1cTU1cTU1cTU1cTU1cTU1cTU1cTU1cTU 1cTU1cTU1cTU1cTU1cTU1cTU1cTU1cTU1CKChUQUFcTU1cTU1cTU1cTU1cTU1cTU1cTU1cTU1cTU1 cTU1cTU1cTU1cTU1cTU1cTU1cTU1cTU1cTU1CKChUQUFcTU1cTU1cTU1cTU1cTU1cTU1cTU1cTU3n 4+P///////////////////////////////////////////////////////////////////////8AA P//////////////////////////////////////////////////////////////////////////// ///////////////////////5ZpadzNzf///////////////////////////////////////////// //////////////////////////5ZpadzNzf////////////////////////////////////////// /////////////////////////////5ZpadzNzf/////////////////////////////////////// ////////////////////////////////////////////////////////////////////wAA////// ///////////////////////////////////////////////////////////////////////////// /////////////////lmlp3M3N//////////////////////////////////////////////////// ////////////////////lmlp3M3N///////////////////////////////////////////////// ///////////////////////lmlp3M3N////////////////////////////////////////////// //////////////////////////////////////////////////////////////AAD//////////// ///////////////////////////////////////////////////////////////////////////// //////////+siYnp4OD////////////////////////////////////////////////////////// /////////////+siYnp4OD/////////////////////////////////////////////////////// ////////////////+siYnp4OD//////////////////////////////////////////////////// ///////////////////////////////////////////////////////8AAP////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////wAADgAAABQAAAAAAAAAEAAAABQAA AA=TC0104981610332005-12-30T06:50:452006-02-19T08:01:582006-02-19T08:01:512005-12-30T06:50:459295340000011100.010102000201010100000000010000100.500000000000000000000000000000000000103310000032320088000010.50.500001201100000000000000000000000010000.1250.1250.250.250.3750.3750.1250.1250.666666666666670.66666666666667000000.250.250.250.25111100001170000000000000400010.1666666666666667000000000000-11033000-1.2001000-10011100.010002000201000100000000010000000.500000-1.2000000-10011100.0100020002010001000000000111100.055555555555555550.055555555555555550.055555555555555550.05555555555555555100.5001110042302000201000100000000010.055555555555555550.0555555555555555500200.500010000000000000010331111000000000000440010.125000000000000-1103311100.055555555555555550.055555555555555550.055555555555555550.05555555555555555100.500400010.1111111111111111000000000000-11033000-1.2001000-10011110.01010200020#ffffff#c0c0c01#dddddd10000000001400010.1666666666666667000000000000-1103311100.00333333333333333401020002011100.0033333333333333340102000200.055555555555555550.055555555555555550.055555555555555550.05555555555555555100.500400010.1111111111111111000000000000-11033000-1.2001000-10011110.010102000200#ffffff11410000000001400010.1666666666666667000000000000-1103311100.055555555555555550.055555555555555550.055555555555555550.055555555555555551150.500400010.1111111111111111000000000000-11033000-1.2001000-10011110.01#ffffff10200020#ffffff#9696961#eaeaea10000000001400010.1666666666666667000000000000-1103311100.055555555555555550.055555555555555550.055555555555555550.05555555555555555120.5000.0033333333333333340102000201111410000000001400010.1111111111111111000000000000-1103311110.010102000201111410000000001400010.1666666666666667000000000000-1103311110.01#ffffff10200020#ffffff#dddddd1#eaeaea10000000001400010.1666666666666667000000000000-1103311110.01010200020#dddddd11#dddddd10000000001400010.1666666666666667000000000000-1103311110.01#a78450102000201#c9ba961#dddddd10000000001400010.1666666666666667000000000000-1103311110.01#ffffff10200020#ffffff#e1d8c11#dddddd10000000001400010.1666666666666667000000000000-1103311110.01#ffffff10200020#ffffff#b6a06d1#dddddd10000000001400010.1666666666666667000000000000-1103311110.01#81723d10200020#dcd2b8#8e74371#dddddd10000000001400010.1666666666666667000000000000-1103311110.01#37377310200020#c6d1e3#4e8ec21#dddddd10000000001400010.1666666666666667000000000000-1103311110.01#ffffff10200020#c6d1e3#8baede1#dddddd10000000001400010.1666666666666667000000000000-1103311110.01#ffffff10200020#c6d1e3#6363b11#dddddd10000000001400010.1666666666666667000000000000-1103311110.01#2e2e5a10200020#a9a9d3#4343891#dddddd10000000001400010.1666666666666667000000000000-1103311110.01#dddddd10200020#efefef#ffffff1#dddddd100000000014#dddddd0010.1666666666666667000000000000-1103311110.01#ffffff10200020#fafafa11#dddddd100000000014#dddddd0010.1666666666666667000000000000-1103311110.01#dddddd1020002015#ffffff1#dddddd100000000014#c0c0c00010.1666666666666667000000000000-1103311110.01#dddddd10200020#ffffff#dddddd1#dddddd100000000014#c0c0c00010.1666666666666667000000000000-1103311110.01010200020#000000#ffffff114100000000014#ffffff0010.1666666666666667000000000000-1103311110.01010200020000-1.2001000-1001110#ffffff#dddddd30#eaeaea10000000001000-1.2001000-10011100.01110200020#ffffff#96969631#eaeaea10000000001000-1.2001000-1001110#ffffff#c0c0c032#dddddd100000000010.01010200020000-1.2001000-10011100.020833333333333330102000201110#c6d1e3#4e8ec226#dddddd100000000010000001033118.50.125-0.12511200000100110000000000011010000.0984251968503940.0984251968503940.196850393700790.196850393700790.295275590551180.295275590551180.0984251968503940.0984251968503940.666666666666670.66666666666667000000.250.250.250.2511110000217Co&lor Schemes...000000Network2552000000025520000000Connector2550110011Connector03.853.856.96.33.453.1500007#c0c0c01#dddddd100000000010000006.906.96.306.3006.4196428571428565.592.1607142857142880.21.0803571428571440.100005.3392857142857125.587.55.62000000001002202120100103311.0903571428571440.090000000000000220.55555555555555560.24444444444444440.27777777777777780.122222222222222201.0903571428571440.090000000000000221.0903571428571440.09000000000000022500Reposition Text100000.090000000000000222.1607142857142880.090000000000000222.1607142857142880.114.2696428571428565.59-2.1392857142857120.2-1.0696428571428560.100005.3392857142857125.583.25.6200000000100220212010010331-1.0796428571428560.090000000000000220.55555555555555560.24444444444444440.27777777777777780.12222222222222220-1.0796428571428560.09000000000000022-1.0796428571428560.09000000000000022500Reposition Text100000.09000000000000022-2.1392857142857120.09000000000000022-2.1392857142857120.115.33756.590.2-2.020.1-1.0100005.3357142857142857.65.3392857142857125.582000000001002201220100103310.1017857142857136-1.0082142857142860.55555555555555560.24444444444444440.27777777777777780.122222222222222200.1017857142857136-1.0082142857142860.1017857142857136-1.008214285714286500Reposition Text10000.0982142857142859500.101785714285714100.1017857142857141-2.021.93.9428571428571452.65.61.32.80000#c6d1e3#c0c0c01#dddddd10000000001400010.25000000000000-110330000002.602.65.605.600Dom0 Ursa 206.124.146.178/ 192.168.1.5 5.3392857142857125.582.552.041.2751.02000000000000000000001Bridge0000103311.275-0.17222222222222220.11111111111111110.34444444444444440.055555555555555550.1722222222222222001.275-0.17222222222222221.275-0.1722222222222222271Reposition Text1.2751.020000400010.1944444444444444000000000000-110332.2857908040645080.39985330406450761.1715816081290170.79970660812901550.58579080406450860.3998533040645078000001000.531250000000001401.168750.4781251.08906250.31875-1.2509988949148091.0065146579804560.85000000000000220.79687500000000061.08906250.717187501000.531250000000001401.2750000000000051.3262.5499999999999921.4281.2750.71399999999999920000000000.94861.69999999999999102.5499999999999920.46920.84999999999999041.42800.94862.1250.54060.85000000000000091.08120.4250.540600000000000.80750000000000070.44880.80750000000000070.53040.85000000000000050.55080.85000000000000091.081200.612000.85000000000000450.78031.699999999999991.56060.84999999999999520.78030000000001.03020.04249999999999020.99960.04249999999999020.9181.6999999999999901.699999999999990.612000000000000501.560601.03021.5717655892453930.5624788571266480.086468821509215140.12535771425329590.043234410754607570.062678857126647930000#c0c0c0331#dddddd10000000001000000.044344225450146690.086468821509215200.08646882150921520.079307941670453700.125357714253295400.044344225450146690.24355144624573461.247374221983790.19289710750853090.27965155603242130.096448553754265450.13982577801621060000#c0c0c0431#dddddd10000000001000000.098924359957049690.19289710750853100.1928971075085310.176922413000105900.279651556032420200.098924359957049691.4507148795046090.62956737363524340.086468821509215140.12535771425329590.043234410754607570.062678857126647930000#c0c0c0#3366ff31#dddddd10000000001000000.044344225450146690.086468821509215200.08646882150921520.079307941670453700.125357714253295400.044344225450146691.3280897019477890.6954894769349110.086468821509215140.12535771425329590.043234410754607570.062678857126647930000#c0c0c0231#dddddd10000000001000000.044344225450146690.086468821509215200.08646882150921520.079307941670453700.125357714253295400.044344225450146691.2054645243909690.76336220604878720.086468821509215140.12535771425329590.043234410754607570.062678857126647930000#c0c0c0231#dddddd10000000001000000.044344225450146690.086468821509215200.08646882150921520.079307941670453700.125357714253295400.044344225450146691.0815006966672690.8327977940567430.086468821509215140.12535771425329590.043234410754607570.062678857126647930000#c0c0c0331#dddddd10000000001000000.044344225450146690.086468821509215200.08646882150921520.079307941670453700.125357714253295400.044344225450146690.95439498377663880.89933092983285560.086468821509215140.12535771425329590.043234410754607570.062678857126647930000#c0c0c0#3366ff31#dddddd10000000001000000.044344225450146690.086468821509215200.08646882150921520.079307941670453700.125357714253295400.044344225450146690.83176980621981920.96720365894673180.086468821509215140.12535771425329590.043234410754607570.062678857126647930000#c0c0c0231#dddddd10000000001000000.044344225450146690.086468821509215200.08646882150921520.079307941670453700.125357714253295400.044344225450146690.70780597849611871.0366392469546880.086468821509215140.12535771425329590.043234410754607570.062678857126647930000#c0c0c0#3366ff31#dddddd10000000001000000.044344225450146690.086468821509215200.08646882150921520.079307941670453700.125357714253295400.044344225450146691.2751.022.552.041.2751.020000100001.560601.03020.042499999999994920.99960.042499999999994920.9181.702.50750.44882.50750.53042.550.55082.551.08120.84999999999999522.0401.56065.357.7732142857142857.10.42500000000000083.550.2125-7.401486830834382E-1700000000000000000009Ethernet0000103313.550.21250.464100293968750.2333812988281250.2320501469843750.11669064941406257.401486830834382E-1711.183570.85000000000000161.183570.2125001Connect To Network Device2.36643-0.42500000000000082.366430.2125001Connect To Network Device4.73357-0.42500000000000084.733570.2125001Connect To Network Device3.550.85000000000000163.550.2125001Connect To Network Device5.9166430.85000000000000165.9166430.2125001Connect To Network Device1.7750.21251.7750.2125001Connect To Network Device5.3250.21255.3250.2125001Connect To Network Device1.7750.21251.7750.2125001Connect To Network Device5.3250.21255.3250.2125001Connect To Network Device1.7750.21251.7750.2125001Connect To Network Device5.3250.21255.3250.2125001Connect To Network Device1.7750.21251.7750.2125001Connect To Network Device5.3250.21255.3250.2125001Connect To Network Device1.7750.21251.7750.2125001Connect To Network Device5.3250.21255.3250.2125001Connect To Network Device1.7750.21251.7750.2125001Connect To Network Device5.3250.21255.3250.2125001Connect To Network Device1.7750.21251.7750.2125001Connect To Network Device5.3250.21255.3250.2125001Connect To Network Device1.7750.21251.7750.2125001Connect To Network Device5.3250.21255.3250.2125001Connect To Network Device1.7750.21251.7750.2125001Connect To Network Device5.3250.21255.3250.2125001Connect To Network Device1.7750.21251.7750.2125001Connect To Network Device5.3250.21255.3250.2125001Connect To Network Device1.7750.21251.7750.2125001Connect To Network Device5.3250.21255.3250.2125001Connect To Network Device1.7750.21251.7750.2125001Connect To Network Device5.3250.21255.3250.2125001Connect To Network Device1.7750.21251.7750.2125001Connect To Network Device5.3250.21255.3250.2125001Connect To Network Device1.7750.21251.7750.2125001Connect To Network Device5.3250.21255.3250.2125001Connect To Network Device1.7750.21251.7750.2125001Connect To Network Device5.3250.21255.3250.2125001Connect To Network Device1.7750.21251.7750.2125001Connect To Network Device5.3250.21255.3250.2125001Connect To Network Device1.7750.21251.7750.2125001Connect To Network Device5.3250.21255.3250.2125001Connect To Network Device1.7750.21251.7750.2125001Connect To Network Device5.3250.21255.3250.2125001Connect To Network Device1.7750.21251.7750.2125001Connect To Network Device5.3250.21255.3250.2125001Connect To Network Device1.7750.21251.7750.2125001Connect To Network Device5.3250.21255.3250.2125001Connect To Network Device1.7750.21251.7750.2125001Connect To Network Device5.3250.21255.3250.2125001Connect To Network Device1.7750.21251.7750.2125001Connect To Network Device5.3250.21255.3250.2125001Connect To Network Device1.7750.21251.7750.2125001Connect To Network Device5.3250.21255.3250.2125001Connect To Network Device1.7750.21251.7750.2125001Connect To Network Device5.3250.21255.3250.2125001Connect To Network Device1.7750.21251.7750.2125001Connect To Network Device5.3250.21255.3250.2125001Connect To Network Device1.7750.21251.7750.2125001Connect To Network Device5.3250.21255.3250.2125001Connect To Network Device1.7750.21251.7750.2125001Connect To Network Device5.3250.21255.3250.2125001Connect To Network Device1.7750.21251.7750.2125001Connect To Network Device5.3250.21255.3250.2125001Connect To Network Device1.7750.21251.7750.2125001Connect To Network Device5.3250.21255.3250.2125001Connect To Network Device1.7750.21251.7750.2125001Connect To Network Device0.106250.212500003.550.212500007.10.21250000400010.1944444444444444000000000000-11033LAN 3.550.21249999999999677.10.42500000000000083.550.2125-7.401486830834382E-1700000000000000000001Ethernet0000103310.106250.212500007.10.2125000010001.183570.85000000000000161.183570.21253.550.212510002.36643-0.42500000000000082.366430.21253.550.212510004.73357-0.42500000000000084.733570.21253.550.212510003.550.85000000000000163.550.21253.550.212510005.9166430.85000000000000165.9166430.21253.550.212510001.7750.21251.7750.21253.550.212510005.3250.21255.3250.21253.550.212510001.7750.21251.7750.21253.550.212510005.3250.21255.3250.21253.550.212510001.7750.21251.7750.21253.550.212510005.3250.21255.3250.21253.550.212510001.7750.21251.7750.21253.550.212510005.3250.21255.3250.21253.550.212510001.7750.21251.7750.21253.550.212510005.3250.21255.3250.21253.550.212510001.7750.21251.7750.21253.550.212510005.3250.21255.3250.21253.550.212510001.7750.21251.7750.21253.550.212510005.3250.21255.3250.21253.550.212510001.7750.21251.7750.21253.550.212510005.3250.21255.3250.21253.550.212510001.7750.21251.7750.21253.550.212510005.3250.21255.3250.21253.550.212510001.7750.21251.7750.21253.550.212510005.3250.21255.3250.21253.550.212510001.7750.21251.7750.21253.550.212510005.3250.21255.3250.21253.550.212510001.7750.21251.7750.21253.550.212510005.3250.21255.3250.21253.550.212510001.7750.21251.7750.21253.550.212510005.3250.21255.3250.21253.550.212510001.7750.21251.7750.21253.550.212510005.3250.21255.3250.21253.550.212510001.7750.21251.7750.21253.550.212510005.3250.21255.3250.21253.550.212510001.7750.21251.7750.21253.550.212510005.3250.21255.3250.21253.550.212510001.7750.21251.7750.21253.550.212510005.3250.21255.3250.21253.550.212510001.7750.21251.7750.21253.550.212510005.3250.21255.3250.21253.550.212510001.7750.21251.7750.21253.550.212510005.3250.21255.3250.21253.550.212510001.7750.21251.7750.21253.550.212510005.3250.21255.3250.21253.550.212510001.7750.21251.7750.21253.550.212510005.3250.21255.3250.21253.550.212510001.7750.21251.7750.21253.550.212510005.3250.21255.3250.21253.550.212510001.7750.21251.7750.21253.550.212510005.3250.21255.3250.21253.550.212510001.7750.21251.7750.21253.550.212510005.3250.21255.3250.21253.550.212510001.7750.21251.7750.21253.550.212510005.3250.21255.3250.21253.550.212510001.7750.21251.7750.21253.550.212510005.3250.21255.3250.21253.550.212510001.7750.21251.7750.21253.550.212510005.3250.21255.3250.21253.550.212510001.7750.21251.7750.21253.550.212510005.3250.21255.3250.21253.550.212510001.7750.21251.7750.21253.550.212510005.3250.21255.3250.21253.550.212510001.7750.21251.7750.21253.550.21253.550.21250000000000067.10.42500000000000093.550.212500000000000500000000000006.993750.21250000000000057.05750.21250000000000056.993750.382500000000000800000.106250.42500000000000096.993750.42500000000000096.9937507.10.2125000000000005-1.570796326794920.1062500.106250.425000000000000900.2125000000000005-1.570796326794923.550.21257.10.42500000000000093.550.212500000000000500000000010000.106250.42500000000000096.993750.42500000000000096.9937507.10.2125000000000005-1.570796326794920.1062500.106250.425000000000000900.2125000000000005-1.570796326794925.7142857142857146.610.40.50.2000000000400010.1944444444444444000000000000-110330000001010.400.400peth0 93.935.81.52.90000#c6d1e3#c0c0c01#dddddd10000000001400010.25000000000000-110330000003035.805.800DomU Lists 206.124.146.177/ 192.168.1.7 3.5857142857142865.410.40.50.2000000000400010.1944444444444444000000000000-110330000001010.400.400vif0.0 2.85.610.40.50.2000000000400010.1944444444444444000000000000-110330000001010.400.400eth0 75.410.40.50.2000000000400010.1944444444444444000000000000-110330000001010.400.400vif1.0 7.95.610.40.50.2000000000400010.1944444444444444000000000000-110330000001010.400.400eth0 4.7817712822131296.0888047174539241.2492568501405490.53667627937787280.62462842507027450.2683381396889364000000000400010.25000000000000-110330000001.24925685014054901.2492568501405490.536676279377872800.536676279377872800xenbr0 5.31.52.60.61.30.3000000000400010.25000000000000-110330000002.602.60.600.600Extended Dom0 1101192953400.5100101102103104105106107108shorewall-docs-xml-5.0.15/images/MultiZone2.vdx0000644000000000000000000120265013020330134020017 0ustar rootroot MultiZone1 TEastep Hewlett Packard Company 671351309 671351309 AQAAAGwAAABbAAAAOgEAAPkCAABYAgAAAAAAAAAAAABzbQAApVQAACBFTUYAAAEAVEkAAG0BAAAEA AAAAAAAAAAAAAAAAAAAAAUAAAAEAABAAQAA8AAAAAAAAAAAAAAAAAAAAADiBACAqQMARgAAACwAAA AgAAAARU1GKwFAAQAcAAAAEAAAAAEQwNsBAAAAYAAAAGAAAABGAAAAhAAAAHgAAABFTUYrMEACABA AAAAEAAAAAACAPx9ABAAMAAAAAAAAAB5AAQAMAAAAAAAAAB1AAAAUAAAACAAAAAIAAAB+AwAAHUAA ABQAAAAIAAAAAgAAAJsDAAAKQACAJAAAABgAAAAA/wD/AQAAAPZA/EPt/J1DAAB+Q6XijEMhAAAAC AAAAGIAAAAMAAAAAQAAACQAAAAkAAAAAACAPQAAAAAAAAAAAACAPQAAAAAAAAAAAgAAACcAAAAYAA AAAQAAAAAAAAAA/wAAAAAAACUAAAAMAAAAAQAAACUAAAAMAAAACAAAgEwAAABkAAAA+QEAADwBAAD 2AgAAVQIAAIkfAADAEwAA4A8AAJwRAAAhAPAAAAAAAAAAAAAAAIA/AAAAAAAAAAAAAIA/AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAlAAAADAAAAAcAAIAlAAAADAAAAAAAAIAkAAAAJAAAA AAAgEEAAAAAAAAAAAAAgEEAAAAAAAAAAAIAAABGAAAApAAAAJgAAABFTUYrCEAAAjwAAAAwAAAAAR DA2wAAAABOAAAAAAAAAEoMgj8CAAAAAgAAAAIAAAACAAAAARDA2wAAAAAAAAD/CEABA0gAAAA8AAA AARDA2wUAAAAAAAAA9kD8Q8lvFUR7oD1EyW8VRHugPUTt/J1D9kD8Q+38nUP2QPxDyW8VRAABAQGB AAAAFUABABAAAAAEAAAAAAAAACQAAAAkAAAAAACAPQAAAAAAAAAAAACAPQAAAAAAAAAAAgAAAF8AA AA4AAAAAgAAADgAAAAAAAAAOAAAAAAAAAAAAAEAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJQAAAA wAAAACAAAAJQAAAAwAAAAFAACAVgAAADAAAAD3AQAAOgEAAPkCAABYAgAABQAAAIkfXCVpL1wlaS/ AE4kfwBOJH1wlJQAAAAwAAAAHAACAJQAAAAwAAAAAAACAJAAAACQAAAAAAIBBAAAAAAAAAAAAAIBB AAAAAAAAAAACAAAAKAAAAAwAAAACAAAARgAAADQAAAAoAAAARU1GKwpAAIAkAAAAGAAAAP//AP8BA AAAYh8ARMmv9EOQwm5DBLmXQigAAAAMAAAAAQAAACQAAAAkAAAAAACAPQAAAAAAAAAAAACAPQAAAA AAAAAAAgAAACcAAAAYAAAAAQAAAAAAAAAA//8AAAAAACUAAAAMAAAAAQAAACUAAAAMAAAACAAAgEw AAABkAAAAAQIAAOkBAADuAgAANAIAAAggAACWHgAA7A4AAL4EAAAhAPAAAAAAAAAAAAAAAIA/AAAA AAAAAAAAAIA/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAlAAAADAAAAAcAAIAlAAAAD AAAAAAAAIAkAAAAJAAAAAAAgEEAAAAAAAAAAAAAgEEAAAAAAAAAAAIAAABGAAAApAAAAJgAAABFTU YrCEAAAjwAAAAwAAAAARDA2wAAAABOAAAAAAAAAEoMgj8CAAAAAgAAAAIAAAACAAAAARDA2wAAAAA AAAD/CEABA0gAAAA8AAAAARDA2wUAAAAAAAAAYh8ARAVPDUQG0DtEBU8NRAbQO0TJr/RDYh8ARMmv 9ENiHwBEBU8NRAABAQGBAAAAFUABABAAAAAEAAAAAAAAACQAAAAkAAAAAACAPQAAAAAAAAAAAACAP QAAAAAAAAAAAgAAAF8AAAA4AAAAAgAAADgAAAAAAAAAOAAAAAAAAAAAAAEAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAJQAAAAwAAAACAAAAJQAAAAwAAAAFAACAVgAAADAAAAD/AQAA5wEAAPECAAA3AgA ABQAAAAggVCP0LlQj9C6WHggglh4IIFQjJQAAAAwAAAAHAACAJQAAAAwAAAAAAACAJAAAACQAAAAA AIBBAAAAAAAAAAAAAIBBAAAAAAAAAAACAAAAKAAAAAwAAAACAAAARgAAAPQBAADoAQAARU1GKwhAA QPUAQAAyAEAAAEQwNsxAAAAAAAAAMrI/kJK1vND4RcOQ/FfBUT+jC9DA4YJRBsfSkNaLwNEgthMQ/ uIAkThb09DYMkBRBDeUUOZ8gBEhJJpQ3IhCURXFoZDmHoHRKuTj0NAhPpDvYyQQ7tr+EPwapFDsy/ 2Q98rkkNQ1vNDn4WZQz4c90PzBKFDq3zvQ9HqokNXz+JDAzWjQ7/f4EOOWqND9eHeQ49ao0Md4txD j1qjQ1rKz0MTM51DNC3FQ56blUM0LcVD1XKUQzMtxUM+S5ND9G3FQ+ErkkPp7cVDIdKKQ1QEr0MmL 3RDMLimQwqdWUOFZbNDouNWQ0GytENETFRDeDG2QxXeUUMH37dDoSk6Q1SBp0N2jxdDCM+qQ9CUBE P5P79DqqICQ35YwUNF5gBDhpTDQ9HI/kLo7cVD02HhQvmnwkOBZMNCjEfKQwvNu0Lh9NZDQqS6Qnn k2EMUDrpCQ+LaQxQOukIb4txDEg66Qt756UMCrNJCA5f0Q9cJ8UIEl/RD+qz1QgSX9ENYS/pCRFb0 Q8jI/kJO1vNDAAMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDg wAAABRAAYAQAAAABAAAAP////8oAAAADAAAAAEAAAAkAAAAJAAAAAAAgD0AAAAAAAAAAAAAgD0AAA AAAAAAAAIAAAAnAAAAGAAAAAEAAAAAAAAA////AAAAAAAlAAAADAAAAAEAAAATAAAADAAAAAEAAAA 7AAAACAAAAFUAAADgAAAAAAAAAAAAAAD//////////zEAAAD3B3se4ghYIfkKYiKiDMwgzgyjIPcM cyAeDT0gmg5JIsMQ3yHzEVEfEhIOHy4Sxh5GEnseMRPkHiEU8B1eFFocZxQcHGwU3RtsFJ0bbBT6G acTphi0EqYYjxKmGGoSrhhGEr4YWxHhFUMP1xSaDW0Wbw2XFkUNxxYeDfwWowvxFHkJWhVKCOgXKw gsGA8Icxj3B74YDAdVGBwGSRnfBd8a1gUdG9EFXRvRBZ0b0QVAHZYGkx6JB5MergeTHtMHix73B3s ePAAAAAgAAAA+AAAAGAAAAF0AAABNAQAARwEAACcCAAATAAAADAAAAAEAAAAlAAAADAAAAAAAAIAk AAAAJAAAAAAAgEEAAAAAAAAAAAAAgEEAAAAAAAAAAAIAAABGAAAAXAAAAFAAAABFTUYrCEAAAjwAA AAwAAAAARDA2wAAAABOAAAAAAAAAEoMgj8CAAAAAgAAAAIAAAACAAAAARDA2wAAAAAAAAD/FUABAB AAAAAEAAAAAAAAACQAAAAkAAAAAACAPQAAAAAAAAAAAACAPQAAAAAAAAAAAgAAAF8AAAA4AAAAAgA AADgAAAAAAAAAOAAAAAAAAAAAAAEAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJQAAAAwAAAACAAAA JQAAAAwAAAAFAACAVQAAAOAAAABbAAAASwEAAEkBAAAoAgAAMQAAAPcHex7iCFgh+QpiIqIMzCDOD KMg9wxzIB4NPSCaDkkiwxDfIfMRUR8SEg4fLhLGHkYSex4xE+QeIRTwHV4UWhxnFBwcbBTdG2wUnR tsFPoZpxOmGLQSphiPEqYYahKuGEYSvhhbEeEVQw/XFJoNbRZvDZcWRQ3HFh4N/BajC/EUeQlaFUo I6BcrCCwYDwhzGPcHvhgMB1UYHAZJGd8F3xrWBR0b0QVdG9EFnRvRBUAdlgaTHokHkx6uB5Me0weL HvcHex4lAAAADAAAAAcAAIAlAAAADAAAAAAAAIAkAAAAJAAAAAAAgEEAAAAAAAAAAAAAgEEAAAAAA AAAAAIAAAAoAAAA DAAAAAIAAABGAAAA6AAAANwAAABFTUYrKkAAACQAAAAYAAAAMzPLQgAAAAAAAAAAJb/YQhQOukJMe K1DCEACBjAAAAAkAAAAARDA26uqKj4AAAAAAAAAAAAAAAAFAAAAQQBSAEkAQQBMAAAANkACgIQAAA B4AAAAAAAA/wEAAAABAAAACAAAAEkAbgB0AGUAcgBuAGUAdABmDl4/zcxsPxHpaT/NzGw/3tGAP83 MbD8zv4Y/zcxsP4mckj/NzGw/M7eZP83MbD+JlKU/zcxsP95xsT/NzGw/AACAPwAAAAAAAAAAAACA PwAAAAAAAAAAEgAAAAwAAAABAAAAGAAAAAwAAAAAAAAAFgAAAAwAAAAYAAAAUgAAAHABAAACAAAA7 v///wAAAAAAAAAAAAAAAJABAAAAAAAABwAEAEEAcgBpAGEAbAAAAAAATQBvAG4AbwB0AHkAcABlAD oAQQByAGkAYQBsACAAUgBlAGcAdQBsAGEAcgA6AFYAZQAAAAAABAAAAAEAAAA82xIAAAAAABDdEgA KOdd3OJvZd/////+ZWNR3kjU0d6gEIwCCAAAAAAAAAAAAAAAAAAAAKzQ0dwAAAAArNDR3AAAAAAQA BQCoBCMAQ75ydHR/1Hfc2xIAAACzAOYX9XcdAAAA+AuzAAAAswBgVm8ytNsSAAAAAAD83RIABZD3d /DV9nf/////5hf1d3gX9XeyF/V3hOESAOAAAABYOG8yFwAAAMgfJTNQWdR3EakAABGpAAAAANR3QC ttABGpAAAAAAAA2T7Hdxg/x3fLCxDFDAAAAPTgEgDgh3IyywsQxQwAAAD04BIAsIYlMwEAAADw1fZ 3ZHYACAAAAAAlAAAADAAAAAIAAABUAAAAfAAAALUAAACuAQAA7AAAAMIBAAABAAAAAADIQQCAu0G1 AAAAvwEAAAgAAABMAAAAAAAAAAAAAAAAAAAA//////////9cAAAASQBuAHQAZQByAG4AZQB0AAUAA AAJAAAABQAAAAkAAAAGAAAACQAAAAkAAAAAAAAAJQAAAAwAAAANAACARgAAAHQAAABoAAAARU1GKy tAAAAMAAAAAAAAAAhAAQNIAAAAPAAAAAEQwNsFAAAAAAAAAMLNz0P3GvpDXAfmQw9m4kNcB+ZDs9a +Q8LNz0Obi9ZDws3PQ/ca+kMAAQEBgQAAABRAAYAQAAAABAAAAE9i0P8oAAAADAAAAAEAAAAkAAAA JAAAAAAAgD0AAAAAAAAAAAAAgD0AAAAAAAAAAAIAAAAnAAAAGAAAAAEAAAAAAAAA0GJPAAAAAAAlA AAADAAAAAEAAAATAAAADAAAAAEAAAAlAAAADAAAAAgAAIBWAAAAMAAAAJ8BAAB9AQAAzQEAAPUBAA AFAAAA+hlEH8EcTRzBHNsX+hnSGvoZRB8lAAAADAAAAAcAAIATAAAADAAAAAEAAAAlAAAADAAAAAA AAIAkAAAAJAAAAAAAgEEAAAAAAAAAAAAAgEEAAAAAAAAAAAIAAABGAAAAXAAAAFAAAABFTUYrCEAA AjwAAAAwAAAAARDA2wAAAABOAAAAAAAAAEoMgj8CAAAAAgAAAAIAAAACAAAAARDA2wAAAADNzc3/F UABABAAAAAEAAAAAAAAACQAAAAkAAAAAACAPQAAAAAAAAAAAACAPQAAAAAAAAAAAgAAAF8AAAA4AA AAAwAAADgAAAAAAAAAOAAAAAAAAAAAAAEAEAAAAAAAAADNzc0AAAAAAAAAAAAAAAAAJQAAAAwAAAA DAAAAJQAAAAwAAAAFAACAVgAAADAAAACeAQAAfAEAAM4BAAD2AQAABQAAAPoZRB/BHE0cwRzbF/oZ 0hr6GUQfJQAAAAwAAAAHAACAJQAAAAwAAAAAAACAJAAAACQAAAAAAIBBAAAAAAAAAAAAAIBBAAAAA AAAAAACAAAAKAAAAAwAAAADAAAARgAAAOgEAADcBAAARU1GKwhAAAI4AAAALAAAAAEQwNsAAAAAFg AAAAAAAABKDII/AQAAAAEAAAAAAABAARDA2wAAAADNzc3/CEABA5AEAACEBAAAARDA238AAAAAAAA A11vLQ9V43EPCzc9D1XjcQ/aU0kM4gtlD9pTSQziC2UMpXNVDm4vWQylc1UObi9ZDXCPYQ/6U00Nc I9hD/pTTQ4/q2kNhntBDj+raQ2Ge0EPCsd1DxKfNQ8Kx3UPEp81D9njgQyexykP2eOBDJ7HKQylA4 0OKusdD11vLQw9m4kPCzc9DD2biQ/aU0kNyb99D9pTSQ3Jv30MpXNVD1XjcQylc1UPVeNxDXCPYQz iC2UNcI9hDOILZQ4/q2kObi9ZDj+raQ5uL1kPCsd1D/pTTQ8Kx3UP+lNND9njgQ2Ge0EP2eOBDYZ7 QQylA40PEp81DKUDjQ8SnzUNcB+ZDJ7HKQ9dby0NJU+hDws3PQ0lT6EP2lNJDrFzlQ/aU0kOsXOVD KVzVQw9m4kMpXNVDD2biQ1wj2ENyb99DXCPYQ3Jv30OP6tpD1XjcQ4/q2kPVeNxDwrHdQziC2UPCs d1DOILZQ/Z44EObi9ZD9njgQ5uL1kMpQOND/pTTQylA40P+lNNDXAfmQ2Ge0EPXW8tDg0DuQ8LNz0 ODQO5D9pTSQ+ZJ60P2lNJD5knrQylc1UNJU+hDKVzVQ0lT6ENcI9hDrFzlQ1wj2EOsXOVDj+raQw9 m4kOP6tpDD2biQ8Kx3UNyb99DwrHdQ3Jv30P2eOBD1XjcQ/Z44EPVeNxDKUDjQziC2UMpQONDOILZ Q1wH5kObi9ZD11vLQ70t9EPCzc9DvS30Q/aU0kMgN/FD9pTSQyA38UMpXNVDg0DuQylc1UODQO5DX CPYQ+ZJ60NcI9hD5knrQ4/q2kNJU+hDj+raQ0lT6EPCsd1DrFzlQ8Kx3UOsXOVD9njgQw9m4kP2eO BDD2biQylA40Nyb99DKUDjQ3Jv30NcB+ZD1XjcQ/aU0kM4gtlD9pTSQ/6U00P2lNJDrFzlQ/aU0kN yb99D9pTSQyA38UP2lNJD5knrQylc1UO9LfRDKVzVQ4NA7kMpXNVD1XjcQylc1UObi9ZDKVzVQ0lT 6EMpXNVDD2biQ1wj2EP+lNNDXCPYQ8SnzUNcI9hDcm/fQ1wj2EM4gtlDXCPYQ+ZJ60NcI9hDrFzlQ 4/q2kODQO5Dj+raQ0lT6EOP6tpDm4vWQ4/q2kNhntBDj+raQw9m4kOP6tpD1XjcQ8Kx3UPEp81Dwr HdQ4q6x0PCsd1DOILZQ8Kx3UP+lNNDwrHdQ6xc5UPCsd1Dcm/fQ/Z44ENJU+hD9njgQw9m4kP2eOB DYZ7QQ/Z44EMnscpD9njgQ9V43EP2eOBDm4vWQylA40P+lNNDKUDjQ8SnzUMpQONDcm/fQylA40M4 gtlDKUDjQ4q6x0MpQONDUM3BQylA40OKusdDXAfmQ+3DxEMAAQEAAQABAAEAAQABAAEAAQEAAQABA AEAAQABAAEAAQABAQABAAEAAQABAAEAAQABAAEBAAEAAQABAAEAAQABAAEAAQEAAQABAAEAAQABAA EAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABABVAAQAQAAAABAA AAAAAAAA6AAAADAAAAAIAAAAkAAAAJAAAAAAAgD0AAAAAAAAAAAAAgD0AAAAAAAAAAAIAAABfAAAA OAAAAAMAAAA4AAAAAAAAADgAAAAAAAAAACEBABAAAAAAAAAAzc3NAAAAAAAAAAAAAAAAACUAAAAMA AAAAwAAACUAAAAMAAAABQAAgFoAAAAQAwAAkgEAAH8BAADRAQAA7QEAAD0AAAB/AAAAAwAAAAIAAA ACAAAAAgAAAAIAAAACAAAAAgAAAAMAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAAAACAAAAAwAAAAI AAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAAAADAAAAAgAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAA AAMAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAAAACAAAAA gAAAAIAAAACAAAA AgAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAAGwZkBv6G ZAbUxoxG1MaMRusGtIarBrSGgUbcxoFG3MaXhsUGl4bFBq3G7UZtxu1GRAcVxkQHFcZaBz4GGwZTR z6GU0cUxruG1Ma7husGpAbrBqQGwUbMRsFGzEbXhvSGl4b0hq3G3MatxtzGhAcFBoQHBQaaBy1GWg ctRnBHFcZbBkLHfoZCx1TGqwcUxqsHKwaTRysGk0cBRvuGwUb7hteG5AbXhuQG7cbMRu3GzEbEBzS GhAc0hpoHHMaaBxzGsEcFBpsGckd+hnJHVMaah1TGmodrBoLHawaCx0FG6wcBRusHF4bTRxeG00ct xvuG7cb7hsQHJAbEByQG2gcMRtoHDEbwRzSGmwZhh76GYYeUxonHlMaJx6sGskdrBrJHQUbah0FG2 odXhsLHV4bCx23G6wctxusHBAcTRwQHE0caBzuG2gc7hvBHJAbUxoxG1MacxpTGqwcUxruG1MaJx5 TGmodrBqGHqwayR2sGpAbrBrSGqwaCx2sGk0cBRtzGgUbtRkFG+4bBRsxGwUbah0FG6wcXhvJHV4b Cx1eG9IaXhsUGl4bTRxeG5Abtxu1Gbcb+Bi3GzEbtxtzGrcbrBy3G+4bEBwLHRAcTRwQHBQaEBxXG RAckBsQHNIaaBxzGmgctRloHO4baBwxG2gc+BhoHDoYaBz4GMEcmRglAAAADAAAAAcAAIAlAAAADA AAAAAAAIAkAAAAJAAAAAAAgEEAAAAAAAAAAAAAgEEAAAAAAAAAAAIAAAAoAAAADAAAAAMAAAA6AAA ADAAAAAoAAABGAAAANAAAACgAAABFTUYrCkAAgCQAAAAYAAAAX37c/wEAAADXW8tDm4vWQ2A9DkFw PY5CKAAAAAwAAAABAAAAJAAAACQAAAAAAIA9AAAAAAAAAAAAAIA9AAAAAAAAAAACAAAAJwAAABgAA AABAAAAAAAAANx+XwAAAAAAJQAAAAwAAAABAAAAJQAAAAwAAAAIAACATAAAAGQAAACXAQAArQEAAJ 8BAADzAQAAbBkAANIaAACOAAAAcgQAACEA8AAAAAAAAAAAAAAAgD8AAAAAAAAAAAAAgD8AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACUAAAAMAAAABwAAgCUAAAAMAAAAAAAAgCQAAAAkAAAA AACAQQAAAAAAAAAAAACAQQAAAAAAAAAAAgAAAEYAAACoAAAAnAAAAEVNRisIQAACQAAAADQAAAABE MDbAAAAAF4AAAAAAAAASgyCPwIAAAACAAAAAgAAAAAAAEACAAAAARDA2wAAAADm5ub/CEABA0gAAA A8AAAAARDA2wUAAAAAAAAA11vLQ/ca+kPXW8tDm4vWQ8LNz0Obi9ZDws3PQ/ca+kPXW8tD9xr6QwA BAQGBAAAAFUABABAAAAAEAAAAAAAAACQAAAAkAAAAAACAPQAAAAAAAAAAAACAPQAAAAAAAAAAAgAA AF8AAAA4AAAAAwAAADgAAAAAAAAAOAAAAAAAAAAAAAEAEAAAAAAAAADm5uYAAAAAAAAAAAAAAAAAJ QAAAAwAAAADAAAAJQAAAAwAAAAFAACAVgAAADAAAACVAQAAqwEAAKIBAAD2AQAABQAAAGwZRB9sGd Ia+hnSGvoZRB9sGUQfJQAAAAwAAAAHAACAJQAAAAwAAAAAAACAJAAAACQAAAAAAIBBAAAAAAAAAAA AAIBBAAAAAAAAAAACAAAAKAAAAAwAAAADAAAARgAAAGgAAABcAAAARU1GKwhAAQNIAAAAPAAAAAEQ wNsFAAAAAAAAALgG0kObi9ZDUkDoQ7PWvkNSQOhDz3e8Q7gG0kO3LNRDuAbSQ5uL1kMAAQEBgQAAA BRAAYAQAAAABAAAAJqamv8oAAAADAAAAAEAAAAkAAAAJAAAAAAAgD0AAAAAAAAAAAAAgD0AAAAAAA AAAAIAAAAnAAAAGAAAAAEAAAAAAAAAmpqaAAAAAAAlAAAADAAAAAEAAAATAAAADAAAAAEAAAAlAAA ADAAAAAgAAIBWAAAAMAAAAKQBAAB4AQAA0QEAAK4BAAAFAAAAQRrSGgkd2xcJHY8XQRqGGkEa0hol AAAADAAAAAcAAIATAAAADAAAAAEAAAAlAAAADAAAAAAAAIAkAAAAJAAAAAAAgEEAAAAAAAAAAAAAg EEAAAAAAAAAAAIAAABGAAAAYAAAAFQAAABFTUYrCEAAAkAAAAA0AAAAARDA2wAAAABeAAAAAAAAAL dlrT4CAAAAAgAAAAIAAAAAAABAAgAAAAEQwNsAAAAAAAAA/xVAAQAQAAAABAAAAAAAAAAkAAAAJAA AAAAAgD0AAAAAAAAAAAAAgD0AAAAAAAAAAAIAAABfAAAAOAAAAAMAAAA4AAAAAAAAADgAAAAAAAAA AAABAAUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACUAAAAMAAAAAwAAACUAAAAMAAAABQAAgFYAAAAwA AAAogEAAHcBAADSAQAArwEAAAUAAABBGtIaCR3bFwkdjxdBGoYaQRrSGiUAAAAMAAAABwAAgCUAAA AMAAAAAAAAgCQAAAAkAAAAAACAQQAAAAAAAAAAAACAQQAAAAAAAAAAAgAAACgAAAAMAAAAAwAAAEY AAAA0AAAAKAAAAEVNRisKQACAJAAAABgAAADAwMD/AQAAAOEiyUO3LNRDcD2OQQC5l0AoAAAADAAA AAEAAAAkAAAAJAAAAAAAgD0AAAAAAAAAAAAAgD0AAAAAAAAAAAIAAAAnAAAAGAAAAAEAAAAAAAAAw MDAAAAAAAAlAAAADAAAAAEAAAAlAAAADAAAAAgAAIBMAAAAZAAAAJIBAACoAQAAowEAAKwBAAAlGQ AAhhoAABwBAABMAAAAIQDwAAAAAAAAAAAAAACAPwAAAAAAAAAAAACAPwAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAJQAAAAwAAAAHAACAJQAAAAwAAAAAAACAJAAAACQAAAAAAIBBAAAAAAAA AAAAAIBBAAAAAAAAAAACAAAARgAAAKgAAACcAAAARU1GKwhAAAJAAAAANAAAAAEQwNsAAAAAXgAAA AAAAAC3Za0+AgAAAAIAAAACAAAAAAAAQAIAAAABEMDbAAAAAAAAAP8IQAEDSAAAADwAAAABEMDbBQ AAAAAAAADhIslDtyzUQ+EiyUObi9ZDuAbSQ5uL1kO4BtJDtyzUQ+EiyUO3LNRDAAEBAYEAAAAVQAE AEAAAAAQAAAAAAAAAJAAAACQAAAAAAIA9AAAAAAAAAAAAAIA9AAAAAAAAAAACAAAAXwAAADgAAAAD AAAAOAAAAAAAAAA4AAAAAAAAAAAAAQAFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAlAAAADAAAAAMAA AAlAAAADAAAAAUAAIBWAAAAMAAAAJEBAACnAQAApgEAAK8BAAAFAAAAJRmGGiUZ0hpBGtIaQRqGGi UZhholAAAADAAAAAcAAIAlAAAADAAAAAAAAIAkAAAAJAAAAAAAgEEAAAAAAAAAAAAAgEEAAAAAAAA AAAIAAAAoAAAADAAAAAMAAABGAAAAaAAAAFwAAABFTUYrCEABA0gAAAA8AAAAARDA2wUAAAAAAAAA 4SLJQ7cs1EN7XN9Dz3e8Q1JA6EPPd7xDuAbSQ7cs1EPhIslDtyzUQwABAQGBAAAAFEABgBAAAAAEA AAA5ubm/ygAAAAMAAAAAQAAACQAAAAkAAAAAACAPQAAAAAAAAAAAACAPQAAAAAAAAAAAgAAACcAAA AYAAAAAQAAAAAAAADm5uYAAAAAACUAAAAMAAAAAQAAABMAAAAMAAAAAQAAACUAAAAMAAAACAAAgFY AAAAwAAAAkgEAAHgBAADRAQAAqQEAAAUAAAAlGYYa7BuPFwkdjxdBGoYaJRmGGiUAAAAMAAAABwAA gBMAAAAMAAAAAQAAACUAAAAMAAAAAAAAgCQAAAAkAAAAAACAQQAAAAAAAAAAAACAQQAAAAAAAAAAA gAAAEYAAABgAAAA VAAAAEVNRisIQAACQAAAADQAAAABEMDbAAAAAF4AAAAAAAAAt2WtPgIAAAACAAAAAgAAAAAAAEACA AAAARDA2wAAAAAAAAD/FUABABAAAAAEAAAAAAAAACQAAAAkAAAAAACAPQAAAAAAAAAAAACAPQAAAA AAAAAAAgAAAF8AAAA4AAAAAwAAADgAAAAAAAAAOAAAAAAAAAAAAAEABQAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAJQAAAAwAAAADAAAAJQAAAAwAAAAFAACAVgAAADAAAACRAQAAdwEAANIBAACqAQAABQAA ACUZhhrsG48XCR2PF0EahholGYYaJQAAAAwAAAAHAACAJQAAAAwAAAAAAACAJAAAACQAAAAAAIBBA AAAAAAAAAAAAIBBAAAAAAAAAAACAAAAKAAAAAwAAAADAAAARgAAAMwAAADAAAAARU1GKwhAAAI4AA AALAAAAAEQwNsAAAAAFgAAAAAAAABKDII/AQAAAAEAAAAAAABAARDA2wAAAADm5ub/CEABA3QAAAB oAAAAARDA2woAAAAAAAAAws3PQ9V43EPXW8tD1XjcQ8LNz0MPZuJD11vLQw9m4kPCzc9DSVPoQ9db y0NJU+hDws3PQ4NA7kPXW8tDg0DuQ8LNz0O9LfRD11vLQ70t9EMAAQABAAEAAQABAAAVQAEAEAAAA AQAAAAAAAAAOgAAAAwAAAACAAAAJAAAACQAAAAAAIA9AAAAAAAAAAAAAIA9AAAAAAAAAAACAAAAXw AAADgAAAADAAAAOAAAAAAAAAA4AAAAAAAAAAAhAQAQAAAAAAAAAObm5gAAAAAAAAAAAAAAAAAlAAA ADAAAAAMAAAAlAAAADAAAAAUAAIBaAAAAXAAAAJIBAAC0AQAApQEAAO0BAAAFAAAACgAAAAIAAAAC AAAAAgAAAAIAAAACAAAA+hmQG2wZkBv6GU0cbBlNHPoZCx1sGQsd+hnJHWwZyR36GYYebBmGHiUAA AAMAAAABwAAgCUAAAAMAAAAAAAAgCQAAAAkAAAAAACAQQAAAAAAAAAAAACAQQAAAAAAAAAAAgAAAC gAAAAMAAAAAwAAADoAAAAMAAAACgAAAEYAAADcAAAA0AAAAEVNRisIQAACQAAAADQAAAABEMDbAAA AAF4AAAAAAAAAJb/YPwIAAAACAAAAAgAAAAAAAEACAAAAARDA2wAAAAAAAAD/CEABA3wAAABwAAAA ARDA2wsAAAAAAAAA11vLQ/ca+kPXW8tDm4vWQ+EiyUObi9ZD4SLJQ7cs1EN7XN9Dz3e8Q1JA6EPPd 7xDUkDoQ7PWvkNcB+ZDlzXBQ1wH5kMPZuJDws3PQ/ca+kPXW8tD9xr6QwABAQEBAQEBAQEBABVAAQ AQAAAABAAAAAAAAAAkAAAAJAAAAAAAgD0AAAAAAAAAAAAAgD0AAAAAAAAAAAIAAABfAAAAOAAAAAM AAAA4AAAAAAAAADgAAAAAAAAAAAABABsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACUAAAAMAAAAAwAA ACUAAAAMAAAABQAAgFcAAABIAAAAkAEAAHcBAADTAQAA9wEAAAsAAABsGUQfbBnSGiUZ0holGYYa7 BuPFwkdjxcJHdsXwRwnGMEcTRz6GUQfbBlEHyUAAAAMAAAABwAAgCUAAAAMAAAAAAAAgCQAAAAkAA AAAACAQQAAAAAAAAAAAACAQQAAAAAAAAAAAgAAACgAAAAMAAAAAwAAAEYAAADoAAAA3AAAAEVNRis qQAAAJAAAABgAAAAzM8tCAAAAAAAAAAAlv9hCcLXRQ9EE/kMIQAIGMAAAACQAAAABEMDbq6oqPgAA AAAAAAAAAAAAAAUAAABBAFIASQBBAEwAAAA2QAKAhAAAAHgAAAAAAAD/AQAAAAEAAAAIAAAARgBpA HIAZQB3AGEAbABsADmO4zxhCzY+x7EEPmELNj5ynCo+YQs2PsdxYz5hCzY+OS6hPmELNj45zt4+YQ s2PschBz9hCzY+cpwQP2ELNj4AAIA/AAAAAAAAAAAAAIA/AAAAAAAAAAASAAAADAAAAAEAAAAYAAA ADAAAAAAAAAAWAAAADAAAABgAAAAlAAAADAAAAAIAAABUAAAAfAAAAKYBAAD+AQAA3gEAABICAAAB AAAAAADIQQCAu0GmAQAADwIAAAgAAABMAAAAAAAAAAAAAAAAAAAA//////////9cAAAARgBpAHIAZ QB3AGEAbABsAAoAAAAEAAAABgAAAAkAAAAMAAAACQAAAAQAAAAAAAAAJQAAAAwAAAANAACARgAAAG QBAABYAQAARU1GKytAAAAMAAAAAAAAAAhAAQM4AQAALAEAAAEQwNsgAAAAAAAAAJ6ZCkSV+OND2O4 JRIfs40NlZglEeDvhQ9poCUSH9d1DQmsJRJbA2kNP8glE8inYQ56ZCkQiHthDZUQLRDAq2EPYzAtE P9vaQ2PKC0QwId5D+8cLRCFW4UPuQAtExezjQ5+ZCkSV+ONDn5kKRGNF10Nshi1EY0XXQ95mLkRiR ddD0hwvRLVN2kPSHC9EWwveQ9IcL0QAyeFD3mYuRFTR5ENshi1EVdHkQ2yGLURV0eRDa4YtRFXR5E Nrhi1EVdHkQ2yGLURV0eRDn5kKRFXR5EMsuQlEVdHkQzgDCUQCyeFDOAMJRFwL3kM4AwlEt03aQyy 5CURjRddDnpkKRGJF10MAAwMDAwMDAwMDAwODAAEDAwMDAwMDAwMBAQMDAwMDgxRAAYAQAAAABAAA AMDAwP8oAAAADAAAAAEAAAAkAAAAJAAAAAAAgD0AAAAAAAAAAAAAgD0AAAAAAAAAAAIAAAAnAAAAG AAAAAEAAAAAAAAAwMDAAAAAAAAlAAAADAAAAAEAAAATAAAADAAAAAEAAAA7AAAACAAAABsAAAAQAA AApyIAAIAcAABYAAAATAAAAAAAAAAAAAAA//////////8MAAAAfCJ+HFoiKBxbIr8bWyJZG30iBhu nIgQb0iIGG/QiXBvzIsUb8iIrHNEifhynIoAcPQAAAAgAAAAbAAAAEAAAAKciAADpGgAANgAAABAA AABiKwAA6RoAAFgAAABAAAAAAAAAAAAAAAD//////////wkAAACaK+kayCtKG8grwhvIKzocmiubH GIrmxxiK5scYiubHGIrmxxZAAAAJAAAAAAAAAAAAAAA//////////8CAAAAYiubHKcimxxYAAAANA AAAAAAAAAAAAAA//////////8GAAAAbyKbHEEiOhxBIsIbQSJKG28i6RqnIukaPQAAAAgAAAA8AAA ACAAAAD4AAAAYAAAAJAIAAK4BAAC9AgAAygEAABMAAAAMAAAAAQAAACUAAAAMAAAAAAAAgCQAAAAk AAAAAACAQQAAAAAAAAAAAACAQQAAAAAAAAAAAgAAAEYAAABMAgAAQAIAAEVNRisIQAACQAAAADQAA AABEMDbAAAAAF4AAAAAAAAAt2WtPgIAAAACAAAAAgAAAAAAAEACAAAAARDA2wAAAAAAAAD/CEABA+ wBAADgAQAAARDA2zQAAAAAAAAAnpkKRJX440PY7glEh+zjQ2VmCUR4O+FD2mgJRIf13UNCawlElsD aQ0/yCUTyKdhDnpkKRCIe2ENlRAtEMCrYQ9jMC0Q/29pDY8oLRDAh3kP7xwtEIVbhQ+5AC0TF7OND n5kKRJX440OfmQpEY0XXQ2yGLURjRddD3mYuRGJF10PSHC9EtU3aQ9IcL0RbC95D0hwvRADJ4UPeZ i5EVNHkQ2yGLURV0eRDbIYtRFXR5ENrhi1EVdHkQ2uGLURV0eRDbIYtRFXR5EOfmQpEVdHkQyy5CU RV0eRDOAMJRALJ4UM4AwlEXAveQzgDCUS3TdpDLLkJRGNF10OemQpEYkXXQyZdD0RxuclDJl0PRFw L3kMGEBxEXAveQxm2FURIXfJDGbYVRFwL3kMGEBxEXAveQ/NpIkRIXfJD82kiRFwL3kMGEBxEXAve QwYQHERxuclDBhAcRFwL3kMxwyhEcbnJQzHDKERcC95DBhAcRFwL3kMGEBxEISzmQwYQHERcC95DO eMYRFwL3kMGEBxE XAveQ9I8H0RcC95DBhAcRFwL3kMAAwMDAwMDAwMDAwMDAAEDAwMDAwMDAwMBAQMDAwMDAwABAQABA QABAQABAAEBAAEAAQABFUABABAAAAAEAAAAAAAAACQAAAAkAAAAAACAPQAAAAAAAAAAAACAPQAAAA AAAAAAAgAAAF8AAAA4AAAAAwAAADgAAAAAAAAAOAAAAAAAAAAAAAEABQAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAJQAAAAwAAAADAAAAJQAAAAwAAAAFAACAOwAAAAgAAAAbAAAAEAAAAKciAACAHAAAWAAA AEwAAAAAAAAAAAAAAP//////////DAAAAHwifhxaIigcWyK/G1siWRt9IgYbpyIEG9IiBhv0Ilwb8 yLFG/IiKxzRIn4cpyKAHBsAAAAQAAAApyIAAOkaAAA2AAAAEAAAAGIrAADpGgAAWAAAAEAAAAAAAA AAAAAAAP//////////CQAAAJor6RrIK0obyCvCG8grOhyaK5scYiubHGIrmxxiK5scYiubHFkAAAA kAAAAAAAAAAAAAAD//////////wIAAABiK5scpyKbHFgAAAA0AAAAAAAAAAAAAAD//////////wYA AABvIpscQSI6HEEiwhtBIkobbyLpGqci6RobAAAAEAAAANgjAAA4GQAAWQAAACQAAAAAAAAAAAAAA P//////////AgAAANgjwhsEJ8IbGwAAABAAAABuJQAATB4AAFkAAAAkAAAAAAAAAAAAAAD/////// ///wIAAABuJcIbBCfCGxsAAAAQAAAAmygAAEweAABZAAAAJAAAAAAAAAAAAAAA//////////8CAAA AmyjCGwQnwhsbAAAAEAAAAAQnAAA4GQAANgAAABAAAAAEJwAAwhsAABsAAAAQAAAAMSoAADgZAABZ AAAAJAAAAAAAAAAAAAAA//////////8CAAAAMSrCGwQnwhsbAAAAEAAAAAQnAADGHAAANgAAABAAA AAEJwAAwhsAABsAAAAQAAAAOSYAAMIbAAA2AAAAEAAAAAQnAADCGwAAGwAAABAAAADQJwAAwhsAAD YAAAAQAAAABCcAAMIbAAA8AAAACAAAAEAAAAAYAAAAIgIAAJIBAAC+AgAA5gEAACUAAAAMAAAABwA AgCUAAAAMAAAAAAAAgCQAAAAkAAAAAACAQQAAAAAAAAAAAACAQQAAAAAAAAAAAgAAACgAAAAMAAAA AwAAAEYAAAA0AAAAKAAAAEVNRisKQACAJAAAABgAAADAwMD/AQAAABxgFkTtPdlDQP01QmCui0EkA AAAJAAAAAAAgD0AAAAAAAAAAAAAgD0AAAAAAAAAAAIAAAAlAAAADAAAAAEAAAAlAAAADAAAAAgAAI BMAAAAZAAAAFoCAACzAQAAhgIAAMMBAACYJQAAKBsAANgCAAAYAQAAIQDwAAAAAAAAAAAAAACAPwA AAAAAAAAAAACAPwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJQAAAAwAAAAHAACAJQAA AAwAAAAAAACAJAAAACQAAAAAAIBBAAAAAAAAAAAAAIBBAAAAAAAAAAACAAAARgAAAOgAAADcAAAAR U1GKypAAAAkAAAAGAAAADMzy0JH4dOrMqPGKyW/2EI5AwlEY0XXQwhAAgYwAAAAJAAAAAEQwNs5ju M9AAAAAAAAAAAAAAAABQAAAEEAUgBJAEEATAAAADZAAoCEAAAAeAAAAAAAAP8BAAAAAQAAAAgAAAB FAHQAaABlAHIAbgBlAHQAcjwKPyIiIj5VNR0/IiIiPnIcJT8iIiI+Oe40PyIiIj4AwEQ/IiIiPuQ4 Tj8iIiI+qwpePyIiIj5y3G0/IiIiPgAAgD8AAAAAAAAAAAAAgD8AAAAAAAAAABIAAAAMAAAAAQAAA BgAAAAMAAAAAAAAABYAAAAMAAAAGAAAACgAAAAMAAAAAgAAAFIAAABwAQAAAgAAAPT///8AAAAAAA AAAAAAAACQAQAAAAAAAAcABABBAHIAaQBhAGwAAAAAAE0AbwBuAG8AdAB5AHAAZQA6AEEAcgBpAGE AbAAgAFIAZQBnAHUAbABhAHIAOgBWAGUAAABtMgkAAAAUAAAAgAUAAAAAAABQ////uAIAAEICAACA BQAABAUAAAIAAACAqgAAn7fgcAAEDwABAAAAAQAAAP////8ASQMAQAAAAP////98AAAAIAAAAAQAA AAgAAAA5NsSAJCvbTJfiNNwDAABAAAAFAAY2xIAAJ5tMgzcEgAAAPd3yNX2d/////9qFvV3y2Dndw AAFAAAAAAA3mDnd4kECo+Y728zIMDKd8CQswDwsW0yGgAAAAEAAADo2xIAAAAAAATmEgAJSOl3iDL od//////eYOd3Ha3Hd5jvbzOwhiUzmO9vMxAAAABU3BIA3nTIdyDAynfWCSHcAgAAAGR2AAgAAAAA JQAAAAwAAAACAAAAVAAAAHwAAABbAgAAtAEAAIQCAADCAQAAAQAAAAAAyEEAgLtBWwIAAMABAAAIA AAATAAAAAAAAAAAAAAAAAAAAP//////////XAAAAEUAdABoAGUAcgBuAGUAdAAIAAAAAwAAAAYAAA AGAAAABAAAAAYAAAAGAAAAAAAAACUAAAAMAAAADQAAgEYAAACYAAAAjAAAAEVNRisrQAAADAAAAAA AAAAIQAACQAAAADQAAAABEMDbAAAAAF4AAAAAAAAAt2WtPgIAAAACAAAAAgAAAAAAAEACAAAAARDA 2wAAAAAAAAD/CEABAywAAAAgAAAAARDA2wIAAAAAAAAAj+raQ0eo3UOfmQpEXAveQwABAAAVQAEAE AAAAAQAAAAAAAAAJAAAACQAAAAAAIA9AAAAAAAAAAAAAIA9AAAAAAAAAAACAAAAXwAAADgAAAADAA AAOAAAAAAAAAA4AAAAAAAAAAAAAQAFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAlAAAADAAAAAMAAAA lAAAADAAAAAUAAIBXAAAAJAAAALQBAAC6AQAALAIAAL4BAAACAAAAXhu2G6ciwhslAAAADAAAAAcA AIAlAAAADAAAAAAAAIAkAAAAJAAAAAAAgEEAAAAAAAAAAAAAgEEAAAAAAAAAAAIAAAAoAAAADAAAA AMAAABGAAAAJAEAABgBAABFTUYrKkAAACQAAAAYAAAAMzPLQgAAAAAAAAAAJb/YQiACC0Qm/LVDCE ACBjAAAAAkAAAAARDA26uqKj4AAAAAAAAAAAAAAAAFAAAAQQBSAEkAQQBMAAAANkACgMAAAAC0AAA AAAAA/wEAAAABAAAADgAAADEAOQAyAC4AMQA2ADgALgAxAC4AMAAvADIANAAiYhM+mpmZPs1Mcj6a mZk+vJuoPpqZmT4REdg+mpmZPmbG7z6amZk+3p0PP5qZmT6JWCc/mpmZPjMTPz+amZk+3u1KP5qZm T6JqGI/mpmZPjODbj+amZk+7x6DP5qZmT5EDIk/mpmZPprplD+amZk+AACAPwAAAAAAAAAAAACAPw AAAAAAAAAAEgAAAAwAAAABAAAAGAAAAAwAAAAAAAAAFgAAAAwAAAAYAAAAKAAAAAwAAAACAAAAUgA AAHABAAACAAAA7v///wAAAAAAAAAAAAAAAJABAAAAAAAABwAEAEEAcgBpAGEAbAAAAAAATQBvAG4A bwB0AHkAcABlADoAQQByAGkAYQBsACAAUgBlAGcAdQBsAGEAcgA6AFYAZQAAAG0yDgAAAAcAAAA0A gAAABsAAJ7///+UAwAAVAMAADQCAADEAQAAAgAAAMAfAACft+BwAAQAAAEAAAABAAAA/////wAhAQ BAAAAA/////9wAAABAAAAABAAAACAAAAAYsG0yYK9tMl+I03ABAAEAAAAUABjbEgAAnm0yDNwSAAA A93fI1fZ3/////2oW9XfLYOd3AAAUAAAAAADeYOd3iQQKkJjvbzMgwMp3qD+zAGCzbTI0AAAAAgAA AOjbEgAAAAAABOYSAAlI6XeIMuh3/////95g53cdrcd3mO9vM7CGJTOY728zEAAAAFTcEgDedMh3I MDKd9YJIdwCAAAA ZHYACAAAAAAlAAAADAAAAAIAAABUAAAAoAAAADsCAAB7AQAAqAIAAI8BAAABAAAAAADIQQCAu0E7A gAAjAEAAA4AAABMAAAAAAAAAAAAAAAAAAAA//////////9oAAAAMQA5ADIALgAxADYAOAAuADEALg AwAC8AMgA0AAkAAAAJAAAACQAAAAUAAAAJAAAACQAAAAkAAAAFAAAACQAAAAUAAAAJAAAABQAAAAk AAAAAAAAAJQAAAAwAAAANAACARgAAAJgAAACMAAAARU1GKytAAAAMAAAAAAAAAAhAAAJAAAAANAAA AAEQwNsAAAAAXgAAAAAAAAC3Za0+AgAAAAIAAAACAAAAAAAAQAIAAAABEMDbAAAAAAAAAP8IQAEDL AAAACAAAAABEMDbAgAAAAAAAACPWqNDHOLcQ9dby0NHqN1DAAEAABVAAQAQAAAABAAAAAAAAAAkAA AAJAAAAAAAgD0AAAAAAAAAAAAAgD0AAAAAAAAAAAIAAABfAAAAOAAAAAMAAAA4AAAAAAAAADgAAAA AAAAAAAABAAUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACUAAAAMAAAAAwAAACUAAAAMAAAABQAAgFcA AAAkAAAARQEAALgBAACYAQAAvQEAAAIAAABsFJ0bbBm2GyUAAAAMAAAABwAAgCUAAAAMAAAAAAAAg CQAAAAkAAAAAACAQQAAAAAAAAAAAACAQQAAAAAAAAAAAgAAACgAAAAMAAAAAwAAAEYAAADAAAAAtA AAAEVNRisqQAAAJAAAABgAAAAzM8tCAAAAAAAAAAAlv9hCCm+oQ/ILzEMIQAIGMAAAACQAAAABEMD bq6oqPgAAAAAAAAAAAAAAAAUAAABBAFIASQBBAEwAAAA2QAKAXAAAAFAAAAAAAAD/AQAAAAEAAAAE AAAAZQB0AGgAMABEhHM+zcxMPnc3qT7NzEw+zezAPs3MTD4iYvA+zcxMPgAAgD8AAAAAAAAAAAAAg D8AAAAAAAAAABIAAAAMAAAAAQAAABgAAAAMAAAAAAAAABYAAAAMAAAAGAAAACUAAAAMAAAAAgAAAF QAAABkAAAAaQEAAJ0BAACIAQAAsQEAAAEAAAAAAMhBAIC7QWkBAACuAQAABAAAAEwAAAAAAAAAAAA AAAAAAAD//////////1QAAABlAHQAaAAwAAkAAAAFAAAACQAAAAAAAAAlAAAADAAAAA0AAIBGAAAA zAAAAMAAAABFTUYrK0AAAAwAAAAAAAAAKkAAACQAAAAYAAAAMzPLQgAAAAAAAAAAJb/YQvgi3kMIb 8xDCEACBjAAAAAkAAAAARDA26uqKj4AAAAAAAAAAAAAAAAFAAAAQQBSAEkAQQBMAAAANkACgFwAAA BQAAAAAAAA/wEAAAABAAAABAAAAGUAdABoADEARIRzPs3MTD53N6k+zcxMPs3swD7NzEw+ImLwPs3 MTD4AAIA/AAAAAAAAAAAAAIA/AAAAAAAAAAASAAAADAAAAAEAAAAYAAAADAAAAAAAAAAWAAAADAAA ABgAAAAlAAAADAAAAAIAAABUAAAAZAAAANQBAACeAQAA8QEAALIBAAABAAAAAADIQQCAu0HUAQAAr wEAAAQAAABMAAAAAAAAAAAAAAAAAAAA//////////9UAAAAZQB0AGgAMQAJAAAABQAAAAkAAAAAAA AAJQAAAAwAAAANAACARgAAAJQBAACIAQAARU1GKytAAAAMAAAAAAAAACpAAAAkAAAAGAAAADMzy0I AAAAAAAAAACW/2ELBkAVEmZ/qQwhAAgYwAAAAJAAAAAEQwNurqio+AAAAAAAAAAAAAAAABQAAAEEA UgBJAEEATAAAADZAAoAkAQAAGAEAAAAAAP8BAAAAAQAAABgAAAAxADkAMgAuADEANgA4AC4AMQAuA DgALQAxADkAMgAuADEANgA4AC4AMQAuADEANQA5jmM9MzOzPjnOFz4zM7M+5Lh2PjMzsz7H0ao+Mz OzPhyHwj4zM7M+cvzxPjMzsz7kuBA/MzOzPo5zKD8zM7M+OU40PzMzsz7kCEw/MzOzPo7jVz8zM7M +OZ5vPzMzsz6O030/MzOzPhzHij8zM7M+cqSWPzMzsz7HgaI/MzOzPhxvqD8zM7M+cky0PzMzsz7H KcA/MzOzPhwHzD8zM7M+cvTRPzMzsz7H0d0/MzOzPhy/4z8zM7M+cpzvPzMzsz4AAIA/AAAAAAAAA AAAAIA/AAAAAAAAAAASAAAADAAAAAEAAAAYAAAADAAAAAAAAAAWAAAADAAAABgAAAAlAAAADAAAAA IAAABUAAAA3AAAABwCAADqAQAA2AIAAP4BAAABAAAAAADIQQCAu0EcAgAA+wEAABgAAABMAAAAAAA AAAAAAAAAAAAA//////////98AAAAMQA5ADIALgAxADYAOAAuADEALgA4AC0AMQA5ADIALgAxADYA OAAuADEALgAxADUACQAAAAkAAAAJAAAABQAAAAkAAAAJAAAACQAAAAUAAAAJAAAABQAAAAkAAAAGA AAACQAAAAkAAAAJAAAABQAAAAkAAAAJAAAACQAAAAUAAAAJAAAABQAAAAkAAAAAAAAAJQAAAAwAAA ANAACARgAAAPQAAADoAAAARU1GKytAAAAMAAAAAAAAACpAAAAkAAAAGAAAADMzy0IAAAAAAAAAACW /2ELX7wFE7fydQwhAAgYwAAAAJAAAAAEQwNtyHEc+AAAAAAAAAAAAAAAABQAAAEEAUgBJAEEATAAA ADZAAoCEAAAAeAAAAAAAAP8BAAAAAQAAAAgAAABMAE8AQwAgAFoAbwBuAGUABvsZP97dnT4iqjU/3 t2dPiJiXD/e3Z0+ZiqAP97dnT6fFIc/3t2dPp9Ilj/e3Z0+LiCkP97dnT6897E/3t2dPgAAgD8AAA AAAAAAAAAAgD8AAAAAAAAAABIAAAAMAAAAAQAAABgAAAAMAAAAAAAAABYAAAAMAAAAGAAAACgAAAA MAAAAAgAAAFIAAABwAQAAAgAAAOv///8AAAAAAAAAAAAAAACQAQAAAAAAAAcABABBAHIAaQBhAGwA AAAAAE0AbwBuAG8AdAB5AHAAZQA6AEEAcgBpAGEAbAAgAFIAZQBnAHUAbABhAHIAOgBWAGUAAABtM g4AAAAlAAAAIAoAAAAAAADM/v//VAQAAIQDAAAgCgAARgkAAAIAAACQDAIAn7fgcABpLgABAAAAAQ AAAP////8AxAkAQAAAAP/////aAAAAQAAAAAQAAAAgAAAAVLBtMpCvbTJfiNNwEgABAAAAFAAY2xI AAJ5tMgzcEgAAAPd3yNX2d/////9qFvV3y2DndwAAFAAAAAAA3mDnd4kECpGY728zIMDKd9h9cTIw s20yLgAAAAIAAADo2xIAAAAAAATmEgAJSOl3iDLod//////eYOd3Ha3Hd5jvbzOwhiUzmO9vMxAAA ABU3BIA3nTIdyDAynfWCSHcAgAAAGR2AAgAAAAAJQAAAAwAAAACAAAAVAAAAHwAAABFAgAASgEAAJ 4CAABhAQAAAQAAAAAAyEEAgLtBRQIAAF0BAAAIAAAATAAAAAAAAAAAAAAAAAAAAP//////////XAA AAEwATwBDACAAWgBvAG4AZQALAAAADwAAAA4AAAAFAAAADAAAAAsAAAALAAAAAAAAACUAAAAMAAAA DQAAgEYAAAAAAQAA9AAAAEVNRisrQAAADAAAAAAAAAAqQAAAJAAAABgAAAAzM8tCAAAAAAAAAAAlv 9hC1+8BRKl4AkQIQAIGMAAAACQAAAABEMDbchxHPgAAAAAAAAAAAAAAAAUAAABBAFIASQBBAEwAAA A2QAKAkAAAAIQAAAAAAAD/AQAAAAEAAAAJAAAATABPAEMAMQAgAFoAbwBuAGUAdyMMP97dnT6U0ic /3t2dPpSKTj/e3Z0+P31yP97dnT4uFoc/3t2dPmYAjj/e3Z0+ZjSdP97dnT71C6s/3t2dPoPjuD/e 3Z0+AACAPwAAAAAAAAAAAACAPwAAAAAAAAAAAAASAAAADAAAAAEAAAAYAAAADAAAAAAAAAAWAAAAD AAAABgAAAAlAAAA DAAAAAIAAABUAAAAhAAAAD8CAAAYAgAAowIAAC8CAAABAAAAAADIQQCAu0E/AgAAKwIAAAkAAABMA AAAAAAAAAAAAAAAAAAA//////////9gAAAATABPAEMAMQAgAFoAbwBuAGUAAgALAAAADwAAAA4AAA ALAAAABQAAAAwAAAALAAAACwAAAAAAAAAlAAAADAAAAA0AAIBGAAAAHAAAABAAAABFTUYrK0AAAAw AAAAAAAAATAAAAGQAAABcAAAAOwEAAPcCAABXAgAAXAAAADsBAACcAgAAHQEAACkAqgAAAAAAAAAA AAAAgD8AAAAAAAAAAAAAgD8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACIAAAAMAAAA/ ////0YAAAAcAAAAEAAAAEVNRisCQAAADAAAAAAAAAAOAAAAFAAAAAAAAAAQAAAAFAAAAA== 2003-11-09T10:53:13 2003-12-23T08:58:38 2003-11-09T13:14:48 2003-11-09T10:53:13 9 295 34 0 0 0 0 0 1 1 0 0 0 1 1 1 0.25 0.25 0.25 0.25 1 1 1 0 0.01 0 1 0 2 0 0 0 2 0 1 0 1 0 1 0 0 0 0 0 0 0 0 0 1 0 0.5 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 32 32 0 0 8 8 0 0 0 0 1 0.5 0.5 0 0 0 0 1 2 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0.125 0.125 0.25 0.25 0.375 0.375 0.125 0.125 0.66666666666667 0.66666666666667 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0.16666666666667 0 0 0 0 0 0 0 0 0 -1.2 0 0 1 0 1 1 1 0 0.01 0 0 0 2 0 0 0 2 0 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0.5 0 0 0 0 0 -1.2 0 0 0 0 1 1 1 0 0.01 0 0 0 2 0 0 0 2 0 1 0 0 0 1 0 0 0 0 0 1 1 1 0 0.055555555555556 0.055555555555556 0.055555555555556 0.055555555555556 1 0 0.5 0 0 1 1 1 0 0 4 23 0 2 0 0 0 2 0 1 0 0 0 1 0 0 0 0 0 0.055555555555556 0.055555555555556 0 0 2 0 0.5 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 0 0 0 0 0 0 0 0 0 0 0 4 0 0 1 0 0.125 0 0 0 0 0 0 1 1 1 1 0.01 0 1 0 2 0 0 0 2 0 0 1 1 0 1 0 0 0 0 0 0 0 0 0 1 0 0.16666666666667 0 0 0 0 0 0 1 1 1 0 0.055555555555556 0.055555555555556 0.055555555555556 0.055555555555556 1 2 0.5 0 0 0.0033333333333333 0 1 0 2 0 0 0 2 0 0 1 1 0 1 0 0 0 0 0 0 0 0 0 1 0 0.11111111111111 0 0 0 0 0 0 1 1 1 1 0.01 0 1 0 2 0 0 0 2 0 1 0 1 0 1 0 0 0 0 0 0 0 0 0 1 0 0.16666666666667 0 0 0 0 0 0 1 1 1 1 0.01 0 1 0 2 0 0 0 2 0 1 0 1 0 1 0 0 0 0 0 0 0 0 0 1 0 0.16666666666667 0 0 0 0 0 0 1 1 1 1 0.01 0 1 0 2 0 0 0 2 0 14 1 1 0 1 0 0 0 0 0 0 0 0 0 1 0 0.16666666666667 0 0 0 0 0 0 1 1 1 1 0.01 0 1 0 2 0 0 0 2 0 1 0 1 0 1 0 0 0 0 0 0 0 0 0 1 0 0.16666666666667 0 0 0 0 0 0 1 1 1 1 0.01 0 1 0 2 0 0 0 2 0 1 0 1 0 1 0 0 0 0 0 0 0 0 0 1 0 0.16666666666667 0 0 0 0 0 0 1 1 1 1 0.01 0 1 0 2 0 0 0 2 0 15 15 1 0 1 0 0 0 0 0 0 0 0 0 1 0 0.16666666666667 0 0 0 0 0 0 1 1 1 1 0.01 0 1 0 2 0 0 0 2 0 18 1 1 0 1 0 0 0 0 0 0 0 0 0 1 0 0.16666666666667 0 0 0 0 0 0 1 1 1 1 0.01 0 1 0 2 0 0 0 2 0 15 18 1 0 1 0 0 0 0 0 0 0 0 0 1 0 0.16666666666667 0 0 0 0 0 0 1 1 1 1 0.01 0 1 0 2 0 0 0 2 0 14 1 1 0 1 0 0 0 0 0 0 0 0 0 1 0 0.16666666666667 0 0 0 0 0 0 1 1 1 1 0.01 0 1 0 2 0 0 0 2 0 15 1 1 0 1 0 0 0 0 0 0 0 0 0 1 0 0.16666666666667 0 0 0 0 0 0 1 1 1 1 0.01 0 1 0 2 0 0 0 2 0 18 14 1 0 1 0 0 0 0 0 0 0 0 0 1 0 0.16666666666667 0 0 0 0 0 0 1 1 1 1 0.01 0 1 0 2 0 0 0 2 0 15 18 1 0 1 0 0 0 0 0 0 0 0 0 1 0 0.16666666666667 0 0 0 0 0 0 1 1 1 1 0.01 15 1 0 2 0 0 0 2 0 #efefef 1 1 15 1 0 0 0 0 0 0 15 0 0 1 0 0.16666666666667 0 0 0 0 0 0 1 1 1 1 0.01 1 1 0 2 0 0 0 2 0 1 0 1 15 1 0 0 0 0 0 0 15 0 0 1 0 0.16666666666667 0 0 0 0 0 0 1 1 1 1 0.01 14 1 0 2 0 0 0 2 0 15 #fafafa 1 15 1 0 0 0 0 0 0 14 0 0 1 0 0.16666666666667 0 0 0 0 0 0 1 1 1 1 0.01 15 1 0 2 0 0 0 2 0 1 15 1 15 1 0 0 0 0 0 0 14 0 0 1 0 0.16666666666667 0 0 0 0 0 0 1 1 1 1 0.01 0 1 0 2 0 0 0 2 0 0 1 1 0 1 0 0 0 0 0 0 0 0 0 1 0 0.16666666666667 0 0 0 0 0 0 1 1 1 1 0.01 0 1 0 2 0 0 0 2 0 0 1 1 0 1 0 0 0 0 0 0 1 0 0 1 0 0.16666666666667 0 0 0 0 0 0 1 1 1 0 0.055555555555556 0.055555555555556 0.055555555555556 0.055555555555556 1 0 0.5 0 0 0 0 0 0 1 0 0.11111111111111 0 0 0 0 0 0 0 0 0 -1.2 0 0 1 0 1 1 1 0 0.0033333333333333 0 1 0 2 0 0 0 2 0 1 1 1 0 0.0033333333333333 0 1 0 2 0 0 0 2 0 0.055555555555556 0.055555555555556 0.055555555555556 0.055555555555556 1 0 0.5 0 0 0 0 0 0 1 0 0.11111111111111 0 0 0 0 0 0 0 0 0 -1.2 0 0 1 0 0 0 1 0 0.027777777777778 0.027777777777778 0.027777777777778 0.027777777777778 1 0 0.5 0 0 0 0 0 0 1 0 0.11111111111111 0 0 0 0 0 0 0 0 0 -1.2 0 0 1 0 1 1 1 0 0.055555555555556 0.055555555555556 0.055555555555556 0.055555555555556 1 15 0.5 0 0 0 0 0 0 1 0 0.11111111111111 0 0 0 0 0 0 0 0 0 -1.2 0 0 1 0 1 1 1 0 0.0033333333333333 0 1 0 2 0 0 0 2 0 0.055555555555556 0.055555555555556 0.055555555555556 0.055555555555556 1 2 0.5 0 0 0 0 0 0 1 0 0.11111111111111 0 0 0 0 0 0 0 0 0 -1.2 0 0 1 0 1 1 1 0 15 1 1 0 1 0 0 0 0 0 1 1 1 0 0.0033333333333333 0 1 0 2 0 0 0 2 0 14 15 1 0 1 0 0 0 0 0 0 0 0 0 1 0 0.11111111111111 0 0 0 0 0 0 0 0 0 -1.2 0 0 1 0 1 1 1 0 18 15 1 0 1 0 0 0 0 0 1 1 1 0 20 14 1 0 1 0 0 0 0 0 1 1 1 0 3 15 1 0 1 0 0 0 0 0 0.0033333333333333 3 1 0 2 0 0 1 2 0 1 1 1 0 1 #8a8aff 31 0 1 0 0 0 0 0 0.0033333333333333 0 0 0 2 0 0 0 2 0 1 1 1 0 15 18 1 0 1 0 0 0 0 0 0.0016666666666667 0 1 0 2 0 0 0 2 0 2 0 1 0 2 Visio Network Solutions
http://officeupdate.com/visio/
0 0 11 8.5 0.125 -0.125 1 1 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 0 0 0 0.125 0.125 0.25 0.25 0.375 0.375 0.125 0.125 0.66666666666667 0.66666666666667 0 0 0 0 Co&lor Schemes... 0 0 0 Black & White Network 255 0 1 1 0 0 1 1 Network 0 Apple 255 0 1 1 0 0 1 1 Apple 0 Digital 255 0 1 1 0 0 1 1 Digital 0 Cray 255 0 1 1 0 0 1 1 Cray 0 IBM 255 0 1 1 0 0 1 1 IBM 0 Connector 255 0 1 1 0 0 1 1 Connector 0 6.2 4.3 2.5 2.6 1.25 1.3 0 0 0 0 3 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 2.5 0 2.5 2.6 0 2.6 0 0 6.2035714285714 3.65 2.35 0.7 1.175 0.35 0 0 0 0 7 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 2.35 0 2.35 0.7 0 0.7 0 0 2.05 4.4392857142857 2.3 1.75 1.15 0.875 0 0 0 0 0 0 0 0 0 0 0 0.875 0 0 0 0 0.8117643 1.75 0 0 0 0 1.48833 1.75 0 0 0 0 0.8117643 0 0 0 0 0 1.4882357 0 0 0 0 0 2.3 0.875 0 0 0 0 0 0 0 0 1 0 0.16666666666667 0 0 0 0 0 0 0 0 0 0 0.33823529411765 0.45139244650857 1.15 0.19195334392518 0.70682204248263 0.01660909406747 0 0.61848739495799 1.9617647058824 0.45139244650857 1.5931779575174 0.016609094067465 0 0.61848739495799 2.3 0.875 2.1951125414236 0.52912588091909 0 0.61848739495799 1.9617647058824 1.2986075534914 2.1951125414236 1.2208741190809 0 0.61848739495799 1.15 1.5580466560748 1.5931779575174 1.7333909059325 0 0.61848739495799 0.33823529411765 1.2986075534914 0.70682204248263 1.7333909059325 0 0.61848739495799 0 0.875 0.10488745857643 1.2208741190809 0 0.61848739495799 0.33823529411765 0.45139244650857 0.10488745857643 0.52912588091909 0 0.61848739495799 Internet 4.03125 4.25 0.0875 0.7 0.04375 0.35 0 0 0 0 0 0 0 0 0 0 0.125 -0.2 0.04375 0.35 4 2 0 Reposition Text 0 0 0 1 0 0 0.30625 0.21875 0 0 0 0 0.30625 0.525 0 0 0 0 0 0.525 0 0 0 0 0.04921875 0 0 0 0 0 0.2625 0.91875 0 0 0 0 0.30625 0.546875 0.4375 1.09375 0.21875 0.546875 0 0 0 0 0 #d0624f 15 1 0 1 0 0 0 0 0 0.21875 0.546875 0.4375 1.09375 0.21875 0.546875 0 0 0 0 0 0 0 0.4375 0.4375 0.4375 1.09375 0 0.65625 0 0 0.2625 0.57421875 0.525 0.9296875 0.2625 0.46484375 0 0 0 0 0 0.2625 0.46484375 0.525 0.9296875 0.2625 0.46484375 0 1 0 0 0 0 0.4375 0.0875 0.4375 0.1421875 0.4921875 1 0 0 0 0.1421875 0.4921875 0.196875 0.546875 1 0 0 0 0.196875 0.546875 0.2515625 0.6015625 1 0 0 0 0.2515625 0.6015625 0.30625 0.65625 1 0 0 0 0.30625 0.65625 0.3609375 0.7109375 1 0 0 0 0.3609375 0.7109375 0.415625 0.765625 1 0 0 0 0.415625 0.765625 0.4703125 0.8203125 1 0 0 0 0 0.328125 0.0875 0.328125 0.1421875 0.3828125 1 0 0 0 0.1421875 0.3828125 0.196875 0.4375 1 0 0 0 0.196875 0.4375 0.2515625 0.4921875 1 0 0 0 0.2515625 0.4921875 0.30625 0.546875 1 0 0 0 0.30625 0.546875 0.3609375 0.6015625 1 0 0 0 0.3609375 0.6015625 0.415625 0.65625 1 0 0 0 0.415625 0.65625 0.4703125 0.7109375 1 0 0 0 0.4703125 0.7109375 0.525 0.765625 1 0 0 0 0 0.21875 0.0875 0.21875 0.1421875 0.2734375 1 0 0 0 0.1421875 0.2734375 0.196875 0.328125 1 0 0 0 0.196875 0.328125 0.2515625 0.3828125 1 0 0 0 0.2515625 0.3828125 0.30625 0.4375 1 0 0 0 0.30625 0.4375 0.3609375 0.4921875 1 0 0 0 0.3609375 0.4921875 0.415625 0.546875 1 0 0 0 0.415625 0.546875 0.4703125 0.6015625 1 0 0 0 0.4703125 0.6015625 0.525 0.65625 1 0 0 0 0 0.109375 0.0875 0.109375 0.1421875 0.1640625 1 0 0 0 0.1421875 0.1640625 0.196875 0.21875 1 0 0 0 0.196875 0.21875 0.2515625 0.2734375 1 0 0 0 0.2515625 0.2734375 0.30625 0.328125 1 0 0 0 0.30625 0.328125 0.3609375 0.3828125 1 0 0 0 0.3609375 0.3828125 0.415625 0.4375 1 0 0 0 0.415625 0.4375 0.4703125 0.4921875 1 0 0 0 0.4703125 0.4921875 0.525 0.546875 1 0 0 0 0 0 0.0875 0 0.1421875 0.0546875 1 0 0 0 0.1421875 0.0546875 0.196875 0.109375 1 0 0 0 0.196875 0.109375 0.2515625 0.1640625 1 0 0 0 0.2515625 0.1640625 0.30625 0.21875 1 0 0 0 0.30625 0.21875 0.3609375 0.2734375 1 0 0 0 0.3609375 0.2734375 0.415625 0.328125 1 0 0 0 0.415625 0.328125 0.4703125 0.3828125 1 0 0 0 0.4703125 0.3828125 0.525 0.4375 1 0 0 0 0.1421875 0.4921875 0.1421875 0.6015625 1 0 0 0 0.1421875 0.2734375 0.1421875 0.3828125 1 0 0 0 0.1421875 0.0546875 0.1421875 0.1640625 1 0 0 0 0.196875 0 0.196875 0.109375 1 0 0 0 0.196875 0.4375 0.196875 0.546875 1 0 0 0 0.196875 0.21875 0.196875 0.328125 1 0 0 0 0.2515625 0.6015625 0.2515625 0.7109375 1 0 0 0 0.2515625 0.3828125 0.2515625 0.4921875 1 0 0 0 0.2515625 0.1640625 0.2515625 0.2734375 1 0 0 0 0.30625 0.109375 0.30625 0.21875 1 0 0 0 0.30625 0.546875 0.30625 0.65625 1 0 0 0 0.30625 0.328125 0.30625 0.4375 1 0 0 0 0.3609375 0.7109375 0.3609375 0.8203125 1 0 0 0 0.3609375 0.4921875 0.3609375 0.6015625 1 0 0 0 0.3609375 0.2734375 0.3609375 0.3828125 1 0 0 0 0.415625 0.21875 0.415625 0.328125 1 0 0 0 0.415625 0.65625 0.415625 0.765625 1 0 0 0 0.415625 0.4375 0.415625 0.546875 1 0 0 0 0.4703125 0.6015625 0.4703125 0.7109375 1 0 0 0 0.4703125 0.3828125 0.4703125 0.4921875 1 0 0 0 0.4703125 0.8203125 0.4703125 0.9296875 1 0 0 0 0.4703125 0.8203125 0.525 0.875 0.04375 0.328125 0.0875 0.65625 0.04375 0.328125 0 0 0 0 0 #dc7e5f 15 1 0 1 0 0 0 0 0 0.04375 0.328125 0.0875 0.65625 0.04375 0.328125 0 0 0 0 0 0 0 0 0.65625 0.0875 0.65625 0.0875 0 0 0 0.35 0.896875 0.4375 0.48125 0.21875 0.240625 0 0 0 0 0 0.21875 0.240625 0.4375 0.48125 0.21875 0.240625 0 0 0 0 0 0 0 0.4375 0.4375 0.4375 0.48125 0 0.04375 0 0 0.04375 0.678125 0.175 0.04375 0.0875 0.021875 0 0 0 0 0 0.0875 0.021875 0.175 0.04375 0.0875 0.021875 0 0 0 0 0 0 0.04375 0 0 0.175 0 0.175 0.04375 0 0.04375 0.2625 0.91875 0.6125 0.4375 0.30625 0.21875 0 0 0 0 0 0.30625 0.21875 0.6125 0.4375 0.30625 0.21875 0 0 0 0 0 0 0 0.4375 0.4375 0.6125 0.4375 0.175 0 0 0 0.04375 0.328125 0.0875 0.4375 0.04375 0.21875 0 0 0 0 0 0.04375 0.21875 0.0875 0.4375 0.04375 0.21875 0 1 0 0 0 0.0875 0.4375 0 0.4375 1 0 0 0 0.0875 0.328125 0 0.328125 1 0 0 0 0.0875 0.21875 0 0.21875 1 0 0 0 0.0875 0.109375 0 0.109375 1 0 0 0 0.0875 0 0 0 0.2625 0.56875 0.6125 1.1375 0.30625 0.56875 0 0 0 0 0 0.30625 0.56875 0.6125 1.1375 0.30625 0.56875 0 0 0 0 0 0.04375 0 0.04375 0.65625 0 0.65625 0 0.7 0.4375 1.1375 0.6125 1.1375 0.6125 1.09375 0.56875 1.05 0.56875 0.4375 0.13125 0 0.04375 0 0 0 0.62969292634722 0.25555555555556 -0.125 0.32777777777778 0 0 0 0 0 0 0 0 0 0 0.31484646317361 0.12777777777778 0.62969292634722 0.25555555555556 0.31484646317361 0.12777777777778 0 0 0 0 0 1 0 0.16666666666667 0 0 0 0 0 0 1 0 1 0 0 0 0.62969292634722 0 0.62969292634722 0.25555555555556 0 0.25555555555556 0 0 Firewall 6.1285714285714 4.4178571428571 1.5 0.25 0.75 0.125 -7.4014868308344E-17 0 0 0 0 0 0 0 0 0 0.75 0.125 1.5 0.25 0.75 0.125 0 0.055555555555556 0.055555555555556 0.055555555555556 0.055555555555556 1 15 0.5 0 0 0.25005 0.5 0.25005 0.125 0 0 1 Connect To Network Device 0.49995 -0.25 0.49995 0.125 0 0 1 Connect To Network Device 1.00005 -0.25 1.00005 0.125 0 0 1 Connect To Network Device 0.75 0.5 0.75 0.125 0 0 1 Connect To Network Device 1.249995 0.5 1.249995 0.125 0 0 1 Connect To Network Device 0.75 -0.024999999999998 0.75 0.125 0 0 1 Connect To Network Device 0.625 0.125 0.625 0.125 0 0 1 Connect To Network Device 0.875 0.125 0.875 0.125 0 0 1 Connect To Network Device 1 0.0625 0.125 0 0 0 0 1.5 0.125 0 0 0 0 0 0 0 0 0.0625 0.015625 0.0625 0.234375 0.015625 0.125 -1.5707963267949 2.3 0.0625 0.015625 0.109375 0.125 -1.5707963267949 2.3 0 0 0 0 0.0625 0.25 1.4375 0.25 1.4375 0 1.5 0.125 -1.5707963267949 2 0.0625 0 0.0625 0.25 0 0.125 -1.5707963267949 2 1 0 0 0 0.25005 0.5 0.25005 0.125 0.75 0.125 1 0 0 0 0.49995 -0.25 0.49995 0.125 0.75 0.125 1 0 0 0 1.00005 -0.25 1.00005 0.125 0.75 0.125 1 0 0 0 0.75 0.5 0.75 0.125 0.75 0.125 1 0 0 0 1.249995 0.5 1.249995 0.125 0.75 0.125 1 0 0 0 0.75 -0.024999999999998 0.75 0.125 0.75 0.125 1 0 0 0 0.625 0.125 0.625 0.125 0.75 0.125 1 0 0 0 0.875 0.125 0.875 0.125 0.75 0.125 4.8674107142857 4.4214285714286 1.1473436629307 0 0.57367183146537 0 -0.0062256005017924 0 0 0 4.29375 4.425 5.4410714285714 4.4178571428571 0 0 0 0 0 5 0.57367183146537 0 0.55555555555556 0.24444444444444 0.27777777777778 0.12222222222222 0.0062256005017924 0 0 0 1 0 0 0 3 2 2 2 0 0 0 0.57367183146537 0 0.57367183146537 0 0 0 0 Curve Position 0.57367183146537 0 0 0 0 0 1 0 0 0 0 0 1.1473436629307 0 0.57367183146537 0 0 1 6.1571428571429 4.9071428571429 1.4 0.5 0.7 0.25 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0.16666666666667 0 0 0 0 0 0 0 0 0 0 0 0 1.4 0 1.4 0.5 0 0.5 0 0 192.168.1.0/24 3.59375 4.4321428571428 0.78762956498131 0 0.39381478249066 0 -0.018138600054222 0 0 0 3.2 4.4392857142857 3.9875 4.425 0 0 0 0 0 5 0 0 0 1 0 0 0 3 2 2 2 0 0 0 0.39381478249066 0 0.55555555555556 0.24444444444444 0.27777777777778 0.12222222222222 0.018138600054222 0.39381478249066 0 0.39381478249066 0 0 0 0 Curve Position 0.39381478249066 0 0 0 0 0 1 0 0 0 0 0 0.78762956498131 0 0.39381478249066 0 0 1 3.7 4.6 0.8 0.3 0.4 0.15 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0.16666666666667 0 0 0 0 0 0 0 0 0 0 0 0 0.8 0 0.8 0.3 0 0.3 0 0 eth0 4.7571428571429 4.5928571428571 0.8 0.3 0.4 0.15 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0.16666666666667 0 0 0 0 0 0 0 0 0 0 0 0 0.8 0 0.8 0.3 0 0.3 0 0 eth1 6.8928571428571 3.8857142857143 3.3 0.6 1.65 0.3 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0.16666666666667 0 0 0 0 0 0 0 0 0 -1.2 0 0 0 0 0 0 0 0 0 0 3.3 0 3.3 0.6 0 0.6 0 0 192.168.1.8-192.168.1.15 6.15 5.35 2.1 0.5 1.05 0.25 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0.19444444444444 0 0 0 0 0 0 0 0 0 0 0 0 2.1 0 2.1 0.5 0 0.5 0 0 LOC Zone 6.15 3.45 2.1 0.5 1.05 0.25 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0.19444444444444 0 0 0 0 0 0 0 0 0 0 0 0 2.1 0 2.1 0.5 0 0.5 0 0 LOC1 Zone 1 1 0 1 1 9 295 34 0 0.33 10 0 10 1 10 2 10 3 10 4 shorewall-docs-xml-5.0.15/images/KVM1.png0000644000000000000000000006614013020330134016511 0ustar rootrootPNG  IHDR3ݦbKGDtIME :| IDATxyXTe{؆ME@MAs^5KS-4L5lVVjiFhK*j.(&"| #Ü\Wq3tDVaȌde@~~eP5hx%26v3Ec!"""0CDDDa,GY[ *Z f,APN=ˠ*8qb7bb*]Qn&"""h 3DDDdfȢ1Ec!"""0CDDDa, Y4"""h 3DDDdfȢ1Ec!"""0CDDDa, Y4"""h 3DDDdfȢ1Ec!"""0CDDDa, Y4"""h 3DDDdfȢ1Ec!"""0CDdE"""ЧO* *eZ޽{UޟFJh;BVC8vX[Z˫ǐe"""бcG888m۶t tfr/l.o̓Y}bϞ=-;`߾}X|9݋ٳgWi_}Qo%D_~%駟 ..{ũS0f̘2Է!ǐe>C$$$`߾}8s +oQpӱp dB 8qիW 4iR?z/Oj9tۗYG2ZY=-oռ|r3fLˤIvoU?@V~̿&?ᇏ%$dowONOO{N\]]U*W^սVf^gggUV7o RϯVM 9qDy7nVn2ZQ=.sq ]ttcƌ˗Wx\ӧO>̤瑚-3F֠AL4 dT*]*m^ƐZ+ezFaݺut^cccyfL2š1n ʕ+?#D7oFˬ3~x|78{,1mڴ2ܱcnܸz OBUjI,͛nݺv]:C A@[:T֭[Q^rm۶ ."6lyаaC,^u[ƐZ+evލ+W躊7!!뫷ӧc֬YPՕNaUVСCѣG? ))0۷gܼygy;wI_^=< j cȝ)999UiРZ<6lXf ua@=tӎ9#GSN8t|||ʬoCj5;"##+o/DjDŽ ʌK$c12е|g^{ 3G}w𝃃llJxKÓY@իqAT*k@ᗢ ӯ_?w߿eRU@9sЦMݴٳgѸqc)}Րs!t ?t?W}5/T>#Cx饗燴4凙K.@iI.}WOBd5 fB߾}ѿ]@un?D޽1zhjMĶm JsYO2Yk}}}^zaŊyĐJDt|6mL<@apڵK4~ A`` tK7 999AAA8pt邰0x{{Wggg۰̙3s-eZ޾+:f}۾z|}}___T;.aa2 zuT Gĉ݈9XfFcgO||ZaҤwL]a!2# 3փatDDDDa, Y4"""h 3DDDdfȢ1Ec!"""0CDDDa, Y4"""h 3DDDdfȢ1Ec!"""0CDDDa, Y4"""h 3DDDdfȢ1Ec!"""0CDDDa, Y4"""h 3DDDdfȢ1ES"Ν+R.@)Pa)]HNNVt9888""f hj-[[t("f ԨQClÆMA]=aȄT* >wQ"0Cd&23S" ˤhTAxi6LE\QY?FnaHaYYi=KypQ\t)DVLD LEl]!CG:0C4UiJCR4;ǧ5 Wd0U3"dd">/h4.WxB8 s6m sQ\[BaĪdΝ;RrdZNhz)j)dƏA(Fa!2!CLVVag1'h89]FcHH(dƎ CTMfL*A&>A;M.pt,ŋgu<<`ؙS)$fL 3 cѪ#xnZQ Qb!f73dLΝ; cfh89](\V7 0U˯ 2 2f0t$hU&Ȍ Cd" 3D$33 G Zb)jJ̙3ѸpnZa,"b!c_ wȴкuAFh?J7-2D`!2€Ryu+!1EF-l9wn[׋AH! 3DF~硑g@3Qed{{Gj0+211%[do3)aHZd 2"cf #m9AƓ-2D c!2LZd312fξu-iqLT9Am{L"҃a>v6(Ȝ= cnZd 2ȸ3 iP)\AƼڵTE3 {dhL1'vv((ӵ^LJ0 Dne .ΰbc0Ș SUKpR]Kԯ 2CTEw[Z*#8Ș;; S LgwwO;A 1UAa!7D\\$d̉mT%)dرPguHDa@EA&?ݺ3g#++D! [dUi9}:Tqd̙JDD"̝A&'' gDw5'hٲ \\*Z:s& qqQq!WϫK$JvUd.f1/hժAW-1Y& ## 2fN-+{֒J7zw0Y"= F2$d 2& agVKmhZŔ 2ǿ CdAfQ%Âa3cgp%cdLl 47zZ"@ 3Ddrpqh`kko2h߀ sTqBm2Ȉx5Q1\ >>uӊԯ@ʈ^qDwٳdl`cctf S6 c } RE·@ޙJe @@R)Xyh4?[&Ȍ77T2"_ 3TDZH ERi!J%hT*h jZ)?Ÿqd hY=l1AFlmｇ(bhp\,Ξ=Vv]; 2Dրaj,YJFS`0B%`!LFGQ%CY2FcDΝ-'d!2 8E-2ѵTH%h7nHBvv6T*kӳVll ..g#S Hʈ:j[8sRV.##{UfJBZ%҇,Z sgVdP2".99YVd? 2@zFMDEE*3L"+n&rsx%iZdW\ffaڈKUƍ ac Y;-21P666hѢ+llTEm˙k]d3gȸݹjAq Y5k 2]c V`cJԩS͛wy+*h>3o3 3d%!77* ΰ$Lo VFD0CVpLG"Z=@.@"&nZQ Q0CVǚL)\{}˪ Hr2w.CLݴDʈH LV0XΝ} R`kF-6OZjZhl"$$/d\\j3`l!q7(]Ih4;OVy [[[hJ%QlcAԩúi..1n\j0 5-Dg7n4` QMƛɾHkj 2D0C/:z4|ˠjZ^ | YsWYYhؐA j&"..0f 0CD0DF 2DT =G5U"2C3Cյ%n#55jkރv4ʈȒ>3Dd2۶m[*]Y v3 IJȚ0ܾ}p%DdMfȢ1Ec!"*\ Y"2FU"& 3DDDdfȢ1ɤ Y4"""h 3Dd2  3CDՁa, Y4"2>5 LNNIJȚ0Ec!"""0CD&n&" 3Dd2LDՁa, Y4"2>΀  4IDՁa, Y4"2t•5a!"""0CDDDaLW3Qu`!"}f:0Ec!"""0CD&çfQu`!"899)\ Y"""h 3DdUT*T*'''# j{׫OFott4VSO~믿cǎPС;f6sss /͚5Î;[nE-`oo-[btjrZo-3=!!oyUׯW>HUNm'Nzj &M=*e/dƍ@^yZ-Ҿ}{9k, ӧFFF _=6l dذaeIKKvڕu2f̘ WߺDUŖ"2|}Uxzz.""gϞ|Prss#/^Ի͊%*zdLfrrr$''GcyYYY+̔o]vnZի'jZ7obcc# 6YTiFDDF!d@}228˫_,Y"ҪU+8p,[L/^ o]{WjGcvv[Ky5nX.͊>p+!-[ÇKbbARI&@w\EDV^ުzՖ_b/h%3CD&jAׯǦMzׯ <<п2H?ӧ\]]~ܸq>,`xDZ~4nX!W <.:tm۶vڕ٦,ںt'''ݻnLEԷ.=Q(DQ |.Q:u$ϟ׻$ݻKϞ=%))[dӦMҸqcqvv1cHNNԩSDKĜ9sVzZjjtQN8!""ҹsgN:ITTTgeHV^z!.\ѷ͊T"DTDDw O;DdLf"")\ Y"""h 3DDDdf$ J&"Yf$nݺpuuU"6 3DDDdfȢ1I0fMg'yJWbn`mZpsR+] btD #@Rҕ~$X-}ҥQ9fjcA|tDT@*0(z[J̓ @ =GK!J0@)|+1O*b׆uJBDLD5̎Gd4FǨބ ' a!A\+lU| <'`L`v4Z9 ]مn~h+V=mNL9[68"Nf"!'ϝ,$ZJp8p/14զ?6]ނAHjԟhصc7oa0u>< pu7hj[س3%"c}fjUW'v pppjn_;ׯ_b[dKiڃV: ;Ã>jn?3G݄-~UҖ΄33CdnfD`ix?yqÿ/ݽV[7NuWʝjӆ_0? NwԪWb-bS~f :x4Pޛx2'GjXnh[o@m{EoA0Cdfԧ灷ΖdkBϿ1e)@bݐ&' UhҤAh'3i* lH\18qe!2OLdލ\[<苧SRMO2>(]fᝡd (*w3 _Nz&LFcGDDO>;m۶EDDQj#T|Q->fA>p5@O :qu NW;^@NObu5\܀+mlZZ-pl5d(-;{)mrTcapt/// 6 AAA޽;T8hs0`<;wk׮FRRJ$83CdM2nk0dȐӚ’HشqnVr<!&:u~ڵA7SNwml^uw5}cװc#^k5~˯r s/1<`Ѹ/='Μ9P]qqqꫯW_ÇGpp0 ޾!$JC0n8š~X`F[vرXv-ڴi0<رcĉIdi2Cda*l)W~ƢEJL"/QNCtӣeַoLݛšFYoAo-1}雘#Sέ, ޸5\B \C"vZflUXP<ףCXv-BCCxe˖FPPZn]UUe]vXd 4h-ZnݺHII-j*"88?8~7ݶPV-߿Fq Y,c=HNNF@@j5zׯWn߾t Gmo/d| ~B\\͛6m1Z_xx8oߎgypy]+K۽{7\1c&"K0Co߾سg}mw}|rݻg6Rus-YO>$7o^8& ⤶Ck##m Z^RG/qܹƍ;N83gYf޽;.\q裏7ؔ1O#.К< ;yWЁHnդ%Ovv6lقu!<<yyy{{{ 0AAAxZK.̙3K"##!!! DXXBvʔ)X|9:t耰0 ""SNE||}dɒ o/}Scbb"/^۷#**J7h {{{(fN>5k`͚5%ck#Gȑ#K p Yx9vuʼ dZյ15oTJOO/ua׮](((PҸqcy7ĉz(M<1-V~yPԩ#ڷ[y5ɟׯˢEW^bcc֮][F-rm?ᐞ.= :T^Z[Cᥗ^gggUV7oӇ++׷z7nV f-ӳ]vr e18WDd̘1| >}|g֭+/ٳG4MRRRaÆ@>jWNN4mT_|Q2[,X ?p󨇇L.1JݺuV{Y Vn2e8::?, "RݻKϞ=%))ɨ5fgg˺u䩧]-NNN2bٴiuҳgO|oٲEH:u}?ZxyJF%22R외  3Zjiqtt,珙'ZVJ-(fJȮ]KZn-+т~z > fQ۷oҦM1b͛ џ}2۪qK?p@YlYӽ1ﱠ@WWWmmm'~A222LV/\\\ܹs&o`` &l%**JBBBYf%ι͚5R=wgBDBuLi>==Ji {PQnA-[ÇA%11,&MxZ]bzQ+*c,Ҋ/&b*^rvvV{h[[[9~x5W%ҥKG[[[1Jppl޼C6Qi 3DRxeɫ*%1<#31ƇrEw9u/ꫯ իhwo[^?M6bkk[RڢeƎ+WfvE$/[nRtܹS .1P+s̑-Zlٲ̝;Wc}(D]qs^*.==]:W^]b^cm۶ݻW(rVZKl^ŋ壏>N:xxyy/,/ (W\ҹs' ȑ#J("PN)^rrr2VX!@důD)}.]3gJǎK+󺜜tz٫9sH˖-K}||7ߴ+fꥥ/+1MƎ+5CmUxg}f22Vc믿^^Ѫ\j ;&o[ ̙#111JHtT"|}`ԨQxgp3ƇrC̶m0x`899ɓhѢE5L:/Fc,]3gDzz:.] 00aaaJަL˗C ݑǜ9s0w\%h4޽֭?T]"((Ç•ZijHJ`AF?~g/"um\.徉ΝCL|WK*GŚ5kWw BÆ \Đ0ի??ƣ3j )))1tP֫Jkokb˖-V=[[[u*\p! 7n\Q.^GaHMMVj{qq'aHΝ;5k`͚5Mo޼9F#GUV VhP/^SI&8s +?2̔/;;Ahh(o߮략ǀ0b 2< VO"5Z 9FgOܹ(4b ?!3ҥ7VӧO…3i 3.99Xv-"##uӽ1bK. VhzP޾};-{8FΝ;ĉ={6}]K _n:ڵ ''' <AAAf=HO6F#HL/1a掂|ŭ[i/l4 իJLg /Xf vF]6#G_~URdK8p={ZFLL 6mtIVvZj ߇C APP{1+\ 7o^|A  Lg#:]12pR.\-3aryyy(iƓO>iUW(xRDDE^x+WĐ!C/(]պ|2BCC#G{xxgň#`Q]p>$%WHLLKLg#&*]Qc3̔Ob޽+A@@J$www+4hv/VZ!##[nE``%Ys~O{iF0l0GQB0SIQ'No ˖-Cjj*:uO?.]ݻ1a#JMMĉϷ zwӧO ^Ӽys8uf͚ʕ+ѥKΟ?HL>5… cǎh߾=ϟs)].Yv3Uv3tuOXf :Çȑ#ѵkW%vލG}8{,5jtI5VQqhh(֯_7^cĈ1bDRIE~ Vdv]9v3)WNit|9JaVtW"ܹSw%J{ vvf2*iii4i^*o߾6lcݺuJTc}O>Xp!vڅkbƍ8r93fGƳ>+]ؠYJaܬa'a@~~>~WY6m]dooAaȑxy%BO˗/[nVսTڂ m6_D߾}.ƳO<'xؾ};֭[[b߾}طoM~!((CGyoEMɓ'O7z)[yyyŋ͛7#((AF!Xbb 2M4AHHq4E7|#駟puZ JŽ;0vXxyyaС Evv%c{z M6E޽7͛ر#>c\x{ɓ\^jٲU7x-ZSh"!=\]]1j(lٲXt)}Q`ƍ F-[*5* UIBB>t=>$&&!!!ɓ'1c 4iDr鎚ҽTZ]4g\fñvuń k.\|_|u[naڵxꩧРAL0n UƍXhzf͚+ၩSbp}o^rp,_NNNX|Uw/@᭷RoooL6  GSNHMMw}5+? f\YYYXf  ⥗^Ÿ 9[nիW_GL^ O/>Z?C)]___[8~8Μ99se˖v+1c?tǶm0j(x{{cԨQضmoWFrr2V^@>T?qKh3f̀W^=$,S֭1w\رc;'&&O??Zjs̙3JK&0SÉߏ^z 6fdggGqUlݺ#G%}^*m̙hҤ =NrH'ŋؿ?^~exyy!..C۶mѩS'|HHHP\F 35ԩSMW^Xhnܸ>НN ˥**޽u W,ggg,X0k,(\JB=_ʕ+عs'ƏwwwC=:?ĥKФI̘1'ODtt4f͚˥҆ }"%%gV&xǰl2₃W_Eƍѯ_?,[ 7oTd2+wM,YAtQQQ[.&O{ŋѱem*%koʼn'.|IY׮ IDAT]úu0tP?ĉ'|VBff%=bB999Xnz)x{{cʔ)طo͛7#99/F^`c×(^{5{6m`ڴih46m/A1bϸvVX@DuV+Tӧ+]Yzw}TRƌ_W^ŢEΝ;_ c„ ̛7K=z4zdJCf믿Ç#>>Gvp ,Y}E&M0}tDFF*].0c!._ ڵￏ .oǏxѬY3%+޽+]STꫯ`kk ٳJDfyGDGG#$$͚5Õ+W矣k׮xo#::Zrk<3vM,[ }|M8qB0ݻwҥKOѩS'%o^:u¤I_~YrȌo>Ο?HL>5… cǎh߾=ϟx˭fLNN~' 2 6ĉZÇcƍz*.]>}J.==Ǐg=zP^=ڵ aaaJCG?$&&bݘXx1^p=nnn8rx -Bjj%[5EFFW_EFO`ʕ@.]_ʕ+رcƌڵk+].K˗/g=4i:wDUNDUaoo;'''cÆ 6lj5ۇ^z _}L2ÌcΜ9hѢv튅 ڵkhժ͛x:tӦM咙JOOĉٽTLDDYRARlrr2Vѷo_PTOqyh0`j5;jNHTT40*ZVwQ*U+ *u VqֶgSh2U2YEQET@D! $HBK:s]>7}D:XvNj6?WWWL8ոx"R0dygsΝCeeZ/US߼y3BCC5%Ĕ1x;xZÒOBBD"),,T gժU8tp믪oiɸr JJJTXEEEkܻwo|kB*.\ѣGjw 3͂( 2nnnxxx`ի?1UÚ6ݻ￯]BL)1OkXRYv- [gH<111x Tt`rժU6lrrrcm9sݻwsN k׮EXN8͛7 v2MB2|7(..V}|ǏcժUE/^ģGT=y]t%3hx e)GyGqqZl%(ߋ#c uuuz籵U*H$UFu.""'x|8233 6 A멜F ]xmA4m߾6lnܸC"f$?c֬w8pssfe+0fBL;iƢE+1|k\GTUU B|ذa!uR^^^_uq1# Rde࣢ Ejɠ6kjjaee _Ft|0f$''+ L,66̓3޽B=J됕u R|ּ1gLuu-c$.h87HjzU0P0<2Օ|wKΟ?{B?>N>p$RWWhh:zB/DRӮprpuw-d,Ac!s99y2UHJj/w/m޼Yu01իWt`UϔNPTLxxX\86TV#772ٍ#lٲӧO6h>/CCetG~zb̘1㏹S߿?֯_/WƵkרhh)Y[@.GJ;UW7 33`YSQ/2qrIgI\.:dzBÃP_oɼ% 2\ۇt.\@TT^@q:$ҁeͽ[(tDTx #3O>32zQsɊ˻ Bs;;{DG“'LQm)S {U=htNUUU c 9^ ʕ$rOڬs,]xT?A^ h|G4QTGqq1_hfb"ܻw_+++.5EHJI#\OxEEQ\kvOզWT6eԨ!ps3ZW)( <|71{\c֖0:Z%${7 kB&k@JO%f2?|N/u@BY#r׹b0&@d&;H7I1SYi(",1H`ooH:A(rDycCi3\L:B=KN.ÆyG ## ɐwbqס\[(,iybB3ltҷo_:Aijg%\.rr2!b6(SHj![)rIJPJҥ8z4MmDӷeT̴_vk @ɅBE,BNNAhh{zS0zteV0ݯ˘<^2I!ĸ^}u("#oS=}!:iyMQ1  k!D\7^T̴}#8x#lmF_!0<5 u)--DEE)a+VD{!P12/_O(Ӳ€\a7ҡ42F)d*f:~c])Bجx,  'DbEZjC3<VVedr^XlBB,c<89gGrdf^C>z#$$BQἘХKXYY旝z ;]߾;S!C!f}|pJ+Eyy9ƌs]%4z!XC'B!ܒPbB׮ '\Ƥ=3 IB!3bMBܿդjX_6!6$j0 ׯ'AAڵ;!i0i!֘r&SQ7n$uتBq塼1aT*Ejj+1dd Hԏt2I1SP[X)rܾ n@j%ݻ\aB#** 0p#u8z)Lfy<T!8xcZ !?kk>|;0 kk>-[_:M$wWB߈ I/hEB!WUB!ӠbB!fB!5*f!b֨!BYbB!fB!5*f!b֨!BY₰0HgVq4cʔ)mxx{{={ް[B!-S{\.w}u۷ocm6Nڮo۶ HJJ¸qoFbb"ƍ@ܾ}Um7&B:3LVVVXd ѣJ;prrx 5 PPz*<==accHhi6l؀nݺgϞ i`ʔ)Ő!C6OXXbhܹs]Pk| vzz:$ l|ruѷ=M!qL==Z B\\.\_!!!jL>CZZV\ٳYYY())5kƏ9ΝCYY6nܨ3ئAӞ+WDBBN>,8'O+W}?;wt &S*bZ|kvLL B@ŋjӼ몿5߰k.={6~…i ӧ:ci)+q1ci_u|@iiv.^QF!00 'N`pssî] DJ.Tx?!ס.4e1O5qѷ=i JE]] ͇uLMc"#`)Hakqfkdǎؽ{7iӦ/Ā^xlڴIu{W_}| /_5k #Gbǎ3fZ=_a\.ܹsqy% V\Ǐv¬YT㣢{l_G[m;4Q̜O6 G 3%#!+Z0&Crr j1Ʀ 33UZuu-c$#GhvލuaHKKCll,/^""" H0sLOj$$$ ٺu+"##k=!;v@xx8\]]w^ڵ K, }m۶aժUǤIT뙒 UcӦM:ii{4;88Uqv\~ju \bT/Hjy|ptt[ozK5WV,Ϙ1;wH$Rc޽_y;pttĆ o>|WXh6l΃ne13aパ#G]oeĉQ]]6n ڵk48Cȑ#4h֛d_3*TJ.eP(8}ݸN..5&3߂#Gkjk LZ_~Cff>?3۠J$'C}}M7PD'OnijٲeFbb"|>Ə9s ..N>^z cǎEQVVquuuGCClmm! Q[[[aoo \^^^L:prrP(Ç1m4i͛G[`gggggbG/޽ :Wߑ#GÒ%K]m! %(rC&#SUUz)2 qqq;w. ;w`ܹXp!BBB .FP(.TBE?J.G,.Cn 2d2|?Ff<'üy]_UVW^>6|pܺu N‚555Zoi%q-a IDAT?'ܹCbѸvZyyy8p PYY5nL>*WHH$v yZP]]ݪb[ 1CP舨-&|ڜ\H땗?A^ (r࣏4e銋qE՝0W{ｇݻwcڴi8u.] //Ϡii~ȺutRl۶ vR=_y]/zbFcǎŭ[믿^{5 m͛~Ν)f[obp~\WRҙvEZZ=xн{w`ҤIv36nŗ_~nݺ_~ػw/~mמY3g6^7awm߾>,X &`/[nEAAoz f"OE uީSagG6UUuOHGE=3sIPMLVOGɄB!*f!b4!KѸ6!BD{OopB %bJbqrr ZPw6>Giy 3J.Ĕ^}u("#oS}!:iy 3J.ĔD"WDF_[HG !턒 4nnX"5LJ.TH׈YB%Ӱdz119:=/.1ftt* kP1C8GɅ)L:<;; Gcbq9@Ϟ>|2!BɅk桢0V( 8;w:B2/D f 1g(01+k,\1 !%b*I-߿uFP(pN&JKť7VS"(! %b*2Y 7pQ<~\[ڵ;BB"ԕ1:D: J.Ĕ߿ 0B, pvvAPPvuH3àBL(叹(R)RS!:bѳ1::D:J.TKQT++{vc iiɐ^!bTQr!tm=:  QQѧ@!d!BLښ>ߎ0ښe֡W1C^ Ced$\avv{ :BXTB!ĬLB1kTB!ĬQ1C!F !B3B1kTB!ĬQ1C!F !B3B1kTB!ĬQ1C!F !B3B1kTB,)Sz>}qEkۑH$ # sΩۦ^t;b(cq!eT5|1Wlm'22۶mCRRfϞѣGŋX &?٦3ƶ')!:)x<\\\Tj|ז^(XղB(999 ٰau놞={Ԙv uUxzz"jmM6 ƍ`ԨQ  U1vXx<ܾ}pmx<=ZmYǏ+&NjU!7oVkS}Tv"1Bt0\ξmܸLߋ."""ؔ)ST***СCݚoæ9r>|`~~~waݻ8͇7c,110EmXSc~~~ؔ_bXxx8c72ZGW^a"3b/H$-mSڷEtjTRR3lٲeё9::Hm&بQXvvFW\aC a֬wСCjӬ_uڕCGy[͇5WXX|}}g vڴWfj145h u]رà|}C[ܤx4o۳<6rH&XHH4/fԮj3[[[222ZU8mTv"/'ѩў={i&co&~0___ =ZkL9s0y[:z%榾 &0.]uH3D= ...?TnK.]0;;;6sL:Z3byOH|k1Z:z%F 0kkk6h ڗH@#BYB!ĬQ1C!F !B3B1kTB!ĬQ1C!E NIENDB`shorewall-docs-xml-5.0.15/images/network3.vdx0000644000000000000000000770147413020330134017601 0ustar rootroot networkteastepHewlett Packard Company738201805738201805 AQAAAIwAAAAAAAAAAAAAAHwAAAChAAAAAAAAAAAAAADKDAAAlRAAACBFTUYAAAEAHO8AAAMAAAABA AAADwAAAGwAAAAAAAAAAAUAAAAEAABSAQAADgEAAAAAAAAAAAAAAAAAAFAoBQCwHgQAVgBJAFMASQ BPAAAARAByAGEAdwBpAG4AZwAAAAAAAABMAAAAfO4AAAAAAAAAAAAAfAAAAKEAAAAAAAAAAAAAAH0 AAACiAAAAIADMAAAAAAAAAAAAAACAPwAAAAAAAAAAAACAPwAAAAAAAAAA////AAAAAABkAAAAKAAA AIwAAADw7QAAKAAAAH0AAACiAAAAAQAYAAAAAADw7QAAAAAAAAAAAAAAAAAAAAAAAP/////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// //////////////////////////wD///////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////8A////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////////////////////////////AP/////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////wD//////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////////////////////8A////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////AP////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////wD//////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////8A//////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// //////////////////AP///////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////wD////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////8A//////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////AP//////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////////////wD////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////8A/////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////AP//////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////wD///////////////////////8AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD// /////////8A////////////////////////AAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP 8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8 AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8A AP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAAAA AAAAP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP //AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP/ /AP//AP//AP//AP//AP//AP//AP//AP//AAAA////////////AP///////////////////////wAA AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/A AD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AA D/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD /AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAAAAAAAAAD//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wAAAP ///////////wD///////////////////////8AAAAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wA A/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA /wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/ wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAAA AAAAAA//8AAAAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wA A/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAAAAA//8A//8A//8A//8A//8A//8A//8A//8A//8A //8A//8A//8A//8A//8A//8A//8A//8A//8AAAD///////////8A////////////////////////A AAAAP8AAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAP8AAP8AAP8AAP8AAP 8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8 AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8A AP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAAAAAAAAP//AAAAAP8AAP8AAP8AAP8AAP8AAP8AA P8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAA AAAP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AAA A////////////AP///////////////////////wAAAAD/AAD/AAD/AAAAAAD/AAAAAAD/AAAAAAD/ AAAAAAD/AAAAAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/A AD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AA D/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAA AAAAAAAD//wAAAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAAAAAD/AAAA AAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD//wD//wD//wAAAAD//wAAAAD//wAAAAD// wAAAAD//wAAAAD//wAAAAD//wD//wD//wD//wAAAP///////////wD/////////////////////// 8AAAAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wA A/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA /wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAAAAA/wAAAAAA/wAAAAAA/wAAAAAA/wAAAAAA/wAA/ wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAAAAAAAAA//8AAAAA/wAA/wAA/wAA/wAA/wAA/w AA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAAAAA/wAAAAAA/wAAAAAA/wAAAAAA/wAAAAAA/wAA/wA AAAAA//8A//8AAAAA//8AAAAA//8AAAAA//8AAAAA//8AAAAA//8AAAAA//8AAAAA//8A//8A//8A AAD///////////8A////////////////////////AAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAA P8AAAAAAP8AAAAAAP8AAAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAAAAP8AAAAAAP8AAA AAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8 AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8A AAAAAAAAAP//AAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAAAAP8AA AAAAP8AAAAAAP8A AAAAAP8AAAAAAP8AAAAAAP8AAAAAAP//AP//AP//AAAAAP//AAAAAP//AAAAAP//AAAAAP//AAAAA P//AAAAAP//AP//AP//AP//AAAA////////////AP///////////////////////wAAAAAAAAD/AA AAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAD/AAD/AAD/AAD/AAD/AAD /AAD/AAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAD/AAD/AAD/ AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/A AD/AAD/AAD/AAD/AAD/AAD/AAAAAAAAAAD//wAAAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AA D/AAD/AAD/AAD/AAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAD/AAAAAAD//wD//wD //wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wAAAP////////// /wD///////////////////////8AAAAA/wAAAAAA/wAAAAAA/wAAAAAA/wAAAAAA/wAAAAAA/wAAA AAA/wAAAAAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/w AA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAAAAA/wAAAAAA/wAAAAAA/wAAAAAA/wAAAAA A/wAAAAAA/wAAAAAA/wAAAAAA/wAAAAAA/wAAAAAA/wAA/wAA/wAA/wAA/wAA/wAAAAAAAAAA//8A AAAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/ wAA/wAA/wAA/wAA/wAA/wAA/wAAAAAA//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A// 8A//8A//8A//8A//8A//8A//8AAAD///////////8A////////////////////////AAAAAP8AAP8 AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8A AP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AA P8AAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP 8AAAAAAP8AAP8AAP8AAP8AAP8AAAAAAAAAAP//AAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8 AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAAAAP8AAAAAAP8AAAAAAP8AAP8AAP8AAP8AAAAAAP//AP// AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AAAA///////// ///AP///////////////////////wAAAAD/AAD/AAD/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD /AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAAA AAD/AAAAAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAAAAAAAAAD// wAAAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAAAAA D/AAAAAAD/AAD/AAD/AAD/AAD/AAAAAAD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD //wD//wD//wD//wD//wD//wD//wAAAP///////////wD///////////////////////8AAAAA/wAA /wAA/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAA/wAA/wAA/wAA/wAA/wAA/ wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/w AA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAAAAA/wAAAAAA/wAA/wAA/wAA/wAA/wAA/wA A/wAA/wAA/wAA/wAA/wAA/wAA/wAAAAAAAAAA//8AAAAA/wAA/wAA/wAA/wAAAAAA/wAAAAAA/wAA AAAA/wAAAAAA/wAAAAAA/wAA/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAA/wAAAAAA//8A/ /8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8AAAD/////// ////8A////////////////////////AAAAAP8AAP8AAP8AAP8AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAP8AAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAP8A AP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAP8AAP8AAP8AAP8AAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAAAAAAAAP //AAAAAP8AAP8AAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAP8AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP// AP//AP//AP//AP//AP//AP//AP//AAAA////////////AP///////////////////////wAAAAD/A AD/AAD/AAD/AAD/AAD/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAAAAD/AAAAAAD/AA AAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAD/AAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD /AAAAAAD/AAD/AAD/AAD/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/ AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAAAAAAAAAD//wAAAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/A AD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAAAAD//w D//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wAAAP///// //////wD///////////////////////8AAAAA/wAA/wAA/wAA/wAA/wAA/wAAAAAAAAD/Tk7/Tk7/ Tk7/Tk7/Tk7/Tk4AAAAAAAAA/wAA/wAA/wAAAAAA/wAAAAAA/wAAAAAA/wAA/wAA/wAA/wAA/wAA/ wAA/wAA/wAA/wAAAAAA/wAAAAAA/wAAAAAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAAADAwMDAwMDAwM AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAAAAAAAA A//8AAAAA/wAA/wAA/wAAAAAA/wAAAAAA/wAAAAAA/wAAAAAA/wAAAAAA/wAAAAAA/wAA/wAA/wAA /wAAAAD/c3P/c3P/c3P/WVkAAAAAAAAAAAAA//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A/ /8A//8A//8A//8A AAAA//8A//8A//8AAAD///////////8A////////////////////////AAAAAP8AAP8AAP8AAP8AA P8AAP8AAP8AAAAA/3Z2/3Z2/3Z2/3Z2/2Ji/05O/zs7AAAAAP8AAP8AAP8AAP8AAAAAAP8AAAAAAP 8AAAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAAAAP8AAAAAAP8AAP8AAP8AAP8AAP8AAP8 AAP8AAP8AAAAAwMDAwMDAwMDAAP8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAP8AAP8AAP8A AP8AAP8AAP8AAP8AAAAAAAAAAP//AAAAAP8AAP8AAP8AAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAA P8AAAAAAP8AAP8AAP8AAP8AAP8AAAAAAAAA/5mZ/3Nz/1lZ/0BAAAAAAAAAAP//AP//AP//AP//AP //AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AAAA////////////AP///// //////////////////wAAAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAAAAAAAAP+np/+Tk/+AgP9iYv9O Tv87OwAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAD/AAD/AAD/AAD/AAD/AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAD/AAD/AAD/AAD/AAD/AAD/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAAAAAAAAAD//wAAAAD/AAD /AAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAD/AAD/AAD/AAD/AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD// wD//wD//wD//wD//wAAAP///////////wD///////////////////////8AAAAA/wAA/wAA/wAA/w AA/wAA/wAA/wAA/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAA/wAA/wAA/wAA/wAA/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAA /wAA/wAA/wAA/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAA/wAA/wAA/ wAA/wAA/wAA/wAA/wAAAAAAAAAA//8AAAAA/wAA/wAAAAAA/wAAAAAA/wAAAAAA/wAAAAAA/wAAAA AA/wAAAAAA/wAAAAAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAAAAA/wAA/wAAAAAA//8A//8A//8A//8 A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8AAAD///////////8A//// ////////////////////AAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAP8AAP8AAP8AAP8AAA AAwMDAAP8AAAAAAAAAAAAAAAAAAAAAAAAAAP8AAP8AAP8AAP8AAP8AAAAAwMDAq6ursbGxu7u7AAA AzMzM1dXVwMDAAAAAAAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAAAAAAAAP//AAAAAP8A AP8AAP8AAP8AAP8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AA P8AAAAAAAAAAP8AAP8AAAAAAP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP //AP//AP//AP//AP//AAAA////////////AP///////////////////////wAAAAD/AAD/AAD/AAD /AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAAAAAD/AAD/AAD/AAD/AAD/AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAD/AAD/AAD/AAD/AAD/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/A AD/AAD/AAD/AAD/AAAAAMDAwP+trf+trf+trf+trf+trf+hocDAwAAAAAAAAAD/AAD/AAD/AAD/AA D/AAD/AAD/AAD/AAD/AAAAAAAAAAD//wAAAAD/AAD/AAD/AAD/AAD/AAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAAAAAAAAAD/AAD/AAAAAAD//wD//wD//wD/ /wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wAAAP///////////wD// /////////////////////8AAAAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAAA AA/wAA/wAA/wAA/wAA/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAA/wAA/wAA/wAA/wA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAA/wAA/wAA/wAA/wAAAADAwMD/v7//v7//v7// v7//ra3/oaHAwMAAAAAAAAAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAAAAAAAAA//8AAAAA/ wAA/wAA/wAA/wAA/wAA/wAA/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAA/wAA/wAA/wAA/wAA/w AA/wAAAAAA/wAA/wAA/wAAAAAA//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8 A//8A//8A//8A//8A//8AAAD///////////8A////////////////////////AAAAAP8AAP8AAP8A AP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAAAAP8AAP8AAP8AAP8AAP8AAP8AAAAAAP//AAD/A AAAAAAAAAAAAAAAAAAAAP8AAP8AAP8AAP8AAP8AAAAAp6en/7a2/7a2/7a2/6CgAAAAAAAAAP8AAP 8AAP8AAP8AAP8AAP8AAAAAwMDA/9bW/9bW/9DQ/7+//62t/6GhwMDAAAAAAAAAAP8AAP8AAP8AAP8 AAP8AAP8AAP8AAP8AAP8AAAAAAAAAAP//AAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAAAAAAA/1lZ /1lZ/1lZ/01NAAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAAAAP8AAP8AAP8AAAAAAP//AP//AP//A P//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AAAA////////////AP ///////////////////////wAAAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAA AAAD/AAD/AAD/AAD/AAD/AAD/AAAAAPz8/Pr6+gAAAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/ AAAAAKenp//MzP/MzP+2tv+goAAAAAAAAAD/AAD/AAD/AAD/AAD/AAD/AAAAAMDAwP/o6P/c3P/Q0 P+/v/+trf+hocDAwAAAAAAAAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAAAAAAAAAD//wAAAA D/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAAAAP+Zmf+MjP9zc/9NTQAAAAAAAAD/AAD/AAD/AAD/AAD /AAD/AAAAAAD/AAD/AAD/AAAAAAD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD/ /wD//wD//wD//wD//wD//wAAAP///////////wD///////////////////////8AAAAA/wAA/wAA/ wAA/wAA/wAA/wAA /wAA/wAA/wAA/wAA/wAA/wAAAAAA/wAA/wAA/wAA/wAA/wAA/wAAAAAAAAAAAAAAAAAA/wAA/wAA/ wAA/wAA/wAA/wAA/wAA/wAA/wAAAACnp6f/2tr/zMz/trb/oKAAAAAAAAAA/wAA/wAA/wAA/wAA/w AA/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAA/wAA/wAA/wAA/wAA/wAA/wA A/wAA/wAAAAAAAAAA//8AAAAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA/wAA/wAA/wAA/wAA/wAA/wAAAAAA/wAA/wAA/wAAAAAA//8A//8A//8A//8A//8A//8A/ /8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8AAAD///////////8A////////////// //////////AAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAAAAP8AAP8AAP8 AAP8AAP8AAP8AAP8AAP8AAP8AAAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAAA5ubm5ubm5ubmAAAA5ubm5ubm5 ubmAAAAAAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAAAAAAAAP//AAAAAP8AAP8AAP8AAP 8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAAAAAAAAP8 AAP8AAP8AAAAAAP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP// AP//AP//AAAA////////////AP///////////////////////wAAAAD/AAD/AAD/AAD/AAD/AAD/A AD/AAD/AAD/AAD/AAD/AAD/AAAAAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAAAAAD/AAD/AA D/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAAAAAAAAAAAAAAAAAAAAAAAAAD/AAD/AAD/AAD/AAD /AAD/AAD/AAD/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAD/AAD/AAD/AAD/AAD/AAD/ AAD/AAD/AAAAAAAAAAD//wAAAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAAAA AD/AAD/AAD/AAD/AAD/AAD/AAD/AAAAAAAAAAD/AAAAAAD/AAAAAAD//wD//wD//wD//wD//wD//w D//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wAAAP///////////wD//////////// ///////////8AAAAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAAAAA/wAA/wAA /wAA/wAA/wAA/wAA/wAA/wAA/wAAAAAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/ wAA/wAAAAAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAAAAA/wAA/w AA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAAAAAAAAA//8AAAAA/wAA/wAA/wA A/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAAAAA/wAA/wAA/wAA/wAA/wAA/wAAAAAAAAAA AAAAAAAA/wAAAAAA//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A/ /8A//8A//8AAAD///////////8A////////////////////////AAAAAP8AAP8AAP8AAP8AAP8AAP 8AAP8AAP8AAP8AAP8AAP8AAP8AAAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAAAAP8AAP8 AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8A AP8AAP8AAP8AAP8AAP8AAP8AAP8AAAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AA P8AAP8AAP8AAAAAAAAAAP//AAAAAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAP 8AAAAAAAAAAP8AAP8AAP8AAP8AAP8AAAAA////////AAAAAP8AAAAAAP//AP//AP//AP//AP//AP/ /AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AAAA////////////AP////////// /////////////wAAAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAAAAAD/AAD/A AD/AAD/AAD/AAD/AAD/AAD/AAD/AAAAAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AA D/AAD/AAAAAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAAAAAD/AAD /AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAAAAAAAAAD//wAAAAD/AAAAAAD/ AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAD/AAAAAAD/AAD/AAAAAAD/AAD/AAAAAAAAA AAAAAAAAAD/AAAAAAD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//w D//wD//wD//wAAAP///////////wD///////////////////////8AAAAA/wAA/wAA/wAA/wAA/wA A/wAA/wAA/wAA/wAA/wAA/wAA/wAAAAAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAAAAA/wAA /wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAAAAA/wAA/wAA/wAA/wAA/wAA/wAA/ wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAAAAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/w AA/wAA/wAA/wAAAAAAAAAA//8AAAAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wA A/wAA/wAAAAAAAAAAAAAAAAAA/wAA/wAAAAAA/wAAAAAAAAAA/wAAAAAA//8A//8A//8A//8A//8A //8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8AAAD///////////8A///////// ///////////////AAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAAAAP8AAP 8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8 AAP8AAP8AAAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAAAAP8A AP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAAAAAAAAP//AAAAAP8AAP8AA P8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAAAAAAA////AAAAAP8AAP8AAP 8AAAAAAAAAAP8AAAAAAP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP/ /AP//AP//AP//AAAA////////////AP///////////////////////wAAAAD/AAD/AAD/AAD/AAD/ AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAAAAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAAAAAD/A AD/AAD/AAD/AAD/ AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAAAAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/A AD/AAAAAAD/AAAAAAAAAAAAAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AA AAAAAAAAD//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//wD//wD//wD//wD//wD//wD//wD//wD/ /wD//wD//wD//wD//wD//wD//wD//wD//wD//wAAAP///////////wD////////////////////// /8AAAAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAAAAA/wAA/wAA/wAA/wAA/w AA/wAA/wAA/wAA/wAAAAAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAAAA A/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAAAAA/wAAAAAA/wAA/wAA/wAA/wAA /wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAAAAAAAAA//8A//8A//8A//8A//8A//8A//8A/ /8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8AAAAAAAAAAAAAAAAA//8A//8AAAAA//8A// 8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8 AAAD///////////8A////////////////////////AAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8A AP8AAP8AAP8AAP8AAAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAAAAP8AAP8AAP8AAP8AA P8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAAAAP8AAP8AAP8AAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAP8AAP8AAP8AAP8 AAAAAAAAAAP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP// AP//AAAAAP//AAAAAAAAAAAAAP//AAAAAP//AAAAAP//AAAAAP//AP//AP//AP//AP//AP//AP//A P//AP//AP//AP//AP//AP//AP//AP//AP//AP//AAAA////////////AP//////////////////// ///wAAAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAAAAAD/AAD/AAD/AAD/AAD /AAD/AAD/AAD/AAD/AAAAAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAAA AAD/AAD/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAD/AAD/AAD/AAD/AAAAAAAAAAD//wD//wD//wD//wD//wD//wD//w D//wD//wD//wD//wD//wD//wD//wD//wD//wD//wAAAAD//wAAAAD//wAAAAAAAAAAAAAAAAAAAAD //wAAAAD//wAAAAD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD/ /wAAAP///////////wD///////////////////////8AAAAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/ wAA/wAA/wAA/wAA/wAAAAAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAAAAA/wAA/wAA/wAA/w AA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAAAAA/wAA/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACampoAAAAA/wAA/wAA /wAAAAAAAAAA//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A/ /8A//8A//8A//8A//8A//8AAAAA//8AAAAA//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A// 8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8AAAD///////////8A/////////////////// /////AAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAAAAP8AAP8AAP8AAP8A AP8AAP8AAP8AAP8AAP8AAAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AA AAAAP8AAP8AAAAAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM DAwMDAwMDAwMDAwMDAAAAAmpqampqaAAAAAP8AAP8AAAAAAAAAAP//AP//AP//AP//AP//AP//AP/ /AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AAAAAP//AAAAAP//AAAAAAAAAAAAAAAAAAAA AP//AAAAAP//AAAAAP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//A P//AAAA////////////AP///////////////////////wAAAAD/AAD/AAD/AAD/AAD/AAD/AAD/AA D/AAD/AAD/AAD/AAD/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDAwMDAwMDAwMDAwMDAwMDA wMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwAAAAJqampqamgAAAAD/A AD/AAAAAAAAAAD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//w D//wD//wAAAAD//wAAAAD//wAAAAAAAAAAAAD//wAAAAD//wAAAAD//wD//wD//wD//wD//wD//wD //wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wAAAP///////////wD///////////////// //////8AAAAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/ wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/w AA/wAA/wAA/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAACampqampoAAAAA/wAA/wAAAAAAAAAA//8A//8A//8A//8A//8A//8A //8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAA//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A// 8A//8AAAD///////////8A////////////////////////AAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8 AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8A AP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAAA5ubm5ubm5ubm5ubm5 ubm5ubm5ubm5ubm 5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubmmpqaAAAAAP8AAP8AAAAAAAAAA P//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AAAAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAmpqaAAAAAP//AP//AP//AP//AP//AP//AP//AP//AP/ /AP//AP//AP//AP//AP//AP//AP//AAAA////////////AP///////////////////////wAAAAD/ AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/A AD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AA D/AAD/AAAAAObm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5gAAAObm5ubm5ubm5ubm5ubm5ubm5ub m5ubm5ubm5ubm5ubm5gAAAAD/AAD/AAAAAAAAAAD//wD//wD//wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJqam gAAAAD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wAAAP//// ///////wD///////////////////////8AAAAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wA A/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA /wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAA/wAAAAAAAA AA//8A//8A//8AAAAA//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8AAAD m5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5uYAAAAA//8A//8A//8A//8A//8A//8A//8A//8A //8A//8A//8A//8A//8A//8A//8A//8AAAD///////////8A////////////////////////AAAAA P8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP 8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8 AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAAAAP8AAP8AAP8AAP8AAP8AAP8A AP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAAAAAAAAP//AP//AP//AAAAAP//AP//AP//AP//AP//A P//AP//AP//AP//AP//AP//AP//AP//AP//AP//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AAAA/// /////////AP///////////////////////wAAAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/ AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/A AD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AA D/AAD/AAD/AAAAAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////wD///////////////////////8AAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAD/////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// //////////8A///////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////AAAA//////////////////////////////////////////////////////////// ////////////////AAAA///////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////AP///////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////wAAAP///wAAAP///wAAAP///w AAAP///wAAAP///wAAAP///wAAAP///wAAAP///////////////////wAAAP///////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////////////wD/////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////8AAAD///8AAAD/ //8AAAD///8AAAAAAAD////////////////////////////////////////////////////////// /////////8AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAD///////////8A/////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////AAAA////AAAA////AAAA////AAAA////////////////////////////////// //////////////////////////////////AAAAAAD/AAAAAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD /AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/ AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAAA////////////A P//////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////wAAAP////////// /wAAAP///////////////////////////////////////////////////////////////////wAAA AAA/wAAAAAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/w AA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wA A/wAA/wAA/wAA/wAA/wAA/wAAAP///////////wD///////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////////////////////8AAADm5uYAAAD///////8AAAD//////////////////////////////// ///////////////////////////////////8AAAAAAP8AAAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8A AP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AA P8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAD/////////// 8A/////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////AAAA5ubmzc3NAAAAA AAAAAAA////////////////////////////////////////////////////////////////////AA AAAAD/AAAAAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD /AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAA AAD/AAD/AAD/AAD/AAD/AAD/AAAA////////////AP/////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// //////////////////////wAAAObm5s3Nzc3NzQAAAP////////////////////////////////// /////////////////////////////////////wAAAAAA/wAAAAAA/wAA/wAA/wAAAAAA/wAAAAAA/ wAAAAAA/wAAAAAA/wAAAAAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/w AA/wAAAP///////////////wAAAP///////////wAAAAAA/wAA/wAA/wAA/wAA/wAAAP///////// //wD///////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////8AAADm5ubNzc3Nzc 3Nzc0AAAD///////8AAAD///8AAAD///8AAAD///8AAAD///8AAAD///8AAAD///8AAAD///////8 AAAAAAP8AAAAAAP8AAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAP8AAP8A AP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAD////////////////////////////////// /////8AAAAAAP8AAP8AAP8AAP8AAAD///////////8A////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////////////////////////AAAA5ubmzc3Nzc3Nzc3Nzc3NAAAAAAAA////AAAA////AAAA////A AAA////AAAA////AAAA////AAAA////////////AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAA D/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAAAAAA A////////////////////////////////////////////////AAAAAAAAAAD/AAD/AAAA//////// ////AP/////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////wAAAObm5s3Nzc3 NzQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA/wAA/wAAAAAA/wAAAAAA/wAAAAAA/wAAAAAA/wAAAAAA/wAAAAAA/wAA/wAA/ wAA/wAA/wAA/wAA /wAA/wAA/wAA/wAA/wAAAP///////////wAAAP///wAAAP///wAAAP///wAAAP///wAAAP/////// wAAAAAA/wAA/wAAAP///////////wD/////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// //////////8AAAAAAAAAAADNzc3Nzc3Nzc0AAAD////////////////////////////////////// /////////////////////////8AAAAAAP8AAP8AAP8AAP8AAP8AAP8AAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP////////////////////8 AAAD///8AAAD///8AAAD///8AAAD///////////////8AAAAAAP8AAAD///////////8A//////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////AAAAAAAAAAAAAAAAzc3Nzc3NAAA A////////////////////////////////////////////////////////////////AAAAAAD/AAD/ AAD/AAD/AAD/AAAAwMDAgIAAgIAAgIAAgIAAgIAAgIAAAAAAAAAAAAD/AAD/AAD/AAD/AAD/AAD/A AD/AAD/AAD/AAD/AAD/////////////////AAAA////AAAA////AAAA////AAAA////AAAA////// //////AAAAAAD/AAAA////////////AP///////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////////////////wAAAObm5gAAAAAAAM3NzQAAAP//////////////////////////////////// ///////////////////////////wAAAAAA/wAA/wAA/wAA/wAA/wAAAObm5tDQANDQANDQANDQAND QANDQAAAAAJqamgAAAAAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA//////////////////// /////////////////////////////////////////////wAAAAAA/wAAAP///////////wD////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////8AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADm5uaampoAAAAAAP8AAP8AAP8AAP 8AAP8AAP8AAP8AAP8AAP8AAAD//////////////////////////////////////////////////// ///8AAAAAAP8AAP8AAAD///////////8A//////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// //////////////////////////AAAA5ubmAAAAAAAA/////////////////////////////////// /////////////////////////////AAAAAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAAA5ubm5ubm5ubm 5ubm5ubm5ubm5ubm5ubmAAAAAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAAAAAAA///// ///////////////////////////////////AAAAAAAAAAD/AAD/AAD/AAAA////////////AP//// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////wAAAAAAA AAAAP///////////////////////////////////////////////////////////////wAAAAAA/w AA/wAA/wAA/wAA/wAA/wAA/wAA/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAA/wAA/wA A/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAAP///////////////////////////////////////wAA AAAA/wAA/wAA/wAA/wAAAP///////////wD////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////////8AAAD ///8AAAD///8AAAD///8AAAD///8AAAD///8AAAD///8AAAD///8AAAD///////////////////// //////////////////////////////8AAAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AA P8AAP8AAP8AAP8AAP8AAP8AAAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAA AAAAD///////8AAAAAAAD///////8AAAAAAAAAAP8AAP8AAP8AAP8AAP8AAAD///////////8A/// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////AAAA////AAAA////AAAA////AAAA////AAAA// //AAAA////AAAA////AAAA////////////////////////////////////////////////AAAAAAD /AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAAAAAD/AAD/AAD/ AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAAAAAD/AAD/AAD/AAD/A AD/AAD/AAD/AAD/ AAD/AAAA////////////AP/////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////////wAAAAAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/ wAA/wAA/wAAAAAAAAAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/w AAAAAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAAP///////////wD//////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////////////////8AAAD///8AAAD///8AAAD///8AAAD///8AAAD///8AAAD///8AAA D///8AAAD///////////////////////////////////////////////8AAAAAAP8AAP8AAP8AAP8 AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAAAAP8AAP8AAP8AAP8AAP8A AP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AA P8AAP8AAAD///////////8A////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////AAAAAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AA D/AAD/AAD/AAD/AAAAAAD/AAAAAAAAAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAA AAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAAA////////////AP////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////wAAAP///wAAAP///wAAAP///wAAAP///wAAAP///wAAAP///wA AAP///wAAAP///////////////////////////////////////////////wAAAAAA/wAA/wAA/wAA /wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAAAAAAP///wAAAAAA/wAA/ wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAAAAAAAAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/w AA/wAA/wAAAP///////////wD//////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////8AAAD///8AAAD// /8AAAD///8AAAD///8AAAD///8AAAD///8AAAD///8AAAD/////////////////////////////// ////////////////////8AAAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8 AAP8AAP8AAAAAAP8AAAAAAAAAAAAAAAAAAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAAAAAAAA AAAAAAAAAAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAD///////////8A///////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////////////////////AAAA////AAAA////AAAA////AAAA////AAAA////AAAA//// AAAA////AAAA////////////////////////////////////////////////AAAAAAD/AAD/AAD/A AD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAAAAAD/AAAAAAAAAAAAAAAAAA AAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAA////////AAAAAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD /AAD/AAD/AAAA////////////AP////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////wAAAP///wAAAP ///wAAAP///wAAAP///wAAAP///wAAAP///wAAAP///wAAAP///////////////////////////// //////////////////////wAAAAAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA /wAA/wAA/wAA/wAA/wAA/wAAAAAA/wAAAAAAAAAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAAAAAAAAAA AAAAAAAAAAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAAP///////////wD/////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// //////////////////////////////8AAAD///8AAAD///8AAAD///8AAAD///8AAAD///8AAAD// /8AAAD///8AAAD///////////////////////////////////////////////8AAAAAAP8AAP8AAP 8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAAAAP8AAAAAAAA AAAAAAP8AAAAAAP8AAAAAAP8AAP8AAP8AAP8AAAAAAAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8A AP8AAP8AAP8AAAD///////////8A///////////////////////////////////////////////// /////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////AAAA////AAAA////AAAA////AA AA////AAAA////AAAA////AAAA////AAAA/////////////////////////////////////////// /////////AAAAAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/ AAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAD/AAD/AAAAAAD/AAD/AAD/A AD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAAA////////////AP//////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////wAAAAAA/wAA/wAA/wAA/wAA/wAA/w AA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAA/wAAAAAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA AP///////////wD////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// //////////8AAAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AA P8AAACysrK9vb3Hx8fm5uaampqampqamprm5ubGxsa8vLyxsbEAAAAAAAAAAAAAAP8AAP8AAP8AAP 8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAD///////////8A/////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////AAAAAAD/AAD/AAD/AAD/AAD/AAD /AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAAAAAAAvb29x8fHAP8AAP8AAP8AAP8AAP8A xsbGvLy8sbGxAAAAmpqaAAAAAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/A AAA////////////AP//////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////////////wAAAAAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/w AA/wAAAAAAAAAAAAAAAAAAAObm5ubm5ubm5gAAAAAAAAAAAAAAAAAAAJqamgAAAAAA/wAA/wAA/wA A/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAAP///////////wD///////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////8AAAAAAP8AAP8AAP8AAP8AAP8A AP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAADm5ubm5ubm5ubm5ubm5ubm5ubm5 ubm5ubm5ubm5ubm5ubm5uYAAAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP 8AAAD///////////8A/////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// //////////////AAAAAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD /AAD/AAD/AAD/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAD/AAD/AAD/ AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAAA////////////AP/////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////wAAAAAA/wAA/wAA/wAA/wAA/ wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/w AA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wA A/wAAAP///////////wD///////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// 8AAAAAAP8AAP8AAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAP8AAP8AAP8 AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8A AP8AAP8AAP8AAP8AAP8AAP8AAP8AAAD///////////8A///////////////////////////////// ///////////////////////////////////////////////////////////////////AAAA////AA AA////AAAA////AAAA////AAAA////AAAA/////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////AAAAAAD/AAD/AAD/AAD/AAAAAAD/AAAAAAD/A AAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AA D/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAAA/////// /////AP////////////////////////////////////////////////////////////////////// /////////////////////////wAAAP///wAAAP///wAAAP///wAAAP///wAAAP///wAAAP/////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// //wAAAAAA/wAA/wAA/wAAAAAA/wAAAAAA/wAAAAAA/wAAAAAA/wAAAAAA/wAAAAAA/wAA/wAA/wAA /wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/ wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAAP///////////wD/////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////8AAAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP 8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8 AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAD///// //////8A///////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////AAAAAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/A AD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AA D/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAAA////////////AP///////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP/// ////////wD/////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////8A//////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// //////////AP///////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// //////////////////////////////////wD///////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////////8A// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////////////////////////////////////AP/////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////wD ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////////////////////////////8A////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// AP/////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////wD//////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /8A////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// //////////////////////////AP///////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////wD////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////8A//////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////AP//////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////////////////////wD////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////8A/////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////AP//////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////wD///// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////// ///////////////////////////////////////////////////////////////////////////// /////////////////8A////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////AP////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////wD//////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////8A///////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////////////AP////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////wD/////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// //////////////////////8A///////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////AP///////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////// /////////wD////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////8A/////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////AP//////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////wD///////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////////////8A/////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////AP/////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// //////////////wD///////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////8A////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////////////////AP/////////////////////////////////////////////////////////// /////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////wD/////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// //8A///////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////AP///////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////wD/////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////8A//////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// //////AP///////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////wD////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////8A//////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////////////////////////////////AP/////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////wD//// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////////////////////////8A////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////////AP// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////wD//////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////8A/ ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////////////////////////////AP////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////////////w D//////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////8A//////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////AP//////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////////////////wD////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////8A/////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////AP//////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////wD///////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////////////////////////////8A/////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////AA4AAAAUA AAAAAAAABAAAAAUAAAA2002-08-11T08:58:322006-03-10T08:54:342006-03-10T08:54:242002-08-11T08:58:32113910000011100.010102000201010100000000010000100.500000000000000000000000000000000000103310000032320088000010.50.500001201100000000000000000000000010000.1250.1250.250.250.3750.3750.1250.1250.666666666666670.66666666666667000000.250.250.250.25111100001170000000000000400010.1666666666666667000000000000-11033000-1.2001000-10011100.010002000201000100000000010000000.500000-1.2000000-10011100.0100020002010001000000000111100.055555555555555550.055555555555555550.055555555555555550.05555555555555555100.5000423020002010001000000000111100.055555555555555550.0555555555555555500200.500010000000000000010331111000000000000440010.125000000000000-110330.003333333333333301020002010101000000000111100.055555555555555550.055555555555555550.055555555555555550.05555555555555555100.500400010.1111111111111111000000000000-110330.0101020002010000.00333333333333330102000201000001010000000001010000100.055555555555555550.055555555555555550.055555555555555550.05555555555555555120.5000.01110200020100000100.055555555555555550.055555555555555550.055555555555555550.05555555555555555100.500400010.1388888888888889000000000000-11033000-1.2001000-10000100.055555555555555550.055555555555555550.055555555555555550.05555555555555555000.500400010.1388888888888889000000000000-11033000-1.2000000-10000100.055555555555555550.055555555555555550.055555555555555550.05555555555555555000.500400010.1388888888888889000000000000-11033000-1.2001000-10000100.055555555555555550.055555555555555550.055555555555555550.05555555555555555100.5002300010.1388888888888889000000000000-11033000-1.2001000-10000100.055555555555555550.055555555555555550.055555555555555550.05555555555555555000.5002300010.1388888888888889000000000000-11033000-1.2001000-10000100.055555555555555550.055555555555555550.055555555555555550.05555555555555555000.5002300010.1388888888888889000000000000-11033000-1.2000000-1000.00333333333333333301020002011100.055555555555555550.055555555555555550.055555555555555550.05555555555555555120.500400010.11111111111111000000000000-110330.003333333333333301020002011100.055555555555555550.055555555555555550.055555555555555550.05555555555555555100.500400010.1111111111111111000000000000-11033000-1.2001000-1000.010102000200110100000000011111400010.1666666666666667000000000000-110330.010102000201010100000000011110400010.1111111111111111000000000000-11033000-1.2001000-1000.010102000201010100000000011111400010.1666666666666667000000000000-110331815101000000000111100.0033333333333333010200020141510100000000011110400010.1111111111111111000000000000-11033000-1.2001000-100151101000000000111100.0033333333333333310200120315101000000000111100.0101020002001101000000000100100.027777777777777780.027777777777777780.027777777777777780.02777777777777778100.500400010.1111111111111111000000000000-11033000-1.2001000-1000.0016666666666666670102000201518101000000000111102014101000000000111100.00333333333333330002000201#8a8aff3101000000000111102000121033Visio Network Solutions
http://officupdate.com/visio/
000